1. 문제의 발단: ‘최근 업데이트’ 섹션
‘소개(About)’ 페이지에 하드코딩으로 ‘연혁(History)‘을 만들었다. 그런데 이 중 5개만 ‘홈(Index)’ 페이지에도 “최근 업데이트”로 보여주고 싶어졌다.
여기서 문제가 발생했다. about.astro와 index.astro 두 파일에 데이터를 복사/붙여넣기 하면, 나중에 연혁을 추가할 때마다 두 파일을 모두 수정해야 했다.
데이터를 한 곳에서 관리해야 할 필요성이 명확해졌다.
2. 두 가지 선택지
Gemini와 함께 두 가지 방식을 비교했다.
- MD 콘텐츠 컬렉션 (현재 블로그 방식):
src/content/history/폴더에1.md,2.md처럼 연혁 1건당 1파일로 관리. - 단일 JSON 파일 (새로운 방식):
src/data/history.json파일 하나에 모든 연혁을 배열(array)로 저장.
직관적으로는 연혁 데이터가 간단하니, JSON 파일 하나로 관리하는 것이 더 깔끔해 보였다. 하지만 Astro 환경에서는 이것이 최선이 아니었다.
3. 왜 MD 컬렉션이 더 나은 선택인가?
JSON 방식은 Astro의 강력한 기능 두 가지를 포기해야 했다.
핵심 1: 데이터 검증 (Type Safety)
Astro의 콘텐츠 컬렉션(src/content/config.ts)은 ‘데이터 경찰’처럼 작동한다.
- MD 컬렉션:
config.ts에pubDate: z.date()라고 정의해두면, 내가 새 연혁 파일을 추가할 때pubDate를 빠뜨리거나 오타를 내면 Astro가 빌드를 중단시키고 오류를 알려준다. - JSON 파일: Astro는
history.json의 내용이 올바른지 전혀 검사하지 않는다.pubDate를pbuDate라고 오타를 내도 빌드는 성공하고, 사이트에서는 날짜 정렬이 깨지는 등 찾기 힘든 버그가 발생한다.
핵심 2: 자동 타입 변환
- MD 컬렉션:
z.date()설정 덕분에, Astro는 “2025-11-14”라는 문자열을 실제 JavaScript 날짜(Date) 객체로 자동으로 변환해 준다. 덕분에b.data.pubDate.valueOf() - a.data.pubDate.valueOf()같은 코드로 정렬이 즉시 가능했다. - JSON 파일: JSON에서 불러온 날짜는 그냥 문자열이다. 이 데이터를 사용하려면
new Date(entry.pubDate)처럼 내가 직접 날짜 객체로 변환하는 코드를 매번 작성해야 한다.
4. 결론
“1 항목 = 1 파일” 방식이 처음엔 번거로워 보였지만, 데이터의 무결성을 보장하고 자동 타입 변환까지 해주는 ‘MD 콘텐츠 컬렉션’ 방식이 장기적으로 훨씬 더 안전하고 전문적인 방법이라는 것을 깨달았다.