전통 검색에서 답변 엔진으로: 검색의 패러다임 전환

웹 검색의 결과 생성 파이프라인이 교체되고 있다. 전통 검색은 역색인(inverted index)과 BM25 스코어링으로 문서를 랭킹한 뒤 URL 목록을 반환했다. ChatGPT Search·Perplexity·Google AI Overviews는 동일한 쿼리를 받아 관련 문서를 회수(retrieve)하고, LLM이 그 문서를 컨텍스트로 주입받아 자연어 답변을 직접 생성한다. 이 파이프라인 교체는 "무엇이 가시성을 결정하는가"의 신호 집합을 바꾸며, 기존 SEO 설정만으로는 답변 엔진 인용을 보장할 수 없다.

전통 검색 엔진의 기술 파이프라인

전통 검색의 핵심은 역색인이다. 크롤러가 수집한 문서를 토큰 단위로 분해하고, 각 토큰에 대해 등장 문서와 빈도를 색인한다. 랭킹은 두 레이어로 작동한다.

• 관련성 스코어 (BM25/TF-IDF): 쿼리 토큰이 문서에 얼마나 자주, 희귀하게 등장하는지 계산한다. 왜: 키워드 밀도가 주제 관련성의 일차 지표이기 때문이다. 어떻게: 본문 내 쿼리 키워드 배치와 H2·H3 헤딩 사용이 BM25 점수에 직접 기여한다.
• 권위 신호 (PageRank 계열): 인바운드 링크의 양과 품질로 외부 권위를 측정한다. 왜: 링크는 편집자의 명시적 추천이므로 신뢰 지표로 쓰인다. 어떻게: 고품질 도메인 링크 획득이 핵심 전술이다.
• 출력 형식: SERP 10개 링크를 반환하며, 사용자가 클릭해 원본 문서로 이동한다. 측정 지표는 인상(impression)과 CTR이다.

답변 엔진의 RAG 파이프라인

ChatGPT Search·Perplexity·Google AI Overviews는 모두 RAG(Retrieval-Augmented Generation) 구조를 채택한다.

1. 쿼리 분석: LLM이 입력을 인텐트(정보형·거래형·탐색형)와 엔터티로 분해한다. 왜: 인텐트에 따라 검색 전략과 생성 스타일이 달라지기 때문이다. 어떻게: "최저가 노트북 추천"은 거래형으로 분류되어 최신성 가중 검색이 실행된다.
2. 하이브리드 검색(Retrieval): BM25 키워드 검색과 밀집 벡터 검색(dense retrieval)을 병합한다. 왜: 키워드 검색은 정확 매칭에 강하고 벡터 검색은 의미적 유사성에 강해 상호 보완된다. 어떻게: 상위 K개 청크(chunk, 보통 512~2048 토큰)를 LLM 컨텍스트 윈도우에 주입한다.
3. 생성(Generation): LLM이 회수된 청크를 근거로 자연어 답변을 생성하고 출처 URL을 인용한다. 왜: 파라미터 지식만 쓰면 할루시네이션과 최신성 한계가 있기 때문이다. 어떻게: 문서 내 개별 문장이 독립적으로 이해 가능할수록 청크로 추출·인용될 가능성이 높아진다.

패러다임 전환이 바꾸는 최적화 신호

구현: robots.txt와 llms.txt 설정

답변 엔진이 콘텐츠를 소비하려면 크롤러 허용과 콘텐츠 힌트 파일이 올바르게 구성되어야 한다.

# robots.txt — 주요 AI 크롤러 명시 허용 예시
User-agent: Googlebot
Allow: /

# OpenAI 웹 검색 크롤러 (ChatGPT Search 색인용)
User-agent: GPTBot
Allow: /blog/
Allow: /docs/
Disallow: /admin/
Disallow: /user/

# OpenAI 실시간 검색 전용 (2024~ 추가)
User-agent: OAI-SearchBot
Allow: /blog/
Allow: /docs/

User-agent: PerplexityBot
Allow: /blog/
Allow: /docs/

User-agent: ClaudeBot
Allow: /blog/
Allow: /docs/

Sitemap: https://example.com/sitemap.xml

# llms.txt — 사이트 루트 배치 (https://example.com/llms.txt)
# Anthropic 제안 사양 기반 (2024, 비공식 표준화 진행 중)

# Site
> Citeon: GEO·AEO·SEO 전문 마케팅 기술 블로그

## Blog
- [AEO와 GEO는 같은 말일까](https://example.com/blog/aeo-vs-geo): 기술 아키텍처 차이와 구현법
- [AI 검색 가시성(SOV)](https://example.com/blog/ai-sov): AI SOV 정의·측정·최적화 전략

## Docs
- [JSON-LD 스키마 가이드](https://example.com/docs/schema): Article·FAQ·HowTo 예시

## Optional
- [전체 마크다운 아카이브](https://example.com/llms-full.txt)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "전통 검색에서 답변 엔진으로: 검색의 패러다임 전환",
  "datePublished": "2026-06-18",
  "dateModified": "2026-06-18",
  "author": {
    "@type": "Person",
    "name": "이서연",
    "jobTitle": "GEO 전략 리드",
    "url": "https://example.com/authors/seoyeon-lee"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Citeon",
    "url": "https://example.com"
  },
  "description": "역색인·BM25 기반 전통 검색과 RAG 파이프라인 기반 답변 엔진의 기술 구조 차이 분석",
  "articleSection": "기초 개념",
  "keywords": ["GEO", "AEO", "SEO", "RAG", "답변 엔진", "AI 검색 가시성"]
}
</script>

흔한 오해: "Google SEO가 좋으면 AI 인용도 자동으로 된다"

이 가정은 부분적으로만 맞다. E-E-A-T와 콘텐츠 품질은 SEO와 GEO 모두에 긍정적으로 작용하지만, 크롤러 허용 여부는 별개 문제다.

• 실제 함정: User-agent: * 블록에 Disallow: /가 있으면 GPTBot·PerplexityBot도 차단된다. Google SEO를 위해 Googlebot만 Allow하고 나머지를 전체 차단한 설정이 AI 크롤러를 조용히 막고 있는 사례가 실무에서 자주 발견된다.
• 올바른 처리: User-agent: * 블록을 점검하고, 각 AI 크롤러를 위 예시처럼 명시적으로 Allow한다. 허용 여부는 curl -A "GPTBot" https://example.com/blog/sample-post로 HTTP 상태코드를 직접 확인할 수 있다. 200이 반환되어야 한다.

가시성 검증과 측정

답변 엔진 가시성은 Google Search Console로 측정되지 않는다.

1. 서버 로그에서 AI 크롤러 활동 확인: 왜: 크롤링이 없으면 색인도 없고, 색인이 없으면 인용도 없기 때문이다. 어떻게: grep -E "GPTBot|PerplexityBot|ClaudeBot|OAI-SearchBot" /var/log/nginx/access.log | awk '{print $1,$7}' | sort | uniq -c | sort -rn
2. AI SOV 수동 측정: 타깃 쿼리 100~200개를 ChatGPT Search·Perplexity·AI Overviews에 질의하고, 자사 도메인 인용 횟수를 집계한다. 왜: 플랫폼마다 색인과 검색 전략이 달라 SOV가 다르게 나타나기 때문이다. 어떻게: Perplexity API 또는 OpenAI API(search 도구 활성화)로 배치 자동화 가능하다.
3. 구조화 데이터 유효성 확인: Google Rich Results Test로 JSON-LD schema.org 준수 여부를 검증한다.

참고 자료

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

• Google 검색 센터 — SEO 기본 가이드
• GEO: Generative Engine Optimization (arXiv 2311.09735)
• Google 검색의 AI 기능과 내 웹사이트