AI Overviews, ChatGPT, Claude, Gemini, Perplexity를 위한 AEO와 GEO 완벽 가이드
검색 결과는 더 이상 링크 목록이 아니다. AI가 사용자를 대신해 페이지를 읽고, 직접 답을 구성하는 시대가 왔다. AI Overviews, ChatGPT, Claude, Perplexity, Gemini가 모두 실시간으로 웹 페이지를 참조하며 답변을 만든다. 전통적인 SEO만으로는 이 새로운 검색 환경에서 사용자에게 도달하기 어렵다. 바로 이 지점에서 AEO와 GEO가 필요하다.
검색이 바뀐다: 더 이상 링크 목록이 아니라 AI 답변이다
2년 전만 해도 검색 결과는 파란 링크 목록이었다. 사용자가 링크를 클릭하면 site으로 이동했다. 지금은 다르다. Google은 AI Overviews로 답변을 직접 보여주고, ChatGPT와 Claude는 실시간 웹 결과를 답변에 끌어오며, Perplexity는 이 방식 자체로 제품을 만들었다. Gemini는 모든 Google surface에서 한 번의 탭으로 접근 가능하다. 페이지는 더 이상 목적지가 아니라 모델이 사용자를 대신해 읽는 소스다.
이 변화의 핵심은 답변 엔진의 작동 방식에 있다. 답변 엔진이 직접 답을 줄 때 사용하는 소스가 되려면 AEO(Answer Engine Optimization)를 고민해야 한다. 생성형 AI가 페이지를 참조해 처음부터 답변을 작성할 때 그 안에 등장하려면 GEO(Generative Engine Optimization)가 필요하다. 둘 다 중요하지만, 같은 العمل 아니다.
AEO와 GEO: SEO와 같은 작업의 다른 이름일 뿐
Google은 자체 AI 최적화 가이드에서 두 개념을 기존 SEO의 변형으로명규정했다. 동일한 ranking과 품질 시스템이 일반 검색과 AI Overview 모두를 결정한다. 파란 링크 목록을 결정하는 시스템과 AI Overview 노출을 결정하는 시스템이 같다. 한쪽을 개선하면 다른 쪽도 함께 개선된다.
이는 단순한 이론이 아니라 실전 가이드다. 각 AI surface는 서로 다른 웹 인덱스를 사용하지만, 대부분의 인덱스가 동일한 크롤링과 렌더링과 품질 작업의 하위 결과물이다. Eligibility가 모든 것에 앞선다. 페이지가 AI 기능에 노출되려면 일반 검색 스니펫에 노출될 자격이 먼저 충족되어야 한다.
Eligibility가 먼저다: 모든 레이어의 게이트가 열려야 한다
페이지가 AI Overviews나 ChatGPT 답변에 노출되려면 기본적인 자격 요건이 충족되어야 한다. 이 단계가 생략되면 콘텐츠를 아무리우화해도 소용없다.
첫 번째는 인덱싱이다. URL이 먼저 Google이나 각 AI 표면의 인덱서에 등록되어 있어야 한다. 두 번째는 크롤링 허용이다. robots.txt에서 크롤링이 차단되어 있으면 안 된다. 세 번째는 스니펫 허용이다. nosnippet이나 max-snippet:0이 설정되어 있으면 안 된다. 네 번째는 렌더링이다. 무거운 JavaScript 없이 콘텐츠가 로드되어야 한다. Google Search Console의 URL 검사에서 Test live URL로 렌더링된 HTML을 확인했을 때 본문이 빠져 있으면 이것부터 수정해야 한다. 서버 렌더링과 정적 생성이 가장 안전한 방식이다.
많은 site이 실수로 검색용 크롤러를 차단하고 있다. GPTBot과 ClaudeBot은 학습용 크롤러여서 차단해도 검색 노출에 영향 없다. 하지만 Googlebot, Bingbot, OAI-SearchBot, Claude-SearchBot, PerplexityBot은 검색 인덱서다. 이 중 하나를 차단하면 해당 AI surface에서의 가시성이 떨어진다. AI 검색 가시성을 허용하면서 학습용 봇은 차단하는 robots.txt 구성은 충분히 가능하므로 설정을 점검해볼 문제 없다.
인용되는 콘텐츠는 모델이 학습 데이터만으로 못 만드는 것이다
생성형 검색은 구체성에 보상한다. 일반적 정보는 모델이 인용 없이 요약할 수 있다. 인용되는 페이지는 모델이 스스로 합성할 수 없는 내용을 담은 페이지다. Google 가이드는 고유하고 가치 있으며 사람 중심의 콘텐츠 작성을 강조한다. 다른 페이지가 똑같이 말하는 commodity 콘텐츠는 지양해야 한다.
구체적인 예를 살펴보자. Next.js 마이그레이션 글이 있다고 하자. Commodity 버전은 이런 내용이다. 모델이 학습 데이터만으로 생성할 수 있는 일반적인 migration 가이드다. 인용되지 않는다. Distinctive 버전은 다르다. 47개의 깨진 페이지라는 구체적 수치, 함수 시그니처의 특정 함정, 3시간이라는 시간 추정까지 담고 있다. 이런 디테일이 하나만 있어도 학습 데이터 요약 페이지에서 인용 참조 페이지로 전환된다.
이 원칙은 기술 블로그든 비즈니스 site든 동일하게 적용된다. 커밋 메시지 포맷 하나, 특정 함수 사용 시 발생하는 경고 메시지 하나, 경쟁 제품 대비 고유한 수치 하나. 모델이 학습 데이터만으로 생성할 수 없는 정보가 핵심이다.
깨끗한 기술 구조가 크롤러와 모델 모두를 돕는다
Semantic HTML 사용이 필수다. 의미 있는 계층의 실제 heading 레벨을 사용해야 한다. 페이지 주제에 대한 답을 상단 가까이 배치하고 서두 아래 콘텐츠를 묻어두지 않아야 한다. 개선된 버전은 article, h1, section, h2 같은 명확한 구조를 제공한다. 크롤러에게는 구조를 제공하고, 모델에게는 heading과 lede와 body의 깨끗한 경계를 제공한다.
Core Web Vitals가 ranking에 직접 반영되고, ranking이 다시 AI 기능 자격에 직접 반영된다. ranking 알고리듬이 보는 수치는 실제 Chrome 사용자의 28일 필드 데이터다. 로컬 Lighthouse 결과가 아니다. JavaScript의 web-vitals로 로컬 테스트와 Google 시스템 측 데이터를 정렬할 수 있다. 측정 가능한 것을 측정하고, 불가능한 것을 좇지 말라.
가이드가 부인하는 최적화 꼼수에 현혹되지 마라
AI Overviews를 위한 최적화로 보이는 몇 가지 방법이 있지만, 가이드 자체가 효과를 부인한다. llms.txt 파일 추가는 ranking 신호가 아니며 Google의 AI 기능이 사용하지 않는다. 콘텐츠를 잘게 청크화하거나 모든 heading을 질문 형태로 바꾸는 작업도 불필요하다. 모델은 페이지 전체의 컨텍스트를 읽기 때문이다. 구조화 데이터는 문서화된 rich result를 지원할 때 유용하지만 AI 기능 노출에 필수데하나이. 그 시간을 실제 콘텐츠 품질과 렌더링에 투자하는 것이 낫다.
반면 비주얼과 스키마와 커머스 데이터는 구조화 파이프라인의 일부로 가치가 있다. AI Overviews는 고품질 이미지와 비디오를 직접 끌어온다. 실제 스크린샷, 실제 다이어그램, 짧은 비디오 워크스루가 스톡 이미지보다 유용하다. 기존 이미지 SEO 기본을 적용하면서 alt 텍스트를 설명적으로 작성하고 파일명을 의미 있게 짓고 캡션을 도움되는 내용으로 채운다. 예를 들어 Next.js 성능 글의 이미지 alt 텍스트가 "다크모드 전환 버튼"이라면 모델이 무엇을 입증하는지 이해하기 어렵다. 하지만 "Next.js 앱에서 다크모드 전환 버튼을 클릭하면 250ms 내에 전환되며 이는 Core Web Vitals CLS 측정 결과 0.05 이하를 충족하는 것을 입증합니다"라면 충분한 설명이 된다.
구조화 데이터는 Recipe, Product, FAQ, Event, Article 스키마처럼 일반 검색에서 문서화된 효과가 있는 것만 추가할 가치가 있다. 배포 전에 Rich Results Test로 필수 필드 누락과 오류를 확인하라.
에이전트 경험이 다음 surface가 된다
이미 자율 에이전트가 사용자를 대신해 브라우징하는 시대다. Claude with computer use, ChatGPT Operator, Perplexity의 assistant가 이미 사용자가 직접 site을 탐색하지 않아도 되게 만든다. Google AI 최적화 가이드는 에이전트가 DOM과 컨트롤과 콘텐츠를 어떻게 해석하는지 고려할 것을 권고한다. 혼란스러운 마크업, 숨겨진 컨트롤, 이미지로만 렌더링된 핵심 정보를 가진 site은 에이전트가 다루기 어렵다.
유의하게도 이 문제는 접근성 작업과 같다. 스크린리더용 접근성 작업이 동일한 영역을 대부분 커버한다. 예약 페이지를 생각해보자. 개선 전 버전은 에이전트에게Submitted 버튼이라고만 알려준다. 개선 후 버전은 세 가지를 전달한다. 이것은 제출 버튼이고, 액션은 Confirm booking이며, 아이콘은 장식용이라는 것이다. 예약 확정 버튼을 식별 못 하는 에이전트는 포기하고 다른 site으로 이동한다. 폼 필드도 동일한 원리다. 에이전트는 name과 id와 aria-label과 주변 label 요소를 읽는다. type="datetime-local"로의 전환은 작은 변경이지만 브라우저와 에이전트 모두에 네이티브 datetime picker와 구조화된 값 처리를 제공한다. 에이전트가 포맷을 추측할 필요 없다.
측정 가능한 것을 측정하라
Search Console이 여전히 Google 측 데이터의 진실 공급원이다. AI Overviews와 AI Mode 트래픽은 표준 Web performance 리포트에 통합되어 있다. impressions와 clicks가 확인할 지표다. Performance를 how와 what과 why와 is와 can 같은 대화형 시작어를 포함한 쿼리로 필터링하면 AI Overviews를 유발하는 종류의 long-tail 쿼리를 찾을 수 있다. 해당 쿼리의 impressions 대비 clicks의 눈에 띄는 변동은 페이지가 방문 대신 AI 답변 내에서 요약되고 있을 가능성과 일치한다. 단, 이것은 증거가 아닌 가설로 사용해야 한다. 레이아웃 변경, ranking 변동, 쿼리 믹스 변화, 계절성도 유사한 패턴을 발생시킬 수 있다.
모델 인용 여부는 직접 테스트하는 것이 가장 확실하다. 각 surface를 열고 콘텐츠가 답해야 할 질문을 입력한다. 도메인이 inline 소스 목록이나 답변 인용에 등장하면 검색되고 있는 상태다. 주요 surface에서 비즈니스 관련 주제로 몇 주마다 반복 테스트하고, 백링크처럼 cite-event 수를 추적하라.
결론: AEO와 GEO는 SEO와 분리된학문이 아니다
AEO와 GEO는 SEO와 분리된 별개 분야가 아니다. 콘텐츠 독창성, 렌더링, 모든 AI surface에 입력되는 구조화 파이프라인에 더 날카로운 주의를 기울인 동일한 작업이다. Eligibility 문제를 해결하고, 모델이 학습 데이터만으로 합성할 수 없는 구체적 수치와 고유 경험을 담은 페이지를 만들며, semantic 구조와 Core Web Vitals를 챙기고, 에이전트가 해석할 수 있는 마크업을 사용하면, 위의 작업은 Google AI 최적화 가이드의 권고와 다른 AI 검색 surface이 보상하는 모든 것을 커버한다.
AI 검색 시대에 сай트를 최적화하고 싶다면 traditional SEO를 소홀히 하지 말고, 그 위에 AI surface 특화 작업을 레이어링하라. 하나의 작업이 모든 surface에서 효과를 낸다.
📚 출처
• Google 생성형 AI 검색 기능 최적화 공식 가이드
• SEO in 2026: AI Search, AEO & GEO Complete Playbook
📚 출처
'AI 뉴스' 카테고리의 다른 글
| 마이크로소프트, Claude Code 라이선스 회수 시작하다 — 개발자가 알아야 할 핵심 정리 (0) | 2026.05.23 |
|---|---|
| agentmemory - AI 코딩 에이전트용 영구 메모리 시스템 완벽 가이드 (0) | 2026.05.23 |
| Herdr - AI Agent 시대를 위한 tmux 스타일 터미널 워크스페이스 완벽 가이드 (0) | 2026.05.23 |
| AI는 그저 더 큰 규모의 무단 표절이다 (0) | 2026.05.23 |
| 공격적인 AI 스크래퍼가 위키 운영을 꽤 힘들게 만들고 있음 (0) | 2026.05.23 |