개발 slecs

검색 노출 누수 막은 사이트맵 정정, 고아버그는 기록하다

목차

이번 주 문서 정정은 작아 보였지만 꽤 중요한 작업들이었다. blindboxdex 의 GSC 사이트맵을 손본 것과 3dex 의 고아버그를 기록한 일인데, 둘 다 "크리티컬 버그는 아니지만 방치하면 팀 전체에 누적되는 작은 부채"를 처리하는 것이었다.

사이트맵 정정: 보이지 않는 곳에서의 영향

blindboxdex 의 /sitemap.xml 이 왜 정정 대상이었는지부터 풀어야 한다. Google Search Console(GSC) 에서 보는 사이트맵은 단순한 URL 나열이 아니다. 크롤러가 우리 사이트를 얼마나 효율적으로 탐색할지, 어떤 페이지가 우선순위인지를 직접 알려주는 신호다. 여기에 오류가 있으면:

  • 색인 누수: 중요 페이지가 크롤링 큐에서 밀려난다
  • 갱신 지연: 신규 콘텐츠 반영 속도가 느려진다
  • 프로토콜 오류: lastmod 또는 priority 태그가 잘못되면 크롤러가 혼동한다

실제로 운영자 입장에서는 이런 문제가 "왜 검색 노출이 안 되지?" 하는 미스터리로 남아 있을 수 있다. 구글의 알고리즘 변경 탓이라고 생각하기 쉽지만, 근처에 더 단순한 원인이 있을 때가 많다. 이번 정정이 그 중 하나였다.

고아버그를 기록한다는 것

"고아버그"는 좀 특이한 카테고리다. 보통 버그 트래킹 시스템에서는 open / closed / resolved 같은 상태만 본다. 그런데 3dex 에서는 몇 가지 이슈가 있는데:

  • 재현 불가: 예전에 신고된 것 같은데 지금은 못 본다
  • 환경 의존성: 특정 설정에서만 나타나던 게 이제 그 환경이 없다
  • 수정 여부 불명: 지금 코드에서 관련 로직을 건드린 게 이 버그를 의도치 않게 고쳤을 수도 있다

이런 게 코드 어딘가에 있으면:

상태 문제점 팀에 미치는 영향
기록 안 함 팀원이 같은 증상 만난 후 중복 신고 시간 낭비, 혼란
Closed 로 표시 누군가 왜 닫혔는지 궁금해함 의사결정 근거 불명
"고아" 상태로 문서화 알려진 미해결, 방치 중임이 명확 투명성 + 나중 재검토 근거

이번 작업에서는 3dex 의 그런 케이스들을 docs/sites-detail.md 에 정리했다. 단순히 "버그 있음" 이 아니라 "언제 신고됐고, 왜 미해결이고, 재현해본 시점은 언제인가" 까지다.

문서의 신뢰도와 운영 책임

좀 더 팀 레벨에서 생각해보면, 문서는 단순 기록이 아니라 의사결정의 증거다. 신규 팀원이 들어와서 "이 버그는 왜 있어?" 물었을 때:

  • "모르겠음" → 신뢰 하락, 다시 파보게 됨
  • "있는데 중요도 낮음" → 근거 없어 보임, 의심
  • "2023년 신고, 재현했을 때 단계 X에서만 발생, 우선순위 8번 대기" → 명확, 신뢰도 높음

사이트맵도 마찬가지다. "사이트맵 정정됨" 이라는 기록이 있으면:

blindboxdex: /sitemap.xml 정정 (2026-06-22)
- 개선: GSC 색인 큐 정상화
- 영향: 신규 페이지 크롤링 지연 해소

다음 누군가가 "GSC 노출이 이상한데" 하면 이 기록이 문맥을 제공한다. 근거 있는 대화가 가능해진다.

작은 정정들의 누적

이 작업들이 단순해 보이는 이유는 코드 변경이 없기 때문이다. 하지만 운영 관점에서는 이런 문서 정정이:

  • 검색 노출 복구로 이어지고
  • 팀원의 의사소통 비용을 줄이고
  • 나중의 큰 인프라 작업(예: 사이트 마이그레이션)의 기초가 된다

결국 개발만큼 운영도, 문서만큼 신뢰성도 중요하다는 걸 다시 느낀 정정이었다.


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

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

댓글 0

첫 댓글 달아줘.