구글, GEO와 AEO는 전설이며 전통적인 SEO만이 AI 검색에 필요하다고 말한다

구글의 이번 공식 문서는 AI 검색(SGE, AI Overviews, Gemini 등)이 별도의 색인이나 랭킹 시스템을 사용하는 것이 아니라, 기존 구글 검색의 동일한 크롤링·인덱싱·랭킹 파이프라인 위에서 동작한다는 점을 명확히 밝히고 있다. 즉, 생성형 AI가 응답을 만들 때 참조하는 후보 문서들은 결국 전통적인 검색 랭킹 알고리즘이 선별한 결과이며, 그 위에 LLM이 요약·재구성 레이어를 얹는 구조다. 그 결과 업계에서 유행하던 LLMS.txt 파일 배치, 콘텐츠 청킹(chunking) 최적화, AI 친화적 마크다운 구조 같은 "GEO/AEO" 기법들은 별도의 랭킹 시그널로 작동하지 않으며, 구글은 이를 "마케팅 용어 재포장"에 불과하다고 일축했다. 핵심 시그널은 여전히 E-E-A-T, 구조화된 데이터(Schema.org), 코어 웹 바이탈, 백링크, 콘텐츠 품질 같은 기존 SEO 요소들이다.

개발자와 엔지니어 관점에서 이는 최근 1~2년간 쏟아진 "AI 검색 최적화 전용 도구"나 미들웨어 도입을 재검토해야 한다는 신호다. 특히 사이트에 별도의 LLM 전용 엔드포인트(/llms.txt, /ai-sitemap.json 등)를 구축하거나, robots.txt에 AI 봇 전용 룰을 복잡하게 분기시키는 작업의 실효성이 낮다는 점이 공식 확인된 셈이다. 반대로 서버사이드 렌더링(SSR) 또는 하이드레이션 최적화로 Googlebot이 자바스크립트 실행 없이도 본문을 읽을 수 있게 하는 작업, JSON-LD 구조화 데이터의 정확성, sitemap.xml과 canonical 태그 관리 같은 "기본기"가 AI 검색 노출에도 그대로 영향을 미친다. 프런트엔드 팀이 React/Next.js 기반 사이트에서 메타데이터·OG 태그·서버 렌더링을 챙기는 것이 곧 AI 검색 대응이라는 의미다.

실무적으로 당장 취할 액션은 세 가지로 압축된다. 첫째, 이미 운영 중인 SEO 파이프라인(사이트맵 자동 갱신, 구조화 데이터 검증, 페이지 속도 모니터링)을 강화하고, 별도의 GEO/AEO 트랙을 신설하기보다 통합 운영하는 것이 비용 대비 효과가 높다. 둘째, GSC(Google Search Console)의 "AI Overviews" 관련 노출/클릭 데이터가 점진적으로 분리 제공되고 있으므로, 로그 분석 시 GoogleOther·Google-Extended 같은 사용자 에이전트를 일반 Googlebot과 함께 모니터링하되 차단 여부는 콘텐츠 학습 허용 정책 관점에서만 결정하면 된다. 셋째, 콘텐츠 측면에서는 LLM이 인용하기 쉬운 명확한 정의문·요약 단락·FAQ 구조가 여전히 유효하지만, 이는 "AI 전용 트릭"이 아니라 사람 독자에게도 좋은 글쓰기 원칙이라는 점을 팀에 공유할 필요가 있다. 결국 구글의 메시지는 분명하다 — AI 시대에도 검색 노출의 본질은 "신뢰할 만한 콘텐츠를 크롤러가 잘 읽을 수 있게 제공하는 것"이며, 새로운 약어에 휘둘리기보다 기존 SEO 자산에 투자하는 편이 ROI가 높다.