Google은 청킹(Chunking)이 필요 없다고 말하지만, 자체 연구 결과는 정반대임을 증명합니다

Google은 청킹(Chunking)이 필요 없다고 말하지만, 자체 연구 결과는 정반대임을 증명합니다.

Google의 공식 AI 검색 가이드라인(2026년 5월)은 퍼블리셔들에게 다음과 같이 안내합니다: "… 콘텐츠를 작은 조각으로 나눌 필요가 없습니다. Google은 여러 주제를 포함하는 페이지를 이해합니다." 이는 합리적으로 들립니다 — Google의 시스템이 실제로 무엇을 하는지 확인하기 전까지는 말이죠.

2024년, Google Research는 현대적인 AI 답변 레이어(answer layers)의 기반이 되는 검색 알고리즘인 MUVERA를 발표했습니다. 이 알고리즘은 페이지를 가져와 각각 별개의 의미론적 블록(semantic block)을 나타내는 구절 수준(passage-level)의 벡터로 분할한 다음, 각 블록을 사용자 쿼리와 개별적으로 비교합니다. 그들의 자체 결과에 따르면: 이전 방식 대비 지연 시간(latency)은 -90%이면서 재현율(recall)은 +10% 향상되었습니다. Google이 AI Overviews를 제공하기 위해 구축한 시스템은 말 그대로 여러분의 콘텐츠를 대신 청킹(chunking)해 주면서, 정작 여러분에게는 청킹에 대해 걱정하지 말라고 말하고 있는 것입니다.

이것은 새로운 일이 아닙니다. 2021년 2월부터 Google은 페이지의 전체 콘텐츠와 무관하게 페이지 내 개별 구절을 독립적으로 순위 매기는 공식 기능인 구절 인덱싱(Passage Indexing)을 운영해 왔습니다. 시스템이 부분(parts)을 순위 매긴다면, 그 부분들의 품질이 중요합니다. 구절 수준의 명확성을 위해 구조를 재조정한 사이트들 — 주제별 H2/H3 앵커, 섹션당 하나의 아이디어 — 은 이전에 내용이 빈약한 경쟁사들에게 돌아갔던 피처드 스니펫(featured snippets)과 PAA(People Also Ask) 슬롯을 확보하기 시작했습니다.

iPullRank의 Mike King은 AI Overviews의 배후에 있는 동일한 검색 레이어인 Gemini API를 대상으로 직접 테스트를 수행했습니다. 그는 "머신러닝 (machine learning)"과 "데이터 프라이버시 (data privacy)"를 동시에 다루는 문단을 가져와 각 주제에 대한 코사인 유사도(cosine similarity)를 측정했습니다:

원래 문단: 0.648 / 0.695
주제별로 깨끗하게 두 개의 파편으로 분할한 후: 0.748 / 0.763

이는 검색 점수(retrieval score)에서 각각 +15.4%와 +9.8%의 상승을 의미합니다. Google이 AI Overviews를 위한 소스를 선택할 때 실제로 사용하는 시스템에서 측정된 결과입니다.

특히 Bing은 어떤 일이 일어나는지에 대해 더 솔직합니다. 그들의 2026년 5월 엔지니어링 블로그(engineering blog)는 "청킹/변환(chunking/transformations)은 답변에 사용되는 의미와 주장(claims)을 보존해야 한다"라고 명시적으로 밝히고 있으며, "콘텐츠를 검색 가능한 청크(chunks)로 분할하고 빠른 조회를 위해 변환하는 과정은 어떤 랭킹 신호(ranking signal)에서도 나타나지 않는 방식으로 페이지의 실질적인 내용을 왜곡할 수 있다"라고 경고합니다. 즉, 당신의 텍스트가 추출 과정에서 온전하게 살아남지 못한다면, AI 답변에는 왜곡된 상태로 들어가거나 아예 들어가지 못한다는 뜻입니다.

그렇다면 왜 Google은 자신들의 인프라와 모순되는 가이드를 계속해서 발표하는 것일까요? 만약 SEO 전문가들이 아무것도 변하지 않았고 청킹(chunking)이 무관하다고 믿는다면, 그들은 GEO/AEO 전문가를 고용하지 않을 것이고, ChatGPT/Perplexity/Claude 최적화를 위한 예산을 할당하지 않을 것이며, Google 외부에서의 브랜드 존재감을 위해 투자하지 않을 것이기 때문입니다. 현상 유지는 Google에게 매우 유리합니다.

이제 명확히 해두자면, 사이트를 수천 개의 마이크로 페이지(micro-pages)로 나누는 것이 정답은 아닙니다. 그 점에 대해서는 Google이 맞습니다. 하지만 페이지 내에서 의미론적 블록(semantic blocks)을 구조화하는 것은 매우 중요합니다. 제가 실제로 한다면 다음과 같이 할 것입니다:

문단당 하나의 아이디어. 각 문단은 하나의 주장(claim)과 그에 대한 근거로 구성합니다. "머신러닝(machine learning)과 데이터 프라이버시(data privacy)는 현대 AI에서 중요한 주제이다"라는 내용을 하나의 블록에 몰아넣지 마십시오. 대신 ML에 관한 블록 하나, 프라이버시에 관한 블록 하나로 두 개의 별도 블록을 만드십시오. 검색 계층(retrieval layer)이 이를 분리할 때, 각 파편(fragment)이 명확한 의미를 유지할 수 있습니다.

페이지의 첫 1/3 지점에 깨끗한 텍스트로 핵심 사실을 배치하십시오. 가격, 사양, 결론, 정의 등은 JS 컴포넌트나 아코디언 패널(accordion panels)이 아닌 일반 텍스트(plain text)여야 합니다. 그것이 그라운딩 계층(grounding layer)이 가장 먼저 읽는 파편입니다.

서사(narrative)가 아닌 출처를 밝힐 수 있는 주장(attributable claims)을 사용하십시오. "많은 전문가들이 페이지 속도가 전환율에 영향을 미친다고 믿는다"라는 문장을 "Google(2024)에 따르면, LCP를 4초에서 2.5초로 줄이면 전환율이 12% 증가한다"로 교체하십시오. 출처(Provenance) — 저자, 날짜, 소스 — 는 AI 시스템이 그라운딩(grounding) 과정에서 검증을 위해 사용하는 요소입니다.

헤딩(Headings)을 검색 앵커(retrieval anchors)로 활용하기. 모든 H2/H3는 그 자체로 완결된 질문이나 문장 역할을 해야 합니다. 나쁜 예: "추가 정보". 좋은 예: "2026년에 페이지 속도가 순위에 영향을 미치는 이유". 시스템은 헤딩과 함께 섹션을 추출하여 완전한 의미 단위(semantic unit)를 얻어야 합니다.

청킹(Chunking)은 RAG 시스템이 여러분의 콘텐츠에 묻지도 않고 수행하는 작업입니다. 유일한 질문은 여러분의 텍스트가 그 의미를 온전히 유지한 채 이 과정을 통과할 수 있느냐 하는 것입니다.