Google AI Overviews·Perplexity·ChatGPT Search가 콘텐츠를 인용할 때, 이 시스템들은 전통 SEO의 검색 의도(search intent) 분류 체계가 아닌 답변 의도(answer intent)라는 별개 판단 기준을 적용한다. 검색 의도가 "이 쿼리를 입력한 사용자가 어떤 페이지에 도달하려 하는가"를 페이지 단위로 분류한다면, 답변 의도는 "AI 시스템이 이 쿼리에 응답하기 위해 출처 콘텐츠에서 어떤 클레임·구조·속성을 추출해야 하는가"를 문장·엔티티 단위로 분석한다. 두 개념의 분기를 이해하지 못하면 검색 SERP 상위에 올라도 AI 답변에서 누락되는 역설이 반복된다.
두 파이프라인의 구조적 차이
전통 검색: 의도 분류 → 페이지 랭킹
Google은 BERT 계열 쿼리 분류기와 Navboost 클릭 데이터를 결합해 쿼리를 정보형·탐색형·거래형·상업 조사형 4가지로 분류한다. 이 분류 결과는 콘텐츠 형식 매칭(블로그 vs 제품 페이지 vs 비교표)과 랭킹 신호(E-E-A-T, 백링크, CTR)에 영향을 미친다. 최적화 단위는 페이지다.
AI 답변: 쿼리 분해 → 클레임 추출 → 교차 인용
AI Overviews·Perplexity의 RAG 파이프라인은 쿼리를 복수의 서브쿼리로 분해한 뒤, 각 서브쿼리에 대한 사실적 클레임을 출처 문서에서 추출하고 복수 출처 간 교차 검증한다. 평가 대상은 페이지 전체가 아니라 문단·문장·구조화 데이터 스니펫이다. 최적화 단위는 클레임(claim)이다.
답변 의도의 4가지 구성 요소
- 사실적 특정성(Factual Specificity): "SEO는 중요하다"가 아니라 "Google AI Overviews가 활성화된 쿼리에서 유기 클릭률이 평균 15~25% 감소했다(2024 Q4 복수 사례 기준 추정)"처럼 수치·맥락이 명시된 클레임. — 왜: LLM은 검증 가능한 구체적 수치를 인용 적합 클레임으로 판단하도록 학습되어 있기 때문; 어떻게: 핵심 문장에 수치 + 출처 + 기간을 한 문장으로 묶어 작성.
- 엔티티 귀속(Entity Attribution): 클레임의 주체·객체가 명확한 엔티티(조직·제품·표준)로 지정되어 지식그래프와 매핑 가능한 형태. — 왜: AI 파서가 모호한 대명사·약어로는 클레임을 엔티티에 귀속시킬 수 없기 때문; 어떻게: 콘텐츠 내 핵심 엔티티 최초 등장 시 공식 명칭과 설명을 병기.
- 구조적 추출 가능성(Structural Extractability): 질문-답변 쌍, 정의 블록, 단계형 목록처럼 AI 파서가 의미 경계를 인식할 수 있는 포맷. — 왜: RAG 청킹 알고리즘이 의미 단위를 분리해 임베딩하기 때문; 어떻게: H2/H3 직후 첫 단락을 "X란 …" 정의형 문장으로 시작.
- 교차 일관성(Cross-source Consistency): 동일 클레임이 복수의 권위 있는 출처에서 동일 형태로 반복 등장. — 왜: AI 시스템이 단일 출처보다 다수 출처 간 일치 클레임을 더 높은 신뢰로 인용하기 때문; 어떻게: 업계 리포트·공식 문서를 1차 출처로 인용하고 동일 클레임을 상호 참조.
구현: JSON-LD로 답변 의도 신호 명시
검색 의도 최적화는 메타 태그·타이틀 최적화로 충분하지만, 답변 의도 최적화는 클레임 수준의 구조화 마크업이 필요하다. 아래는 FAQPage와 Article의 speakable을 결합한 실제 적용 예시다.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"headline": "검색 의도와 답변 의도는 어떻게 다른가",
"author": {
"@type": "Person",
"name": "이서연",
"jobTitle": "GEO 전략 리드"
},
"publisher": {
"@type": "Organization",
"name": "Citeon",
"sameAs": "https://citeon.io"
},
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".key-claim", "h2 + p", "h3 + p"]
},
"datePublished": "2026-06-18",
"dateModified": "2026-06-18"
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "AI 답변 엔진이 콘텐츠를 인용할 때 검색 의도 분류를 적용하는가?",
"acceptedAnswer": {
"@type": "Answer",
"text": "적용하지 않는다. AI Overviews·Perplexity의 RAG 파이프라인은 페이지 단위 의도 분류가 아니라 문장·단락 단위의 클레임 추출과 복수 출처 교차 검증을 수행한다. 최적화 단위가 페이지에서 클레임으로 이동한다."
}
}
]
}
]
}
speakable.cssSelector에 지정한 CSS 선택자 블록이 Google의 음성 답변 및 AI 파서 우선 청킹 대상이 되는 것으로 추정된다(Google 공식 확인 범위 밖, 적용 비용이 낮아 권장).
측정: AI 인용 신호 추적
- AI Overviews 노출 측정: Google Search Console의 "검색 유형: AI Overviews" 필터(2025 Q1 도입)로 impression 추적. — 왜: impression이 있어도 클릭이 낮으면 인용되었으나 답변 내 링크 표시가 억제된 상태일 수 있기 때문.
- Perplexity 인용 확인: 브랜드명·핵심 클레임 문구를 Perplexity에서 직접 쿼리해 인용 소스 URL 노출 여부 점검. — 어떻게:
site:perplexity.ai "[브랜드명]"Google 연산자로 스냅샷 주기 수집. - 클레임-응답 매핑 자동화: 핵심 클레임 문장 10~20개를 추출해 AI 답변에서 동일 또는 패러프레이즈로 등장하는지 Claude/GPT API의 semantic similarity로 비교. — 어떻게: 클레임 문장과 AI 응답 텍스트를 임베딩 후 cosine similarity 0.85 이상을 인용 성공으로 정의.
검색 의도 vs 답변 의도 비교
| 항목 | 검색 의도 (SEO) | 답변 의도 (AEO/GEO) |
|---|---|---|
| 최적화 단위 | 페이지 | 클레임·문장·단락 |
| 분류 기준 | 정보형·탐색형·거래형·상업 조사형 | 사실적 특정성·엔티티 귀속·구조적 추출 가능성·교차 일관성 |
| 1차 신호 | CTR·체류 시간·백링크·E-E-A-T | 구조화 마크업·인용 밀도·엔티티 정합·출처 권위 |
| 측정 도구 | Search Console·SEMrush·Ahrefs | AI Overviews 필터·Perplexity 인용 추적·클레임 임베딩 비교 |
| 콘텐츠 형식 | 롱폼 가이드·비교글·랜딩 페이지 | 정의형 단락·FAQPage·단계형 절차·수치 클레임 블록 |
흔한 오해: "FAQ 섹션을 추가하면 답변 의도를 충족한다"
FAQ 섹션의 존재 자체가 아니라 답변 텍스트의 품질이 핵심이다. "Q: SEO가 중요한가? A: 네, 중요합니다"처럼 추상적 답변은 AI 파서가 인용 가치 있는 클레임으로 분류하지 않는다. FAQPage 스키마를 적용해도 acceptedAnswer.text가 수치·기간·출처 없이 1문장 추상 서술이면 효과가 없다.
올바른 처리법: acceptedAnswer.text에 수치·기간·출처가 포함된 완결형 클레임 1~3문장을 작성한다. 동일 클레임을 본문 H3 직후 첫 단락에도 반복해 교차 일관성을 확보한다. FAQ 페이지를 별도 URL로 분리하기보다 해당 토픽 상세 페이지 하단에 인라인으로 배치하는 것이 클레임 맥락 연속성 유지에 유리하다.
검색 의도 최적화를 완료했는데 AI 답변에서 계속 누락된다. 무엇이 문제인가?
검색 의도 최적화(정보형 쿼리 매칭·E-E-A-T 강화·백링크 확보)와 답변 의도 최적화(클레임 수준 구조화·FAQPage 마크업·speakable 지정)는 별개 레이어다. SERP 상위에 올라도 AI 파서가 추출 가능한 클레임 포맷과 신호가 없으면 인용되지 않는다. 우선 조치: 핵심 클레임 5~10개를 정의형 단락으로 재작성하고, FAQPage JSON-LD에 수치 포함 답변을 추가한 뒤 Search Console AI Overviews 필터로 impression 변화를 4주 간격으로 추적한다.
speakable 스키마가 AI Overviews 인용에 직접적으로 영향을 주는가?
Google이 speakable과 AI Overviews 인용의 직접 인과관계를 공식 확인한 바는 없다. speakable은 원래 Google Assistant 음성 답변을 위해 설계된 스펙이나, cssSelector로 지정된 블록이 AI 파서 우선 청킹 대상이 될 가능성이 구조적으로 추정된다. 구현 비용이 JSON-LD 블록 추가 수준으로 낮고 부작용이 없으므로 적용을 권장하되, 인용 증가를 speakable 단독 효과로 귀속시키는 것은 통제 실험 없이는 불가능하다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.