몇 주 전, 저는 우리 사이트의 목차(Table of Contents)가 그 누구에게도 렌더링되지 않고 있다는 사실을 발견했습니다.

코드는 있었습니다. CSS도 있었습니다. 수개월 동안 프로덕션(Production) 환경에 배포되어 왔습니다. 하지만 단 한 번도 나타나지 않았는데, 그 이유는 partial이 h2[id]를 찾고 있었던 반면, 우리의 마크다운 렌더러(Markdown renderer)는 오직 <a name="...">만을 생성했기 때문입니다. 즉, 헤딩(Heading) 자체에 id가 없는 레거시 앵커(Legacy anchor) 방식이었습니다. 그래서 셀렉터(Selector)가 모든 기사에서 매번 단 하나의 요소도 일치시키지 못했던 것입니다. 아무도 그것을 보고 있지 않았기에 아무도 눈치채지 못했습니다.

제가 이것을 발견한 이유는 다른 것을 찾고 있었기 때문입니다. 바로 왜 우리의 콘텐츠가 AI 검색 — ChatGPT, Perplexity, Google의 AI Overviews — 에 의해 채택되지 않는가 하는 점이었습니다. 우리는 약 1,600개의 게시된 기사를 보유하고 있습니다. 역사적으로 트래픽도 충분했습니다. 하지만 어떤 답변 엔진(Answer engine)에서도 _인용(Citation)_으로 나타나는 것이 거의 없었습니다.

그 추적 과정은 몇 주간의 작업으로 이어졌습니다. 무엇이 실제로 중요했는지, 무엇이 중요하지 않았는지, 그리고 그 과정에서 제가 틀렸던 것들에 대해 말씀드리겠습니다.

아무도 말해주지 않는 것: 접근성이 우선이다

저는 하루 종일 AEO 체크리스트(AEO는

제가 몰랐던 정말 지독한 함정이 하나 있었습니다. robots 프로토콜에서, 특정 이름이 지정된 user-agent 그룹은 해당 봇에 대해 * 그룹을 **대체(replaces)**합니다. 즉, 병합(merge)되는 것이 아닙니다. 따라서 만약 당신이 "친절하게" User-agent: GPTBot / Allow: / 블록을 추가했다면, 축하합니다. 이제 해당 봇들은 당신의 모든 * disallows(거부 설정)를 무시하고 /reactions, /admin 등 무엇이든 즐겁게 크롤링할 것입니다. 저희는 정확히 이 이유 때문에 GPTBot이 트래킹 엔드포인트(tracking endpoints)에서 크롤링 예산(crawl budget)을 낭비하게 만들었습니다. 해결책은 개별 봇 그룹을 모두 삭제하고, 콘텐츠를 허용하면서 쓰레기 데이터만 차단하는 하나의 User-agent: *를 유지하는 것이었습니다. 봇을 포함한 모든 대상이 이를 따릅니다.

그다음 llms.txt를 추가하세요. 이는 당신의 가장 좋은 URL들을 한 줄의 설명과 함께 수동으로 큐레이션한 plain-text(일반 텍스트) 목록입니다. 이는 모델들을 위한 "읽을 가치가 있는 것들" 파일입니다. 작성 비용이 저렴하며, 하나의 실제적인 관례(convention)가 되어가고 있습니다.

문단을 인용 가능하게 만들기

이 부분이 저에게 깨달음을 준 지점입니다. 답변 엔진(Answer engines)은 페이지를 인용하지 않습니다. 그들은 **구절(passages)**을 인용합니다. 그리고 모델이 깔끔하게 가져갈 수 있는 구절은 다음과 같습니다:

• 실제 질문에 답하는 헤딩(heading) 아래에 위치함 (예: "요구 사항"이 아니라 "70B 모델을 돌리려면 VRAM이 얼마나 필요한가?"),
• "위에서 논의한 바와 같이" 같은 표현 없이, 처음 두 문장 안에 답을 명시함,
• 그리고 그 자체로 하나의 청크(chunk)가 될 수 있을 만큼 충분히 작음 (대략적인 단위는 약 500 토큰입니다).

비교 콘텐츠는 이 지점에서 기대 이상의 성능을 발휘하며, 저는 이제 그 이유를 마침내 이해했다고 생각합니다. 이 시스템들이 사용하는 리랭커(rerankers)는 대조와 부정에 능숙합니다. 즉, "X는 이것을 하지만, Y는 _하지 않는다"와 같은 식입니다. 따라서 아래에 표가 포함된 "Cursor vs Copilot"이라는 제목의 섹션은 기본적으로 이들에게 "미리 씹어서 먹여주는(pre-chewed)" 것과 같습니다.

그리고 — 제 죽어버린 목차 이야기로 돌아가서 — 헤딩에 id를 부여하세요:

<!-- legacy, 부족함
<h2><a name="vram">VRAM</a></h2>

...

파편화하여 주소 지정이 가능한 섹션 (/post#vram)은 모델이 격리하고 인용하기 더 쉽습니다. 저희의 렌더러(renderer)를 수정하는 데는 단 한 줄이면 충분했습니다. 하지만 기존의 1,600개 기사를 수정하는 것은 그 모든 기사를 다시 렌더링해야 함을 의미했습니다. HTML이 실시간으로 생성되는 것이 아니라 저장되어 있었기 때문입니다. 이 단계를 잊지 마세요 — 저도 하마터면 잊을 뻔했습니다.

스키마 (Schema): 유용하지만, 당신이 생각하는 이유 때문은 아니다

네, JSON-LD를 출력하세요. 하지만 Google은 2023년에 대부분의 사이트에 대해 FAQ 리치 결과 (rich results)를 폐지했습니다. 따라서 검색 결과의 작은 드롭다운을 위해 FAQ 스키마를 적용하려 한다면, 그만두세요 — 얻을 수 없을 것입니다. 대신 답변 엔진 (answer engines)이 이를 파싱 (parse)하기 때문에 수행하세요.

마크다운 (markdown)에서 FAQ 스키마를 생성할 때 당신에게 반드시 있을 것이라고 확신하는 버그가 하나 있습니다: 답변 텍스트가 마크다운으로 가득 차 있다는 점입니다. acceptedAnswer.text 안에 들어있는 [link](url)나 **bold**는 파서 (parser)에게 깨진 것처럼 보입니다. 저희도 정확히 이렇게 하고 있었습니다. 저장하기 전에 구문을 제거하세요 — 오직 일반 텍스트 (plain text)만 남겨야 합니다.

하지만 가장 중요하다고 생각하는 것은 사이트 수준의 엔티티 그래프 (entity graph)입니다. 모든 페이지에서 출력되는 Organization + WebSite 블록과, 실제 소셜/프로필 URL을 가리키는 sameAs 배열을 구성하세요. 이것은 이러한 시스템에 "이 도메인은 당신이 소스로 신뢰할 수 있는 일관된 엔티티 (entity)이다"라고 말하는 방법입니다. 만약 스키마 작업을 딱 하나만 해야 한다면, 이것을 하세요.

솔직한 부분

제가 말씀드릴 수 없는 부분은 이것입니다: 이 모든 것이 실제로 효과가 있었는지 여부입니다.

저희의 Google 트래픽은 지난 한 달 동안 여전히 약 24% 감소한 상태입니다. AEO (Answer Engine Optimization) 변화가 일어난 지 불과 며칠밖에 되지 않았습니다. 크롤러 (crawlers)는 자신들만의 주기에 따라 다시 가져오며, 답변 엔진은 느리게 업데이트됩니다. 따라서 변화를 확인할 수 있는 가장 빠른 시점은 몇 주 후가 될 것입니다. 48시간 안에 전후 차이를 보여주겠다고 약속하는 사람은 무엇인가를 팔고 있는 것입니다.

제가 말씀드릴 수 있는 것은 지켜봐야 할 지표이며, 그것은 Google 클릭수가 아닙니다. 바로 인용된 페이지 (cited pages) 입니다 — 당신의 URL 중 얼마나 많은 수가 ChatGPT / Perplexity / AI Overviews 내부에서 소스로 나타나는지를 확인하세요. 이제 이를 보고하는 일부 도구들이 있습니다. 그 수치가 바로 이번 작업에 반응하는 수치입니다. 매주 몇 번씩 추적하되, 일일적인 소음은 무시하세요.

따라서 이것이 바로 실행 전략(playbook)입니다: 크롤러(crawlers)의 접근을 허용하고, 각 단락이 그 자체로 완결성을 갖게 하며, 엔티티(entity)를 일관되게 설명하고, 올바른 지표를 측정하는 것입니다. 이 과정의 대부분은 화려하지 않습니다. 아무에게도 렌더링되지 않은 목차(table of contents)는 이번 작업 전체를 보여주는 적절한 비유입니다. AEO(Answer Engine Optimization)의 절반은 이미 작동하고 있다고 가정했던 사소한 것들을 바로잡는 일입니다.

저는 프롬프트 엔지니어링(prompt engineering) 및 AI 빌더들을 위한 커뮤니티인 PromptZone을 운영하고 있습니다. 위의 모든 내용은 저희의 자체 코퍼스(corpus)에 이 작업을 직접 수행하며 얻은 결과입니다.