청킹
청킹(Chunking)은 RAG에서 긴 문서를 검색과 임베딩에 적합한 작은 단위(청크)로 나누는 작업입니다. 분할 방식과 청크 크기, 오버랩이 검색 정확도와 답변 품질을 좌우하므로 RAG 파이프라인 설계의 핵심 단계로 다뤄집니다.
- 청킹은 RAG에서 문서를 검색·임베딩에 알맞은 작은 단위로 나누는 작업으로, 청크가 검색의 최소 단위가 되므로 분할 품질이 곧 답변 품질을 결정합니다.
- 대표 전략은 고정 크기, 재귀(recursive), 문서 구조 기반, 시맨틱, 컨텍스트 기반(late chunking 포함)이며, 대부분의 경우 재귀 분할이 균형 잡힌 기본값입니다.
- Pinecone은 출발점으로 512토큰 청크에 50~100토큰 오버랩을 제시하며, 업계 통념은 오버랩 10~20%입니다.
- 청크 크기는 임베딩 모델의 입력 길이, 콘텐츠 유형, 예상 질의 형태를 기준으로 정하고, 실제 코퍼스에서 벤치마크로 튜닝해야 합니다.
- Anthropic의 컨텍스트 검색(Contextual Retrieval)은 각 청크에 설명 맥락을 덧붙여 임베딩하여 상위 20개 청크 검색 실패율을 최대 49%까지 낮췄습니다.
청킹이란
청킹(Chunking)은 RAG(검색 증강 생성) 파이프라인에서 긴 원문을 임베딩과 벡터 검색에 적합한 작은 조각, 즉 청크(chunk)로 나누는 작업입니다. 검색 단계는 질의와 의미적으로 가까운 청크를 찾아 LLM에 컨텍스트로 전달하므로, 청크가 검색·인용의 최소 단위가 됩니다. 따라서 어떻게 자르느냐가 검색 정확도와 최종 답변 품질을 직접 좌우합니다.
청크가 지나치게 크면 하나의 청크에 여러 주제가 섞여 임베딩이 흐려지고 불필요한 정보가 컨텍스트에 들어가 답변이 희석됩니다. 반대로 지나치게 작으면 문장이나 논지가 도중에 끊겨 맥락이 사라지고, 정작 필요한 정보가 흩어져 검색에서 누락됩니다. 청킹의 목표는 이 둘 사이에서 의미가 온전히 보존되는 단위를 찾는 것입니다.
청킹 전략 비교
실무에서 쓰이는 대표적인 청킹 전략은 다음과 같습니다. 시맨틱 청킹은 이 가운데 한 갈래이며, 청킹은 이러한 전략 전반을 아우르는 상위 개념입니다.
| 전략 | 분할 기준 | 장점 | 한계 |
|---|---|---|---|
| 고정 크기 (fixed-size) | N 토큰(또는 글자) 단위로 일정하게 절단, 선택적 오버랩 | 구현이 가장 단순하고 청크 크기가 균일 | 문서 구조를 무시해 문장·논지를 중간에서 끊음 |
| 재귀 분할 (recursive) | 문단→줄바꿈→공백→글자 순으로 구분자를 적용하며 목표 크기까지 분할 | 외부 모델 없이 문서 구조를 대체로 보존, 범용 기본값 | 구분자에 의존하므로 구조가 빈약한 문서엔 효과 제한 |
| 문서 구조 기반 (document-based) | 제목·섹션·표·코드 블록 등 문서가 제공하는 구조를 그대로 활용 | 법률·기술 문서·API 문서 등 구조가 뚜렷한 자료에 적합 | 구조가 일관되지 않은 일반 텍스트엔 적용이 어려움 |
| 시맨틱 청킹 (semantic) | 문장 임베딩의 유사도로 주제가 바뀌는 경계를 찾아 분할 | 자연스러운 의미 경계를 따라 청크를 형성 | 청크 크기가 들쭉날쭉하고 임베딩 연산 비용이 추가됨 |
| 컨텍스트 기반 (contextual / late) | 청크에 문서 맥락을 덧붙여 임베딩하거나, 전체 문서를 먼저 임베딩한 뒤 분할 | 주변 맥락을 보존해 검색 정확도를 끌어올림 | LLM 호출이나 긴 컨텍스트 모델이 필요해 비용·복잡도 증가 |
권장 파라미터와 근거
Pinecone의 청킹 가이드는 출발점으로 512토큰 청크에 50~100토큰 오버랩을 제시하며, 콘텐츠가 짧고 사실 위주이면 128~256토큰 같은 작은 청크를, 맥락이 중요하면 512~1024토큰 같은 큰 청크를 시험해 보라고 권합니다. 오버랩(인접 청크가 일부 내용을 공유하도록 겹치는 부분)은 청크 경계에서 맥락이 끊기는 손실을 줄여 주며, 업계 통념상 청크 크기의 10~20%를 출발점으로 잡습니다.
재귀 분할의 표준 구현인 LangChain의 RecursiveCharacterTextSplitter는 구분자 목록 ["\n\n", "\n", " ", ""]를 우선순위대로 적용하여 문단을 먼저 살리고, 그래도 크면 줄바꿈·공백·글자 순으로 잘라 문서 구조를 최대한 보존합니다. 공식 문서의 예시 파라미터는 다음과 같습니다.
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=100, # 청크 최대 크기
chunk_overlap=20, # 인접 청크 간 겹침
)
chunks = splitter.split_text(document)청크 크기는 절대적인 정답이 없으며, 사용하는 임베딩 모델의 입력 길이, 콘텐츠 유형, 예상 질의 형태에 맞춰 정하고 실제 코퍼스에서 벤치마크로 검증해야 합니다. 토큰 단위가 아니라 글자 단위로 자르면 임베딩 모델의 토큰 한계와 어긋날 수 있으므로, 분할 길이 함수는 사용하는 임베딩 모델의 토크나이저에 맞추는 것이 안전합니다.
청크 자체의 맥락 부족을 보완하는 방향도 활발히 연구됩니다. Anthropic의 컨텍스트 검색(Contextual Retrieval)은 각 청크에 그 청크가 문서 어디에 속하는지를 설명하는 맥락을 LLM으로 생성해 덧붙인 뒤 임베딩합니다. 발표에 따르면 이 컨텍스트 임베딩만으로 상위 20개 청크 검색 실패율이 35%(5.7%→3.7%) 줄었고, 컨텍스트 BM25를 결합하면 49%(5.7%→2.9%), 리랭킹까지 더하면 최대 67%까지 감소했습니다. 프롬프트 캐싱을 쓰면 문서 100만 토큰당 약 1.02달러로 청크 맥락을 생성할 수 있어 비용 효율도 확보됩니다. 또한 Jina AI가 제안한 레이트 청킹(Late Chunking, arXiv:2409.04701, 2024)은 청크를 먼저 자르지 않고 긴 컨텍스트 모델로 문서 전체를 임베딩한 뒤 토큰 임베딩을 청크 단위로 묶어, 분할 과정에서 사라지던 전역 맥락을 보존합니다.
실행 체크리스트
- 기본값으로 재귀 분할(문서 유형별 구분자 적용)을 채택하고, 특별한 이유가 없으면 여기서 출발하십시오.
- 512토큰 청크 + 오버랩 10~20%(50~100토큰)로 시작한 뒤 조정하십시오.
- 분할 길이 함수를 임베딩 모델의 토크나이저에 맞춰 토큰 단위로 측정하십시오.
- 제목·표·코드 등 구조가 뚜렷한 문서라면 문서 구조 기반 분할을 우선 검토하십시오.
- 시맨틱 청킹은 추가 비용을 쓰기 전에 자사 코퍼스에서 재귀 분할 대비 실제 개선이 있는지 벤치마크로 확인하십시오.
- 청크 맥락 부족이 검색 실패의 원인이라면 컨텍스트 임베딩이나 레이트 청킹을 도입해 보십시오.