---
id: 청킹-전략
title: "청킹 전략"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["텍스트 분할", "Text Splitting"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-08
updated_at: 2026-06-08
review_reason: ""
merge_history: []
tags: ["research", "RAG 아키텍처 및 파이프라인 기초", "Chunking"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["/NVIDIA/GenerativeAIExamples", "Jina AI Late Chunking Research", "Anthropic Contextual Retrieval", "Microsoft Research GraphRAG", "MongoDB Python Documentation Study"]
github_commit: ""
---

# [[청킹 전략]]

## 🎯 한 줄 통찰 (One-line insight)
청킹은 단순히 텍스트를 자르는 과정이 아니라, 검색의 정밀도(Precision)와 문맥의 일관성(Coherence) 사이의 최적 균형을 찾아 LLM에 전달할 정보의 밀도를 결정하는 RAG 파이프라인의 핵심 공정이다.[1-3]

## 🧠 핵심 개념 (Core concepts)
- **토큰 제한 및 컨텍스트 창 관리:** LLM과 임베딩 모델의 입력 제한을 준수하면서 필요한 정보를 효율적으로 주입하기 위한 수단이다.[4-6]
- **의미론적 무결성(Semantic Integrity):** 텍스트를 분할할 때 문장이나 문단의 논리적 흐름이 끊기지 않도록 '완전한 생각' 단위를 유지하는 것이다.[6-8]
- **검색 정밀도와 재현율의 트레이드오프:** 청크가 작으면 검색 정밀도는 높아지나 문맥이 부족해지고, 크면 문맥은 풍부하나 관련 없는 노이즈가 포함될 가능성이 커진다.[5, 9-11]
- **메타데이터 및 구조 인지:** 원본 문서의 헤더, 섹션, 계층 구조를 반영하여 분할함으로써 검색 후에도 데이터의 출처와 관계를 유지한다.[12-14]

## 🧩 추출된 패턴 (Extracted patterns)
- **계층적 분할 패턴(Small2Big):** 검색은 작은 청크(자식)로 수행하여 정밀도를 높이고, 생성 모델에는 더 큰 부모 단락을 전달하여 문맥을 보강하는 설계 패턴이다.[11, 15, 16]
- **재귀적 구분자 우선순위:** 텍스트를 나눌 때 단락(`\n\n`), 줄바꿈(`\n`), 공백(` `) 순으로 우선순위를 두어 논리적 단위를 최대한 보존하려는 휴리스틱이다.[17-19]
- **슬라이딩 윈도우 오버랩:** 인접한 청크 간에 일정한 비율(보통 10~20%)의 중복 구간을 두어 경계면에서 정보가 단절되는 것을 방지한다.[18, 20, 21]
- **데이터 맞춤형 전략(Adaptive Selection):** 코드, 표, 마크다운, 대화 로그 등 원본 데이터의 형식에 따라 전용 분할기를 선택하는 전략이다.[22-24]

## 📖 세부 내용 (Details)
청킹은 RAG 시스템의 성능을 결정하는 가장 중요한 전처리 단계로 간주된다.[2] 소스 데이터에 따르면 다음과 같은 주요 전략들이 활용된다.

- **고정 크기 분할(Fixed-size Chunking):** 캐릭터나 토큰 수를 기준으로 기계적으로 분할하는 가장 단순한 방식이다.[20, 25] 구현이 빠르지만 의미적 경계를 무시하고 문장 중간을 자를 위험이 크다.[11, 26]
- **재귀적 문자 분할(Recursive Character Splitting):** 다양한 구분자 세트를 사용하여 논리적으로 의미 있는 가장 큰 단위를 유지하려 시도하는 방식이다.[18, 27] 범용 RAG 인프라의 표준 알고리즘으로 권장된다.[19]
- **구조 인식형 분할(Structure-aware Splitting):** 마크다운 헤더, HTML 태그, JSON 깊이 등을 인지하여 분할한다.[12, 28] 기술 문서나 API 가이드처럼 서식이 명확한 데이터에 적합하다.[28]
- **의미론적 청킹(Semantic Chunking):** 임베딩 유사도를 기반으로 인접 문장 간의 의미 이격이 발생하는 지점을 찾아 분할한다.[28, 29] 주제가 수시로 바뀌는 복잡한 문서에 유리하나 계산 비용이 높다.[11, 30, 31]
- **문장 창 검색(Sentence-window Retrieval):** 개별 문장 단위로 인덱싱하되, 검색 시에는 해당 문장의 앞뒤 맥락을 포함한 '윈도우'를 함께 추출하여 LLM에 전달한다.[28, 32]

**최적화 가이드라인:**
- **일반적인 텍스트:** 200~512 토큰 크기, 10~20% 오버랩이 권장된다.[21, 33]
- **코드 및 기술 문서:** 100~200 토큰의 작은 크기와 15~25%의 높은 오버랩이 유리하다.[21]
- **서사적 콘텐츠:** 문맥 유지를 위해 500~1000 토큰의 큰 청크가 적합할 수 있다.[21]

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **컨텍스트 창 확대와 청킹의 필요성:** 최신 LLM(예: Llama 4 Scout)이 수백만 토큰의 컨텍스트 창을 지원함에 따라 청킹이 불필요해질 것이라는 견해가 있으나, 소스는 여전히 검색 효율성, 비용 관리, 그리고 '중간 소실(Lost in the Middle)' 현상 방지를 위해 청킹이 필수적이라고 강조한다.[34-36]
- **청크 크기 편향:** 너무 짧은 청크는 키워드 매칭 성능은 좋으나 실제 정보 가치가 낮을 수 있으며, 임베딩 모델의 특성에 따라 짧은 텍스트가 비정상적으로 높은 유사도 점수를 받는 '임베딩 편향'이 발생할 수 있다.[37, 38]

## 🛠️ 적용 사례 (Applied in summary)
- **NVIDIA:** `/NVIDIA/GenerativeAIExamples` 리포지토리에서 512 토큰 제한을 가진 `e5-large-v2` 모델에 맞추기 위한 텍스트 분할 파이프라인을 구축했다.[39, 40]
- **Jina AI:** 문서 전체를 인코딩한 후 분할하는 'Late Chunking' 기법을 연구하여 문맥 보존 성능을 개선했다.[15]
- **Anthropic:** 'Contextual Retrieval' 기법을 통해 청크 앞에 50~100 토큰의 요약 컨텍스트를 추가하여 검색 실패율을 67% 감소시켰다.[15]
- **Microsoft Research:** GraphRAG 방법론에서 Leiden 알고리즘을 사용해 문서를 계층적 커뮤니티(청크 단위)로 탐지하고 요약하는 방식을 적용했다.[41]
- **MongoDB:** 파이썬 문서 처리에 있어 100토큰 크기와 15토큰 오버랩을 가진 재귀적 분할기가 최적의 성능을 보인다는 실증적 데이터를 제시했다.[42]

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례가 소스 전반에서 다수 확인됨)
- **출처 신뢰도:** B (NVIDIA, IBM, Databricks 등 공식 기술 블로그 및 연구 보고서 기반)
- **중복 검사 결과:** 신규 생성 (RAG 아키텍처 연구 보고서 핵심 주제)

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

### 상위/유사 개념
#### [아키텍처/기반 기술]
- [[RAG 아키텍처 및 파이프라인 기초]]
  - 연결 이유: 청킹은 파이프라인의 오프라인 수집 단계에서 핵심적인 전처리 공정이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 수집부터 생성까지의 전체 워크플로우 연계성.
- [[벡터 데이터베이스]]
  - 연결 이유: 분할된 청크는 벡터로 변환되어 데이터베이스에 인덱싱된다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 효율적인 유사도 검색을 위한 인덱싱 구조 최적화.

#### [구현/활용 도구]
- [[LangChain]]
  - 연결 이유: `RecursiveCharacterTextSplitter` 등 다양한 분할 인터페이스를 제공한다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 레벨에서의 구체적인 청킹 구현 방법.
- [[LlamaIndex]]
  - 연결 이유: `HierarchicalNodeParser` 등 문서 구조 기반의 정교한 분할 기능을 제공한다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 계층적 문서 트리 구조화 및 검색 최적화 전략.

### 심층 후속 질문 (Deeper Research Questions)
- 문장 중간이 아닌 의미적 단절 지점을 정확히 포착하는 'Semantic Chunking'의 임계값 설정 휴리스틱은 무엇인가?
- 'Late Chunking'이 기존의 사전 분할 방식 대비 검색 성능과 레이턴시 측면에서 갖는 구체적인 이득은 얼마인가?
- 표(Table)나 이미지 캡션과 같은 비정형 요소가 포함된 문서에서 구조를 파괴하지 않는 가장 효과적인 분할 로직은 무엇인가?
- LLM의 컨텍스트 창이 무한대에 가까워질 때, 청킹 전략은 '분할'에서 '요약 및 계층화'로 어떻게 진화할 것인가?
- 특정 도메인(법률, 의료)에 특화된 청킹 구분자(Separator) 설계 시 고려해야 할 언어적 특성은 무엇인가?

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** `RecursiveCharacterTextSplitter`를 기본으로 사용하되, 데이터 특성에 따라 오버랩 크기를 조정하여 배포한다.[19, 21]
- **System Design:** 검색 정밀도가 낮을 경우 'Parent-Child' 계층적 분할 구조를 도입하여 인덱싱 구조를 재설계한다.[15, 16]
- **Operation / Maintenance:** 원본 데이터의 업데이트 주기에 맞춰 벡터 인덱스가 동기화될 때, 청킹 로직의 일관성을 유지해야 검색 품질 저하를 방지할 수 있다.[43]
- **Learning Path:** 단순 고정 크기 분할에서 시작하여 구조 인식 분할, 그리고 의미론적 청킹으로 기술적 난이도를 높여가며 실험한다.[42]

### 인접 주변 주제 (Adjacent Topics)
- [[임베딩 모델]]
  - 확장 방향: 모델의 최대 토큰 제한과 청킹 크기 사이의 상관관계 분석.
- [[RAG 평가 지표]]
  - 확장 방향: 청킹 전략 변경이 'Context Precision'과 'Context Recall'에 미치는 정량적 영향 평가.

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