RAG 청킹 전략(chunking strategy)은 문서를 임베딩 모델과 검색 시스템이 다룰 수 있는 단위로 나누는 규칙이다. 단순히 512토큰마다 자르는 전처리 단계가 아니라, 검색 정확도·컨텍스트 비용·업데이트 복잡도를 함께 결정하는 RAG 데이터 모델링의 핵심이다.
왜 청킹이 중요한가
RAG는 “문서를 검색해 LLM 프롬프트에 넣는 구조”처럼 보이지만, 실제 검색 대상은 원문 전체가 아니라 청크다. 부정 표현과 대상 문장이 갈라지거나, 코드 블록이 중간에서 끊기거나, 표의 열 관계가 사라지면 임베딩은 이미 훼손된 의미를 벡터화한다. 좋은 리랭커나 최신 임베딩 모델도 잘못 잘린 청크의 의미 손실을 완전히 복구하지 못한다.
청킹과 파싱(parsing)도 구분해야 한다. 파싱은 PDF, HTML, Markdown, Office 문서에서 논리 구조를 추출하는 단계이고, 청킹은 그 구조를 검색 가능한 단위로 나누는 단계다. 파싱이 나쁘면 청킹도 실패하지만, 파싱이 좋아도 청킹 설계가 없으면 프로덕션 질의 부하를 견디기 어렵다.
7가지 전략 비교
| 전략 | 핵심 아이디어 | 적합한 경우 | 주요 리스크 |
|---|---|---|---|
| 고정 크기 + 오버랩 | 토큰 수 기준으로 일정하게 자르고 일부 겹침 | 로그, 평문 스트림, 빠른 인제스트 | 의미 경계 파괴, 벡터 DB 팽창 |
| 문장 윈도우 검색 | 문장은 작게 임베딩하고 검색 후 주변 문장을 확장 | 법률, 의료, 고밀도 사실 문서 | 중복 윈도우 병합 필요 |
| 구조 기반 청킹 | H1/H2, 문단, 리스트, DOM 경계 기준 분할 | API 문서, 계약서, 보고서 | 큰 섹션은 fallback 분할 필요 |
| 의미 기반 청킹 | 문장 간 임베딩 유사도 변화로 경계 감지 | 회의록, 인터뷰, 장문 내러티브 | 비용·지연 증가, 임계값 튜닝 난해 |
| 계층형 청킹 | 작은 child 청크와 큰 parent 청크를 함께 관리 | 세부 질의와 요약 질의가 공존 | parent-child 동기화와 삭제 복잡도 |
| LLM 명제 기반 청킹 | LLM이 원자적 사실이나 자연 경계를 추출 | 고가치 비정형 데이터 | 비결정성, JSON 오류, 텍스트 누락 |
| 표·멀티모달 보존 | 표·그림을 별도 객체로 추출하고 요약 임베딩 | 재무 보고서, 논문, 정량 문서 | 주변 문맥 분리, 넓은 표 처리 문제 |
전략별 설계 포인트
고정 크기 청킹
가장 단순하고 빠르다. 균질한 로그나 구조가 거의 없는 텍스트에서는 여전히 실용적이다. 다만 오버랩을 늘릴수록 인제스트 비용과 저장량이 선형으로 증가한다. 기본값으로 시작할 수는 있지만, 제품 품질을 기대하는 RAG에서는 장기 해법으로 두기 어렵다.
문장 윈도우 검색
검색 단위는 작게 유지하고, 생성 모델에 넣을 때는 주변 문장을 함께 제공한다. 세밀한 사실을 잘 찾으면서도 맥락을 잃지 않는 장점이 있다. 단, 인접 문장 여러 개가 동시에 검색되면 같은 주변 문맥이 반복될 수 있으므로 retrieval middleware에서 겹치는 윈도우를 병합해야 한다.
구조 기반 청킹
Markdown heading, HTML DOM, 문단, 리스트 같은 문서 구조를 그대로 활용한다. 각 청크에 상위 제목 경로를 붙이면 청크가 원래 어떤 섹션에 속했는지 유지할 수 있다.
H1: 제품 보안 정책 > H2: 데이터 보존 > [본문 청크]API 문서와 계약서처럼 heading hierarchy가 의미를 담는 문서에서는 기본 전략으로 둘 만하다. 문제는 섹션 크기가 일정하지 않다는 점이다. 큰 섹션이 임베딩 모델 길이를 넘을 때 보조 분할 규칙을 준비해야 한다.
의미 기반 청킹
문장별 임베딩을 만든 뒤 인접 문장 사이의 cosine similarity가 크게 떨어지는 지점에서 분할한다. 구조가 없는 회의록이나 음성 전사처럼 주제가 갑자기 바뀌는 문서에 유리하다. 대신 모든 문장을 먼저 임베딩해야 하므로 인제스트 비용이 높고, 전역 임계값 하나로 다양한 문서군을 처리하기 어렵다.
계층형 청킹
작은 청크는 검색 정밀도를, 큰 청크는 생성 맥락을 담당한다. 예를 들어 256토큰 child 청크를 검색하고, 같은 1024토큰 parent에 속한 child가 충분히 많이 검색되면 parent를 프롬프트에 넣는다. 이 방식은 질의 범위가 “정확한 수치 하나”부터 “전체 섹션 요약”까지 넓을 때 유용하다.
운영 난도는 높다. 문서 업데이트 시 child와 parent의 무효화, 삭제, 재색인을 함께 처리해야 한다.
LLM 명제 기반 청킹
LLM에게 문서를 읽히고 원자적 명제(proposition) 또는 자연스러운 경계 목록을 JSON으로 출력하게 한다. 불규칙하지만 가치가 높은 데이터에서는 좋은 청크가 제품 품질을 직접 좌우할 수 있다. 다만 LLM 기반 인제스트는 비결정적이다. 누락, 환각, malformed JSON을 잡는 검증 파이프라인 없이 실시간 인제스트에 넣으면 위험하다.
표·멀티모달 보존 청킹
표와 그림은 일반 텍스트처럼 자르면 열 관계와 공간 정보가 사라진다. 표는 원본 Markdown/HTML을 보존하고, 검색용으로는 표의 의미를 요약한 텍스트를 임베딩한 뒤, 최종 프롬프트에는 원본 표를 넣는 방식이 안정적이다. 과학 논문, 재무 보고서, 정량 리포트에서 특히 중요하다.
프로덕션에서는 청킹 이후가 더 중요하다
초기 실험은 청킹 전략 선택에 집중하지만, 운영 100일 이후의 문제는 index lifecycle management다. 문서가 수정되면 오래된 청크, 중복 청크, orphan chunk가 생긴다. 이를 방치하면 검색 결과에 낡은 정보가 섞이고, 같은 맥락이 반복 주입되어 토큰 비용과 지연이 증가한다.
실무 파이프라인에서는 다음을 함께 설계해야 한다.
- 원문 content hash 기반 deterministic chunk ID
- 문서 버전별 삭제와 재색인 정책
- parent-child chunk cascade invalidation
- 중복 컨텍스트 병합
- TTL과 stale chunk pruning
- 검색 결과에 chunk provenance와 문서 버전 노출
선택 기준
| 문서 유형 | 우선 전략 |
|---|---|
| 로그·평문 스트림 | 고정 크기 + 낮은 오버랩 |
| API 문서·기술 문서 | 구조 기반 청킹 |
| 법률·의료 문헌 | 문장 윈도우 검색 |
| 회의록·인터뷰 | 의미 기반 청킹 |
| 질의 범위가 넓은 지식 베이스 | 계층형 청킹 |
| 고가치 비정형 지식 추출 | LLM 명제 기반 청킹 |
| 표·그림 중심 문서 | 표·멀티모달 보존 청킹 |
관련 문서
- rag — 외부 지식을 LLM에 실시간으로 주입하는 검색 증강 생성 기술
- adaptive-chunking — 문서별 최적 청킹 전략 자동 선택 프레임워크
- voyage-context-4 — 청킹 고민을 줄이는 문맥 인식 임베딩 모델
- rag-tips-production — 프로덕션 RAG에서 문서 레지스트리와 무중단 인덱스를 설계하는 법
- rag-tips-scale-million-documents — 대규모 문서 집합에서 RAG 검색과 컨텍스트를 확장하는 설계
참고 자료
- 7 Chunking Strategies That Decide Whether Your RAG Works — Machine Learning Mastery (2026-08-05)