ChatGPT Search·Perplexity·Gemini AI Overviews는 HTML 문서를 통째로 LLM에 입력하지 않는다. 크롤러가 수집한 HTML을 내부 파서가 헤딩 태그 기준으로 세그먼트(청크)로 분할한 뒤 독립적으로 벡터 임베딩한다. H2·H3 태그는 시각적 계층 표시이기 이전에 AI 파이프라인이 청크 경계를 결정하는 분할 신호다. 잘못된 헤딩 계층은 관련 콘텐츠를 무관한 청크로 분산하거나 이질적 내용을 하나의 청크로 뭉쳐 검색 랭킹과 AI 인용 확률을 동시에 낮춘다.
헤딩이 청크 경계가 되는 메커니즘
오픈소스 RAG 파이프라인을 살펴보면 헤딩 기반 분할이 사실상 표준으로 자리 잡고 있다. LangChain의 HTMLHeaderTextSplitter는 기본값으로 h1~h4를 분할 기준으로 사용하며, 분할된 각 청크에 헤딩 텍스트를 메타데이터로 부착해 쿼리와의 코사인 유사도 계산에 활용한다. 상용 AI 검색 엔진의 내부 파이프라인은 공개되지 않았으나, 동일 원칙을 따른다고 추정할 근거가 충분하다.
- H2 = 1차 청크 경계: 페이지의 주요 토픽을 분리하는 가장 중요한 분할점이다. 각 H2 섹션이 하나의 독립 질문에 완결 답변을 제공해야 단독 인용이 가능하다.
- H3 = 2차 청크 경계: 부모 H2 컨텍스트를 메타데이터로 상속하면서 서브토픽을 다루는 청크를 생성한다. H3 없이 H2 하나에 긴 본문이 이어지면 청크가 비대해져 임베딩 품질이 저하된다.
- 헤딩 텍스트 자체가 의미 벡터 결정 인자: 많은 RAG 파이프라인이 "헤딩 + 본문"을 연결해 임베딩한다. 헤딩 텍스트가 추상적이면 청크 전체의 의미 벡터가 임베딩 공간에서 분산된다.
H1·H2·H3 계층 설계 원칙
계층 건너뜀 금지
H1 직후 H3를 배치하거나 H2 없이 H3를 사용하면 ARIA landmark 파서와 AI 문서 파서 모두에서 계층 구조가 무너진다. H1→H3 건너뜀은 H3를 H1의 직계 자식이 아닌 별도 섹션으로 처리하게 만들어 청크 컨텍스트 상속이 끊긴다.
- 왜: 청크 메타데이터 상속 체계가 H1→H2→H3 순서에 의존하므로, 건너뜀이 있으면 서브토픽이 부모 토픽 컨텍스트 없이 독립 청크가 된다.
- 어떻게: 페이지당 H1 1개, H2로 주요 섹션 분리, H2 하위 세분화만 H3를 사용한다. 시각 크기 조정은 CSS로 처리하되 HTML 태그 레벨은 건너뜀 없이 순차 증가시킨다.
질문형 헤딩으로 쿼리-청크 매핑 최적화
AI 검색 입력은 대부분 자연어 질문 형식이다. H2·H3 텍스트를 해당 섹션이 답하는 질문과 동일하거나 유사하게 작성하면 임베딩 공간에서 코사인 유사도가 높아져 인용 후보로 선택될 가능성이 올라간다.
- 왜: "배터리 수명은 얼마나 되나요?" 쿼리는 임베딩 공간에서 "배터리 수명 개요"보다 "전기차 배터리 수명은 얼마나 되나요?"에 훨씬 가깝게 매핑된다.
- 어떻게: 명사형 헤딩을 질문형으로 전환한다. "가격 비교" → "어떤 제품이 비용 대비 성능이 좋은가".
헤딩 직후 첫 문장에 직접 답변 배치
AI 시스템은 긴 청크에서 핵심 문장을 재추출한다. 헤딩이 질문을 제기하고 첫 1~2 문장이 즉시 답변을 제공하는 구조(heading-lede pattern)는 해당 청크를 단독 인용 가능 단위로 만든다.
- 왜: 답변이 문단 중간이나 끝에 있으면 추출 모델이 헤딩과 답변의 연결을 놓칠 수 있다.
- 어떻게: H2/H3 직후 결론 먼저 방식으로 작성하고, 근거·예시는 그 이후 문단에 배치한다. answer-first 작성 공식과 결합해야 효과가 극대화된다.
구현 예시: 헤딩 구조와 FAQPage 스키마 연동
H2 텍스트와 JSON-LD FAQPage의 Question.name을 일치시키면 Google 리치 결과와 AI Overviews에서 동시에 구조적 노출을 기대할 수 있다. Answer.text에는 H2 직후 첫 문장(직접 답변)을 그대로 사용한다.
<!-- HTML: 헤딩 계층 구조 예시 -->
<article>
<!-- h1은 페이지 타이틀 (CMS 템플릿에서 자동 삽입) -->
<h2>전기차 배터리 수명은 얼마나 되나요?</h2>
<p>일반적으로 8~15년 또는 10만~25만 km이며,
제조사 보증 기준은 잔존 용량 70% 이상 8년·16만 km입니다.</p>
<h3>주행 거리별 배터리 용량 감소율</h3>
<p>...</p>
<h2>배터리 수명을 늘리는 충전 방법은 무엇인가요?</h2>
<p>80% 이상 급속충전 빈도를 낮추고 완속충전을 주로 사용하면
배터리 열화 속도를 줄일 수 있습니다.</p>
<h3>급속충전 vs 완속충전 열화 비교</h3>
<p>...</p>
</article>
<!-- JSON-LD: 헤딩과 1:1 대응하는 FAQPage 스키마 -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "전기차 배터리 수명은 얼마나 되나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "일반적으로 8~15년 또는 10만~25만 km이며, 제조사 보증 기준은 잔존 용량 70% 이상 8년·16만 km입니다."
}
},
{
"@type": "Question",
"name": "배터리 수명을 늘리는 충전 방법은 무엇인가요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "80% 이상 급속충전 빈도를 낮추고 완속충전을 주로 사용하면 배터리 열화 속도를 줄일 수 있습니다."
}
}
]
}
</script>
SEO·AEO·GEO별 헤딩 전략 비교
| 항목 | 전통 SEO | AEO (답변엔진최적화) | GEO (생성형엔진최적화) |
|---|---|---|---|
| H2 형식 | 키워드 포함 명사형 ("배터리 수명") | 질문형 ("배터리 수명은 얼마나?") | 질문형 + 구체 수치 ("8~15년의 근거는?") |
| 첫 문단 역할 | 키워드 자연 배치 | 직접 답변 (50자 이내 권장) | 인용 가능 완결 단위로 설계 |
| H3 역할 | 롱테일 키워드 보조 | 답변 세부 항목 분리 | 청크 세분화로 임베딩 품질 향상 |
| 스키마 연동 | 선택적 (리치 결과 목적) | FAQPage로 H2와 1:1 매핑 | FAQPage + HowTo + Article 복합 |
| 핵심 측정 지표 | 키워드 순위, CTR | Featured Snippet 점유율 | AI 인용 빈도, 브랜드 언급 수 |
흔한 함정: H2를 시각 강조 도구로 오용
본문 중간 특정 문장을 크게 표시하려고 H2·H3를 사용하는 경우가 있다. 예를 들어 "주의: 이 설정은 Pro 플랜에서만 작동합니다" 같은 경고 문구를 H3로 마크업하면, AI 파서는 해당 위치에서 새로운 섹션이 시작된다고 인식하고 앞 내용과 분리된 청크를 생성한다. 이렇게 생성된 짧은 경고 청크는 질문-답변 구조가 없어 인용 가능성이 거의 없으며, 앞 섹션의 청크는 맥락이 잘려 품질이 저하된다.
- 함정 패턴: "크게 보이고 싶다" 목적으로 H2/H3 사용 → 논리 구조와 무관한 청크 경계 생성 → 앞뒤 청크 품질 동시 저하
- 올바른 처리: 강조 목적에는
<strong>·<em>·CSSclass를 사용한다. H2·H3는 반드시 그 아래 본문이 논리적으로 종속되는 실제 섹션 시작점에만 사용한다.
검증 방법
- Chrome DevTools 헤딩 점검: 왜: 계층 건너뜀을 가장 빠르게 발견할 수 있다. 어떻게: DevTools Elements 패널에서 Cmd/Ctrl+F로 "h2" 검색해 H2 순서와 계층이 논리적인지 확인한다.
- WAVE 접근성 검사기 (wave.webaim.org): 왜: 헤딩 구조 오류를 별도 항목으로 보고하며, 접근성 오류와 AI 파서 오류는 높은 상관을 보인다. 어떻게: 브라우저 확장 설치 후 대상 페이지에서 실행하면 계층 오류 위치가 시각적으로 표시된다.
- Google Rich Results Test: 왜: FAQPage JSON-LD의 파싱 오류를 사전 확인해 AI Overviews 채택 확률을 높인다. 어떻게: search.google.com/test/rich-results에 URL 또는 HTML 코드를 직접 입력한다.
- 서버 응답 HTML 직접 확인: 왜: 동적 렌더링 환경에서 헤딩이 실제로 서버 HTML에 포함되는지 도구 없이 가장 확실하게 검증한다. 어떻게:
curl -A "Mozilla/5.0" <URL> | grep -i "<h[1-3]"을 실행해 응답 HTML에 헤딩이 존재하는지 확인한다.
H1은 페이지당 반드시 1개여야 하는가, 여러 개 사용해도 SEO에 문제가 없는가?
Google은 공식적으로 "H1 복수 사용에 SEO 패널티 없음"이라고 밝혔다. 그러나 LangChain HTMLHeaderTextSplitter 등 주요 RAG 파이프라인은 H1을 문서 루트로 처리한다. H1이 복수면 각각이 독립 문서 루트로 파싱되어 청크 계층 구조 상속이 무너질 수 있다. AI 인용 최적화를 우선한다면 H1 1개를 유지하고, 페이지 내 복수 주제는 H2로 분리하는 것이 SEO와 AI 파서 모두에서 안전하다.
JavaScript로 동적 렌더링된 헤딩은 AI 검색 엔진이 읽는가?
Googlebot은 JavaScript를 렌더링해 헤딩을 인식한다. 그러나 Perplexity·Bing Copilot 등 타 AI 검색 엔진의 크롤러는 JavaScript 렌더링 지원이 제한적이라고 추정된다(내부 구현 미공개). React·Next.js SPA에서 헤딩이 클라이언트 렌더링만으로 생성되면 Google 외 AI 엔진에서는 헤딩 구조가 누락될 수 있다. 해결책은 Next.js SSR·SSG 또는 React Server Components로 헤딩을 서버 응답 HTML에 포함시키는 것이다. 점검 방법은 위 curl 명령으로 서버 응답에 헤딩 태그가 존재하는지 직접 확인하는 것이다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.