장례 콘텐츠 10편 backfill 배치 편입 작업 회고

콘텐츠 backfill 배치 작업을 처음으로 마무리했다. funeral 카테고리 10개 포스트를 한 번에 밀어 넣은 작업인데, 단순한 글 추가처럼 보여도 배치 단위로 콘텐츠를 관리하는 방식에 대해 다시 생각하게 된 커밋이었다.

왜 backfill 배치인가

실제로 글 작성과 배포 타이밍이 항상 일치하진 않는다. 초안이 완성된 시점과 실제로 사이트에 올리는 시점 사이에 간격이 생기기 마련이고, 그 간격이 쌓이면 "언제 어떤 글이 실제로 어떤 상태였는가"를 추적하기가 애매해진다. 이번 backfill은 이미 작성된 포스트들을 실제 작성 일자 기준으로 slug에 날짜를 박아서 콘텐츠 저장소에 정식 편입시킨 작업이다.

커밋 메시지에서도 의도적으로 etiquette(4) + money(3) + procedure(3) = 10으로 카운팅해서 명시했는데, 이건 리뷰어나 미래의 내가 "이 배치에 뭐가 들어갔는지"를 커밋 로그만 봐도 파악할 수 있게 하려는 의도였다. 배치 작업일수록 커밋 메시지가 인덱스 역할을 해야 한다고 생각하는 편이다.

편입된 파일들

변경 파일에 올라온 것만 6개인데, 커밋 메시지 기준으로는 10개다. 나머지 4개는 아마 별도 경로에 있거나 이전 커밋과 분산된 것으로 보인다. 이런 상황 자체가 backfill 작업의 특성 중 하나다 — 파일이 한 곳에 몰려 있지 않고 여기저기 흩어져 있어서, 작업자가 명시적으로 "이 배치에 이만큼 들어갔다"고 선언하지 않으면 전체 그림을 잃기 쉽다.

콘텐츠 backfill 작업에서 주의할 것들

이런 류의 배치 편입 작업을 할 때 매번 확인하는 체크리스트가 있다.

• 날짜 슬러그 일관성: 파일명의 날짜가 frontmatter의 date 필드와 일치하는지. 빌드 타임에 둘 중 하나만 참조하는 경우 불일치가 생겨도 드러나지 않는다.
• 카테고리 필드 정합성: etiquette, money, procedure 같은 카테고리 값이 사이트의 분류 체계와 맞는지. 오타 하나가 해당 글을 카테고리 목록에서 누락시킨다.
• 중복 slug 방지: 날짜 기반 slug가 충돌하면 정적 사이트 빌더에 따라 에러가 아니라 조용히 덮어쓰는 경우가 있다. 배치 단위로 추가할 때 특히 확인이 필요하다.
• backfill 표시 여부: 독자가 "이 글이 언제 발행된 건가"를 오해하지 않도록 frontmatter에 backfilled: true 같은 플래그를 달아두는 방식도 팀마다 다르게 운용한다.

# frontmatter 예시
---
title: "부의금 봉투 쓰는 법"
date: 2026-01-18
category: money
tags: [부의금, 봉투, 장례]
backfilled: true
---

마지막 backfilled 플래그는 이번에 실제로 적용한 건 아니지만, 콘텐츠가 쌓일수록 이런 메타 정보가 나중에 꽤 유용하게 쓰인다. 특히 SEO나 sitemap 우선순위 조정 시 "오래된 backfill 글"과 "최근 발행 글"을 구분해서 처리하고 싶을 때.

배치 1이라는 네이밍

커밋 메시지에 batch 1이라고 붙인 건, 후속 backfill이 더 있다는 뜻이다. batch 2, batch 3으로 이어질 예정이고, 각 배치가 독립적으로 추적 가능하도록 네이밍을 통일해두는 게 나중에 git log --grep으로 찾을 때 훨씬 편하다.

git log --oneline --grep="backfill batch"
# feat(funeral): backfill batch 1 — etiquette(4) + money(3) + procedure(3) = 10 posts

팀에서 콘텐츠 관리를 코드 저장소로 하는 경우, 이런 검색 가능한 커밋 컨벤션이 작은 것 같아도 장기적으로 꽤 큰 차이를 만든다. 커밋이 곧 변경 이력이고, 이력이 곧 문서다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.