Skip to content

청킹 전략 (Chunking)

RAG를 만들 때 첫 단계는 긴 문서를 검색 단위인 조각(chunk) 으로 자르는 일이에요. 문서 전체를 통째로 임베딩하면 한 문장을 검색하려 해도 조각 하나가 너무 커져 의미가 묻히고, 반대로 너무 잘게 자르면 문맥이 끊겨 근거가 불완전해집니다. 이 "얼마나·어떻게 자를까"를 정하는 작업이 청킹(Chunking) 입니다.

청킹은 RAG 품질의 출발점이에요. 검색 품질이 아무리 좋아도 잘못 잘린 조각이면 좋은 근거를 만들 수 없으니까요. 이 페이지는 소스 문서 LangChain Text Splitters 에서 다루는 기준 세 가지(크기·중복·구조)를 중심으로 설명합니다.

상황부터 — 자르는 기준이 왜 문제인가

문서는 토큰 예산과 임베딩 모델의 한계 때문에 통째로 못 넣어요. 그렇다고 마구 자르면 한 문장이 두 조각으로 갈라져 의미가 절반으로 잘리고, 그 조각만 근거로 쓰면 답에 구멍이 나죠. 그래서 "몇 글자 단위로, 얼마나 겹치게, 어떤 경계에서" 자를지를 정하는 게 핵심입니다.

핵심 개념

크기(Chunk Size)

조각을 얼마나 크게 잡을지입니다. 크면 문맥이 풍부해지지만 임베딩이 의미를 제대로 담지 못하고, 작으면 정확도는 오르지만 문맥이 부족해져요. 검색 조각이 LLM에 들어갈 때 토큰 예산도 함께 고려해야 합니다.

중복(Chunk Overlap)

인접한 조각에 겹침을 둬서, 단락 경계에서 정보가 끊기지 않게 합니다. 딱 떨어지는 경계가 아니라 살짝 겹쳐 잘라야 앞뒤 문맥이 유지돼요. 우리는 문서 구조 경계를 기준으로 조각을 겹치게 나눕니다.

구조(문서 단위 기준)

단순히 글자 수로 자르기보다, 문서의 구조 경계(페이지·섹션·블록)를 따라 자르는 게 좋습니다. LangChain의 RecursiveCharacterTextSplitter는 "\n\n", "\n", 공백, 문장부호 순으로 더 큰 경계부터 재귀적으로 잘라 의미 단위를 보존합니다. 한국어·중국어처럼 단어 경계가 없는 언어는 문장 구분자를 별도로 지정할 수 있어요.

사용 사례 / 실제 적용

  • Notion RAG 청킹 — Notion 페이지를 Page·Section·Block 단위로 자르고, 조각마다 Chunk Overlap을 둬 문맥을 유지합니다. 페이지가 수정되면 해당 섹션만 다시 임베딩합니다.
  • 정책문서 청킹 — 인사·복지 정책처럼 조항 단위로 의미가 구분되는 문서는 섹션 경계로 잘라, 조항 하나가 조각 하나가 되게 합니다.
  • 근거 연결 — 조각마다 출처(문서·위치)를 남겨, 답의 문장 하나하나가 어느 조각에서 나왔는지 추적할 수 있게 합니다.

더 알아보기