"Answer Engine Optimization (AEO, 답변 엔진 최적화)"는 새로운 골드러시입니다. 여러분의 사이트가 ChatGPT, Perplexity, 그리고 Google의 AI Overviews에 인용되도록 만드세요. 스키마 마크업 (schema markup)을 추가하라, 더 많은 페이지를 게시하라, 도구를 구매하라 등 어떻게 해야 하는지에 대한 조언을 파는 거대한 가내 수공업 산업이 존재합니다.

저는 작은 이중 언어 중국 점성술 계산기(auspiceoracle.com)를 운영하고 있습니다. 이 사이트는 니치(niche)하고 권위(authority)가 매우 낮은 사이트이며, 이는 실험용 쥐로 쓰기에 적합합니다. 브랜드 신호(brand signal)도 없고, 백링크(backlinks)도 없어서 측정 결과를 혼란스럽게 할 요소가 전혀 없기 때문입니다. 단 하나의 콘텐츠 페이지를 작성하기 전에, 저는 대부분의 AEO 조언이 건너뛰는 두 가지를 수행했습니다. 바로 실제 연구를 읽는 것과 출시 전에 측정 체계를 구축하는 것이었습니다. 데이터와 대조하여 살아남은 사실들은 다음과 같습니다.

발견 1: 스키마 마크업 (schema markup)은 AEO 레버가 아니다

이 부분은 뼈아팠습니다. 왜냐하면 JSON-LD를 추가하는 것이 AEO 조언 중 가장 많이 반복되는 내용이기 때문입니다.

사용 가능한 가장 좋은 증거는 Ahrefs의 이중차분(difference-in-differences) 연구입니다. JSON-LD를 추가한 1,885개의 페이지를 대상으로, 이전 기간의 인용 수준이 유사한 다른 도메인의 대조군 URL 3개와 매칭하여 30일간의 기간 동안 네 가지 통계적 접근 방식으로 분석했습니다. 결과는 다음과 같습니다:

자주 인용되는 반대 통계("AI가 인용한 페이지는 JSON-LD를 가질 확률이 3배 더 높다")는 혼란을 줄 수 있으며, Ahrefs 스스로도 그렇게 말합니다. 스키마는 더 잘 관리되는 사이트에 존재하기 때문입니다. 네 가지 독립적인 메커니즘 연구는 그 이유에 대해 일치된 의견을 내놓았습니다. LLM이 라이브 페이지를 가져올 때, 가시적인 HTML을 추출하고 구조화된 데이터(structured-data) 레이어는 무시한다는 것입니다. 한 테스트에서는 FAQ 스키마에만 존재하는 사실을 심어두었으나, 어떤 플랫폼도 이를 사용하지 않았습니다. 또 다른 테스트에서는 모델에 의도적으로 유효하지 않은 스키마를 제공했더니 모델이 기꺼이 거기서 정보를 추출했습니다. 즉, 스크립트 블록이 일반 텍스트로 읽히고 있는 것입니다.

제가 유지한 것은 모든 콘텐츠 페이지의 처음 두 문장 안에 포함된, 추출 가능한 평이한 언어의 정의입니다. 그것이 바로 기계가 실제로 읽는 것입니다. 스키마는 저렴한 리치 결과(rich-result)를 위한 기본 요건으로서 페이지에 남겨두되, AEO를 위한 노력은 스키마에 전혀 할애하지 않습니다.

발견 2: 페이지 볼륨은 약한 신호이며, 브랜드를 지름길로 만들 수는 없다

또 다른 일반적인 조언은 프로그래매틱 콘텐츠 (programmatic content)입니다. 즉, 수백 개의 페이지를 생성하여 노출 면적 (surface area)을 확보하라는 것입니다. 75,000개의 브랜드를 대상으로 한 Ahrefs의 상관관계 연구는 AI 가시성 (AI visibility)을 추적하는 신호들을 다음과 같이 순위 매겼습니다:

하지만 어떤 항목을 실행에 옮기기 전에 세부 사항을 주의 깊게 읽어야 합니다. 샘플은 DR>40 브랜드로 필터링되었고, 상관관계는 0차 상관관계 (zero-order correlations)이며 (브랜드 규모를 통제 변수로 처리하지 않음), 독립적인 재현 연구가 없습니다. 정직한 추론은 "YouTube 영상을 만드세요"가 아니라, AI 가시성이 복합적인 브랜드 인지도 (brand prominence)를 추적한다는 것입니다. 이는 신규 사이트가 가지고 있지 않으며, 페이지 수로도 속일 수 없는 요소입니다. 작은 사이트의 경우, 업체 측의 제안("페이지를 더 많이 만드세요!")과 그에 반대하는 제안("페이지는 중요하지 않습니다!") 모두 당신이 속하지 않은 집단으로부터 도출된 외삽 (extrapolation)일 뿐입니다. 해당 연구들은 말 그대로 이미 100개 이상의 AI 인용 (AI citations)을 보유한 페이지들을 샘플링했습니다. 당신의 페이지는 0개입니다. 아무도 당신에 대한 데이터를 발표하지 않았습니다.

발견 3: 위키피디아(Wikipedia)보다 더 잘 정의하려 하지 마세요; 엔티티 간극 (entity gaps)을 매핑하세요

저의 원래 계획은 제 니치 (niche) 분야의 영어 용어들이 아직 선점되지 않았다고 가정했습니다. 하지만 그렇지 않았습니다. 위키피디아가 활발하게 성장하는 문서를 통해 핵심 용어 (head term)를 점유하고 있었고, LLM은 백과사전적 출처에 대해 명백히 과도하게 인덱싱 (over-index)합니다. 위키피디아보다 더 잘 정의하는 것을 목표로 하는 페이지는 시작부터 실패한 것이나 다름없습니다.

하지만 MediaWiki API는 "위키피디아가 존재한다"는 사실보다 더 유용한 정보를 제공합니다. 즉, 어떤 하위 개념 (sub-concepts)들이 문서도 없고 리다이렉트 (redirect)도 없는지를 알려줍니다. 제 니치 분야에서는 대여섯 개의 핵심 용어 사전 (glossary terms)이 '누락됨(missing)'으로 나타났습니다. 정의상으로는 핵심 용어에 위치하지만, 구조적으로는 그 아래에 흩어져 있는 상태였습니다. 키워드 볼륨이 아니라, 바로 그 간극 지도 (gap map)가 콘텐츠 계획이 되었습니다.

아무도 팔지 않는 부분: 측정 (measurement)

AI 크롤러(crawlers)는 별도의 제출 채널이 없습니다. GPTBot에 핑(ping)을 보낼 수도 없습니다. 크롤링이 전혀 발생하지 않는다는 것은 "설정이 잘못된 것"이 아니라 "아직 발견되지 않은 것"을 의미합니다. 유일하게 선제적으로 조절할 수 있는 레버는 간접적인 방식뿐입니다. Bing의 인덱스(index)가 OpenAI와 Copilot의 검색(retrieval)에 피드를 제공하므로, IndexNow(게시당 하나의 핵심 파일 + 하나의 POST 요청)가 당신이 할 수 있는 가장 영향력 높은 제출 방식입니다. 그 외의 모든 것은 외부 링크가 발견 작업을 수행하는 것입니다.

제 운영 서버(production box)는 nginx 없이 터널 뒤에서 Next.js를 실행하고 있어, 추출할 액세스 로그(access logs)가 없었습니다. 해결책은 미들웨어(middleware)에 한 줄을 추가하는 것이었습니다. AI 유저 에이전트(user-agents)를 매칭하여 console.log를 찍으면, 프로세스 매니저(process manager)의 로그가 데이터셋이 됩니다:

# UA × 히트 횟수, pm2 로그로부터 추출
grep -h '[ai-bot]' ~/.pm2/logs/app-out*.log | awk '{print $3}' | sort | uniq -c | sort -rn

이 로그를 읽을 때 두 가지 구분이 중요합니다:

• GPTBot / ClaudeBot / PerplexityBot = 당신의 페이지가 크롤링 대기열(crawl queue)에 진입했습니다. 필요조건이지만 충분조건은 아닙니다.
• ChatGPT-User / Perplexity-User / Claude-User = 사람이 답변에서 인용된 당신의 사이트를 보았고, 어시스턴트(assistant)가 그들을 위해 페이지를 가져왔습니다(fetch). 이것이 바로 핵심 지표(metric)입니다. 그 외의 모든 것은 선행 지표(leading-indicator)로서의 노이즈일 뿐입니다.

그리고 사후에 맞출 수 없는 한 가지가 있는데, 바로 기준점(baseline)입니다. 페이지를 라이브로 전환하기 전, 저는 ChatGPT, Perplexity, Google을 통해 고정된 6개의 프롬프트(prompts)를 실행하여(총 18개 셀), 누가 인용되는지 기록하고 스크린샷을 보관했습니다. 18개 셀 모두에서 예상대로 저희에 대한 인용은 0건이었습니다. 핵심은 매달 동일한 패널을 사용하고 질문을 절대 수정하지 않는 것입니다. 질문을 바꾸는 것은 자(ruler)를 바꾸는 것과 같습니다. 출시 전의 '0'이라는 행(row)이 없다면, 향후 발생하는 어떤 인용도 "어쩌면 예전부터 이미 있었던 것일지도 모른다"는 의구심을 남길 수 있습니다.

솔직하게 초기 결과를 말씀드리자면, 출시 첫날 크롤러 하나(ClaudeBot)가 체크리스트를 확인하듯 10개의 새 페이지를 각각 정확히 한 번씩 가져갔습니다. 다른 크롤러들은 0건이었습니다. 인용도 0건이었습니다. 이것은 성공 사례가 아니라 90일간의 실험입니다. 바로 그렇기 때문에 기준점(baseline) 행이 중요한 것입니다.

역발상적 제언: 학습용 크롤러를 허용하라

콘텐츠 사이트에 대한 일반적인 조언은 검색용 봇(retrieval bots)은 허용하되, 학습용 크롤러(CCBot, GPTBot-as-trainer, Google-Extended)는 차단하라는 것입니다. 저는 정반대로 했습니다. 모든 것을 명시적으로 허용(explicit allow)했습니다.

그 이유는 콜드 스타트 경제학(cold-start economics) 때문입니다. 어떤 모델도 제 사이트의 용어를 "알고" 있거나 사이트의 존재 자체를 알지 못합니다. 학습 데이터에 포함되는 것이 그 상황을 변화시키는 방법이며, 그 지연 시간은 모델 한 세대(model generation)만큼 걸립니다. 이는 나중에 가시성(visibility)을 얻기 위해 지금 지불해야 하는 비용입니다. 학습용 크롤러를 차단하는 것은 독점적 가치가 있는 콘텐츠를 보호하기 위함입니다. 하지만 신규 사이트에는 그런 가치가 없습니다. 저는 역전 조건(콘텐츠가 대규모로 스크랩되어 재게시되거나, 인용(citation)이 안정화될 경우 재검토)을 기록해 두었으며, 이를 통해 이것이 단순한 기본 설정이 아닌 하나의 결정이 되도록 했습니다.

제가 권장하는 실행 사항

1. 처음 보이는 두 문장 안에 정의를 작성하세요. 스키마(schema) 논쟁은 완전히 건너뛰십시오.
2. 무엇인가를 작성하기 전에 MediaWiki API를 사용하여 엔티티 간극(entity gaps)을 파악하세요.
3. IndexNow를 설정하세요. 그 외의 모든 것은 링크를 통한 발견(discovery-by-links)임을 받아들이십시오.
4. 에지(edge)에서 AI 유저 에이전트(user-agents)를 기록하고, -Bot과 -User의 차이를 익히십시오.
5. 출시 전 인용 기준점(citation baseline)을 기록하세요. 동일한 프롬프트를 사용하여 매달, 영구적으로 수행하십시오.
6. 자신의 로그가 다르게 말하기 전까지는 모든 AEO 연구를 타인의 인구 집단에 대한 데이터로 취급하십시오.

메타 레슨(meta-lesson): 2026년의 AEO는 2003년의 SEO와 같습니다. 벤더(vendors)는 넘쳐나지만 메커니즘(mechanisms)은 부족한 상태입니다. 메커니즘은 검증 가능합니다. 그것들을 검증하십시오.

"추출 가능한 첫 두 문장" 패턴을 실제로 확인하고 싶다면 해당 사이트는 다음과 같습니다: how the engine works, 그리고 이 시리즈의 첫 번째 포스트가 된 true solar time deep-dive입니다.