같은 결함을 왜 한쪽만 고쳤을까 - 사이트맵 lastmod와 실험 중 개입

같은 결함을 두 사이트에서 찾았는데 한 곳만 고쳤습니다. 사이트맵의 lastmod가 콘텐츠가 바뀐 시각이 아니라 데이터베이스 배치가 돈 시각을 담고 있었습니다. 저희 회사 사이트는 바로 고쳐 고유 lastmod가 21개에서 86개로 늘었고, 직접 운영하는 피부과 정보 사이트는 고치지 않고 14일 관측을 먼저 붙였습니다. 그쪽에서 무작위 대조 실험이 돌고 있기 때문입니다(2026-08-11 기준).

무엇이 잘못돼 있었나?

사이트맵의 lastmod는 "이 페이지가 마지막으로 바뀐 시각"을 알리는 값입니다. 두 사이트 모두 그 자리에 데이터베이스 쓰기 시각이 들어가 있었습니다.

저희 회사 사이트에서는 89개 항목 중 고유값이 31개뿐이었고, 41개가 2026-08-06T02:13:11.569Z로 밀리초까지 똑같았습니다. 사람이 41개 글을 같은 밀리초에 고칠 수는 없습니다. 글을 일괄로 반영한 시각이 그대로 나간 것입니다.

피부과 정보 사이트는 규모가 커서 더 뚜렷했습니다. 사이트맵 3,584개 전부가 최근 8일 안의 값을 달고 있었고 고유값은 6개였습니다. 원인은 조건 없는 갱신 트리거입니다. 값이 하나도 바뀌지 않아도 UPDATE 문이 닿기만 하면 갱신 시각이 밀립니다. 부기 목적으로만 컬럼을 쓰는 배치 3종이 매주 전건을 훑으면서 그 값을 밀고 있었습니다.

가장 많이 기여한 것은 짐작과 달랐습니다. 공공데이터 동기화(1,280곳)가 아니라 평점 동기화가 2,111곳으로 58.9%였습니다.

왜 문제가 되나?

공공데이터 동기화는 스스로 변경 여부를 세고 있습니다. 어느 주에는 17,820곳 중 17,792곳이 무변경(99.84%)이었습니다. 무엇이 바뀌었는지 이미 아는데, 그 뒤에 전건의 부기 컬럼을 갱신하면서 트리거가 그 구분을 지워버립니다.

그 결과 사이트맵이 매주 "3,584개가 전부 지난 일주일 안에 수정됐다"고 반복해 신고합니다. 검색엔진은 lastmod가 일관되게 정확하지 않다고 판단하면 그 값을 통째로 무시합니다. 신호를 주는 것이 아니라 신호를 버리게 만드는 상태였습니다.

회사 사이트는 왜 바로 고쳤나?

실험이 걸려 있지 않아서입니다. 같은 시각을 여럿이 공유하면 배치 쓰기로 보고 발행 시각으로 되돌리도록 바꿨습니다. 결과는 고유 lastmod 21개 → 86개, 같은 시각을 공유하던 페이지 60개 → 3개입니다. 남은 3개는 실제로 같은 시각에 발행한 글입니다.

배경도 있습니다. 같은 시점 색인 현황이 색인 65 / 미색인 68로 48.9%였고, 미색인 68건 중 42건이 "발견됨 - 현재 색인이 생성되지 않음", 즉 주소는 아는데 크롤조차 하지 않은 상태였습니다.

다만 이 결함 때문에 42건이 안 잡혔다고 말하지는 않겠습니다. 신생 도메인의 크롤 예산이나 외부 링크 부족이 더 클 수 있습니다. 지금 확정된 것은 "고칠 수 있는 결함이 있었고 고쳤다"까지이고, 효과는 다음 색인 보고서로 확인할 일입니다.

피부과 사이트는 왜 그대로 두었나?

그 사이트에서는 병원 1,991곳을 네 군으로 나눈 무작위 대조 실험이 돌고 있습니다(2026-08-10 시작, 10-05 종료). 실험 중에 다른 것을 바꾸면 공동개입이 됩니다.

따져보면 교환 구조가 나쁩니다. 고쳐서 얻는 것은 검색 크롤러와 색인 쪽인데, 잃을 위험은 AI 봇 방문 수 - 바로 이 실험의 결과변수입니다. 측정하지 않는 지표를 얻자고 측정하는 지표에 위험을 거는 셈입니다.

편향이 생기는 것은 아닙니다. 수정은 군과 무관하게 전 페이지에 걸리므로 무작위 배정이 흡수합니다. 문제는 검정력입니다. "매주 수정됨" 신호가 사라져 크롤 총량이 줄면 관측치가 줄고, 결과변수가 횟수인 실험에서 관측치가 줄면 검정력이 떨어집니다.

그럼 무엇을 근거로 정하나?

핵심 미지수는 하나입니다. AI 크롤러가 사이트맵의 lastmod를 읽는가. lastmod를 스케줄링에 쓴다고 문서로 밝힌 곳은 검색엔진이고, AI 크롤러가 그러는지는 확인된 바가 없습니다.

로그로 답하려 했지만 불가능했습니다. 사이트맵과 robots.txt 요청을 애초에 기록하지 않고 있었습니다. 조회 결과 0건은 "아무도 안 읽었다"가 아니라 "우리가 안 남겼다"였습니다.

그래서 고치는 대신 관측만 붙였습니다. 전용 테이블을 새로 만들어 기존 집계에 섞이지 않게 했고, 미들웨어는 기록만 하고 응답은 바꾸지 않습니다. 그리고 판정 기준을 관측이 시작되기 전에 공개 커밋했습니다 - 결과를 보고 기준을 정하면 그건 사후 합리화입니다.

기준은 이렇습니다. 판정일은 2026-08-25. 적격 4봇의 사이트맵 요청이 0건이면 수정을 진행하고, 1건이라도 있으면 10-05까지 동결합니다. 판정에 쓰는 SQL도 미리 고정했습니다.

거짓 0건을 막는 장치도 숫자로 박아뒀습니다. 같은 창에서 그 4봇의 robots·llms 요청이 10건 미만이면 관측 실패로 보고 창을 연장합니다. 근거는 그 4봇이 직전 14일에 이 사이트에 60,945건을 요청했다는 사실입니다. 그만큼 크롤하면서 메타 파일을 열 번도 안 가져가는 것은 크롤러의 행동이 아니라 기록이 죽었다는 뜻으로 보는 편이 타당합니다.

이 판단을 어디까지 믿어야 하나?

이 검정은 한쪽으로만 결론이 납니다. "0건"은 위험이 없다는 뜻이지만, "1건 이상"은 가져갔다는 사실일 뿐 lastmod를 스케줄링에 쓴다는 증명이 아닙니다. 그래서 1건 이상일 때의 행동을 "추가 조사"가 아니라 동결로 못박았습니다. 모르는 채로 위험을 감수하지 않겠다는 뜻입니다.

규모도 과장하지 않겠습니다. 피부과 사이트의 미색인 페이지는 클리닉 주소 3,584개보다 자릿수가 큽니다. 대부분 지역·시술 조합으로 자동 생성된 페이지이고, 이 결함이 그 미색인의 주원인이라는 근거는 없습니다. 고칠 값어치가 있는 실재하는 결함이라는 것까지가 지금 말할 수 있는 전부입니다.

저희는 순위나 인용, 색인을 보장하지 않습니다. 이 글이 답하는 것은 두 사이트에서 같은 결함을 어떻게 다르게 처리했고 그 판단의 근거가 무엇이었는가까지입니다. 판정 결과는 유의 여부와 관계없이 이 연구소 페이지에 공개합니다.

자주 묻는 질문 (FAQ)

Q. 우리 사이트도 같은 문제인지 어떻게 확인하나요?
사이트맵을 내려받아 lastmod 값의 고유 개수를 세어 보십시오. URL 수에 비해 고유값이 극단적으로 적거나, 여러 페이지가 초·밀리초까지 같은 값을 갖고 있다면 배치 쓰기 시각이 새어 나오고 있을 가능성이 높습니다.

Q. lastmod를 아예 빼는 것은 어떤가요?
모르는 값을 지어내는 것보다는 낫습니다. 저희도 값을 알 수 없는 항목에서는 넣지 않는 쪽을 택했습니다. 다만 정확한 값을 넣을 수 있다면 넣는 편이 낫습니다.

Q. 실험 중이면 아무것도 고치면 안 되나요?
그렇지 않습니다. 판단 기준은 "그 수정이 결과변수에 닿는가"입니다. 닿지 않는다는 근거가 있으면 고쳐도 되고, 근거가 없으면 만들거나 기다리는 것이 맞습니다. 이번에는 근거를 만드는 쪽을 택했습니다.