검색 트래픽 급락을 '수요 없음'으로 오진한 이유 — 분석 창이 진단을 바꿉니다

몇 주 전, 제 블로그의 검색 유입을 들여다보고 "이 주제엔 원래 수요가 없다"고 결론지었습니다. 최근 28일 데이터를 근거로 삼았고, 대응책까지 세웠습니다. 주제를 바꾸거나 언어를 넓혀야 한다는 쪽으로요. 그런데 이번에 같은 데이터를 더 넓은 창으로 다시 열어보니 결론이 뒤집혔습니다. 원래 없었던 게 아니라, 특정 하루에 무너진 것이었습니다.

데이터는 그대로였습니다. 바뀐 건 제가 데이터를 바라본 창의 크기뿐이었습니다. 부끄럽지만 이 오진의 전말을 복기해 두려 합니다. 같은 함정은 자기 사이트의 트래픽 급락 원인을 데이터로 규명하려는 누구에게나 열려 있다는 생각이 들었기 때문입니다.

첫 진단 — "이 주제엔 원래 수요가 없다"

처음 봤을 때 저는 최근 28일 창으로 GSC와 GA4를 열었습니다. 검색 유입은 거의 0에 가까웠고, 그나마 노출이 잡히던 상위 주제들은 한국어 검색량이 희박한 니치였습니다. 개발 도구의 세부 사용법이나 특정 프레임워크의 내부 동작 같은, 애초에 찾는 사람이 적은 글들이었습니다. 그래서 내린 결론이 "주제-수요 미스핏"이었습니다. 이 주제엔 원래 한국어 검색 수요가 없으니 유입이 없는 게 당연하다는 것이었습니다.

돌이켜 생각해보면 이 진단은 지나치게 편했습니다. 작은 블로그이고 니치한 주제를 다룬다는 제 선입견에 딱 맞아떨어졌기 때문입니다. 심리학에서 말하는 확증 편향이 정확히 이렇게 작동합니다. 이미 믿고 있던 그림에 부합하는 설명이 나타나면, 더 파보지 않고 거기서 멈추게 됩니다. 그리고 그 첫 설명이 이후의 사고를 붙잡는 앵커가 됩니다. 저는 "그럴듯한 첫 후보"에 닻을 내리고 검증을 종료해버렸습니다.

재감사 — 창을 넓히자 바닥이 절벽으로 바뀌었다

이번에 다시 볼 때는 창을 90일로 넓히고, 총계 대신 일별로 전수를 펼쳤습니다. 그러자 전혀 다른 그림이 드러났습니다.

첫째, 붕괴 이전엔 실수요가 있었습니다. 초봄 어느 시기엔 몇몇 쿼리로 검색 유입이 실제로 들어왔고, 트래픽이 또렷한 피크를 찍었습니다. "수요 0"이 결코 아니었습니다. 둘째, 절벽은 하루였습니다. 어느 날 하루 만에 노출이 10배 이상 급감했고, 이후로는 회복 없이 바닥에 고착했습니다. 완만한 하락이 아니라, 한 계단을 뚝 떨어진 절벽이었습니다.

여기서 28일 창의 정체가 분명해졌습니다. 제 첫 진단이 봤던 28일은 이미 절벽이 지나간 뒤의 평평한 바닥만 담고 있던 창이었습니다. 바닥만 보면 "원래 이렇게 평평했다", 즉 "수요가 없었다"로 오인하기 쉽습니다. 창이 절벽을 포함하지 못하면, 절벽은 처음부터 존재하지 않는 것처럼 보입니다.

집계가 절벽을 뭉갠다 — 앤스콤의 교훈

이 대목에서 앤스콤의 사분면(Anscombe's quartet)이 떠올랐습니다. 통계학자 프랜시스 앤스콤이 만든 네 개의 데이터셋인데, 평균·분산·상관계수 같은 요약 통계는 거의 똑같지만 산점도로 그려보면 네 모양이 완전히 다릅니다. 교훈은 하나입니다. 요약 통계만 보고 데이터의 형태를 판단하지 말라는 것입니다.

제 실수가 정확히 그것이었습니다. 28일 총계는 "낮고 평평함"이라는 하나의 요약값으로 절벽을 뭉개버렸습니다. 같은 데이터를 일별로 펼치자 절벽이 튀어나왔습니다. 총계와 평균은 이상(anomaly)을 숨기는 데 특히 능합니다. 급락 한 번은 앞뒤 기간에 흡수되어 평균 속으로 사라지기 때문입니다. 이상을 찾으려면 반드시 일별 해상도로, 그리고 이상 지점을 품을 만큼 충분히 긴 창으로 봐야 합니다.

봇 착시인가 진짜 사건인가 — 독립 소스로 확인하기

절벽을 발견했다고 끝이 아니었습니다. 하나의 지표만 보고 있으면, 그 급락이 진짜 사건인지 측정 잡음인지 가를 수 없습니다. 예컨대 GSC 노출만 꺾였다면 크롤러나 봇 트래픽이 만든 착시일 가능성을 의심해야 합니다.

그래서 소스를 둘로 나눠 봤습니다. GSC의 노출은 구글 검색 쪽에서 측정한 지표이고, GA4의 검색 유입 실사용자 세션은 제 사이트 쪽에서 측정한 지표입니다. 측정 경로가 서로 독립입니다. 그런데 이 둘이 같은 날 동시에 꺾였습니다. 한쪽만 봤다면 잡음을 의심했겠지만, 독립된 두 측정이 같은 날짜를 가리킨 것은 실제 랭킹 이벤트가 남긴 지문에 가깝습니다.

전에 어떤 견적을 여러 방법으로 교차검증하면서, 교차검증의 핵심은 방법의 개수가 아니라 입력의 독립성이라는 생각을 한 적이 있습니다. 같은 자료를 네 번 본 것은 한 번 본 것을 네 번 적은 것에 불과하니까요. 트래픽 진단에서도 원리는 같았습니다. 서로 독립인 두 소스가 한 날짜에서 겹칠 때, 비로소 그 날짜를 믿을 수 있습니다.

원인을 좁히는 법 — 감별진단과 타임라인 대조

절벽의 시점과 규모는 데이터로 확정했습니다. 남은 것은 원인이었습니다. 여기서는 의사가 증상의 원인을 좁혀가듯 감별진단의 방식을 빌렸습니다. 원인 후보를 하나씩 절벽 날짜와 대조해, 타임라인이 맞지 않는 것부터 지워나가는 방법입니다.

원인 후보	확인한 것	판정
내 배포·코드 변경	절벽이 있던 주에 관련 커밋 0건	배제
사이트 설정 변경(다국어 URL 정리 등)	절벽보다 훨씬 전부터 가동, 상승기에도 문제없이 작동	배제
색인 문제(디인덱싱)	대표 페이지 색인 상태 정상, 정기 크롤 확인	배제
공식 구글 코어 업데이트	공식 롤아웃이 절벽보다 2주 이상 늦음	직접 원인 아님
미확인 순위 변동	같은 시기 검색 커뮤니티에 큰 변동 보고, 내 사이트 프로필이 강등에 취약한 유형과 겹침	유력

이렇게 하나씩 지우고 나니 남는 유력 후보는 그 시점의 미확인 순위 변동이었습니다. 공식 코어 업데이트는 절벽보다 2주 이상 늦게 시작됐으니 절벽의 방아쇠는 아니었습니다. 다만 이후의 회복을 가로막았을 여지까지 배제하지는 못했습니다. 결국 데이터가 가리키는 방향은 특정 배포나 기술적 실수가 아니라, 사이트 레벨의 품질 강등이 하루 만에 일어났다는 가설이었습니다.

"확정"이 아니라 "데이터로 좁힌 가설"

여기서 결론의 톤을 분명히 해두고 싶습니다. 제가 확정한 것은 절벽의 시점과 규모까지입니다. 그것은 독립된 두 소스가 같은 날짜에서 겹쳤으니 사실로 봐도 됩니다. 반면 원인은 배제법으로 좁힌 유력한 추정일 뿐, 확정이 아닙니다. 순위 변동의 정체를 구글이 공표한 것도 아니고, 제가 직접 증명한 것도 아니기 때문입니다.

확정과 추정을 뒤섞지 않는 것이 중요하다는 생각이 들었습니다. 둘을 뭉개면 "원인을 안다"는 잘못된 확신이 생기고, 그 확신 위에서 엉뚱한 대응을 하게 됩니다. 제 첫 진단이 바로 그랬습니다. 추정에 불과한 "수요 없음"을 확정처럼 받아들이고, 주제를 통째로 갈아엎겠다는 대응까지 나아갔으니까요.

급락을 진단하는 절차

이번 일을 다음에 다시 꺼내 쓸 수 있도록 절차로 정리해 두었습니다. 특별한 도구가 필요한 것도 아니고, 순서만 지키면 됩니다.

1. 일별 해상도 + 충분히 긴 창으로 본다. 총계·평균은 절벽을 뭉갭니다. 이상 지점을 품을 만큼 창을 넓히고, 하루 단위로 펼칩니다.
2. 급락을 특정 날짜에 못 박는다. "이번 달에 급감"이 아니라 "며칠에 무슨 일"까지 좁혀야 원인 추적이 시작됩니다. 원인은 언제나 특정 날짜에 붙습니다.
3. 독립 소스 두 개 이상으로 그 날짜를 교차확인한다. 검색엔진 측 지표(노출)와 내 사이트 측 지표(실사용자 세션)가 같은 날 꺾이면 잡음이 아닙니다.
4. 그 날짜를 기준으로 배제법을 돌린다. 배포 이력, 설정 변경 시점, 색인 상태, 알려진 업데이트 롤아웃 날짜를 절벽 날짜와 하나씩 대조합니다.
5. 확정과 추정을 분리해 결론 낸다. 시점·규모는 확정, 원인은 좁힌 가설. 톤을 섞지 않습니다.

데이터는 그대로여도 프레임이 바뀌면 답이 바뀐다

가장 부끄러운 부분은 진단이 틀렸다는 사실 자체가 아닙니다. 첫 진단에서 멈춰버렸다는 점입니다. "수요 없음"이라는 설명이 제 선입견에 너무 잘 맞았기에, 저는 그것을 검증이 끝난 결론으로 착각했습니다. 그럴듯한 첫 후보가 사실은 가장 위험한 함정이었습니다.

결국 남은 교훈은 이렇습니다. 자기 진단도 재검증의 대상입니다. 과거에 내린 결론을 새로운 창으로 다시 돌려보는 습관이 없었다면, 저는 지금도 있지도 않은 수요를 탓하며 엉뚱한 곳을 고치고 있었을 것입니다. 데이터는 조금도 바뀌지 않았는데, 창 하나를 바꾸자 답이 뒤집혔습니다. 어쩌면 분석에서 가장 먼저 의심해야 할 것은 데이터가 아니라, 내가 그 데이터를 담아둔 프레임인지도 모르겠다는 생각이 들었습니다.