핵심 요약 (Key Takeaways)

• RAG 파이프라인 청킹 (Chunking) 전략은 임베딩 모델 (Embedding model)이나 벡터 스토어 (Vector store)보다 검색 품질을 더 크게 결정합니다. 대부분의 재현율 (Recall) 실패는 데이터 주입 (Ingestion) 과정에서 문서가 어떻게 분할되었는지로 거슬러 올라갑니다.
• 고정 크기 청킹 (Fixed-size chunking, 1015% 중첩을 포함한 256512 토큰)은 균질한 산문 형태의 데이터에 적합한 시작점입니다. 기술 문서나 혼합 형식의 코퍼스 (Corpora)에서는 의미론적 (Semantic) 및 구조적 (Structural) 전략이 더 뛰어난 성능을 보입니다.
• 계층적 (Hierarchical, 부모-자식) 청킹은 프로덕션 시스템을 위한 가장 높은 성능의 접근 방식입니다. 정밀한 벡터 검색을 위해 작은 청크 (Chunk)를 사용하고, LLM에 전체 문맥을 전달하기 위해 큰 부모 청크를 사용합니다.
• 배포 전에는 항상 골든 검색 세트 (Golden retrieval set, 30~50개의 주석이 달린 쿼리)를 사용하여 청킹 변경 사항을 평가해야 합니다. 임베딩 모델이나 프롬프트 (Prompt)를 조정하기 전에 recall@3 수치를 80% 이상으로 목표로 하세요.

잘못된 답변을 반환하는 RAG 파이프라인을 진단하는 가장 빠른 방법은 프롬프트를 검사하거나 LLM을 교체하는 것이 아니라, 벡터 스토어가 실제로 무엇을 검색하고 있는지 살펴보는 것입니다. 우리가 진단하는 대부분의 프로덕션 실패 사례에서, 정답 정보는 코퍼스 내에 존재합니다. 단지 검색할 수 없는 방식으로 청킹되었을 뿐입니다.

RAG 파이프라인 청킹 전략은 벡터 스토어가 올바른 문맥 (Context)을 찾을지 아니면 노이즈 (Noise)를 검색할지를 결정합니다. 프로덕션과 관련된 네 가지 접근 방식인 고정 크기 (Fixed-size), 의미론적 (Semantic), 구조적 (Structural), 계층적 (Hierarchical) 방식은 각각 문서 커버리지와 검색 정밀도 (Retrieval precision) 사이의 균형을 다르게 맞춥니다. 귀하의 코퍼스 유형, 쿼리 프로필, 그리고 LLM 문맥 예산 (Context budget)에 따라 어떤 방식이 적합한지가 결정됩니다.

왜 청킹이 RAG 검색 실패의 주요 원인인가

프로덕션 환경에서의 대부분의 RAG 파이프라인 실패는 LLM, 임베딩 모델, 또는 벡터 스토어가 아니라, 데이터 주입 중에 내려진 청킹 결정으로 인해 발생합니다. 출시 후 검색 재현율 (Retrieval recall)이 떨어질 때, 올바른 정보는 대개 코퍼스에 존재하지만 청크 경계에 걸쳐 분할되었거나 의미론적 신호를 희석시키는 문맥과 함께 임베딩되었을 가능성이 큽니다.

그 메커니즘은 간단합니다. 임베딩 모델 (Embedding models)은 텍스트를 의미론적 의미를 인코딩하는 고정된 크기의 벡터 (vector)로 매핑합니다. 청크 (chunk)가 하나의 완전하고 일관된 생각 — 문장, 단락, 또는 문서의 한 섹션 — 을 포함할 때, 생성된 벡터는 해당 아이디어를 깨끗하게 표현합니다. 반면, 청크가 문장 중간에서 끊기거나, 관련 없는 주제들을 섞거나, 세 가지의 서로 다른 개념에 걸쳐 있는 경우, 벡터는 이러한 신호들을 평균화하게 되어 특정 쿼리 (query)에 대해 부적절한 매칭 결과가 됩니다.

실제 운영 환경에서 가장 자주 발생하는 세 가지 청킹 실패 모드는 다음과 같습니다:

경계 절단 (Boundary truncation). 쿼리에 대한 답을 포함하고 있는 문장이 두 개의 청크로 나뉩니다. 어느 청크도 단독으로는 정보를 검색해내지 못합니다. 두 청크가 합쳐져야 답을 할 수 있지만, 벡터 저장소 (vector store)는 이들을 함께 보지 못합니다.

문맥 희석 (Context dilution). 1,024 토큰 (token) 크기의 고정된 청크에 매우 관련성이 높은 단락 하나와 관련 없는 다섯 개의 단락이 포함되어 있습니다. 관련 구절의 신호가 주변의 노이즈와 평균화되면서, 코사인 유사도 (cosine similarity) 점수가 검색 임계값 (retrieval threshold) 아래로 떨어집니다.

메타데이터 누락 (Missing metadata). 크기는 적절하지만 소스 섹션, 문서 유형 또는 날짜에 대한 메타데이터를 포함하지 않는 청크들입니다. 멀티 테넌트 (multi-tenant) 또는 시간에 민감한 코퍼스 (corpora)에 필수적인 메타데이터 필터링 검색 (Metadata-filtered retrieval)은 메타데이터 없이는 작동할 수 없습니다.

고정 크기 청킹 (Fixed-Size Chunking): 올바른 시작점

고정 크기 청킹 (Fixed-size chunking)은 문장이나 단락의 경계와 관계없이 토큰 수에 따라 문서를 분할합니다. 일반적으로 설정 가능한 오버랩 (overlap)을 포함하여 256에서 1,024 토큰 사이로 설정합니다. 이는 대부분의 RAG 프레임워크 (frameworks)에서 기본값으로 사용되며, tiktoken이나 LangChain의 RecursiveCharacterTextSplitter를 사용하여 빠르게 구현할 수 있고, 출력 분포가 예측 가능하다는 장점이 있습니다.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
...

효과적인 경우. 고정 크기 청킹 (Fixed-size chunking)은 금융 보고서, 연구 논문, 장문 기사와 같이 문단이 연속적으로 흐르고 자연스러운 섹션 구분(section breaks)이 드문 균질한 산문 (homogeneous prose)에서 잘 작동합니다. 또한 쿼리 프로필 (query profile)이 특정 사실 중심이 아닌 일반적인 경우에도 효과적입니다.

실패하는 경우. 고정 크기 청킹은 기술 문서, 코드가 많은 위키, 표가 포함된 PDF와 같이 구조화된 문서 (structured documents)에서 성능이 저하됩니다. 이러한 문서에서는 임의의 토큰 분할 (token splits)이 문장 중간이나 표 중간에서 빈번하게 발생하기 때문입니다. 또한 쿼리가 매우 구체적인 경우에도 성능이 떨어집니다. 필요한 단 한 문장과 관련 없는 문맥 490 토큰이 포함된 512 토큰 크기의 청크는, 잘 타겟팅된 128 토큰 크기의 의미론적 청크 (semantic chunk)보다 낮은 순위를 기록할 것입니다.

청크 크기 가이드라인:

오버랩 (Overlap)은 청크 크기의 10–15%로 설정하십시오. 10% 미만이면 경계 절단 (boundary truncation)이 증가하고, 20%를 초과하면 인덱스 팽창 (index inflation)이 재현율 (recall) 이득보다 커집니다.

의미론적 및 구조적 청킹: 문서 경계 준수

의미론적 청킹 (Semantic chunking)은 임의의 토큰 수 대신 문장 또는 문단 경계에서 분할하여, 임베딩 모델 (embedding models)이 표현하도록 학습된 언어적 단위 (linguistic units)를 보존합니다. LangChain의 SemanticChunker는 연속된 문장 사이의 임베딩 거리 (embedding distance)를 사용하여 주제 변화 (topic shifts)를 감지하며, LlamaIndex의 SentenceSplitter는 설정 가능한 최대 청크 크기를 유지하면서 문장 끝을 존중합니다.

**문장 수준의 의미론적 청킹 (Sentence-level semantic chunking)**은 FAQ 페이지, 지원 지식 베이스 (support knowledge bases), 제품 문서와 같이 모든 경계가 중요한 짧고 밀도 높은 문장을 포함하는 문서에서 가장 가치가 높습니다. 결과물로 생성된 청크는 크기가 가변적이지만 의미론적으로 일관성이 있으며, 이는 짧고 정밀한 쿼리에 대해 더 나은 코사인 유사도 (cosine similarity) 매칭을 생성하는 경향이 있습니다.

**구조적 (header-based) 청킹 (Structural chunking)**은 의미론적 신호 대신 문서 구조 — Markdown 헤더, HTML 제목, 또는 PDF 섹션 마커 — 를 기준으로 분할합니다. LangChain의 MarkdownHeaderTextSplitter는 #, ##, ### 경계에서 분할하며, 헤더 계층 구조를 청크 메타데이터 (metadata)로 전파합니다:

from langchain.text_splitter import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
...

이 메타데이터가 핵심적인 장점입니다. 다운스트림 검색 (downstream retrieval) 단계에서 벡터 검색 (vector search)을 실행하기 전에 섹션별로 필터링(h2 == "API Reference")할 수 있어, 개발자 문서나 내부 위키와 같은 구조화된 기술 코퍼스 (technical corpora) 에서 정밀도 (precision)를 극적으로 향상시킵니다.

의미론적 청킹 대신 구조적 청킹을 사용하는 경우: 문서가 일관된 헤더 구조를 가지고 있다면, 구조적 청킹은 정밀도 측면에서 의미론적 분할 (semantic splitting)보다 거의 항상 뛰어난 성능을 보입니다. 반면, 고객 지원 티켓, 이메일 스레드, 자유 형식의 노트와 같이 헤더가 없는 산문 형태의 문서라면 의미론적 분할을 사용하십시오.

계층적 청킹 (Hierarchical Chunking): 전체 문맥을 활용한 정밀 검색

계층적 청킹 (Hierarchical chunking)은 모든 문서 세그먼트 (segment)에 대해 두 가지 표현 방식을 저장합니다. 즉, 정밀한 검색을 위한 작은 청크 (64–128 토큰)와 LLM에 전체 문맥을 전달하기 위한 더 큰 부모 청크 (512–1,024 토큰)입니다. 쿼리 시점에 벡터 스토어 (vector store)가 작은 청크를 검색하면, 시스템은 이를 모델에 전달하기 전에 해당 청크의 부모 청크를 가져옵니다.

이는 청킹의 핵심적인 갈등 요소를 해결합니다. 작은 청크는 더 정밀한 벡터 검색을 생성하지만, LLM이 완전한 답변을 합성하기에는 너무 적은 문맥을 전달합니다. 큰 청크는 전체 문맥을 제공하지만, 희석된 임베딩 (embeddings)으로 인해 검색 성능이 떨어집니다. 계층적 청킹은 이 두 가지 문제를 분리합니다.

LangChain의 ParentDocumentRetriever는 이를 즉시 사용할 수 있도록 구현하고 있습니다:

from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore
from langchain.text_splitter import RecursiveCharacterTextSplitter
...

실무적 이점 (The production advantage). Prodinit의 실제 RAG 배포 사례에 따르면, 평면적인 512-토큰 고정 청킹 (fixed chunking) 방식에서 계층적 128-토큰 자식(child) / 768-토큰 부모(parent) 설정으로 전환했을 때 recall@3 성능이 일관되게 향상되었습니다. 이는 특히 단일 문장을 검색하는 것이 아니라 한 섹션 전체의 정보를 종합해야 하는 질의(query)에서 두드러졌습니다. 이러한 개선 효과는 긴 기술 문서나 여러 문단으로 구성된 정책 콘텐츠에서 가장 명확하게 나타납니다.

트레이드오프 (Trade-offs). 계층적 청킹은 저장 공간 점유율을 두 배로 늘리며 (부모 청크와 자식 청크가 공존), 검색 시점에 데이터를 가져오는 단계(fetch step)를 추가합니다. 10만 개 미만의 문서로 구성된 코퍼스(corpora)의 경우, 지연 시간(latency) 차이는 미미합니다. 일반적으로 벡터 검색(vector search) 외에 문서 저장소(docstore)에서 추가로 가져오는 데 약 20~40ms 정도가 소요됩니다. 하지만 매우 큰 규모의 코퍼스의 경우, 문서 저장소(InMemoryStore, Redis 또는 PostgreSQL)가 리트리버(retriever)와 같은 위치에 있지 않다면 이 두 번째 가져오기 단계가 병목 현상이 될 수 있습니다.

RAG 파이프라인 청킹 전략: 선택 방법

적절한 RAG 파이프라인 청킹 전략을 선택하는 것은 세 가지 변수에 따라 달라집니다: 문서의 유형 및 구조, 질의 프로필 (짧은 사실 확인형 vs. 긴 분석형 질문), 그리고 LLM의 컨텍스트 예산(context budget)입니다. 모든 코퍼스에 통용되는 단 하나의 전략은 없습니다. 결정은 경험적이어야 하며, 실제 적용하기 전에 골든 데이터셋(golden dataset)을 통해 검색 재현율(retrieval recall)을 측정하는 것은 타협할 수 없는 필수 사항입니다.

중요한 평가 루프 (The evaluation loop that matters): 청킹 전략을 최종 확정하기 전에, 30~50개의 대표 질의로 구성된 골든 검색 세트(golden retrieval set)를 구축하고, 정답 소스 구절(source passages)을 주석 처리한 뒤, recall@3 (정답 청크가 상위 3개 결과 안에 포함되는가?)를 측정하십시오. 특정 코퍼스에 잘 구성된 청킹 전략은 임베딩 모델(embedding model)을 튜닝하거나, 유사도 임계값(similarity thresholds)을 조정하거나, 프롬프트(prompts)를 다시 작성하기 전에 recall@3 수치가 80% 이상에 도달해야 합니다.

수집(ingestion) 단계에서 내려진 청킹(chunking) 결정은 운영 환경에서 변경하기 가장 어렵습니다. 전체 코퍼스(corpus)를 다시 임베딩(re-embedding)하고 다시 인덱싱(re-indexing)해야 하기 때문입니다. 출시 전에 청킹을 올바르게 설정하는 것이, 운영 6주 후에 검색 품질 저하(retrieval quality drift)를 수정하는 것보다 훨씬 비용이 저렴합니다. 운영 중인 RAG 시스템의 5가지 실패 모드(five failure modes in production RAG systems)에서는 오래된 임베딩(stale embeddings) 및 쿼리-문서 불일치(query-document mismatch)를 포함하여, 청킹 이후에 발생하는 문제들을 다룹니다.

자주 묻는 질문 (Frequently Asked Questions)

RAG 파이프라인을 위한 최적의 청크 크기는 무엇인가요?

대부분의 RAG 사용 사례에서 청크당 256512 토큰(tokens)이 실질적인 시작점입니다. 더 작은 청크(128256 토큰)는 사실 확인(fact-lookup) 쿼리에 대한 정밀도(precision)를 높여주지만 주변 문맥(context)을 잃을 위험이 있습니다. 더 큰 청크(512~1,024 토큰)는 문맥을 보존하지만 임베딩 신호(embedding signal)를 희석시킵니다. 운영 환경에서 청크 크기를 고정하기 전에, 골든 검색 세트(golden retrieval set)의 쿼리 분포를 대상으로 테스트를 수행하십시오.

청크 오버랩(chunk overlap)은 어떻게 작동하며 얼마나 사용해야 하나요?

청크 오버랩은 한 청크의 끝부분에서 토큰 슬라이스(token slice)를 복사하여 다음 청크의 시작 부분에 붙여넣는 방식으로, 경계에 걸쳐 있는 문장이 최소한 하나 이상의 검색 가능한 단위에 포함되도록 보장합니다. 1015%의 오버랩(512 토큰 청크 기준 2575 토큰)이 표준적인 시작점입니다. 오버랩이 너무 많으면 검색률(recall)의 비례적인 이득 없이 벡터 저장소(vector store)의 크기만 키우게 됩니다.

마크다운(Markdown) 및 기술 문서에는 어떤 청킹 전략이 가장 효과적인가요?

헤더 기반의 구조적 청킹(Header-based structural chunking)이 마크다운 및 기술 문서에 가장 강력한 기본 전략입니다. LangChain의 MarkdownHeaderTextSplitter는 #, ##, ### 경계를 기준으로 분할하며, 헤더 계층 구조를 청크 메타데이터(metadata)로 전파하여 섹션별 메타데이터 필터링 검색(metadata-filtered retrieval)을 가능하게 합니다. 각 헤더 섹션 내부에서 512 토큰 단위의 서브 청킹(sub-chunking)을 병행하여, 너무 큰 청크가 임베딩 정밀도를 희석하는 것을 방지하십시오.

청크 크기가 임베딩 모델의 성능에 영향을 미치나요?

네 — 임베딩 모델 (embedding models)은 가장 의미 있는 벡터를 생성할 수 있는 유효한 입력 범위 (effective input range)를 가지고 있습니다. OpenAI의 text-embedding-3-small 및 text-embedding-3-large는 최대 8,191 토큰을 수용하지만, 검색 정밀도 (retrieval precision)는 일반적으로 256–512 토큰 입력에서 정점에 도달합니다. 매우 긴 청크는 모델이 너무 많은 텍스트에 걸쳐 의미적 신호 (semantic signal)를 평균화하도록 강제하며, 이는 결과 벡터의 차별성을 감소시키고 검색 시 코사인 유사도 (cosine similarity) 점수를 낮추는 결과를 초래합니다.

청킹 전략이 제대로 작동하는지 어떻게 평가하나요?

골든 검색 세트 (golden retrieval set)를 구축하십시오: 정답 소스 구절 (source passages)이 주석 처리된 30–50개의 대표 쿼리 (queries)로 구성합니다. 각 쿼리에 대해, 정답 구절이 상위 k개의 검색된 청크 내에 포함되는지 측정합니다 (recall@k). 잘 청킹된 코퍼스 (corpus)라면 사용자의 쿼리 분포에 대해 recall@3 수치가 80% 이상을 달성해야 합니다. 만약 그렇지 않다면, 임베딩 모델이나 프롬프트 (prompt)를 수정하기 전에 청크 크기, 오버랩 (overlap), 또는 전략을 먼저 조정하십시오.