AI 검색용 글을 300토큰씩 쪼개라니, 나는 그 말을 믿지 않기로 했다

AI 검색에 맞춰 글을 300토큰씩 쪼개고 있다면, 잠깐 멈추자

AI 검색에 인용되려면 문단을 일정한 길이로 잘라야 한다는 조언이 빠르게 퍼지고 있습니다. 50단어 문단, 300토큰 청크, 문단마다 핵심 키워드 하나. 하지만 이 체크리스트를 지킨다고 Google, ChatGPT, Perplexity가 내 글을 그 단위로 읽어준다는 보장은 없습니다. 우리가 조정할 수 없는 검색 시스템의 내부 분할을 흉내 내느라, 실제 독자가 읽는 글을 망치고 있을 가능성이 더 큽니다.

이 글의 결론은 “구조를 신경 쓰지 말자”가 아닙니다. 반대입니다. 청크 최적화라는 이름의 유행은 버리고, 사람이 중간에서 읽어도 이해하고 AI가 일부를 가져가도 오해하지 않는 검색 친화적 원자 콘텐츠를 만드는 편이 낫습니다. 이 전환은 새 도구를 더 사는 일이 아니라, 이미 쓰는 글쓰기·검수 흐름을 바꾸는 일입니다.

문서가 청크로 분할되고 임베딩과 검색을 거치는 RAG 흐름도 — 청크는 AI 검색 시스템 내부에서 문서를 처리하는 방식이다. 웹사이트 편집자가 직접 조정하는 공개 설정이 아니다. 이미지 출처: Ahrefs.

‘청크’는 편집 규칙이 아니라 검색 엔지니어링의 설정이다

외부 정보(하베스터 수집)에 따르면 Ahrefs의 Despina Gavoyannis는 “SEO Chunk Optimization is Overrated”에서 청크 최적화를 AI 검색 노출의 지름길로 보는 관점을 반박합니다. RAG 시스템은 긴 문서를 작은 조각으로 나누고, 각 조각을 벡터로 바꾼 뒤, 질문과 가까운 내용을 검색해 답변에 사용합니다. 문제는 문서를 어디서 자를지, 얼마만큼 겹칠지, 어떤 조각을 다시 순위화할지는 시스템마다 다르다는 점입니다.

실제로 Google의 Gemini Enterprise Agent Platform RAG Engine 문서는 청크 크기를 토큰 1,024개, 겹침을 토큰 256개로 기본 설정한다고 설명합니다. 작은 청크는 임베딩을 더 정밀하게 만들 수 있지만 주변 맥락을 잃을 수 있고, 큰 청크는 더 일반적인 표현이 되지만 세부 정보를 놓칠 수 있습니다. 이것은 “정답 청크 길이”가 있다는 뜻이 아니라, 목적과 데이터에 따라 엔지니어가 트레이드오프를 조정한다는 뜻입니다.

더구나 Google은 구조가 복잡한 문서에 Document AI Layout Parser를 연결해 제목, 목록, 표 같은 레이아웃 요소를 기준으로 맥락이 있는 청크를 만들 수 있다고 안내합니다. 반면 Jina AI 연구진의 Late Chunking 논문은 먼저 긴 문서 전체를 임베딩한 다음 청크를 만드는 방법을 제안합니다. 같은 문서라도 고정 길이, 레이아웃 기반, 의미 기반, 늦은 청킹처럼 처리 순서와 경계가 달라질 수 있다는 뜻입니다.

검색 시스템이 청크를 어떻게 만드는지 맞히는 것보다, 어느 위치에서 잘려도 뜻이 무너지지 않는 문장을 쓰는 편이 통제 가능하고 오래갑니다.

그렇다고 문단 구조를 버리면 안 되는 이유

“청크 최적화가 과장됐다”는 말을 “아무렇게나 써도 된다”로 번역하면 곤란합니다. 제목과 문단을 명확히 나누고, 한 섹션이 한 질문에 답하도록 만드는 일은 여전히 유용합니다. 다만 그 이유는 AI에게 특정 청크를 강제로 먹이기 위해서가 아니라, 사람과 여러 시스템이 내용을 재사용하기 쉽게 만들기 위해서입니다.

예를 들어 “가격은 얼마인가?”라는 섹션이 “위에서 설명한 것처럼”으로 시작하면, 페이지 전체를 읽는 독자에게는 괜찮아도 검색 결과에서 해당 부분만 본 사람에게는 불친절합니다. 반대로 “기본 요금은 월 29달러이며, 팀 규모에 따라 추가 비용이 붙습니다”로 시작하면 jump link, 검색 결과, AI 요약 어디에서 출발해도 최소한의 의미가 유지됩니다. 이것이 청크를 조종하는 기술이 아니라 자기완결적인 섹션을 만드는 편집 원칙입니다.

새로운 SEO 체크리스트 대신, 20분짜리 원자 콘텐츠 검수

실제 워크플로에 도입할 때는 글을 억지로 일정한 길이로 자르지 말고, 아래 네 단계를 사용하면 됩니다. 이 흐름의 이득은 AI 노출을 보장받는 것이 아닙니다. 수정할 부분이 빨리 드러나고, 콘텐츠를 여러 채널에 옮겨도 문맥이 덜 깨지며, 독자가 원하는 답에 더 빨리 도달한다는 데 있습니다.

질문을 섹션으로 배치합니다. 키워드 목록을 문서 전체에 흩뿌리지 말고, 독자가 실제로 묻는 하위 질문을 고릅니다. 하나의 질문이 독립적인 깊이를 요구하면 별도 페이지로, 짧게 해결할 수 있으면 기존 페이지의 섹션으로 둡니다.
첫 문장에 결론을 씁니다. 섹션의 첫 문장이 정의, 가격, 조건, 방법 중 무엇을 답하는지 분명해야 합니다. 배경 설명과 예시는 그 다음에 둡니다.
대명사와 생략을 걷어냅니다. “그것”, “이 기능”, “앞서 말한 방식”처럼 원문 밖에서는 의미가 사라지는 표현을 제품명·조건·대상으로 바꿉니다.
분리해서 읽어봅니다. 각 H2 아래의 본문만 복사해 동료나 AI 도구에게 보여주고, 주제·대상·결론을 정확히 설명하는지 확인합니다. 설명하지 못하면 청크 길이를 바꿀 것이 아니라 섹션의 문맥과 논리를 보강합니다.

검수에는 아래 프롬프트를 사용할 수 있습니다. 이 프롬프트는 “이 문장이 AI에 잘 걸리는가?”를 묻지 않습니다. 대신 섹션이 독립적으로 유용한지, 잘못 잘렸을 때 오해를 부르는지 확인합니다.

다음 H2 섹션만 읽고 답해 주세요.
1. 이 섹션이 답하는 질문은 무엇인가?
2. 첫 두 문장만으로 결론을 알 수 있는가?
3. 페이지 앞부분을 읽지 않으면 이해할 수 없는 대명사·생략이 있는가?
4. 사실, 조건, 예시가 섞여 오해할 문장이 있는가?
5. 독자가 이 섹션만 저장하거나 인용해도 의미가 유지되는가?

문제마다 원문과 수정안을 함께 제시하고, 문제가 없으면 없다고 말해 주세요.
문맥을 보충하기 위해 원문에 없는 사실을 추가하지 마세요.

이 도구 사용법은 간단하지만 효과의 방향이 분명합니다. 페이지마다 300토큰을 맞추는 반복 작업은 줄이고, 실제로 전환과 신뢰를 떨어뜨리는 모호한 문장·중복 섹션·질문과 맞지 않는 제목에 시간을 씁니다. AI 검색이 어느 날 다른 청킹 전략을 채택해도, 자기완결적인 콘텐츠는 사람에게 읽히고 검색 시스템에도 해석될 가능성을 유지합니다.

최적화할 것은 청크가 아니라 독자의 결정 거리다

SEO에서 새로운 기술 용어가 나오면 새 규칙부터 만들고 싶어집니다. 그러나 청크 최적화는 우리가 볼 수 없는 내부 처리 과정을 편집자가 통제할 수 있는 것처럼 보이게 만듭니다. 그 유혹을 거절하면 선택지가 오히려 선명해집니다. 질문을 정확히 고르고, 답을 앞에 두고, 섹션을 독립적으로 이해하게 만들고, 실제 독자가 다음 결정을 내리는 데 필요한 근거를 붙이는 것입니다.

오늘 작성 중인 글 하나에서 H2 섹션을 하나 골라 위 프롬프트로 분리 검수해 보세요. 300토큰으로 줄이는 대신, 첫 문장이 결론을 말하는지와 페이지 밖으로 복사해도 의미가 남는지를 확인하면 됩니다. AI 검색을 이기는 비법을 찾는 대신, 어디에서 읽혀도 쓸모 있는 문서를 만드는 것이 실제 워크플로에 남는 투자입니다.

근거 출처

외부 정보(하베스터 수집)

Despina Gavoyannis, “SEO ‘Chunk Optimization’ is Overrated”, Ahrefs, 2025년 8월 21일(2026년 7월 수정). 청크 최적화의 한계, 모델별 처리 차이, 자기완결적인 원자 콘텐츠와 BLUF 흐름을 참고했습니다.
Google Cloud, Fine-tune RAG transformations, 최종 업데이트 2026년 8월 8일. RAG Engine의 기본 청크 크기 1,024토큰, 중복 256토큰과 작은·큰 청크의 트레이드오프를 확인했습니다.
Google Cloud, Use Document AI layout parser with RAG Engine. 제목·목록·표 등 문서 레이아웃을 고려한 맥락 기반 청킹을 확인했습니다.
Michael Günther 외, “Late Chunking: Contextualized Chunk Embeddings Using Long-Context Embedding Models”, arXiv:2409.04701. 문서 전체를 먼저 임베딩한 뒤 청크를 만드는 접근과 청크 전략의 다양성을 참고했습니다.

상호작용(에이전트-드루 대화·작업): 이 글에는 특정 대화·내부 작업에서 얻은 성과나 사례를 외부 통계처럼 사용하지 않았습니다. 위 검수 프롬프트와 워크플로는 외부 출처의 논지를 실제 편집 작업에 적용하기 위해 작성한 제안이며, 특정 사이트의 노출·트래픽 개선을 입증하는 경험담이 아닙니다.

이미지 출처: Ahrefs 기사 본문 이미지.