---
tags: [AI-Agent, RAG]
---

# Chunking

> 긴 문서를 검색·임베딩에 적합한 작은 단위(청크)로 분할하는 전처리 과정.

## 핵심 개념

LLM의 컨텍스트 윈도우와 임베딩 모델의 입력 길이는 유한하다. 따라서 원문을 통째로 인덱싱하는 대신, 의미 단위로 잘라낸 **청크(chunk)** 를 만들고 각 청크를 임베딩해 벡터 DB에 저장한다. 청크 크기와 경계 설정은 검색 품질에 직접적인 영향을 미친다.

- **청크가 너무 크면**: 하나의 청크에 여러 주제가 섞여 임베딩이 흐려지고, 검색 정밀도(precision)가 떨어진다. 토큰 낭비도 발생한다.
- **청크가 너무 작으면**: 문맥이 끊겨 의미가 사라지고, 답변에 필요한 정보가 여러 청크에 흩어진다(재현율 저하).

## 청킹 전략

### 고정 크기 청킹 (Fixed-size)
토큰 또는 문자 수 기준으로 일정 길이마다 자른다(예: 512 토큰). 구현이 단순하고 빠르지만 문장·문단 중간을 잘라 의미를 훼손할 수 있다.

### 재귀적 청킹 (Recursive)
구분자 우선순위 목록(`\n\n` → `\n` → `. ` → ` `)을 따라 점진적으로 분할한다. 문단 경계를 최대한 보존하면서 목표 크기에 맞추므로 실무에서 가장 널리 쓰인다(LangChain `RecursiveCharacterTextSplitter`).

### 의미 기반 청킹 (Semantic)
인접 문장 간 임베딩 유사도를 계산해 의미가 급격히 바뀌는 지점에서 분할한다. 문맥 응집도가 높지만 임베딩 연산 비용이 추가된다.

### 문서 구조 기반 (Structural)
마크다운 헤더, HTML 태그, 코드 블록 등 문서의 논리 구조를 경계로 활용한다. 메타데이터(제목, 섹션)를 함께 보존하기 좋다.

### 적응형 청킹 (Adaptive)
위 전략들을 정적으로 적용하는 대신, 콘텐츠의 의미 밀도·구조에 따라 청크 크기와 경계를 **구간별로 동적 조정**한다. 2025~2026 RAG 인덱싱의 핵심 방향 → [[Adaptive Chunking]].

## 오버랩 (Overlap)

인접 청크가 일정 토큰(예: 50~100 토큰)을 **겹치게** 만드는 기법. 청크 경계에서 잘린 문맥을 양쪽 청크가 공유하므로, 경계에 걸친 정보의 손실을 줄인다. 다만 중복 저장으로 인덱스 크기와 비용이 증가한다.

## 실무 가이드

- 일반 문서: 재귀적 청킹 + 256~512 토큰 + 10~20% 오버랩이 출발점.
- 청크에 출처·섹션 제목 등 메타데이터를 함께 저장하면 [[Re-ranking]]과 [[Grounding]]에 유리하다.
- 도메인(코드, 법률, 대화 로그)에 따라 전략을 달리해야 한다.

## 관련 노트

- [[Embedding]]
- [[Vector Database]]
- [[Context Engineering]]
- [[RAG Architecture]]
- [[Chunking]] (용어사전)