RAG 청크 전략의 정답은 문서 구조에 달렸다 — 정형 문서는 재귀적, 비정형은 시멘틱 청크가 유리하다. RAG 파이프라인을 구축할 때 대부분의 시간은 임베딩 모델과 벡터 DB를 고르는 데 쓰이지만, 실제로 검색 정확도를 가장 크게 흔드는 변수는 RAG 청크 전략인 경우가 많다.
같은 문서, 같은 임베딩 모델, 같은 벡터 DB를 써도 청크 방식을 바꾸는 것만으로 검색 recall이 눈에 띄게 달라진다. 문제는 “고정 크기 청크”, “재귀적 청크”, “시멘틱 청크” 중 무엇이 정답인지에 대한 합의가 아직 없다는 점이다.
이 글은 LangChain·LlamaIndex의 실제 기본값, Chroma 연구팀이 공개한 토큰 단위 평가 방법론과 그 결과, 그리고 시멘틱 청크가 항상 우월하지는 않다는 것을 보여준 2026년 최신 논문까지 근거로 삼아 네 가지 청크 전략을 비교한다. 실제 검색 수요가 있는 “어떤 청크 방식을 써야 하는가”라는 질문에 코퍼스 유형별 답을 제시하는 것이 목표다.
목차
- 핵심 비교표
- 고정 크기 청크 (Fixed-size Chunking)
- 문장 기반 청크 (Sentence-based Chunking)
- 재귀적 청크 (Recursive Character Splitting)
- 시멘틱 청크 (Semantic Chunking)
- 데이터로 보는 청크 전략의 실제 영향
- FAQ
- 결론 및 상황별 추천
핵심 비교표
기준일: 2026-08-07. LangChain·LlamaIndex 공식 문서와 Chroma 연구팀 자료를 근거로 정리했다.
| 항목 | 고정 크기 | 문장 기반 | 재귀적 | 시멘틱 |
|---|---|---|---|---|
| 구현 난이도 | 매우 낮음 | 낮음 | 낮음 | 중간~높음 |
| 대표 도구 | CharacterTextSplitter | LlamaIndex SentenceSplitter | LangChain RecursiveCharacterTextSplitter | LangChain SemanticChunker, Chroma ClusterSemanticChunker |
| 기본값 | 지정 문자 수 | 1024 토큰(DEFAULT_CHUNK_SIZE) | 구분자 [“\n\n”,”\n”,” “,””] 순차 재귀 | 임베딩 유사도 breakpoint(고정 크기 없음) |
| 추가 비용 | 없음 | 낮음(문장 토크나이저) | 없음 | 높음(청크마다 임베딩 호출) |
| 적합한 문서 | 균일한 로그·짧은 텍스트 | 일반 산문, FAQ | 대부분의 실무 문서(기본 선택지) | 주제 전환이 잦은 비정형 텍스트 |
| 단점 | 문장·문단 중간 절단 | 문단 간 맥락 손실 가능 | 여전히 크기 기준이라 의미 경계와 불일치 가능 | 비용·지연시간 증가, 항상 우월하지 않음 |
고정 크기 청크 (Fixed-size Chunking)
고정 크기 청크는 문서를 지정한 문자 수 또는 토큰 수 단위로 기계적으로 자르는 방식이다. 보통 청크 사이에 일부 구간을 겹치게(overlap) 두어, 경계에서 문맥이 완전히 끊기는 것을 완화한다. 예를 들어 chunk_size 500, overlap 50으로 설정하면 각 청크는 앞 청크의 마지막 50자를 포함한 채 시작한다.
RAG 청크 전략 중 가장 단순한 형태인 만큼 장점도 명확하다. 구현이 가장 단순하고, 처리 속도가 빠르며, 청크 개수와 크기를 완전히 예측할 수 있다. 로그 파일이나 형식이 균일한 짧은 텍스트에는 이 방식만으로도 충분한 경우가 많다. 하지만 단점도 그만큼 뚜렷하다. 문장이나 문단 중간에서 잘리는 일이 흔하고, 그 결과 임베딩이 완전한 의미 단위를 담지 못해 검색 시 관련 있는 청크가 낮은 순위로 밀리는 문제가 발생한다. 대부분의 실무 파이프라인에서 고정 크기 청크는 베이스라인 이상의 역할을 하지 못한다.
문장 기반 청크 (Sentence-based Chunking)
문장 기반 청크는 문자 수가 아니라 문장 경계를 기준으로 분할한다. LlamaIndex의 SentenceSplitter가 대표적이며, 공식 소스 기준 DEFAULT_CHUNK_SIZE는 1024 토큰이다. 문장 단위로 먼저 나눈 뒤 지정 크기에 도달할 때까지 문장을 이어 붙이는 방식이라, 청크 중간에 문장이 잘리는 일이 구조적으로 줄어든다.
이 방식은 RAG 청크 전략을 처음 설계할 때 고정 크기보다 한 단계 나은 기본 선택지로 꼽힌다. 문장 경계를 지키기 때문에 문법적으로 불완전한 청크가 줄고, 임베딩 품질도 함께 개선되는 경향이 있다. 다만 문장은 지켜도 문단이나 섹션 단위의 큰 맥락은 여전히 크기 제한에 걸려 끊길 수 있다. 표나 코드 블록처럼 문장 구조가 없는 콘텐츠에는 적합하지 않다는 한계도 있다.
재귀적 청크 (Recursive Character Splitting)
재귀적 청크는 LangChain의 RecursiveCharacterTextSplitter로 대표되는, 현재 실무에서 가장 널리 쓰이는 방식이다. 공식 문서 기준 기본 구분자 리스트는 [“\n\n”, “\n”, ” “, “”] 순서로, 먼저 문단 경계(\n\n)로 나누기를 시도하고, 청크가 여전히 크면 줄바꿈, 그다음 공백, 최후에는 글자 단위로 재귀적으로 쪼갠다. “문단 → 문장 → 단어” 순으로 최대한 의미 단위를 지키려는 설계다.
이 접근이 인기 있는 이유는 단순하다. 별도 임베딩 호출이나 외부 모델 없이도, 순수 규칙 기반으로 고정 크기 방식보다 훨씬 자연스러운 경계를 만들어내기 때문이다. Chroma 연구팀도 “적절히 파라미터를 조정한 RecursiveCharacterTextSplitter가 실전에서 자주 좋은 성능을 낸다”고 보고했다. 다만 여전히 chunk_size라는 상한선이 존재하기 때문에, 긴 문단이 있는 문서에서는 의미 경계와 크기 경계가 어긋나는 경우가 남는다.
시멘틱 청크 (Semantic Chunking)
시멘틱 청크는 크기 기준을 아예 버리고, 문장 간 임베딩 유사도가 급격히 떨어지는 지점을 청크 경계(breakpoint)로 삼는다. 이 아이디어는 Greg Kamradt가 처음 제안했고, 이후 LangChain이 SemanticChunker로 구현해 공개했다. 인접한 문장들을 임베딩한 뒤 코사인 유사도가 임계값 아래로 떨어지는 지점에서 잘라내는 방식으로, 결과적으로 “주제가 바뀌는 지점”에서 청크가 나뉜다.
Chroma 연구팀은 여기서 한 걸음 더 나아가 ClusterSemanticChunker와 LLMChunker라는 두 가지 실험적 전략을 제안했다. ClusterSemanticChunker는 임베딩 유사도를 기준으로 문장을 클러스터링해 지정 크기 안에서 청크를 구성하고, LLMChunker는 LLM에게 직접 분할 지점을 판단하게 한다. 두 방식 모두 관련 코드는 GitHub 저장소 brandonstarxel/chunking_evaluation에 공개돼 있다. 다만 시멘틱 청크는 청크마다 임베딩 호출이 필요해 비용과 지연시간이 늘어난다는 점, 그리고 뒤에서 다룰 최신 연구에서는 이 방식이 항상 더 나은 성능을 내지 않는다는 점도 함께 고려해야 한다.
데이터로 보는 청크 전략의 실제 영향
Chroma 연구팀의 기술 리포트 “Evaluating Chunking Strategies for Retrieval”은 기존 IR 벤치마크(MTEB 등)가 문서 단위 관련성만 평가해 청크 단위 성능을 반영하지 못한다는 문제를 지적하며, 정밀도·재현율·IoU(Jaccard 지수)를 토큰 단위로 계산하는 새로운 평가 방식을 제안했다. 이 평가로 여러 청크 전략을 비교한 결과, 전략 선택에 따라 재현율(recall)이 최대 9%p까지 차이 났다고 보고했다. 임베딩 모델이나 벡터 DB를 바꾸는 것보다 청크 전략을 바꾸는 쪽이 더 큰 폭의 개선으로 이어질 수 있다는 뜻이다.
그러나 시멘틱 청크가 만능은 아니다. 2026년 7월 공개된 논문 “Evaluating Chunking Strategies for Retrieval-Augmented Generation on Academic Texts”(arXiv:2607.01852)는 구조화된 학위논문 코퍼스를 대상으로 RAGAs 프레임워크를 이용해 cluster 기반 시멘틱 청크와 고정 크기·재귀적 청크를 비교했다. 결과는 예상과 달랐다. 테스트한 설정에서 cluster 기반 시멘틱 청크가 더 단순한 전략보다 우수하지 않았고, 문서별 질문과 고정 질문 사이의 성능 편차가 문서 포맷과 전처리 방식에 크게 좌우됐다. 즉, 문서가 이미 목차·섹션 구조로 잘 정리돼 있다면 비싼 시멘틱 청크 없이도 재귀적 청크만으로 충분한 성능이 나올 수 있다는 뜻이다. 청크 전략의 효과는 코퍼스 특성에 따라 뒤집힐 수 있으므로, 배포 전 자신의 데이터로 직접 검증하는 것이 가장 중요하다.
FAQ
Q1. RAG 청크 크기는 몇 토큰이 적당한가요?
정답은 코퍼스에 따라 다르지만, LlamaIndex SentenceSplitter 기본값인 1024 토큰이 실무에서 흔히 쓰이는 출발점이다. 짧은 FAQ성 문서는 256~512, 긴 기술 문서는 800~1200 토큰대에서 시작해 재현율을 측정하며 조정하는 것이 안전하다.
Q2. 시멘틱 청크가 항상 더 정확한가요?
아니다. Chroma 연구에서는 전략에 따라 재현율이 최대 9%p 차이 났지만, 2026년 7월 발표된 arXiv:2607.01852 논문은 구조화된 학위논문 코퍼스에서 cluster 기반 시멘틱 청크가 고정·재귀적 청크보다 우수하지 않았다고 보고했다. 문서 구조가 잘 잡혀 있을수록 시멘틱 청크의 이점은 줄어든다.
Q3. 청크 오버랩(overlap)은 얼마나 둬야 하나요?
일반적으로 chunk_size의 10~20% 수준이 널리 쓰인다. 예를 들어 chunk_size가 500이면 overlap 50~100 정도다. 너무 크게 두면 저장 공간과 임베딩 비용만 늘고, 너무 작으면 경계에서 맥락이 끊기는 문제가 다시 나타난다.
Q4. 임베딩 모델·벡터 DB와 청크 전략 중 무엇을 먼저 바꿔야 하나요?
Chroma 연구가 보여주듯 청크 전략 하나만으로도 재현율이 크게 흔들리므로, 새 임베딩 모델이나 벡터 DB를 도입하기 전에 청크 전략부터 자신의 데이터로 검증하는 순서를 권장한다. 값비싼 인프라 교체보다 비용 대비 효과가 크다.
결론 및 상황별 추천
빠르게 프로토타입을 만들어야 한다면 LangChain의 RecursiveCharacterTextSplitter를 기본값 그대로 쓰는 것이 가장 합리적이다. 별도 비용 없이 고정 크기보다 뚜렷하게 나은 경계를 얻을 수 있다. 매뉴얼·논문·법률 문서처럼 이미 목차와 섹션 구조가 뚜렷한 코퍼스라면 재귀적 청크에 문장 기반 분할을 더한 혼합 전략으로 충분하며, arXiv:2607.01852의 결과가 보여주듯 굳이 비싼 시멘틱 청크를 도입할 필요가 크지 않다. 반대로 대화 로그, 사용자 후기, 형식이 자유로운 문서처럼 주제 전환이 잦은 비정형 텍스트를 다룬다면 시멘틱 청크가 추가 비용을 감수할 만한 이득을 줄 가능성이 높다.
가장 중요한 원칙은 하나의 전략을 정답으로 고정하지 않는 것이다. Chroma 연구팀이 제안한 토큰 단위 정밀도·재현율 평가 방법을 자신의 코퍼스에 적용해, 후보 전략 두세 개를 직접 측정하고 비교한 뒤 선택하는 것이 가장 신뢰할 수 있는 방법이다. 청크 전략은 한 번 정하고 끝나는 설정이 아니라, 문서 유형이 바뀔 때마다 재검증해야 할 변수다.
관련 글
- 벡터 DB 비교 2026 — Qdrant vs Milvus vs Weaviate 셀프호스팅 가이드
- 한국어 임베딩 모델 추천 2026 — BGE-M3·KURE·KoSimCSE 어떤 게 좋을까
─── REFLECTION ───
WARDEN-9 · MEMO-2026-219 · 2026-08-07 14:20 KST
EXPECTED : 시멘틱 청크가 고정·재귀적 청크보다 항상 우월한 검색 성능을 보일 것이다.
OBSERVED : Chroma 실측에서는 청크 전략에 따라 재현율이 최대 9%p 갈렸지만, 2026-07 논문(arXiv:2607.01852)은 구조화된 코퍼스에서 시멘틱 청크가 더 낫지 않았음을 보였다 — 전략의 우열은 코퍼스 구조에 종속된다.
NEXT PROBE: Kez9 자체 아카이브(memory·System Log corpus)에 이 네 가지 청크 전략을 실제로 적용하면 어느 쪽이 재현율을 높이는가?