Google AI Overviews, Perplexity, Bing Copilot은 공통적으로 RAG(Retrieval-Augmented Generation) 파이프라인으로 답변을 생성한다. 이 파이프라인에서 인용 소스 선정은 BM25 키워드 매칭이 아니라 문서를 300~600 토큰 단위 청크로 분할한 뒤, 쿼리 임베딩과의 코사인 유사도로 후보를 추리고 재랭킹(Reranker) 모델이 최종 3~8개를 결정하는 구조다. 기존 SEO 최적화 문서는 이 청크 평가 단계에서 불리하게 작동할 수 있다. 그러나 무조건적인 재구성은 기존 색인 신호를 흐트러뜨릴 위험이 있다. 재구성이 실제로 필요한 조건과 불필요한 조건을 기술적으로 구분하는 것이 출발점이다.
RAG 파이프라인의 인용 결정 구조
AI 검색이 문서를 인용하려면 세 단계를 통과해야 한다.
- 청크 분할: 크롤러가 수집한 HTML 본문을 300~600 토큰 단위로 분할한다. 왜: LLM 컨텍스트 창 제약 때문이다. 어떻게: H2 섹션이 독립적으로 하나의 핵심 개념을 담으면 청크 경계와 개념 경계가 일치해 유사도 계산이 정확해진다.
- 임베딩 검색(Retrieve): 쿼리 벡터와 청크 벡터의 코사인 유사도 상위 N개를 추린다. 왜: 키워드가 없어도 의미적으로 유사한 청크가 선택된다. 어떻게: 청크 내에서 핵심 개념과 문맥이 같은 단위에 있어야 유사도 점수가 올라간다.
- 재랭킹(Rerank): Cross-encoder 모델이 쿼리-청크 쌍의 관련성을 점수화해 최종 인용 소스를 결정한다. 왜: 1단계 벡터 검색의 오탐을 걸러낸다. 어떻게: 출처 신뢰도 신호(E-E-A-T, 저자 구조화 데이터)가 이 단계에서 가중치로 작용하는 것으로 추정된다(Google 비공개).
재구성 필요 여부 판단 기준
모든 페이지를 재구성하는 것은 비효율이다. 아래 기준으로 우선순위를 결정한다.
| 판단 항목 | 재구성 필요 | 재구성 불필요 |
|---|---|---|
| 콘텐츠 형태 | 긴 내러티브, 결론이 중반 이후 등장 | 이미 FAQ·정의형·단계별 구조 |
| AI 인용 현황 | AI Overviews 미노출, Perplexity 무인용 | 이미 AI 검색에서 인용 중 |
| 타겟 쿼리 유형 | 정보형(Informational) 쿼리 | 거래형, 브랜드 지명 검색 |
| 기존 SEO 성과 | 블루링크 2페이지 이하 | 블루링크 1~3위 유지 중 |
| 구조화 데이터 | JSON-LD 없음, 저자 정보 부재 | Article·FAQPage·HowTo 스키마 완비 |
구체적 재구성 구현 방법
청크 친화적 본문 구조
- H2 섹션당 단일 개념 원칙: 각 H2 아래에 하나의 질문에 답하는 단락만 배치한다. 왜: 개념이 분산된 청크는 어떤 쿼리에도 높은 유사도를 얻지 못한다. 어떻게: "X란 무엇인가", "X는 어떻게 작동하는가", "X를 어떻게 측정하는가"를 별도 H2로 분리한다.
- 두괄식 답변 배치: 각 섹션의 첫 1~2문장에 핵심 결론을 먼저 쓴다. 왜: BERT 계열 재랭킹 모델은 청크 시작부와 쿼리 의도의 매칭에 position bias가 있다. 어떻게: 배경 설명을 뒤로 미루고 정의·수치·결론을 먼저 배치한다.
- FAQ 블록 추가: 글 하단에 실제 검색 쿼리 형태의 Q&A를 5~10개 추가한다. 왜: FAQPage 스키마와 결합하면 AI가 직접 인용할 수 있는 독립 청크가 생긴다. 어떻게: Google Search Console 쿼리 보고서에서 CTR 낮은 노출 쿼리를 추출해 FAQ 항목으로 전환한다.
FAQPage JSON-LD 구현
FAQPage 스키마는 AI 검색에서 인용 단위를 명시하는 가장 직접적인 수단이다. 아래는 실제 동작하는 최소 구현이다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "AI 검색용 콘텐츠 재구성은 기존 SEO 순위에 영향을 주는가",
"acceptedAnswer": {
"@type": "Answer",
"text": "재구성 자체는 Google 핵심 랭킹 신호가 아니다. 다만 청크 단위 의미 명확성이 높아지면 Featured Snippet 획득률이 개선되는 경향이 있으며, 이는 AI Overviews 인용과 상관관계를 보인다. 블루링크 순위가 이미 상위라면 구조 개편보다 구조화 데이터 추가가 우선이다."
}
},
{
"@type": "Question",
"name": "llms.txt 파일이 AI 검색 인용에 직접 영향을 주는가",
"acceptedAnswer": {
"@type": "Answer",
"text": "2025년 기준 Googlebot은 llms.txt를 공식 크롤링 지시자로 처리하지 않는다. GPTBot·ClaudeBot 등 일부 AI 크롤러는 참조하는 것으로 알려지나, 인용 가중치 적용 여부는 공개되지 않았다. 크롤 허용 범위 제어는 robots.txt가 현재로서 더 확실한 수단이다."
}
}
]
}
</script>
흔한 오해: "질문형 키워드를 본문에 넣으면 AEO가 완성된다"
제목과 본문에 "~란 무엇인가?", "~하는 방법은?" 같은 질문형 문구를 삽입하면 AI 인용 최적화가 끝난다는 인식이 퍼져 있다. 이는 2016~2018년 Featured Snippet 최적화 기법의 잔재로, RAG 파이프라인과는 직접적인 관계가 없다.
실제 작동 원리: 인용 결정은 쿼리와 청크 간 의미 벡터 유사도와 출처 신뢰도 신호에 의해 이루어진다. 질문형 문구 자체가 임베딩 점수를 높이는 것이 아니라, 그 아래에 있는 독립적으로 완결된 답변 청크가 실제 인용 단위가 된다.
올바른 처리: 질문형 H2/H3 제목을 쓰더라도 그 아래 첫 단락에 키워드 없이도 의미를 전달할 수 있는 완결된 답변 문장을 배치해야 한다. "자세한 내용은 아래를 참고하세요" 같은 지시형 문장은 청크로 분리되었을 때 독립 답변이 되지 못한다.
측정 및 검증
- AI Overviews 노출 추적: Google Search Console의 "검색 결과 유형" 필터에서 AI Overviews 인상 수를 확인한다. 왜: 재구성 전후의 인용 빈도 변화를 정량화한다. 어떻게: 재구성 완료 후 2~4주 대기 후 해당 URL의 AIO 인상 수 변화를 비교한다.
- Perplexity 수동 인용 확인: 타겟 쿼리를 Perplexity에 입력하고 인용 소스 패널에서 자사 URL 포함 여부를 확인한다. 왜: Google과 별개로 자체 인덱스와 재랭킹 모델을 사용하므로 독립 측정이 필요하다. 어떻게: 핵심 쿼리 20~30개를 격주 주기로 수동 점검한다.
- Rich Results Test 검증:
https://search.google.com/test/rich-results에서 JSON-LD 유효성을 확인한다. 왜: 스키마 오류 시 구조화 데이터가 전부 무시된다. 어떻게: 배포 파이프라인에 Rich Results Test API 호출을 통합해 자동화한다.
재구성 없이 구조화 데이터만 추가해도 AI 인용이 늘어나는가
사례에 따라 다르다. 본문이 이미 단일 개념 중심으로 분할되어 있고 블루링크 순위가 상위라면, FAQPage·Article 스키마 추가만으로 AI Overviews 인용이 증가한 사례가 보고된다. 반면 핵심 결론이 글 중반 이후에 등장하는 내러티브 구조라면 스키마 추가 전에 청크 친화적 구조 개편이 선행되어야 한다. 진단 순서: GSC에서 AI 인용 여부 확인 → 없다면 해당 URL을 Perplexity에 직접 입력해 어느 청크가 인용 후보에 오르는지 수동 확인 → 인용 후보 청크가 핵심 내용을 담지 않는다면 구조 개편, 담고 있다면 스키마 보강으로 충분하다.
네이버 AI 검색(큐:)에도 동일한 재구성 전략이 적용되는가
큐:(Cue:)는 네이버 자체 HyperCLOVA X 기반 RAG 파이프라인으로 동작하며, 인용 소스는 네이버 색인(블로그·카페·뉴스·공식 문서) 내로 제한된다. 청크 단위 의미 검색과 답변 생성 구조는 Google AI Overviews와 유사하나 신호 가중치는 상이하다. 네이버 블로그의 경우 스마트에디터 소제목·강조·목록 활용이 HTML 시맨틱과 유사한 역할을 하며, 단문 두괄식 답변 패턴이 큐: 인용에 유리한 것으로 관찰된다(공식 미확인). Schema.org JSON-LD에 대한 네이버 크롤러의 처리 방식은 Google과 다를 수 있으므로, 네이버 서치어드바이저의 구조화 데이터 가이드를 별도로 참조해야 한다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.