동적 사이트맵으로 포스트 색인 누락 문제 해결

블로그 사이트의 사이트맵을 정적 XML에서 동적 생성 방식으로 전환했다. 그 과정에서 카테고리 구조도 정규화하고, 화면 레이아웃도 개선했던 작업인데, 이번 글에서는 왜 이런 변경이 필요했는지, 팀 입장에서는 어떤 이점이 있는지 풀어보려 한다.

정적 사이트맵의 숨겨진 비용

블로그 운영 초기에는 sitemap.xml을 손으로 작성하거나 빌드 타임에 정적으로 생성하는 방식이 자주 쓰인다. 간단하고, 배포 후 변경될 일도 없다고 생각하기 쉽다. 하지만 몇 가지 문제가 발생한다.

첫째, 새 포스트를 올릴 때마다 사이트맵을 갱신해야 한다. 포스트를 작성하고 배포했는데 사이트맵이 자동으로 업데이트되지 않으면, 검색 엔진이 새 페이지를 발견하는 데 지연이 생긴다. 물론 XML 사이트맵이 없어도 크롤러는 홈 페이지부터 링크를 따라가며 발견하겠지만, 명시적 사이트맵이 있으면 색인 처리가 훨씬 빠르다.

둘째, 개발자 이외의 팀원들(예: 콘텐츠 담당자)이 사이트맵을 신경 쓰지 않기 쉽다. 누군가는 포스트를 올렸는데 사이트맵은 깜빡한다. 이런 상황이 반복되면, 사이트맵에 포함된 포스트 목록이 실제 포스트 목록과 점점 어긋난다.

셋째, 배포 프로세스가 한 단계 더 복잡해진다. 포스트를 추가할 때마다 사이트맵도 함께 수정하고 커밋해야 한다면, 사람은 실수하기 마련이다.

이번 작업에서 이런 문제들을 해결하기로 했다.

동적 생성으로 사이트맵 자동화

변경 파일 중 src/pages/sitemap-index.xml.ts가 핵심이다. Astro의 동적 라우팅 방식을 활용하면, 빌드 타임(또는 요청 타임)에 사이트맵을 자동 생성할 수 있다. 포스트 목록을 스캔하고, 모든 포스트 페이지와 카테고리 페이지를 XML에 포함시킨다.

이렇게 하면:

src/lib/categories.ts가 함께 변경된 이유는, 사이트맵에 포함될 카테고리 목록을 단일 소스 오브 트루스(Single Source of Truth) 로 만들기 위해서다. 이전에는 카테고리가 여러 파일에 산재되어 있었을 가능성이 높다. 이를 정규화하면 코드 일관성도 높아지고, 사이트맵 생성 로직도 간단해진다.

예를 들어 카테고리를 추가할 때:
- 이전: categories.ts 업데이트 + sitemap.xml 수작업 수정 + 다른 여러 파일 동기화
- 이후: categories.ts 한 곳만 수정 → 사이트맵 자동 생성 + 다른 부분도 자동 반영

레이아웃 개선과 함께 진행한 이유

변경 파일에 public/styles.css와 astro.config.mjs가 포함된 이유는 이 작업이 단순히 사이트맵 "기술적 고정"이 아니라 사용자 경험을 함께 개선하는 기회였기 때문이다.

"wider width"는 블로그 본문이나 카테고리 목록의 가독성을 높이는 것을 의미한다. 여러 모바일 기기와 데스크톱을 지원할 때, 텍스트 행 길이(line length)가 너무 좁으면 읽기가 피곤하다. 너무 넓으면 눈을 옮기는 거리가 길어진다. 적절한 폭을 찾아 CSS를 조정하는 것은 간단해 보이지만, 실제로는 여러 기기에서 테스트하고 반응형 디자인을 고려해야 한다.

이런 식으로 여러 개선 사항을 한 커밋에 담는 것을 보면, 팀 내에서 "이 주제 영역 작업을 할 때는 관련 부분도 함께 보자"라는 의식이 있었던 것 같다. 사이트맵을 다루려면 정보 아키텍처(카테고리, URL 구조)도 살피고, 그럼 UI도 한번 점검해보는 식이다.

검색 엔진 최적화와 팀 협업

이번 변경의 가장 큰 이점은 검색 엔진 최적화(SEO) 측면이다. 모든 포스트가 명시적 사이트맵에 포함되므로, Google이나 다른 검색 엔진이 새 콘텐츠를 빠르게 발견하고 색인화한다. 특히 블로그 사이트에서는 이것이 트래픽에 직결된다.

또한 팀 협업 측면에서도 개선된다. 콘텐츠 담당자가 포스트를 올릴 때 "사이트맵도 수정해야 한다"는 생각을 할 필요가 없다. 개발팀은 배포 후 사이트맵 누락을 확인하는 추가 체크리스트 항목도 제거할 수 있다. 이런 자동화는 작은 것처럼 보이지만, 반복되면 상당한 시간과 집중력을 절약해준다.

동적 생성 방식은 또 다른 이점도 있다. 나중에 포스트에 메타데이터(최종 수정 날짜, 우선순위 등)를 추가하려 할 때, 사이트맵 생성 로직을 쉽게 확장할 수 있다. 정적 XML을 손으로 유지보수하는 방식보다는 코드로 다루는 것이 훨씬 유연하다.

마무리

이 작업을 통해 다시 한번 느낀 점은, 작은 수작업을 자동화하는 것의 중요성이다. 사이트맵 같은 부분은 전체 시스템에서 보면 아주 작은 부분이지만, 누군가는 계속 신경을 써야 한다. 그런 반복 작업을 없애거나 줄이면, 팀은 더 중요한 기능 개발과 콘텐츠 작성에 집중할 수 있다. 더불어 카테고리 정규화, 레이아웃 개선처럼 연쇄적으로 개선되는 부분들도 생긴다. 한 곳을 정리하면 전체 코드베이스가 조금씩 좋아지는 경험이다.

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

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

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