RAG 문서 청킹 전략 완벽 가이드

1. 청킹(Chunking)이란?

청킹(Chunking)은 긴 문서를 검색에 적합한 작은 조각(청크, Chunk)으로 나누는 과정입니다. RAG(Retrieval-Augmented Generation) 파이프라인에서 문서를 인덱싱할 때 가장 먼저 거치는 핵심 전처리 단계이며, 이후 임베딩 → 벡터 저장 → 검색 → 생성으로 이어지는 모든 단계의 품질을 좌우합니다.

---

2. 왜 청킹이 필요한가?

① 임베딩 모델의 입력 길이 제한

임베딩 모델마다 한 번에 처리할 수 있는 최대 토큰 수가 정해져 있습니다. 이 상한을 초과하면 텍스트가 잘리거나 오류가 발생합니다.

모델	최대 토큰
all-MiniLM-L6-v2	256
text-embedding-3-small	8,191
jina-embeddings-v2	8,192

 

② 의미 희석 문제

20페이지짜리 매뉴얼을 하나의 벡터로 압축하면, 그 벡터는 문서 전체의 평균적인 의미를 담게 됩니다. 특정 질문에 관련된 내용이 어디 있는지 구분할 수 없습니다. 작은 단위로 나눌수록 각 청크가 하나의 주제에 집중되어 검색 정밀도가 높아집니다.

 

③ 성능 영향이 입증된 핵심 변수

실제 연구들에서 청킹 전략이 얼마나 중요한지 수치로 확인되고 있습니다.

• 동일한 문서·임베딩 모델 환경에서 청킹 전략만 바꿨을 때 Recall이 최대 9%p 차이가 발생합니다.
• NVIDIA의 2024년 실험에서 512~1,024 토큰 범위가 가장 안정적인 성능을 보였습니다.
• 즉, 청킹은 단순한 전처리가 아니라 RAG 시스템 전체 성능의 토대를 결정하는 설계 결정입니다.

---

3. 좋은 청킹의 3가지 원칙

1. 하나의 청크 = 하나의 주제 : 서로 다른 주제가 한 청크에 섞이면 임베딩이 어느 쪽 의미도 정확히 포착하지 못합니다.
2. 경계에서 문맥이 끊기면 안 됩니다 : 문장 중간에서 잘리면 그 청크만으로는 의미를 파악할 수 없습니다.
3. 크기는 임베딩 모델과 LLM 컨텍스트 윈도우를 함께 고려 : 너무 크면 임베딩 상한 초과, 너무 많으면 LLM 프롬프트를 가득 채웁니다.

---

4. 청킹 전략의 종류

① 고정 크기 청킹 (Fixed-size Chunking)

텍스트를 고정된 문자 수(또는 토큰 수)마다 기계적으로 자르는 가장 단순한 방식입니다.

원본: |---- 1000자 ----|---- 1000자 ----|---- 1000자 ----|
청크1: |===========|
청크2:         |===========|   ← 오버랩 영역
청크3:                 |===========|

장점

• 구현이 매우 간단합니다.
• 모든 청크의 크기가 동일하여 예측 가능하고 관리가 쉽습니다.
• 추가 연산이 전혀 필요 없습니다.

단점

• 텍스트 내용을 무시하므로 문장·문단 중간에서 잘릴 수 있습니다.
• "트랜스포머 모델은 셀프 어텐션 메커니즘을 통해 시퀀스 내 모든 토—" 처럼 잘리면 청크만으로 의미 파악이 불가능합니다.

※ 오버랩(Overlap)으로 완화 : 인접한 청크 사이에 일정량의 텍스트를 겹치게 합니다. 1,000자 청크에 200자 오버랩을 설정하면 청크 경계의 문맥 단절을 줄일 수 있습니다. 일반적으로 청크 크기의 10~20%를 오버랩으로 설정합니다.

---

② 재귀적 청킹 (Recursive Character Splitting)

여러 구분자를 우선순위에 따라 순서대로 시도하며 텍스트를 나누는 방식입니다. LangChain의 RecursiveCharacterTextSplitter가 대표적인 구현체이며, 실무에서 가장 널리 쓰이는 범용 전략입니다.

동작 방식

구분자 우선순위: ["\n\n", "\n", ". ", " "]

전체 텍스트
    ↓ 빈 줄("\n\n")로 분할 → 문단 단위 조각들
    ↓ 크기 초과 조각 존재?
      → 줄바꿈("\n")으로 재분할
      → 여전히 초과? → 마침표(". ")로 재분할
      → 여전히 초과? → 공백(" ")으로 재분할
    ↓ 모든 청크가 상한 이내가 될 때까지 반복

장점

• 가능한 한 문단·문장 경계를 유지합니다.
• 구현이 간단하고 추가 비용이 없습니다.
• 대부분의 경우에 합리적인 기준선(baseline)이 됩니다.

단점

• 구분자가 명확하지 않은 텍스트(줄바꿈 없이 이어진 긴 문장)에서는 고정 크기 청킹과 큰 차이가 없습니다.
• 의미의 변화를 감지하지 못합니다.

---

③ 의미 기반 청킹 (Semantic Chunking)

텍스트의 "형식"이 아닌 "의미"를 기준으로, 주제가 바뀌는 지점을 감지하여 청크를 분리하는 방식입니다.

동작 원리

① 텍스트를 문장 단위로 분리
② 각 문장을 임베딩 벡터로 변환
③ 인접한 문장 쌍의 코사인 유사도 계산
④ 유사도가 급격히 떨어지는 지점 = 청크 경계

문장1: "제주도는 대한민국 최남단에 위치한 섬입니다."        유사도
문장2: "연평균 기온이 온화하여 겨울에도 눈이 드뭅니다."    0.80 (높음)
문장3: "한라산, 성산일출봉 등 자연 명소가 풍부합니다."     0.79 (보통)
━━━━━━━━━━━ 유사도 급락 → 청크 경계 ━━━━━━━━━━━
문장4: "제주 공항의 국제선 노선이 꾸준히 늘고 있습니다."   0.21 (낮음)
문장5: "직항 노선 확대로 외국인 관광객 유입이 증가했습니다." 0.85 (높음)

장점

• 하나의 청크가 하나의 주제를 담을 가능성이 매우 높습니다.
• 임베딩 벡터가 주제를 정확하게 표현하여 검색 품질이 높아집니다.
• 단순 방법 대비 Recall을 최대 9%p 향상시킬 수 있습니다.

단점

• 경계 탐지를 위해 문장 단위 임베딩을 먼저 수행하고, 이후 청크 단위 임베딩을 다시 수행하므로 임베딩이 두 번 발생합니다. 다른 청킹 방식은 저장용 청크 임베딩 한 번만 필요합니다.
• 수만 건의 문서에서는 이 이중 임베딩 비용이 인덱싱 단계에서 상당히 누적될 수 있습니다.
• 구현 난이도가 상대적으로 높습니다.

---

④ 문서 구조 기반 청킹 (Structure-aware Chunking)

Markdown의 # 헤더, HTML의 <h1>~<h3> 태그처럼 문서 자체에 존재하는 구조적 표시를 청크 경계로 활용하는 방식입니다.

동작 예시 (Markdown)

# 임베딩 모델 개요           ← 청크 1 시작
임베딩은 텍스트를 고차원 벡터로 변환하는 과정입니다.
모델마다 출력 차원과 최대 입력 토큰 수가 다릅니다.

# 벡터 유사도 계산           ← 청크 2 시작
코사인 유사도는 두 벡터 간 각도를 기준으로 ...

# 벡터 데이터베이스 선택     ← 청크 3 시작
Pinecone, Weaviate, Qdrant 등 ...

메타데이터로 헤더 정보를 함께 저장하면, 검색 결과에 "이 청크는 '벡터 유사도 계산' 섹션에서 온 것"이라는 맥락을 제공할 수 있습니다.

장점

• 문서 작성자의 의도를 그대로 반영합니다.
• 추가 임베딩 비용이 없습니다.
• 메타데이터 필터링을 통해 검색 정밀도를 더욱 높일 수 있습니다.

단점

• 헤더가 없거나 구조가 불규칙한 문서에는 적용 불가능합니다.
• 하나의 섹션이 매우 길면 임베딩 모델의 입력 상한을 초과할 수 있습니다.
• 이 경우 구조 기반 청킹 + 재귀적 청킹의 혼합 전략이 효과적입니다.

---

⑤ 페이지 단위 청킹 (Page-level Chunking)

PDF처럼 페이지 개념이 있는 문서에서 각 페이지를 하나의 청크로 취급하는 방식입니다.

장점

• NVIDIA의 2024년 벤치마크에서 정확도 0.648, 가장 낮은 분산을 기록하며 1위를 차지했습니다.
• 페이지 번호를 메타데이터로 활용하면 출처 인용이 매우 쉽습니다.
• 구현이 단순합니다.

단점

• 페이지 구분이 있는 문서(PDF, 슬라이드)에만 적합합니다.
• 페이지 내용의 길이가 들쑥날쑥하여 청크 크기가 균일하지 않을 수 있습니다.

---

⑥ Late Chunking

2024년 Jina AI가 제안한 기법으로, 기존 청킹의 근본적인 문제인 문맥 손실을 해결하는 접근입니다.

기존 청킹의 문제

"GPT-4는 OpenAI가 개발한 대규모 언어 모델입니다. 이 모델(this model)은 멀티모달 입력을 지원합니다."를 문장 단위로 나누면, 두 번째 청크에서 "this model"이 GPT-4를 가리킨다는 사실을 임베딩 모델이 알 수 없습니다.

Late Chunking의 해결책

① 문서 전체를 Long-context 임베딩 모델에 한 번에 입력
② 전체 문맥을 반영한 토큰 임베딩 시퀀스 생성
③ 그 시퀀스를 청크 단위로 분할한 뒤 Mean Pooling으로 청크 임베딩 생성

각 청크가 문서 전체의 문맥을 담은 상태로 임베딩되므로, "this model"이 GPT-4를 가리킨다는 정보가 해당 청크의 벡터에 녹아듭니다.

장점

• 원거리 의미 의존성(long-distance semantic dependency) 문제를 해결합니다.
• 문맥을 잃지 않으면서 세밀한 청크 단위 검색이 가능합니다.

단점

• Long-context 임베딩 모델(jina-embeddings-v2 등)이 필요합니다.
• 전체 문서를 한 번에 처리하므로 매우 긴 문서에서는 처리 비용이 증가합니다.
• 아직 실험적 단계이며 모든 환경에서 검증되지 않았습니다.

---

⑦ 에이전틱 청킹 (Agentic Chunking)

LLM 자체를 활용하여 문서의 논리적 구조를 파악하고 최적의 분할 지점을 결정하는 방식입니다.

개념

LLM에게 문서를 주고 "이 문서를 의미 단위로 나누어라"고 요청합니다. 코드 파일이라면 함수 단위로, 계약서라면 조항 단위로, 뉴스 기사라면 단락 단위로 나누는 등 문서 유형과 내용 밀도에 따라 적응적으로 분할합니다.

장점

• 가장 정교한 분할이 가능합니다.
• 문서 유형에 자동으로 적응합니다.

단점

• 전처리 비용이 매우 높습니다(문서마다 LLM 호출 필요).
• 처리 속도가 느립니다.
• 아직 대부분의 프로덕션 환경에서 실험적 단계입니다.

---

5. 청크 크기와 오버랩 설정

① 크기 결정의 트레이드오프

청크 크기 검색 정밀도 맥락 완전성 저장·인덱싱 비용

청크 크기	검색 정밀도	맥락 완전성	저장·인덱싱 비용
작음 (128~300 토큰)	높음	낮음	높음
중간 (300~512 토큰)	보통	보통	보통
큼 (512~1,024 토큰)	낮음	높음	낮음

• 너무 작으면: 문맥이 끊겨 Precision 하락, LLM이 답변 생성에 필요한 정보 부족
• 너무 크면: 의미가 희석되어 Recall 하락, 질문과 무관한 내용이 많이 포함됨

② 실무 권장 크기

문서 유형	권장 청크 크기
FAQ, 짧은 문답	128~300 토큰
일반 문서 (매뉴얼, 가이드)	300~512 토큰
법률 문서, 학술 논문	512~1,024 토큰

Databricks, NVIDIA, Pinecone 등의 연구를 종합하면 300~512 토큰이 대부분의 범용 RAG에서 안정적인 성능의 시작점입니다.

③ 오버랩 설정

오버랩은 청크 크기의 10~20%가 일반적입니다. 512 토큰 청크라면 50~100 토큰 오버랩을 설정합니다. 오버랩이 너무 크면 중복 정보가 많아져 저장 비용이 증가하고 검색 결과에 유사 청크가 중복 등장할 수 있습니다.

---

6. 전략별 비교 요약

전략	구현 난이도	전처리 비용	검색 품질	문맥 보존
고정 크기	⭐ 매우 낮음	없음	낮음~보통	낮음
재귀적	⭐⭐ 낮음	없음	보통	보통
문서 구조 기반	⭐⭐ 낮음	없음	높음	높음
페이지 단위	⭐ 매우 낮음	없음	높음 (PDF 한정)	높음
의미 기반	⭐⭐⭐ 높음	높음 (임베딩)	높음	매우 높음
Late Chunking	⭐⭐⭐ 높음	높음 (LLM)	매우 높음	매우 높음
에이전틱	⭐⭐⭐⭐ 매우 높음	매우 높음 (LLM)	최고 (이론상)	최고

---

7. 문서 유형별 추천 전략

① FAQ / 짧은 문답형 문서

추천: 고정 크기 + 소형 청크 (128~300 토큰)

각 Q&A 쌍이 이미 독립적인 의미 단위이므로 복잡한 전략이 필요 없습니다. Q와 A가 하나의 청크에 포함되도록 크기를 설정하는 것이 핵심입니다.

 

② Markdown / HTML 기반 문서

추천: 문서 구조 기반 청킹 (헤더 단위)

개발 문서, 위키, 기술 블로그처럼 헤더 구조가 명확한 문서에 최적입니다. 헤더 정보를 메타데이터로 함께 저장하면 검색 정밀도가 더욱 올라갑니다. 섹션이 너무 길 경우 재귀적 청킹을 추가로 적용합니다.

 

③ PDF 문서 (레포트, 슬라이드, 논문)

추천: 페이지 단위 청킹

NVIDIA 벤치마크에서 입증된 것처럼, 페이지 경계가 명확한 문서에서는 페이지 단위가 가장 안정적입니다. 페이지 번호를 메타데이터로 저장하면 출처 인용도 용이합니다. 단, 페이지 내용이 매우 길거나 짧으면 재귀적 청킹을 보조로 활용합니다.

 

④ 법률 문서 / 계약서

추천: 문서 구조 기반 + 큰 청크 (512~1,024 토큰)

조항과 항목 번호 구조를 기준으로 나누되, 법적 맥락은 긴 논리 흐름이 중요하므로 청크 크기를 크게 가져갑니다. 조항 번호를 메타데이터로 관리하면 검색 결과의 신뢰성이 높아집니다.

 

⑤ 학술 논문 / 기술 보고서

추천: 문서 구조 기반 청킹 + 의미 기반 청킹 혼합

논문은 Abstract, Introduction, Method, Result, Discussion 등 섹션 구조가 명확하므로 먼저 문서 구조 기반 청킹으로 섹션 단위로 나누는 것이 우선입니다. 각 섹션 내부에서 주제 전환이 빈번하거나 섹션이 너무 길다면, 그 안에 의미 기반 청킹을 추가로 적용합니다.

 

⑥ 뉴스 기사 / 블로그 포스트

추천: 재귀적 청킹 (300~512 토큰)

헤더 구조가 있을 수도 없을 수도 있어 구조 기반 청킹의 적용이 불안정합니다. 재귀적 청킹으로 문단 경계를 유지하면서 나누는 것이 가장 범용적입니다.

 

⑦ 주제 전환이 잦은 혼합 문서 / 대화 로그

추천: 의미 기반 청킹

구조적 단서(헤더, 페이지)가 없고 주제가 수시로 바뀌는 문서에서는 코사인 유사도 기반의 의미 청킹이 가장 효과적입니다. 전처리 비용을 감수할 수 있다면 Late Chunking도 고려할 수 있습니다.

 

⑧ 코드베이스 / 소스 코드

추천: 에이전틱 청킹 또는 함수/클래스 단위 분할

함수, 클래스, 모듈 단위로 나누는 것이 자연스럽습니다. 언어별 파서(AST 기반)를 활용하거나, LLM이 코드의 논리 단위를 판단하도록 하는 에이전틱 청킹이 적합합니다.

---

8. 실무 접근 순서

좋은 청킹 전략을 찾는 실무적인 순서는 다음과 같습니다.

1단계: 재귀적 청킹으로 시작 (300~512 토큰, 오버랩 10~20%)
   ↓ 검색 품질 평가
   ↓ 부족하다고 판단되면

2단계: 문서 특성에 따라 분기
   ├─ 헤더가 명확한 문서 → 구조 기반 청킹
   ├─ 페이지 기반 문서(PDF) → 페이지 단위 청킹
   └─ 주제 전환이 잦은 문서 → 의미 기반 청킹
   ↓ 여전히 부족하다면

3단계: 고급 기법 도입
   ├─ 문맥 손실 문제 → Late Chunking
   └─ 다양한 문서 유형 혼재 → 에이전틱 청킹

평가 방법: 동일한 질문 셋에 대해 각 전략의 검색 결과를 RAGAS, DeepEval 같은 도구로 정량 평가하여 전략을 선택합니다. 감이나 직관이 아니라 데이터로 판단하는 것이 중요합니다.

청킹은 한 번 설정하면 끝이 아닙니다. 문서 유형이 바뀌거나 서비스가 성장하면 전략도 함께 재검토해야 합니다.

---

9. 핵심 요약

좋은 RAG는 좋은 청킹에서 시작됩니다. 먼저 재귀적 청킹으로 빠르게 프로토타입을 만들고, 실제 데이터로 평가한 뒤 문서 특성에 맞는 전략으로 단계적으로 고도화하는 접근이 가장 현실적이고 효과적입니다.

항목	핵심 내용
청킹의 목적	긴 문서를 검색에 최적화된 의미 단위로 분할
청크 크기 시작점	300~512 토큰, 오버랩 10~20%
범용 기본 전략	재귀적 청킹
구조화 문서	문서 구조 기반 (헤더/페이지 단위)
고품질 필요 시	의미 기반 청킹
문맥 손실 해결	Late Chunking
평가 도구	RAGAS, DeepEval

 

---

10. 참고 자료

• https://www.firecrawl.dev/blog/best-chunking-strategies-rag
• https://agenta.ai/blog/the-ultimate-guide-for-chunking-strategies
• https://community.databricks.com/t5/technical-blog/the-ultimate-guide-to-chunking-strategies-for-rag-applications/ba-p/113089
• https://amirteymoori.com/rag-text-chunking-strategies/
• https://medium.com/@adnanmasood/chunking-strategies-for-retrieval-augmented-generation-rag-a-comprehensive-guide-5522c4ea2a90