청킹은 RAG 시스템이 문서를 검색과 임베딩 단위로 잘게 나누는 전처리 작업입니다. 잘린 조각 하나를 청크(chunk)라고 부릅니다. 이 글은 AI와 RAG 맥락의 청킹을 다룹니다. 인지심리학에서 기억 단위로 정보를 묶는 청킹과는 다른 쓰임입니다.
먼저 정리할 것이 있습니다. 이 단어는 시스템을 만드는 개발자의 작업을 가리키는 말인데, SEO 업계에서 글을 AI용으로 짧게 쪼개 쓰라는 조언으로 옮겨붙었습니다. 둘은 이름만 같은 다른 행위이고, 뒤쪽 조언은 구글이 공식 문서에서 불필요하다고 지목했습니다.
이 글은 Google 검색 센터의 생성형 AI 최적화 가이드와 Pinecone, LangChain, LlamaIndex, Anthropic의 공식 기술 문서를 기준으로 작성했습니다.
RAG 파이프라인에서 청킹이 하는 일
많은 RAG 시스템은 긴 문서를 저장하기 전에 검색 가능한 조각으로 나눕니다. 임베딩 모델의 토큰 한도에 맞추고 질문과 비교할 검색 단위를 만들기 위해서입니다. 작은 문서는 자르지 않고 넣을 수도 있습니다.
자르는 전략은 기술 문서들이 공통으로 다루는 네 갈래가 있습니다.
- 고정 크기: 토큰이나 글자 수 기준으로 자릅니다. 가장 단순해서 출발점으로 권장됩니다
- 재귀 분할: 문단, 문장, 단어 순으로 큰 단위를 최대한 보존하며 자릅니다
- 문서 구조 기반: 마크다운 헤딩이나 HTML 태그처럼 원래 문서의 구조를 경계로 씁니다
- 시맨틱 청킹: 임베딩으로 주제가 바뀌는 지점을 찾아 그곳을 경계로 삼습니다
인접한 조각끼리 일부를 겹치게 하는 청크 오버랩은 경계에서 문맥이 끊기는 것을 완화하는 선택 장치입니다. 필수 요소는 아니고, 공식 예시 코드들도 오버랩 없이 쓰는 경우가 많습니다.
청킹에는 알려진 한계도 있습니다. 조각만 봐서는 어느 회사, 어느 시점 이야기인지 맥락이 사라지는 문제인데, Anthropic은 조각 앞에 설명을 덧붙여 저장하는 보완 기법을 공개했고, 문서가 충분히 작으면 아예 자르지 않고 통째로 넣는 선택지도 있다고 안내합니다. 자르는 방식이 검색 품질을 좌우하다 보니 계속 개선되는 영역입니다.
콘텐츠 청킹 통설과 구글의 공식 부정
문제는 이 개발 용어가 콘텐츠 조언으로 변형된 쪽입니다. AI가 이해하기 좋게 문단을 잘게 쪼개고 글을 조각내 쓰라는 조언이 AEO, GEO 전술로 팔리는데, 구글은 생성형 AI 최적화 가이드의 통설 바로잡기 섹션에서 이를 정면으로 부정합니다. AI가 더 잘 이해하도록 콘텐츠를 잘게 쪼갤 필요가 없으며, 구글 시스템은 한 페이지 안의 여러 주제를 구분해 관련 구간을 사용자에게 보여줄 수 있고, 이상적인 글 길이는 없으니 생성형 AI 검색이 아니라 독자를 위해 페이지를 만들라는 내용입니다.
헤딩과 문단 구조가 중요하지 않다는 뜻이 아닙니다. 같은 가이드가 명확한 구조를 권장하는데, 이유가 AI 파싱이 아니라 사람 독자와 스크린리더 같은 접근성 도구입니다. 사람이 읽기 좋은 구조를 만들면 기계도 잘 읽는 것이지, 기계용으로 글을 조각내는 것이 아니라는 인과 방향이 공식 문서의 입장입니다.
검색 실무자가 가져갈 것
청킹을 알아 두는 실익은 글을 쪼개는 기술이 아니라 판단력입니다.
- 자체 RAG에서 청크 검색을 쓴다면 어떤 문서 조각이 질문에 검색됐는지 로그로 확인할 수 있습니다. 공개 AI 검색 서비스가 모든 웹페이지를 같은 방식으로 자른다고 단정할 수는 없습니다
- 문단을 몇 문장으로 끊어라, AI용 글 길이가 따로 있다 같은 조언을 들으면 구글 공식 가이드의 부정을 근거로 걸러낼 수 있습니다
- RAG 구축 프로젝트에 관여하게 되면, 청킹 전략이 검색 품질을 좌우하는 설계 변수라는 것을 알고 대화할 수 있습니다
AVCD는 독자가 내용을 찾기 쉽도록 구간별 완결성을 챙기되, 이를 AI 인용 전술로 주장하지 않습니다. 글의 길이와 호흡은 독자 기준으로 정합니다.
자주 묻는 질문
청크 크기는 몇 토큰이 적당한가요?
정답이 없습니다. 공식 기술 문서들의 예시는 수백에서 천 토큰 안팎을 오가고, 데이터와 질문 유형에 따라 테스트로 정하라는 것이 공통 안내입니다. 이 질문 자체가 시스템 구축자의 설계 변수이지, 글쓴이가 맞춰야 할 규격이 아니라는 점이 더 중요합니다.
문단을 짧게 쪼개면 AI 검색에 잘 걸리나요?
그런 요건은 없습니다. 구글은 AI가 이해하기 좋게 콘텐츠를 잘게 쪼갤 필요가 없다고 공식 문서에 명시했고, 이상적인 글 길이도 없다고 밝힙니다. 짧은 문단이 독자에게 읽기 좋다면 그렇게 쓰는 것이고, AI를 위한 조각내기는 근거 없는 통설입니다.
그럼 헤딩과 문단 구조는 왜 강조되나요?
사람을 위해서입니다. 명확한 구조는 독자가 원하는 구간을 찾게 돕고 스크린리더 같은 도구의 탐색을 돕는다는 것이 구글의 공식 설명입니다. 결과적으로 기계가 읽기에도 좋아지지만, 순서가 사람 먼저입니다.
청킹과 컨텍스트 윈도우는 무슨 관계인가요?
청킹이 필요한 이유 중 하나가 컨텍스트 윈도우입니다. 모델이 한 번에 처리할 수 있는 토큰 한도가 있어서 긴 문서를 그 안에 들어가는 조각으로 나누는 것입니다. 모델의 한도가 커지면서 문서가 작을 때는 자르지 않는 선택지도 생겼습니다.
함께 알아두면 좋은 용어
- RAG: 청킹이 전처리 단계로 들어가는 구조
- 임베딩: 청크를 비교 가능한 벡터로 바꾸는 표현
- 토큰: 청크 크기를 재는 단위
- AI 검색 최적화: 콘텐츠 청킹 통설을 다루는 실무 문서