AI 개요 노출수가 8월 13일부터 갑자기 줄었습니다 — 로깅 버그인지 실제 하락인지 가리는 법

8월 13일 이후로 서치콘솔 '생성형 AI 성능' 보고서를 열어본 담당자라면 노출수 그래프가 계단식으로 꺾인 걸 봤을 것이다. AI Overviews, AI Mode 노출이 갑자기 줄어든 것처럼 보인다. 여기서 바로 콘텐츠 팀에 "AI 검색 대응 콘텐츠가 밀렸다"고 보고하기 전에, 이게 실제 노출 감소인지 아니면 구글 쪽 로깅 문제인지부터 가려야 한다. 결론부터 말하면 이번 건은 후자다. 다만 "구글이 버그라고 했으니 무시해도 된다"로 끝낼 문제도 아니다.

무슨 일이 일어났는가

구글은 서치콘솔 도움말의 '데이터 이상(Data Anomalies)' 페이지에 공지를 올렸다. 2026년 8월 13일부터 생성형 AI 성능 보고서의 노출수가 로깅 오류로 인해 실제보다 낮게 집계되고 있다는 내용이다. 존 뮬러도 자신의 블루스카이 계정에서 "검색 노출이 실제로 줄어든 게 아니라 기록 단계의 문제"라고 재확인했다. 구글은 조만간 보고서 화면에 이 기간을 표시하는 주석(annotation)을 추가하겠다고 밝혔지만, 이 글을 쓰는 시점까지 문제는 진행 중이다. 즉 8월 13일 이후 데이터는 그래프가 정상화될 때까지 액면 그대로 믿어서는 안 되는 구간이다.

주의할 점은 이번 공지가 '전체 노출수 하락'이 아니라 '집계값 과소 표시'라는 것이다. 실제 검색 결과에서 AI Overviews나 AI Mode에 사이트가 인용되는 빈도 자체는 바뀌지 않았는데, 서치콘솔이 그 인용을 세는 과정에서 일부를 누락하고 있다는 뜻이다. 이 차이를 구분하지 못하면 "AI 검색에서 우리 콘텐츠 인용이 줄었다"는 결론과 "구글이 인용은 그대로 하는데 집계만 못 하고 있다"는 결론이 완전히 다른 다음 행동으로 이어진다.

왜 이걸 그냥 넘기면 위험한가

실무에서 진짜 문제는 버그 자체가 아니라 이 시점에 다른 의사결정과 겹칠 때 생긴다. 마침 8월 중순에 AI 검색 최적화용 FAQ 페이지를 새로 올렸거나, 반대로 콘텐츠 개편을 미룬 팀이라면 노출수 하락을 그 결정의 결과로 오독하기 쉽다. "새 FAQ가 효과 없다"며 되돌리거나, "AI 검색 유입이 줄고 있으니 예산을 다른 채널로 옮기자"는 보고가 로깅 버그 위에서 나오면, 정작 원인 없는 처방을 하게 된다. 생성형 AI 성능 보고서는 아직 다른 서치콘솔 보고서보다 이력이 짧고 안정성도 낮다는 점을 감안하면, 이번 사례는 앞으로도 반복될 가능성에 대비하는 계기로 삼는 게 맞다.

로깅 버그인지 실제 하락인지 가려내는 순서

첫째, 하락이 정확히 8월 13일 전후로 계단처럼 끊어지는지 본다. 점진적으로 줄어드는 추세라면 버그가 아니라 실제 변화일 가능성이 크다. 둘째, 같은 기간 일반 검색(웹 검색) 성능 보고서의 노출·클릭 추이를 함께 확인한다. 일반 검색 지표는 안정적인데 생성형 AI 보고서만 꺾였다면 이번 버그와 일치하는 패턴이다. 셋째, GA4나 자체 로그에서 리퍼러 기반 AI 검색 유입(구글 AI Overviews, AI Mode에서 넘어온 세션)이 실제로 줄었는지 대조한다. 서치콘솔 노출수는 줄었는데 실유입은 그대로거나 오히려 늘었다면 로깅 문제로 결론 내려도 된다. 넷째, 순위 추적 툴에서 관련 키워드의 AI Overview 노출 자체가 사라졌는지도 확인한다. 세 지표(서치콘솔 노출, GA4 유입, 외부 순위 툴)가 서로 다른 방향을 가리키면 서치콘솔 쪽 로깅을 의심하는 게 합리적이다.

실무에서 이 네 가지를 한 번에 표로 정리해 두면 나중에 다시 설명할 필요가 없다. 예를 들어 8월 1주차부터 4주차까지 주 단위로 서치콘솔 AI 노출수, 일반 검색 노출수, GA4 AI 리퍼러 세션, 순위 툴의 AI Overview 노출 여부를 나란히 적어보면 어느 지표가 8월 13일을 기점으로 끊겼는지 한눈에 보인다. 이 표 하나가 "우리 콘텐츠 문제가 아니라 구글 집계 문제였다"는 근거로 남는다.

이번 사례가 알려주는 생성형 AI 보고서의 한계

생성형 AI 성능 보고서는 2026년 6월에 정식 출시된 비교적 신생 기능이다. 신생 보고서일수록 집계 파이프라인이 아직 다듬어지지 않았고, 이번처럼 로깅 오류가 몇 주간 방치되는 사례가 나온다. 실무적으로는 이 보고서의 절대 수치를 KPI로 그대로 보고하기보다, 클릭 없는 노출수만으로 판단 가능한 범위를 먼저 정해두고 그 안에서만 추세를 읽는 게 안전하다. 특정 날짜를 기점으로 지표가 끊기듯 변하는 현상은 이번이 처음도 아니다. 색인 보고서가 며칠씩 멈췄다가 몰아서 갱신되는 지연 현상도 같은 맥락에서, 보고서 자체의 배치 처리 특성을 색인 문제로 오인하지 않는 습관이 필요하다는 점을 보여준다. 마찬가지로 서로 다른 구글 도구가 같은 지표를 다르게 보여줄 때도 원리는 같다 — 하나의 대시보드만 보고 판단하지 말고, 최소 두 개 이상의 독립적인 데이터 소스로 교차 확인하는 것이다.

점검 순서 요약

생성형 AI 성능 보고서에서 노출수 급감을 발견했다면 다음 순서로 확인한다. ① 서치콘솔 도움말의 데이터 이상 페이지에 해당 기간 공지가 있는지 먼저 확인한다. ② 하락 시점이 계단형인지 점진형인지 구분한다. ③ 일반 검색 성능 보고서와 GA4 실유입을 대조한다. ④ 순위 추적 툴에서 AI Overview 노출 자체의 소실 여부를 본다. ⑤ 위 지표가 엇갈리면 서치콘솔 쪽 문제로 잠정 결론 내리고, 구글이 주석을 추가할 때까지 이 기간 데이터는 보고서에서 별도로 표시해 둔다. 클라이언트 리포트에 이 기간을 그대로 넣으면 원인 없는 하락으로 보고되니, 담당자라면 각주 하나로 이 이슈를 명시해 두는 편이 나중에 설명하기 쉽다.