사내 운영 vs 외부 대행: AEO 어떻게 할까

AEO(Answer Engine Optimization)는 Google AI Overviews·Perplexity·ChatGPT Search 같은 답변 엔진이 질의에 대한 직접 응답을 생성할 때 특정 도메인의 콘텐츠를 인용하도록 최적화하는 작업이다. 기술 구조 측면에서 세 레이어를 동시에 관리해야 한다: 크롤러 접근성(robots.txt·HTTP 헤더·sitemap), 구조화 데이터(JSON-LD 스키마), 그리고 콘텐츠 의미 구조(heading 계층·FAQ 마크업·entity coverage). 이 세 레이어를 올바르게 관리할 수 있는 역량이 사내에 있느냐, 아니면 외부 대행에 위임해야 하느냐는 단순한 비용 문제가 아니라 기술 실행 능력과 측정 인프라의 문제다.

AEO의 기술 레이어와 역량 요건

답변 엔진이 콘텐츠를 인용하는 경로는 크게 두 가지다. 첫째는 실시간 웹 크롤 기반 인용, 둘째는 사전 학습 데이터 내 콘텐츠 포함이다. 실무에서 최적화 가능한 범위는 전자다. 크롤 기반 인용을 위한 기술 역량을 레이어별로 분해하면:

• 크롤러 접근성 레이어 — GPTBot, PerplexityBot, Claude-Web 등 AI 크롤러가 콘텐츠를 수집할 수 있어야 한다. 왜: AI 크롤러는 Googlebot과 User-Agent가 다르므로 기존 SEO 설정이 이들을 의도치 않게 차단할 수 있다. 어떻게: robots.txt에 AI 크롤러별 명시적 Allow 규칙을 추가하고, 서버 응답의 X-Robots-Tag 헤더도 병행 점검한다.
• 구조화 데이터 레이어 — FAQPage, HowTo, Article, Organization 등 JSON-LD 스키마를 오류 없이 마크업해야 한다. 왜: 답변 엔진은 비정형 텍스트보다 구조화된 데이터에서 entity와 관계를 더 높은 신뢰도로 추출한다. 어떻게: Google Rich Results Test와 Schema.org Validator로 스키마 배포마다 오류율 0%를 유지한다.
• 콘텐츠 의미 구조 레이어 — 질의-응답 쌍이 HTML heading 계층과 일치해야 한다. 왜: LLM은 heading을 context boundary로 활용해 해당 섹션을 단위로 인용한다. 어떻게: H2를 질의 형태로, 그 아래 첫 paragraph를 직접 응답으로 작성하는 구조를 일관되게 적용한다.

사내 운영의 구현 체계

기술 실행 조건

사내 운영은 도메인 지식이 깊고 CMS 직접 접근이 가능하다는 구조적 이점이 있다. JSON-LD 스키마 배포, robots.txt 즉각 수정, 크롤러 로그 직접 분석이 모두 사내 권한 안에서 이뤄진다. 단, 다음 조건이 갖춰져야 실제 효과를 낼 수 있다:

1. AEO 전담 인력 — JSON-LD 스키마를 직접 작성하고 검증할 수 있는 기술 마케터 또는 프론트엔드 엔지니어가 필요하다. 왜: CMS 본문만 수정하는 구조로는 구조화 데이터 레이어를 관리할 수 없다. 어떻게: Schema.org 스키마 타입 선택부터 배포 후 Google Search Console Rich Results 상태 확인까지 단일 담당자가 루프를 닫아야 한다.
2. 크롤러 로그 파이프라인 — Nginx/Caddy 접근 로그에서 User-Agent 기준으로 AI 크롤러 방문 빈도와 크롤 경로를 집계하는 인프라가 필요하다. 왜: 이 데이터 없이는 스키마 변경이 크롤 빈도에 미치는 영향을 측정할 수 없어 최적화 루프가 닫히지 않는다.
3. 측정 환경 — 스키마 변경 효과를 검증하려면 컨트롤/실험 URL 세트가 필요하다. 왜: 도메인 전체에 동시 변경하면 인과 관계를 분리할 수 없다. 어떻게: 트래픽 규모가 비슷한 URL 쌍을 선정해 스키마 적용 전후 인용 빈도를 비교한다.

FAQPage JSON-LD 스키마 구현 예시

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "AEO와 SEO의 핵심 차이는 무엇인가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO는 검색 결과 페이지에서 클릭을 유도하는 랭킹 최적화이고, AEO는 답변 엔진이 질의에 대한 직접 응답을 생성할 때 해당 콘텐츠를 인용하도록 유도하는 최적화입니다. AEO에서는 클릭률보다 인용 빈도와 출처 표시 여부가 핵심 성과 지표입니다."
      }
    },
    {
      "@type": "Question",
      "name": "robots.txt에서 AI 크롤러를 어떻게 처리해야 하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "GPTBot, PerplexityBot, Claude-Web, Applebot-Extended 등 주요 AI 크롤러는 User-Agent가 Googlebot과 다릅니다. 기존 robots.txt의 Disallow 규칙이 이들에게도 적용될 수 있으므로, 인용을 허용할 경로는 각 크롤러별로 명시적 Allow 규칙을 추가해야 합니다."
      }
    }
  ]
}

외부 대행의 작동 방식과 검증 기준

외부 대행사는 복수 클라이언트 데이터를 통해 크롤러 행동 패턴과 스키마 효과를 벤치마킹할 수 있다는 이점이 있다. 대행사 선정 시 다음 기준으로 기술 역량을 검증해야 한다:

• 크롤러 로그 분리 보고 — "AI 트래픽이 증가했다"는 집계는 의미가 없다. GPTBot·PerplexityBot·Claude-Web 각각의 크롤 경로와 빈도를 User-Agent 기준으로 분리 보고할 수 있어야 한다. 왜: AI 크롤러마다 인덱싱 주기와 우선 처리 콘텐츠 유형이 다르다.
• 스키마 오류율 0% 유지 이력 — Google Search Console Rich Results 오류 수가 보고서에 포함되어야 한다. 스키마 배포 후 오류율이 0%를 유지하지 못하는 대행사는 구조화 데이터 레이어 관리 능력이 부족하다고 봐야 한다.
• 인용 측정 방법론 명시 — Perplexity·ChatGPT Search·AI Overviews에서 해당 도메인의 인용 빈도를 어떻게 측정하는지 구체적 방법론(쿼리 세트 구성·측정 주기·샘플 크기)을 계약 전에 문서로 확인해야 한다. 정성적 보고는 검증이 불가능하다.

사내 운영 vs 외부 대행: 의사결정 비교

흔한 오해: "robots.txt에서 AI 크롤러를 허용하면 AEO가 자동으로 된다"

크롤러 접근을 허용하는 것은 AEO의 필요 조건이지 충분 조건이 아니다. GPTBot이 페이지를 크롤해도 콘텐츠가 비정형 텍스트 덩어리이거나 FAQPage 스키마가 없으면, 답변 생성 시 인용 대상으로 선택될 가능성이 낮다. robots.txt에서 GPTBot을 명시적으로 허용하면서 FAQPage 스키마가 전혀 없는 사이트는, 크롤러를 차단하지 않으면서 정확한 스키마를 갖춘 사이트보다 AI 인용 빈도가 낮은 사례가 관찰된다(다만 쿼리 도메인과 경쟁 콘텐츠 수준에 따라 다름).

올바른 처리법: robots.txt AI 크롤러 허용과 JSON-LD 스키마 배포를 동시에 진행해야 한다. 배포 후 Google Search Console에서 해당 URL의 Rich Results 상태가 유효함으로 표시되는지 확인하고, 이후 Perplexity나 AI Overviews에서 관련 쿼리를 직접 입력해 인용 여부를 주 단위로 모니터링한다. 크롤러 접근성과 스키마 품질은 별개의 체크리스트로 관리해야 한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

• Google 검색 센터 — SEO 기본 가이드
• Schema.org — 구조화 데이터 시작하기
• Google 검색의 AI 기능과 내 웹사이트