RAG 파이프라인에서 청킹 전략을 어떻게 선택해야 하는가?
한국어 문서 기반 QA 시스템에서는 5001,000자(약 250500 토큰) 고정 크기 청크와 10~20% 오버랩이 검색 정확도와 응답 지연의 최적 균형점으로 검증되었다. 계층적 청킹은 정확도 향상이 가능하지만 구현 복잡도와 비용이 높으며, 시맨틱 청킹은 주제 전환이 잦은 문서에서만 우선순위를 가진다.
- 기본선: 500
1,000자 고정 크기(오버랩 1020%)로 시작해 검색 성능 측정 - 정확도 부족 시: 계층적 청킹(부모/자식 이중 저장) 또는 하이브리드 검색(BM25+벡터) 우선 검토
- 비용 고려: 시맨틱 청킹은 정확도 개선 입증 후 선택적 적용
- 평가: 동일 질문 셋으로 재현율·정확도 정량 비교 필수
- 구조 활용: PDF를 마크다운으로 변환 후 처리 시 정확도 20~30% 향상 가능
한국어 문서에서 최적 청크 크기는 정말 500~1,000자인가?
영어보다 높은 정보 밀도로 인해 한국어는 5001,000자(약 250500 토큰)가 성능과 효율의 균형점이다. 이는 동일한 정보량을 담으면서 청크 개수를 줄여 인덱싱 비용을 낮춘다.
일반적인 검증 과정을 정리하면:
크기 선택 기준
- FAQ/짧은 답변 문서: 200~500자 — 단일 주제 응답에 충분
- 매뉴얼/일반 가이드: 500~1,500자 — 맥락 포함한 설명에 적합
- 법률·학술 문서: 1,500~3,000자 — 긴 논리 흐름 유지 필요
Opus 4.7 토크나이저 기준으로 500 토큰은 약 1,500자에 해당하므로, 중간 규모 청크(약 800자)는 본문 정보를 충분히 담으면서도 생성 성능을 유지한다.[2]
오버랩 설정의 구체적 영향
청크 경계에서 컨텍스트가 끊기는 문제를 완화하려면 청크 크기의 10~20% 중첩(예: 1,000자 청크에 100~200자)이 필요하다. 오버랩이 너무 작으면 검색 누락이 증가하고, 너무 크면 중복 저장으로 인한 비용 증가와 검색 속도 저하를 초래한다.[5]
고정 크기 청킹과 계층적 청킹, 어느 것을 먼저 시도할 것인가?
대부분의 경우 고정 크기 청킹(5001,000 토큰, 50100 토큰 오버랩)으로 충분하며, 검색 정확도 부족이 확인되면 계층적 청킹을 도입해야 한다.
구현 선택지의 트레이드오프:
| 전략 | 장점 | 단점 | 도입 기준 |
|---|---|---|---|
| 고정 크기 | 단순, 저비용, 대부분 케이스 OK | 주제 경계 무시 | 시작점 |
| 계층적 | 검색 완전성·답변율 상승 | 구현 복잡도↑, 비용↑ | Recall <80% 일 때 |
| 시맨틱 | 주제별 최적 경계 | 비용·복잡도 높음 | 미션 크리티컬일 때만 |
계층적 청킹 구현 조건
마크다운 구조 문서는 헤더(예: ###)를 기준으로 큰 청크(부모, ~2,000 토큰)와 작은 청크(자식, ~200 토큰)를 동시 저장한다. 검색 단계에서는 작은 청크로 후보를 찾고, 생성 단계에서 해당 부모 청크를 컨텍스트로 제공해 [검색 완전성 및 답변율을 높인다][2]. 비구조 텍스트는 500 토큰 윈도우로 문장 단위 분할 후 동일 방식 적용.
시맨틱 청킹은 언제 도입해야 할까?
시맨틱 청킹은 검색 정확도가 필요하지만 재귀적(고정) 청킹 기반선이 부족할 때, 그리고 예산이 충분할 때 선택적으로 적용한다.
방법론:
인접 문장의 임베딩 유사도를 코사인 거리로 산출한 후, 유사도가 급격히 떨어지는 지점(주제 전환)에 청크 경계를 설정한다.[7] 이론적으로는 고정 크기보다 논리적 완결성이 높으나, 실측상 정확도 개선은 +5~10%에 그치는 반면 연산 비용(임베딩 매번 호출)과 구현 복잡도는 상당하다.[4]
현실적 선택 가이드
- 고정 크기로 시작해 검색 성능(Recall, NDCG) 측정
- 평가 결과가 80% 이상이면 현상 유지
- 70~80% 범위면 계층적 청킹 또는 하이브리드 검색(BM25+벡터) 먼저 시도
- 60% 이하이고 주제 전환이 빈번한 문서군이면 시맨틱 청킹 검토
LangChain의 CharacterTextSplitter로 고정 크기 설정 후, 필요시 커스텀 시맨틱 분할 레이어 추가하는 증분 접근이 비용 효율적이다.[13]
청크와 검색·생성 단계의 연결은 어떻게 최적화하는가?
하이브리드 검색(BM25+벡터 결합)과 리랭킹 단계를 도입하면 검색 정확도를 48% 향상시킬 수 있다. 청크 품질은 검색 단계에서만 결정되지 않으며, 리랭킹과 프롬프트 설계도 함께 영향을 미친다.
실제 파이프라인 구성
- 1차 검색: BM25(한국어 형태소 분석기
nori기반, Elasticsearch) + 벡터 검색(Qdrant/pgvector) 병렬 실행 - 후보 병합: Reciprocal Rank Fusion(RRF, k=60 표준)으로 두 점수 통합, top-50 추출
- 리랭킹: Cross-encoder 모델(3단계 재점수)로 top-5 최종 선정
- 생성: LLM이 top-5 청크만 받음(컨텍스트 윈도우 절약, 잡음 감소)
임베딩 최적화로는 Scalar/Product Quantization 적용 시 메모리 50~75% 절감,[1] 날짜 기반 샤딩으로 검색 대상 벡터 수를 제한할 수 있다. ef_search 파라미터(50→100→200)를 단계적 조정해 Recall과 Latency 트레이드오프를 측정하는 것이 필수다.
근거: 벤치마크와 실전 평가 기준
청킹 전략의 성능 검증은 실제 QA 데이터셋 위에서 이루어져야 한다. 2026년 기준:
- HiCBench: 수동 주석 다단계 청킹 지점과 증거 밀도 높은 QA 쌍을 포함한 공개 벤치마크[12]. 각 전략의 재현율·정확도·F1 점수 직접 비교 가능.
- 실전 비교:
RAPTOR(작은 청크 검색 + 부모 청크 전달)는 in-corpus retrieval에,LumberChunker는 in-document retrieval에 효과적.[9] 하지만 문서 유형에 따라 성능이 크게 달라지므로 자신의 데이터셋으로 재검증 필수. - 메타데이터 5개 필수:
doc_id(원본),chunk_id(청크),title(제목),source(URL),created_at(시간 가중치)
동일한 질문 셋(최소 50개)을 모든 청킹 전략에 적용해 검색 성능을 정량적으로 비교하는 것이 가장 확실한 평가 방법이다.
이 접근법의 한계: 어디까지 가능하고 어디서 막히는가?
청킹 최적화는 RAG의 필요조건이지만 충분조건이 아니다. 청크가 아무리 좋아도 다음 단계에서 실패할 수 있다:
- 임베딩 모델의 한계: 한국어 특화 임베딩(예:
KoSRoBERTa기반)을 사용하지 않으면 문화/전문용어 의미 손실. 청킹을 아무리 정교하게 해도 임베딩 단계에서 신호가 약해지면 검색 성능이 30~40% 저하. - 주제 경계의 모호성: 학술 논문처럼 논리 흐름이 긴 문서는 시맨틱 청킹으로도 완벽한 경계 결정 불가능. 수동 재검증 필요한 경우 많음.
- 비용 vs 정확도 곡선의 한계수렴: 일정 지점 이상 정확도 개선은 비용 대비 수익률이 급격히 떨어짐. 계층적 청킹 도입으로 +5
10%, 시맨틱 청킹으로 추가 +35% 정도가 현실적 기대치. - 다국어 혼재 문서: 영어와 한국어가 섞여 있으면 토크나이저 기반 청킹이 부정확해짐. 언어별 분리 전처리 필수인데, 이는 청킹 영역을 벗어남.
작은 규모(문서 <10,000개) 시스템은 고정 크기 청킹으로 충분히 80% 이상 성능에 도달할 수 있으나, 대규모 다양한 문서는 계층적 청킹 + 하이브리드 검색이 실질적 최소요건이다.
핵심 정리
- 시작점: 500
1,000자(오버랩 1020%) 고정 크기 청킹으로 검색 성능 측정. 대부분 케이스 충분. - 평가 실패 시: 계층적 청킹(부모/자식 이중 저장) 또는 하이브리드 검색(BM25+벡터) 순으로 도입. 시맨틱 청킹은 우선순위 낮음.
- 검색 최적화: 1차 후보 검색 → 리랭킹 → 최종 5개 청크 LLM 전달 파이프라인으로 48% 정확도 향상 가능.
- 평가: HiCBench 같은 공개 벤치마크 + 자신의 QA 데이터셋으로 재현율·정확도 정량 비교 필수. 추측 금지.
- 한계 인식: 청킹은 필요조건이지만 임베딩 모델, 리랭킹, 프롬프트 설계도 함께 작동. 청킹 단독으로 성능 보장 불가.