AI 검색 준비성을 위한 4계층 모델: 360개 사이트를 감사하며 배운 점

저는 구조화된 AI 검색 준비성 (AI-search-readiness) 프레임워크를 바탕으로 360개의 도메인을 감사했습니다. 평균 점수는 100점 만점에 54.1점이었습니다. "양호 (Good)" 이상의 점수를 받은 곳은 **24.7%**에 불과했습니다. 100점 만점의 완벽한 점수는 2026년 7월이 되어서야 처음 나타났습니다.

이 포스트에서는 제가 사용한 네 가지 계층 모델인 **접근성 (Access), 방향성 (Orientation), 이해도 (Understanding), 인용 가능성 (Quotability)**을 각 계층에 대한 실제 코드 예시, 그 뒤에 있는 벤치마크 데이터, 그리고 제가 반복해서 목격한 인프라 오류와 함께 살펴봅니다.

만약 당신이 개발자나 기술 리드(tech lead)라면, 마케팅 팀이 왜 ChatGPT가 당신의 문서를 인용하지 않는지 묻기 전에 운영화해야 할 프레임워크가 바로 이것입니다.

핵심 논지: AI 검색은 순위를 매기는 것이 아니라 선택한다

전통적인 SEO는 순위(ranking)의 문제입니다. 페이지를 최적화하고, 순위를 높이며, 결과 페이지의 슬롯을 차지하기 위해 경쟁하는 것입니다.

생성형 검색(Generative search) — ChatGPT, Perplexity, Google AI Overviews — 은 선택(selection)의 문제입니다. 모델은 쿼리(query)를 받으면 어떤 소스를 참조할지 결정하고, 구절을 추출하며, 소스를 인용하거나 출처 표기 없이 말을 바꿉니다. '2페이지'란 존재하지 않습니다. 인용되거나, 아니면 보이지 않거나 둘 중 하나입니다.

선택받기 위해서는 다음 네 가지가 순차적으로 작동해야 합니다:

1. 접근성 (Access) — AI 크롤러(crawler)가 당신의 콘텐츠에 도달할 수 있어야 함
2. 방향성 (Orientation) — 사이트에서 중요한 것을 찾아낼 수 있어야 함
3. 이해도 (Understanding) — 당신의 조직과 페이지가 무엇에 관한 것인지 파싱(parse)할 수 있어야 함
4. 인용 가능성 (Quotability) — 인용할 수 있는 독립된 구절을 추출할 수 있어야 함

핵심 원칙: 스키마 (schema)를 수정하기 전에 접근성을 수정하고, 콘텐츠를 수정하기 전에 스키마를 수정하십시오. 순서가 틀리면 작업이 낭비됩니다. 저는 이 패턴을 반복해서 보았습니다. 팀들이 robots.txt가 GPTBot을 차단하고 있는 동안 "AI 최적화"를 위해 콘텐츠를 다시 작성하고 있는 모습을 말입니다.

코드를 통해 계층별로 살펴보겠습니다.

계층 1: 접근성 (Access) — AI 크롤러가 당신에게 도달할 수 있는가?

접근성은 robots.txt, 정적 HTML 전달, 서버 응답 동작, 그리고 렌더링(rendering)에 관한 것입니다. 가장 화려하지 않은 계층이자 가장 흔한 실패 지점입니다.

현재 웹을 활발하게 인덱싱(indexing)하고 있는 AI 크롤러(crawler)는 최소 11개입니다. 각 크롤러는 고유한 User-Agent 토큰을 가지고 있습니다:

벤치마크 결과, 사이트당 평균 23.2개의 봇이 허용된 것으로 나타났습니다. 하지만 이 평균치는 정작 자신들에게 필요한 크롤러를 정확히 차단하고 있는 수많은 사이트들의 실태를 가리고 있습니다.

robots.txt: AI 크롤러 허용하기

개인적인 경로(private paths)는 잠가 두면서 주요 AI 크롤러를 명시적으로 허용하는 최소한의 robots.txt 예시입니다:

# 주요 AI 크롤러의 공개 콘텐츠 접근을 허용합니다
User-agent: GPTBot
Allow: /
...

렌더링의 함정 (The Rendering Trap)

더 미묘한 접근 이슈는 바로 **클라이언트 사이드 렌더링 (client-side rendering)**입니다. 만약 귀하의 사이트가 초기 HTML 응답에서 빈 <div id="root"></div>를 반환하는 SPA(Single Page Application)라면, 많은 AI 크롤러는 아무것도 보지 못합니다. GPTBot과 PerplexityBot은 JavaScript를 안정적으로 실행하지 않습니다. 이들은 정적 HTML(static HTML)을 읽습니다.

만약 콘텐츠가 React/Vue/Svelte의 하이드레이션 (hydration) 단계 뒤에 존재한다면, 다음 중 하나가 필요합니다:

• HTML에 콘텐츠가 포함되도록 하는 SSR (서버 사이드 렌더링, server-side rendering) 또는 SSG (정적 사이트 생성, static site generation),
• 또는 봇 User-Agent에게 캐시된 HTML을 제공하는 프리렌더링 (prerendering) 계층

크롤러가 실제로 무엇을 보는지 확인해 보세요:

curl -A "GPTBot" https://example.com | grep -i "your main heading"

만약 아무것도 반환되지 않는다면, 귀하의 콘텐츠는 크롤러에게 보이지 않는 상태입니다. 다른 무엇보다 이것부터 해결하십시오.

계층 2: 방향성 (Orientation) — 중요한 것을 찾을 수 있는가?

크롤러가 귀하의 사이트에 도달하면, 무엇이 중요한지 알아야 합니다. 방향성(Orientation)은 llms.txt, 사이트맵 (sitemaps), RSS 피드, 그리고 우선순위 URL 신호를 다룹니다.

이 항목은 전체 감사 결과에서 가장 성적이 저조한 카테고리였습니다:

• AI 발견 (AI Discovery) 채택률: 17.5%
• AI 발견 (AI Discovery) 효율성: 10%

llms.txt 수치는 구체적인 이야기를 들려줍니다:

• llms.txt 채택률: 54.2% — 하지만 6월의 58.3%에서 하락했습니다. 사이트들이 이를 제거하고 있습니다.
• 완전한 llms.txt: 단 26.9% — 나머지는 부분적이거나 형식이 잘못되었습니다.

잘못 작성된 llms.txt는 아예 없는 것보다 나쁩니다. 이는 모델에게 도로가 빠진 지도를 보내는 것과 같습니다.

llms.txt 최소 예시

llms.txt 표준은 사이트 루트(root)에 위치한 일반 텍스트(plain-text) 파일로, AI 크롤러(crawler)에게 콘텐츠의 구조화된 요약을 제공합니다:

# Example Company

> Example Company는 AI 기반 검색을 위한 개발자 인프라를 구축합니다.
...

주요 규칙:

• # 라인은 사이트 제목입니다.
• > 라인은 한 문장 요약입니다.
• ## 섹션은 링크들을 그룹화합니다.
• 각 링크는 - [제목](URL): 설명 형식입니다. 여기서 설명은 매우 중요하며, 해당 URL에 무엇이 있는지에 대한 컨텍스트(context)를 모델에게 제공합니다.

모든 블로그 포스트를 나열하지 마세요. "이 사이트는 무엇인가?"와 "무엇을 하는가?"라는 질문에 답할 수 있는 페이지들을 나열하세요.

계층 3: 이해 (Understanding) — 모델이 당신이 누구인지 파싱(Parse)할 수 있는가?

크롤러가 당신의 사이트에 도달하여 우선순위 콘텐츠를 찾았습니다. 이제 엔티티(entity)를 이해하기 위한 구조화된 데이터가 필요합니다. 즉, 당신이 누구인지, 사이트가 무엇을 하는지, 페이지들이 어떤 질문에 답하는지를 알아야 합니다.

이해(Understanding)는 Schema.org JSON-LD, 메타 태그(meta tags), 그리고 엔티티 신호(entity signals)를 의미합니다.

벤치마크 데이터

• 스키마(Schema) 채택률: 75.6% — 6월의 70.1%에서 상승했습니다. 긍정적인 추세입니다.
• Organization 스키마: 52.2% — 사이트의 절반 정도만이 크롤러에게 자신이 누구인지 알려주고 있습니다.
• WebSite 스키마: 58.9%
• FAQ 스키마: 18.1% — 13.2%에서 상승했으나, 질문-답변 추출을 위해 직접 설계된 스키마 유형치고는 여전히 현저히 낮습니다.

"일부 스키마를 보유함" (75.6%)과 "AI 인용(citation)에 중요한 스키마 유형을 보유함" (52% / 59% / 18%) 사이의 격차가 바로 대부분의 사이트가 뒤처지는 지점입니다.

Organization + WebSite JSON-LD 템플릿

이를 홈페이지의 <head> 섹션에 넣으세요. 값들을 실제 데이터로 교체하십시오.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
...

@graph 구조를 사용하면 하나의 블록 내에서 여러 엔티티(Organization + WebSite)를 선언하고 @id를 통해 서로 참조할 수 있습니다. 이것이 모델에게 "이 조직(organization)이 이 웹사이트(website)를 발행한다"라고 알려주는 방법이며, 이는 엔티티 모호성 해소(entity disambiguation)에 중요한 관계입니다.

FAQ 페이지의 경우, 관련 페이지에 다음을 추가하세요:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
...

FAQ 스키마 (schema)는 질문-답변 추출을 위한 직접적인 통로입니다. 모델이 Question과 acceptedAnswer 쌍이 포함된 FAQPage를 인식하면, 해당 답변을 그대로 가져올 수 있습니다. 18.1%라는 채택률이 매우 뼈아픈 이유는, 이 스키마 유형이 인용(quote)을 얻는 것과 가장 직접적으로 연결되어 있음에도 불구하고 82%의 사이트가 이를 갖추고 있지 않기 때문입니다.

계층 4: 인용 가능성 (Quotability) — 독립적인 구절을 추출할 수 있는가?

마지막 계층은 콘텐츠 아키텍처 (content architecture)입니다. 모델은 콘텐츠가 인용될 수 있도록 구조화되어 있을 때만 여러분의 내용을 깔끔하게 인용할 수 있습니다. 즉, 직접적인 답변, 결론 우선 방식 (BLUF, bottom-line-up-front), 짧고 독립적인 단락 구조가 필요합니다.

이 계층은 대부분의 팀이 건너뛰는 단계입니다. 그들은 robots.txt를 수정하고, llms.txt를 추가하며, 스키마 (schema)를 구현하지만, 정작 콘텐츠는 답변을 다섯 번째 단락에 묻어버리는 2,000단어 분량의 서사적 구조로 남겨둡니다.

이전: 서사적 구조 (인용하기 어려움)

# 우리 API의 속도 제한 (Rate Limiting) 처리 방식

2023년에 처음 API를 출시했을 때, 저희는 속도 제한(rate limiting)
...

이 내용을 읽는 모델은 흩어진 문장들로부터 답변을 합성해야 합니다. 모델은 출처를 밝히지 않고 의역하거나, 더 깔끔한 다른 소스를 찾아 이 소스를 건너뛸 가능성이 높습니다.

이후: BLUF 구조 (인용하기 쉬움)

# 우리 API의 속도 제한 (Rate Limiting) 처리 방식

우리 API는 지수 백오프 (exponential backoff)를 사용하는 **고정 윈도우 카운터 (fixed window counter)**를 통해 속도 제한을 적용합니다.
...

첫 번째 단락이 그 자체로 독립적입니다. 모델은 이를 다음과 같이 직접 인용으로 추출할 수 있습니다: "우리 API는 지수 백오프를 사용하는 고정 윈도우 카운터를 통해 속도 제한을 적용합니다. 기본 제한은 API 키당 분당 100회 요청입니다." 이는 전체 페이지의 맥락 밖에서도 의미가 통합니다. 이것이 바로 인용 가능성 (quotability)입니다.

규칙: 모든 페이지는 핵심 질문에 대한 독립적인 답변으로 시작해야 합니다. 세부 사항은 그 아래에 배치합니다. 답변이 먼저 와야 합니다.

상관관계 데이터: 실제로 점수를 움직이는 요소

이번 감사는 단순히 도입 여부뿐만 아니라 그 영향력(impact)까지 측정했습니다. 상관관계는 4계층 모델을 뒷받침하는 가장 강력한 증거입니다:

llms.txt가 있는 사이트는 없는 사이트보다 20점 더 높았습니다. Schema가 있는 사이트는 28점 더 높았습니다. 이것은 마법이 아닙니다. llms.txt 파일 하나가 서버 문제를 해결해주지는 않습니다. 하지만 이는 방향성(orientation)과 이해(understanding) 신호에 투자하는 사이트들이 전반적으로 우수한 성과를 내는 사이트와 동일하다는 것을 보여줍니다. 각 계층은 복리로 작용합니다.

일반적인 인프라 실수

1. robots.txt에서 실수로 AI 크롤러를 차단하는 경우. CMS, 보안 플러그인 또는 보일러플레이트(boilerplate) 템플릿이 GPTBot에 대해 Disallow: /를 추가했고 아무도 이를 검토하지 않았을 수 있습니다. curl https://example.com/robots.txt를 사용하여 robots.txt를 확인하세요. 실제로 직접 읽어봐야 합니다.

2. 프리렌더(prerender) 폴백(fallback)이 없는 클라이언트 사이드 렌더링 (Client-side rendering). SPA(Single Page Application)가 빈 껍데기만 반환하면 AI 크롤러는 아무것도 볼 수 없습니다. SSR/SSG를 사용하거나 봇 유저 에이전트(user-agents)에게 프리렌더링된 HTML을 제공하세요. curl -A "GPTBot" https://example.com으로 확인해 보세요.

3. 불완전한 llms.txt. 깨진 링크, 누락된 섹션, 또는 홈페이지만 나열된 llms.txt는 아예 없는 것보다 못합니다. 도입률(54.2%)과 완전한 구현(26.9%) 사이의 27점 격차는 시중에 있는 llms.txt 파일의 절반이 고장 난 지도라는 것을 의미합니다.

4. 일반적인 Schema만 사용하는 경우. 블로그 게시물에 Article schema를 사용하는 것은 기본 중의 기본입니다. AI 인용(citation)을 유도하는 Schema 유형은 Organization (당신은 누구인가?), WebSite (이 사이트는 무엇인가?), 그리고 FAQPage (답변은 무엇인가?)입니다. 대부분의 사이트는 이 중 어느 것도 갖추고 있지 않습니다.

5. 접근성(access)을 확보하기 전에 콘텐츠를 수정하는 경우. 저는 어떤 팀들이 robots.txt가 모든 AI 크롤러를 차단하고 있는 동안 "AI 최적화"를 위해 콘텐츠를 다시 쓰는 데 몇 주를 소비하는 것을 보았습니다. 순서는 협상의 여지가 없습니다: 접근(Access) → 방향성(Orientation) → 이해(Understanding) → 인용 가능성(Quotability). 단계를 건너뛰면 부서진 토대 위에 건물을 짓는 것과 같습니다.

벤치마크의 현주소

360개 도메인 감사 완료. 평균 점수 54.1/100. 75.3%가 Foundation(기초) 또는 Critical(중요) 단계에 해당. 100/100 만점 사례는 7월에 처음 등장함.

전통적인 SEO (검색 엔진 최적화)와 GEO (생성형 엔진 최적화) 사이의 격차는 측정 가능하며 구조적입니다. 이는 키워드나 백링크의 문제가 아닙니다. AI 크롤러(Crawler)가 귀하의 콘텐츠에 도달할 수 있는지, 스스로 방향을 잡을 수 있는지, 엔티티(Entities)를 이해할 수 있는지, 그리고 깨끗한 구절을 추출할 수 있는지에 관한 문제입니다. 네 가지 계층은 순차적으로 구성되며, 각 계층은 다음 계층을 가능하게 합니다.

개발자들에게 전하는 좋은 소식은 다음과 같습니다. 모든 계층은 인프라 변경을 통해 수정 가능하다는 점입니다. robots.txt는 텍스트 파일입니다. llms.txt도 텍스트 파일입니다. JSON-LD는 스크립트 태그입니다. BLUF (Bottom Line Up Front)는 편집 패턴입니다. 이 중 그 어떤 것도 마케팅 대행사를 필요로 하지 않습니다. 프레임워크를 이해하는 엔지니어가 필요할 뿐입니다.

이제 당신이 그 역할을 할 수 있습니다.

전체 매뉴얼은 160페이지 분량입니다. 4가지 계층 모두를 심도 있게 다루는 15개의 장, 사용자 에이전트(User-agent) 토큰을 포함한 11개의 AI 크롤러, JSON-LD 템플릿이 포함된 12가지 스키마(Schema) 유형, 8가지 프롬프트 인젝션(Prompt injection) 공격 벡터, 그리고 인용 측정 워크플로우를 담고 있습니다. geoready.dev/geo-readiness-manual/에서 무료로 다운로드하세요.