구글, AI 검색이 자체 SEO 전략을 필요로 하지 않는다는 오해를 밝히다

구글이 새로 공개한 문서에서 "생성형 엔진 최적화(GEO)"나 "답변 엔진 최적화(AEO)" 같은 신조어가 결국 기존 SEO와 동일한 작업이라고 못 박았다. 핵심 메시지는 AI 검색 결과(AI Overviews, AI Mode 등)도 결국 구글의 동일한 랭킹 시스템과 인덱스를 사용해 후보 문서를 가져온 뒤, Gemini 기반 LLM이 그 결과를 요약·재구성한다는 점이다. 업계 일부에서 제안해 온 LLMS.txt 파일(LLM 크롤러용 마크다운 메타파일)이나 "콘텐츠 청킹(chunking)"—문서를 LLM 친화적인 작은 단위로 잘게 쪼개는 기법—은 구글봇이 사용하지도, 참고하지도 않는다는 점을 명시했다. 즉 RAG 파이프라인의 retrieval 단계가 별도의 AI 전용 인덱스가 아닌 기존 검색 인프라 위에서 동작하기 때문에, 콘텐츠 품질·구조화 데이터·E-E-A-T·페이지 속도 같은 전통적 SEO 신호가 그대로 작동한다는 설명이다.

개발자와 엔지니어 입장에서 이 발표가 갖는 실질적 영향은 두 가지로 정리된다. 첫째, 마케팅팀이나 외주 에이전시가 "AI 검색용 별도 처리"를 명목으로 LLMS.txt 생성, 청크 단위 메타데이터 주입, AI 전용 라우팅 같은 추가 작업을 요구해 왔다면 그 우선순위를 재조정해야 한다. 이런 작업은 현재 구글 AI 검색 노출에는 기여하지 않으며, 오히려 사이트 복잡도와 유지보수 비용만 늘린다. 둘째, AI Overviews의 인용 노출을 늘리려면 결국 기존 기술 SEO 항목—Core Web Vitals, Schema.org 구조화 데이터(Article, FAQPage, HowTo, Product 등), 정확한 canonical 처리, 크롤링 가능한 렌더링(CSR 사이트의 경우 SSR/프리렌더링)—을 견고히 다지는 것이 가장 직접적인 투자다.

특히 한국 개발자가 자주 부딪히는 SPA/Next.js 환경에서는 클라이언트 사이드 렌더링만으로는 Gemini가 본문을 충분히 파싱하지 못하는 사례가 보고되고 있어, App Router의 Server Components나 ISR/SSG 활용, 그리고 `next-seo` 같은 라이브러리를 통한 JSON-LD 주입이 사실상 필수에 가깝다. 또한 robots.txt에서 `Google-Extended` 토큰을 차단하면 Gemini 학습용 데이터 수집은 막을 수 있지만 AI Overviews 노출에는 영향을 주지 않는다는 점, 그리고 Search Console에 AI 검색 트래픽이 별도 세그먼트로 합산된다는 점도 함께 알아둘 필요가 있다.

결론적으로 엔지니어가 당장 취할 액션은 명확하다. (1) 사내 SEO 백로그에서 LLMS.txt·AI 전용 청킹 관련 티켓은 보류하거나 폐기하고, (2) 구조화 데이터 커버리지와 SSR/하이드레이션 품질을 점검하며, (3) Search Console의 "AI 검색 표시 횟수"를 별도 KPI로 트래킹해 콘텐츠 품질 개선이 실제 AI 인용으로 이어지는지 데이터로 검증하는 사이클을 만드는 것이다. 결국 "AI 시대의 SEO"는 새로운 기술 스택이 아니라, 그동안 미뤄왔던 기본기를 다시 정직하게 다지는 작업에 가깝다.