자동화 slecs

사이트맵 최신 발행일 자동 동기화로 SEO 크롤링 개선

목차

처음엔 별거 아닌 것처럼 보였다. 블로그 피드 생성 스크립트가 RSS와 sitemap을 만들 때, sitemap의 <lastmod> 타임스탐프를 최신 글의 발행 날짜로 자동 갱신하는 기능 추가였거든. 근데 이 작은 변경이 지금까지 왜 미루고 있었는지, 또 어떤 이유로 이제야 우선순위를 올렸는지 되짚어보면 꽤 타당한 배경이 있다.

SEO 신호와 메타데이터의 동기화

블로그를 운영하면서 피드와 sitemap이 따로 놀고 있었다. 신규 글이 올라올 때마다 RSS 피드는 즉시 반영되지만, Google Search Console이나 Bing이 보는 sitemap의 lastmod는 수동으로 또는 불규칙하게 갱신되거나 아예 방치되곤 했다.

검색 엔진 크롤러 입장에선 이게 문제가 된다. <lastmod> 타임스탐프는 "이 페이지가 언제 마지막으로 변경되었나"를 알려주는 신호인데, 이 값이 오래된 채로 놔두면:

  • 크롤러가 변경 빈도를 잘못 추정 (계속 업데이트되는 사이트인데 6개월 전 날짜면 비활성 사이트로 인식)
  • 우선순위 재계산에서 밀림 (최근 변경된 콘텐츠를 더 우대하는 알고리즘 기준)
  • 갱신 주기 최적화 실패 (필요한 만큼 자주 크롤링 안 함)

어? 그럼 왜 지금까지 자동화 안 했는데? 솔직하게 말하면, 초기엔 "시스템 동작하고 있으니 괜찮겠지" 했다. 그런데 글이 쌓이면서 "피드는 있는데 sitemap이랑 누락되면?" 시나리오가 계속 떠올랐다.

스크립트 한 곳에서 진실 유지하기

scripts/gen_blog_feed.py는 이미 블로그의 메타데이터 진실 공급원(single source of truth) 역할을 하고 있었다. 이 스크립트가 markdown 파일들을 읽어서 파싱하고, RSS feed와 sitemap XML을 생성한다. 그런데 sitemap의 lastmod는 생성 시각을 쓰거나 손수 고쳐야 했다.

더 나은 방식:

방식 장점 문제점
생성 시각(now) 사용 간단함 글을 수정 안 했는데도 매번 갱신됨 (불필요한 크롤링 유발)
파일 mtime 사용 실제 변경 감지 빌드 시스템에 따라 부정확할 수 있음
피드 최신 글 날짜 논리적으로 정확함 스크립트가 한 가지 일을 더 해야 함
수동 갱신 없음 빠뜨림, 휴먼 에러, 운영 비용 증가

이번 작업은 세 번째 방식을 택했다. 피드에서 추출한 최신 발행 날짜(published 또는 date)를 sitemap의 <lastmod>로 쓰는 거다. 이게 논리적으로도, SEO 관점에서도 가장 정확하다. 블로그 포스트의 "실제 변경된 시점"이니까.

자동화의 연쇄 효과

이런 작은 자동화가 중요한 이유는 실행 일관성 때문이다.

# 예시: 피드 파싱 → lastmod 추출 → sitemap 갱신
latest_date = max([post.get('published') for post in feed_posts])
update_sitemap_lastmod(latest_date)

매뉴얼 프로세스면 이렇게 되었을 것:
1. 글 발행 → 피드 재생성 (자동)
2. sitemap 갱신 → PR 올림 (수동, 종종 빠짐)
3. 통상 1-2주 늦음 → 그 사이 검색 결과 반영 안 됨

자동화하면:
1. 글 발행 → 배포 파이프라인 → 피드 + sitemap 동시 갱신 (자동)
2. 불일치 불가능

팀 입장에선 이게 얼마나 큰 차이인지 잘 안다. 과거에 메타데이터 불일치로 "왜 새 글이 검색에 안 나와?"라는 문의가 몇 번 있었고, 매번 sitemap을 수동 점검하고 갱신해야 했다.

비슷한 패턴, 다른 메타데이터

이 작업을 하면서 든 생각은, 블로그뿐 아니라 다른 시스템에서도 같은 원리를 적용할 수 있다는 것:

  • 제품 카탈로그: 상품 업데이트 → 상품 피드 갱신 → 마켓플레이스 동기화 metadata도 자동 최신화
  • API 문서: 스펙 변경 → OpenAPI JSON 생성 → docs sitemap 재생성
  • 이벤트 플랫폼: 행사 수정 → iCal feed → calendar service 메타데이터 갱신

정리하면, 피드와 메타데이터는 함께 움직여야 한다는 원칙이다. 하나만 갱신되고 다른 하나가 도마 위에 놔두면, 결국 누군가 일을 만들고, 결국 자동화 필요성을 다시 깨닫게 된다.

마무리

작은 기능 추가지만, 이번 작업을 통해 다시 한 번 확인한 건: 지속 가능한 시스템은 자동화에 있다는 것. 운영 리스크를 줄이고, 팀의 인지 부하를 낮추는 가장 효과적인 방법이다. 특히 이런 "메타데이터 동기화" 류 작업은 처음엔 사소해 보이지만, 시간이 지나면서 드러나는 문제들이 많다.

앞으로 블로그 갱신 파이프라인을 보면서도, 비슷하게 "수동으로 누군가 해줘야 하는 부분"이 남아 있는지 계속 점검해야겠다. 이런 자동화들이 쌓여서 결국 팀의 신뢰성이 높아지니까.


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

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

댓글 0

첫 댓글 달아줘.