---
id: 문서-청킹-전략
title: "문서 청킹 전략"
category: "AI_and_ML"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Text Chunking", "Document Splitting", "텍스트 분할 기법", "청크 사이즈 최적화", "Chunking Strategy", "RecursiveCharacterTextSplitter", "Semantic Chunking"]
duplicate_of: ""
source_trust_level: "A"
confidence_score: 0.95
created_at: 2026-06-08
updated_at: 2026-06-08
review_reason: ""
merge_history: []
tags: ["research", "RAG", "Chunking", "Preprocessing", "Index-Optimization"]
raw_sources: ["1. RAG 파이프라인 기초 아키텍처", "RAG Architecture: 4 Key Components & Example Implementation  - Cloudian", "RAG Pipeline - velog", "RAG 솔루션 디자인 및 개발 - Azure Architecture Center - Microsoft Learn", "[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화", "RAG 기술의 진화: Naive에서 Modular까지 총정리 - 슈퍼브 블로그"]
applied_in: ["01_RAG_파이프라인_기초_아키텍처.ipynb", "Parent Document Retriever implementation", "Azure AI Search Indexing Pipeline"]
github_commit: ""
---

# [[문서 청킹 전략]]

## 🎯 한 줄 통찰 (One-line insight)
청킹은 검색의 정밀도(Precision)와 문맥의 풍부함(Context) 사이의 트레이드오프를 최적화하여 RAG 시스템의 답변 품질을 결정하는 핵심 전처리 공정이다 [S17, S122, S168].

## 🧠 핵심 개념 (Core concepts)
- **청크 사이즈 (Chunk Size):** 문서를 분할하는 텍스트의 크기로, 임베딩 모델의 토큰 제한과 검색 단위의 정밀도를 결정한다 [S18, S27, S62].
- **청크 오버랩 (Chunk Overlap):** 분할된 청크 간의 중첩 영역으로, 청크 경계에서 문맥이 단절되는 것을 방지하고 정보의 연속성을 유지한다 [S18, S62].
- **구분자 우선순위 (Separator Priority):** 재귀적 분할 시 문단(\n\n), 줄(\n), 단어( ) 등의 순서로 의미 단위를 최대한 보존하며 나누는 기준이다 [S17, S61].
- **시맨틱 경계 (Semantic Boundary):** 텍스트의 의미적 유사도가 급격히 변하는 지점을 계산하여 내용적으로 일관된 단위로 분할하는 기법이다 [S20, S64, S238].

## 🧩 추출된 패턴 (Extracted patterns)
- **Structure-then-Size Pattern:** 마크다운 헤더나 HTML 태그 등 문서의 논리적 구조로 먼저 나눈 뒤, 각 섹션이 너무 크면 크기 기반(Recursive)으로 재분할하는 복합 전략이다 [S21, S22, S65].
- **Small-to-Big Retrieval Pattern:** 검색은 작은 청크(자식)로 정밀하게 수행하되, 생성 단계에서는 더 큰 주변 문맥(부모 청크)을 LLM에 전달하여 정확도와 이해도를 동시에 확보한다 [S31, S36, S75, S80].
- **Token-Model Alignment:** 사용하는 임베딩 모델의 실제 토크나이저와 일치하는 토큰 기반 분할기를 사용하여 하드웨어/API 제약 조건 내에서 최대 정보를 수용한다 [S19, S27, S71].

## 📖 세부 내용 (Details)

### 1. 주요 청킹 전략 유형 및 특징 [S17, S22, S61, S66]
| 전략 | 클래스 | 주요 특징 | 최적 적합 사례 |
| :--- | :--- | :--- | :--- |
| **재귀적 문자 분할** | RecursiveCharacterTextSplitter | 문단→줄→단어 순으로 자연스러운 경계 시도 [S18]. | 일반 텍스트, 보고서 (가장 범용적) |
| **토큰 기반 분할** | TokenTextSplitter | LLM의 토큰 제한에 정확히 맞춰 분할 [S19]. | 정확한 토큰 수 관리가 필요한 경우 |
| **구조 기반 분할** | Markdown/HTML HeaderSplitter | 헤더(#, <h1>) 계층에 따라 논리적 섹션 보존 [S19, S21]. | 기술 문서, API 가이드, 웹 문서 |
| **시맨틱 분할** | SemanticChunker | 임베딩 유사도를 기반으로 의미 변화 지점 포착 [S20]. | 주제 변화가 잦은 복합 문서 |

### 2. 실무 파라미터 정의 기준 [S18, S23, S27, S62, S67, S71]
- **기본 권장값:** 대중적으로 `chunk_size` 500~1000자, `chunk_overlap`은 크기의 10~15%(50~150자) 수준에서 시작하여 품질 평가를 통해 튜닝한다 [S23, S67].
- **임베딩 모델 제약:** OpenAI(8191 토큰), Gemini(2048 토큰) 등 모델별 최대 입력 단위를 초과하지 않도록 설정해야 하며, 토큰 기반 분할 시 인코딩(cl100k_base 등)을 일치시켜야 오차가 없다 [S27, S71].
- **도메인 특화:** 법률/계약서처럼 문맥 보존이 중요한 경우 1000~2000자의 큰 단위를, FAQ/용어집처럼 개별 항목이 명확한 경우 200~500자의 작은 단위를 사용한다 [S22, S66].

### 3. 고도화된 청킹 및 인덱싱 기법 [S36, S80, S238]
- **Parent Document Retriever:** 검색용 '자식 청크'는 작게(300~500자) 설정하여 검색 재현율을 높이고, 반환되는 '부모 청크'는 크게(1500~2000자) 설정하여 LLM이 충분한 근거를 갖게 한다 [S36, S80].
- **계층적 인덱싱:** 미시적 개체 정보를 담은 청크와 거시적 요약 정보를 담은 커뮤니티 요약을 계층화하여 검색 범위를 유연하게 조절한다 [S277].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **고정 크기 vs 시맨틱:** 고정 크기 분할은 속도가 빠르고 예측 가능하지만 문맥이 잘릴 위험이 있고, 시맨틱 분할은 품질이 우수하지만 임베딩 모델 추가 호출로 인한 비용과 시간이 발생한다는 트레이드오프가 존재한다 [S20, S64].
- **재인덱싱의 비가역성:** `chunk_size`나 전략을 변경하면 문맥 경계가 불일치해지므로, 기존에 구축된 벡터 DB 인덱스를 100% 재구축(재임베딩)해야 한다 [S28, S72].

## 🛠️ 적용 사례 (Applied in summary)
- **주피터 노트북:** `01_RAG_파이프라인_기초_아키텍처.ipynb`에서 `RecursiveCharacterTextSplitter`를 활용한 세법 문서 분할 예제가 구현되어 있다 [S10, S54].
- **Parent Document 전략:** 실무에서 부모 2000자, 자식 400자 설정을 통해 긴 법률 문서의 정밀 검색과 전체 문맥 확인을 병행하는 아키텍처가 제안되었다 [S37, S81].
- **KT Cloud RAG Suite:** 이미지, PDF, 워드 등 다양한 문서 유형에 대해 레이아웃과 표 구조를 보존하며 최적화된 청킹을 제공하는 API 서비스로 운영되고 있다 [S342, S393].


<!-- CODE-GROUNDING:START -->
### 🔎 코드베이스 근거 (자동 추출 — E:\Wiki 레포)
**실제 구현/사용 위치:**
- `connectai/src/retrieval/evalHarness.ts:13` — *   { "query": "RAG 청킹 전략 비교", "expected": ["문서 청킹 전략.md"], "note": "선택" }
- `connectai/src/retrieval/chunker.ts:7` — * 쪼개면 질의가 정확히 해당 섹션에 매치된다 (제2뇌의 "문서 청킹 전략" 지식 그대로).

_자동 생성: code_grounding.mjs · 재실행 시 갱신됨_
<!-- CODE-GROUNDING:END -->

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 구현 코드 및 라이브러리 가이드 기반)
- **출처 신뢰도:** A (Microsoft, Azure, kt cloud, Cloudian 등 기술 전문 조직의 가이드라인 기반)
- **신뢰 점수:** 0.95
- **중복 검사 결과:** 신규 생성 (New discovery)


## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념
#### [아키텍처/기반 기술]
- [[RAG 아키텍처 및 파이프라인 기초]]
  - 연결 이유: 청킹은 RAG 파이프라인 7단계 중 검색 품질을 결정짓는 두 번째 핵심 단계임 [S8, S53].
- [[텍스트 임베딩 모델]]
  - 연결 이유: 임베딩 모델의 물리적 토큰 제한이 청킹 전략의 기술적 제약 조건이 됨 [S27, S71].

#### [구현/활용 도구]
- [[벡터 데이터베이스]]
  - 연결 이유: 청킹된 결과물이 임베딩되어 영구 저장되는 물리적 장소임 [S28, S73].
- [[데이터 인덱싱 및 오케스트레이션]]
  - 연결 이유: 대규모 데이터셋의 청킹 및 인덱싱 프로세스를 관리하는 상위 워크플로우 [S220, S269].

### 심층 후속 질문 (Deeper Research Questions)
- 시맨틱 청킹 시 사용되는 `breakpoint_threshold_amount`의 최적값을 도메인별(법률 vs 일반)로 자동 산출할 수 있는 방법은 무엇인가? [S21, S65]
- 멀티모달 데이터(이미지+표)를 포함한 문서에서 레이아웃을 깨지 않고 청킹하는 최신 비전 기반 파싱 기법의 성능 차이는? [S312, S363]
- 청크 사이즈를 동적으로 조절할 때, 검색 단계에서의 랭킹 알고리즘(RRF 등)이 청크 간 길이 불균형에 얼마나 민감하게 반응하는가? [S193, S206]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** LangChain의 `RecursiveCharacterTextSplitter`를 기본으로 사용하고, `chunk_size` 500/1000/1500으로 실험 수행 [S23, S67].
- **System Design:** 구조화된 문서(마크다운)의 경우 반드시 `MarkdownHeaderTextSplitter`를 선행 적용하여 논리 구조 보존 [S22, S66].
- **Operation / Maintenance:** 원본 문서의 20% 이상이 변경되거나 청킹 파라미터 수정 시 인덱스 전체 재구축 스케줄 수립 [S28, S72].
- **Learning Path:** 분할 원리 이해 -> 오버랩 효과 실험 -> 구조 기반 분할 실습 -> 시맨틱 청킹 도입 순으로 학습 [S1, S45].

### 인접 주변 주제
- [[텍스트 토크나이저]]
  - 확장 방향: BPE, WordPiece 등 분할 기준이 되는 토큰화 알고리즘의 원리 이해 [S314, S365].

## 🔗 지식 그래프 (Knowledge Graph)
- **상위/루트:** [[RAG 아키텍처 및 파이프라인 기초]]
- **관련 개념:** [[텍스트 임베딩 모델]], [[벡터 데이터베이스]], [[Parent Document Retriever]], [[시맨틱 청킹]]
- **참조 맥락:** 비정형 문서의 지식 밀도를 유지하며 검색 성능을 최적화해야 하는 전처리 설계 단계에서 참조.

## 📚 출처 (Sources)
- [S17] 단계 2: 청킹(Text Chunking/Splitting) 개요 (devspoon)
- [S18] RecursiveCharacterTextSplitter 상세 및 파라미터 (devspoon)
- [S21] SemanticChunker 동작 원리 및 설정 (devspoon)
- [S22] 실무에서의 청킹 전략 선택 가이드 및 복합 전략 (devspoon)
- [S27] 청킹 모델과 임베딩 모델의 선택 기준 (devspoon)
- [S36] Parent Document Retriever 상세 (devspoon)
- [S122] 검색 세밀도와 모델 컨텍스트 제한의 정렬 (Cloudian)
- [S168] 청킹 튜닝 및 인덱스 분할 전략 (Cloudian)
- [S238] Advanced RAG 인덱싱 개선 기법 (슈퍼브 블로그)
- [S260] Azure RAG 데이터 파이프라인 흐름 (Microsoft Learn)
- [S342] kt cloud AI Foundry RAG Suite 파싱 및 청킹 기능 (kt cloud)
- [S360] 비정형 데이터 레이아웃 보존 파싱 (kt cloud)

## 📝 변경 이력 (Change history)
- 2026-06-08: Initial draft generated via Datacollector_MAC P-Reinforce engine.