사이트맵 중복 재제출 차단으로 리소스 낭비 방지

Google Search Console(이하 GSC)에 사이트맵을 등록하는 작업은 검색 인덱싱 파이프라인에서 기본이다. 그런데 우리 시스템에서 자동으로 사이트맵이 계속 반복적으로 재제출되는 현상을 발견했다. 한 번 등록되면 Google이 알아서 주기적으로 크롤링하기 때문에, 같은 사이트맵을 자꾸만 다시 보내는 건 불필요한 API 호출만 증가시킨다. _lib/gsc_submit.py에 제출 차단 로직을 추가해서 이 문제를 차단했다.

왜 중복 제출이 문제인가

이커머스나 미디어 플랫폼처럼 동적 콘텐츠가 계속 변하는 서비스라면, 정기적으로 사이트맵을 업데이트하고 Google에 알려야 한다. 맞다. 하지만 "정기적"과 "매번"은 다르다. 내 경험상 중복 제출 문제는 보통 다음 중 하나에서 비롯된다:

• 배포 파이프라인에서 매번 제출: 배포할 때마다 사이트맵 생성 → 자동 제출 로직이 트리거되는 경우. 하루에 여러 번 배포하면 같은 사이트맵이 5-10번 제출될 수 있다.
• 모니터링/헬스체크 로직의 과다 호출: 사이트맵 상태를 확인하다가 "아, 없네?" 하고 다시 제출하는 방식의 코드.
• 주기적 크론잡의 중복 실행: 스케줄러에서 설정 실수로 같은 작업이 여러 번 돈다거나 로직이 멱등하지 않은 경우.

Google GSC API의 할당량은 서비스 규모와 무관하게 제한되어 있다. 불필요한 요청이 쌓이면 정말로 필요한 순간에 제출이 막힐 수 있다. 또한 Google 입장에서도 반복되는 요청은 일종의 노이즈다. 최악의 경우 리소스 낭비로 이어질 수 있다.

수정 사항과 의도

_lib/gsc_submit.py는 우리 시스템에서 GSC와 통신하는 진입점 역할을 한다. 여기에 제출 차단 로직을 넣었다는 건, 단순한 기술 수정이 아니라 "누가, 언제, 몇 번 제출했는가"를 의식적으로 관리한다는 뜻이다.

일반적인 구현 패턴은 다음과 같다:

• 마지막 제출 시각 기록: 메타데이터나 캐시에 최종 제출 시간을 저장
• 일정 시간(예: 24시간) 내 중복 제출 방지: 최근에 제출했으면 스킵
• 사이트맵 변경 감지: 실제로 내용이 변했을 때만 제출
• 제출 횟수 제한: 하루 최대 N번이라는 상한선 설정

어떤 방식을 선택했든, 핵심은 의도적인 제어다. 자동화는 편하지만, 자동화된 시스템이 통제되지 않은 채 반복 실행되는 건 위험하다.

팀 관점에서의 배운 점

이런 종류의 수정이 흥미로운 이유는, 단순 버그 수정과 다르기 때문이다. 명확한 "에러"가 아닌 것 — 사이트맵 제출은 "작동"하니까. 다만 비효율적이고 리소스를 낭비한다.

코드 리뷰할 때도 이런 케이스가 까다로운 이유가 여기다. "제출 차단"이라는 조건문을 봐야 하는데, "왜 여기서 막지? 혹시 제출이 안 될 수도 있지 않나?" 같은 의심이 생긴다. 그래서 커밋 메시지가 명확해야 한다. 왜 이 블록을 넣었는가를 알아야, 리뷰어가 "맞다, 이게 필요하다"는 확신을 가질 수 있다.

또한 이런 작업은 모니터링과 함께 가야 한다. "제출을 차단한다"는 건 시스템 동작을 제한하는 것인데, 실제로 필요한 제출은 여전히 이루어져야 한다. 차단되는 요청이 정상인지, 정말 불필요한 건지 추적할 방법도 있으면 좋다.

비슷한 케이스들

같은 방식으로 생각할 수 있는 다른 상황들:

이런 패턴들은 모두 "자동화를 신뢰하되, 제어하라"는 같은 원칙에서 나온다.

결국 이번 수정의 핵심은 기술이라기보다 설계 철학이었다. 시스템이 자동으로 뭔가를 반복할 때, 그 반복이 정말 필요한지 한 번씩 물어봐야 한다는 거다.

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

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

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