RAG 답변 품질을 좌우하는 청킹 전략: 실증 데이터로 검증한 최적 크기와 방법

AI에게 "이 보고서의 핵심을 요약해줘"라고 질문하면, 대부분의 RAG 시스템은 문서를 작은 조각으로 나누어 읽어요. 그런데 이 조각(청크)을 어떻게 자르느냐에 따라 답변의 품질이 극적으로 달라집니다.

NVIDIA, LlamaIndex, Arize.ai 등 여러 연구 기관이 수행한 실증 실험 결과를 종합하면, 청킹 전략은 RAG 성능을 결정짓는 가장 중요한 변수 중 하나예요. 이번 글에서는 실제 데이터를 바탕으로 최적의 청킹 전략을 찾는 방법을 알아보겠습니다.

청킹(Chunking)이란? RAG 답변 품질의 결정적인 과정

청킹이란 "AI가 이해할 수 있는 문맥 단위로 문서를 분리하는 과정"이에요. LLM은 한 번에 모든 문서를 읽을 수 없기 때문에, 문서를 여러 구간(청크)으로 나누어 처리합니다.

왜 청킹이 필요한가?

청킹이 필수인 이유는 크게 두 가지예요:

1. 임베딩 모델의 Context Window 제약: 대부분의 임베딩 모델은 한 번에 처리할 수 있는 토큰 수에 한계가 있어요. 예를 들어, OpenAI의 text-embedding-3-small은 최대 8,196 토큰까지 처리할 수 있죠. 이 한계를 넘으면 초과 토큰이 잘려나가 중요한 정보가 손실될 수 있어요.

2. 검색 정밀도 향상: 청크 단위로 검색하면 사용자 질문과 가장 관련 있는 부분만 정확히 찾아낼 수 있어요. 만약 전체 문서를 하나의 덩어리로 검색한다면, 관련 없는 정보까지 함께 딸려와 AI의 판단을 흐릴 수 있죠.

청킹이 품질에 미치는 영향

청킹 방식은 세 가지 측면에서 RAG 성능을 좌우해요:

• 관련성(Relevance): 질문과 관련된 정보를 얼마나 정확히 찾아내는가

• 맥락 완전성(Context Completeness): 필요한 정보가 한 청크 안에 완전히 담겨 있는가

• 토큰 효율성(Token Efficiency): 불필요한 정보 없이 꼭 필요한 내용만 전달하는가

잘못된 청킹이 초래하는 3가지 문제

청킹을 잘못하면 아무리 좋은 LLM을 써도 정확한 답을 얻기 어려워요. 실제로 어떤 문제가 발생하는지 구체적으로 살펴볼게요.

문제 1 - 맥락 단절 (Context Fragmentation)

예를 들어, 반기보고서의 재무제표 부분을 생각해봅시다. 한 청크에는 숫자 표만, 다른 청크에는 표 아래의 주석만 담겨 있다면 어떻게 될까요?

AI는 두 정보를 연결하지 못합니다. 결과적으로 "AI 투자 금액이 얼마인가요?"라는 질문에 표는 읽었지만 설명을 모르고, 설명은 봤지만 숫자를 모르는 맥락 단절형 답변이 나올 수 있어요.

이것이 '잘못된 청킹'의 가장 대표적인 예입니다. 의미적으로 연결된 정보가 물리적으로 분리되면서 발생하는 문제죠.

문제 2 - 정보 희석 (Information Dilution)

반대로 청크가 너무 크면 어떻게 될까요? 하나의 청크 안에 여러 주제가 뒤섞여 들어가게 돼요.

임베딩 모델은 텍스트를 하나의 고정된 크기의 벡터로 압축하는데, 큰 청크는 이 과정에서 중요한 디테일이 희석될 수 있어요. 마치 고해상도 사진을 저해상도로 줄일 때 세부 정보가 뭉개지는 것과 비슷하죠.

Pinecone의 연구에 따르면, 1,000단어가 넘는 긴 텍스트를 하나의 벡터로 표현하면 개별 문장의 의미가 평균화되어 검색 정밀도가 떨어진다고 해요.

문제 3 - 검색 효율 저하

청크가 너무 작으면 문맥이 부족해서 독립적으로 이해하기 어려워져요. 그 결과:

• 하나의 질문에 답하려면 여러 개의 작은 청크를 검색해야 해요

• K값(검색할 청크 수)을 높이면 지연시간이 증가하고

• 불필요한 토큰까지 LLM에 전달되어 비용이 상승하죠

Arize.ai의 실험에서 K=10으로 설정했을 때 K=4 대비 응답 시간이 거의 2배 증가했다는 결과가 이를 뒷받침해요.

실증 데이터로 검증한 최적 청크 크기

그렇다면 최적의 청크 크기는 얼마일까요? 다행히 여러 연구 기관이 다양한 데이터셋으로 이 질문에 답을 찾았어요.

다양한 실험 결과 종합

주요 연구 결과를 테이블로 정리해볼게요:

최적 크기에 대한 합의

이렇게 다양한 연구 결과를 종합하면 몇 가지 명확한 패턴이 보여요:

1. 시작점: 250~500 토큰 (약 1,000~2,000자)

대부분의 연구에서 이 범위가 성능과 효율의 최적 균형점으로 나타났어요. 한국어는 영어보다 정보 밀도가 높아서, 약 500~1,000자 정도가 적당하다고 볼 수 있죠.

2. 문서 유형별 차이

• 간단한 문서 (FAQ, 제품 설명): 200~300 토큰으로 충분

• 복잡한 기술 문서 (논문, 보고서): 512~1024 토큰 필요

• 재무 문서: NVIDIA 실험에서 1024 토큰이 최적으로 나타남

3. K값(검색 청크 수) 최적화

Arize.ai 실험 결과에 따르면:

• K=4~6이 성능과 지연시간의 최적 균형점

• K=10으로 높이면 응답 시간이 2배 증가하지만 정확도 향상은 미미

• 실시간 사용자 응답이 필요하면 K=4 권장

극단적인 크기는 왜 안 좋을까?

LlamaIndex 실험에서 흥미로운 결과가 나왔어요:

• 128 토큰: 너무 작아서 문맥이 단절되고, 여러 청크를 조합해야 해서 비효율적

• 2048 토큰: 너무 커서 정보가 희석되고, 불필요한 내용이 많이 포함됨

• 1024 토큰: Faithfulness와 Relevancy 모두 최고치 기록

이는 "Goldilocks Zone" (골디락스 존) 개념과 일치해요. 너무 작지도 크지도 않은, 딱 적당한 크기가 있다는 거죠.

청킹 전략 비교: 어떤 방법을 선택할 것인가

청크 크기만큼 중요한 게 어떻게 자를 것인가예요. 대표적인 청킹 전략 4가지를 비교해볼게요.

고정 크기 청킹 (Fixed-size Chunking)

작동 원리: 문서를 일정한 토큰/문자 수로 균등하게 자르는 가장 단순한 방법이에요.

🟢 장점:

• 구현이 매우 간단해요

• 청크 크기가 예측 가능해서 메모리 관리가 쉬워요

• 처리 속도가 빨라요

🔴 단점:

• 문장 중간이나 단어 중간에서 잘릴 수 있어요

• 문서의 구조(섹션, 문단)를 무시해요

• 의미적으로 연결된 정보가 분리될 수 있어요

💙 적합한 경우:

• 구조가 단순한 텍스트 (채팅 로그, 제품 설명)

• 빠른 프로토타입이 필요할 때

• 일관된 형식의 대량 문서 처리

의미 기반 청킹 (Semantic Chunking)

작동 원리: 문단, 섹션, 문장 같은 의미적 경계에서 문서를 자르는 방법이에요.

🟢 장점:

• 아이디어의 완결성을 유지해요

• 관련된 정보가 함께 묶여서 검색 정확도가 높아요

• 사람이 읽기에도 자연스러워요

🔴 단점:

• 청크 크기가 일정하지 않아요

• 구현이 다소 복잡해요 (문장 분리 알고리즘 필요)

• 처리 시간이 고정 크기 방식보다 길어요

💙 적합한 경우:

• 구조화된 문서 (학술 논문, 보고서, 기술 문서)

• 문단/섹션이 명확히 구분된 콘텐츠

• 맥락의 연속성이 중요한 경우

Databricks의 연구에 따르면, 의미 기반 청킹은 문서의 자연스러운 흐름을 보존하면서도 검색 성능을 크게 개선할 수 있다고 해요.

재귀적 청킹 (Recursive Chunking)

작동 원리: 구분자의 계층(예: \\\\n\\\\n → \\\\n → . → ``)을 순서대로 적용해서 문서를 자르는 방법이에요.

LangChain의 RecursiveCharacterTextSplitter가 대표적인데, Chroma Research 실험에서 200 토큰 크기, 오버랩 없음 설정이 가장 좋은 성능을 보였어요.

🟢 장점:

• 문맥을 인식하면서도 크기 제어가 가능해요

• 코드나 기술 문서처럼 구조가 명확한 텍스트에 최적이에요

• 고정 크기와 의미 기반의 중간 지점이에요

🔴 단점:

• 구분자 순서를 잘못 설정하면 성능이 떨어져요

• 문서 유형마다 최적의 구분자가 달라요

• 디버깅이 다소 어려워요

💙 적합한 경우:

• 소스 코드 문서

• 마크다운, HTML 같은 구조화된 텍스트

• 기술 매뉴얼, API 문서

적응형 청킹 (Adaptive Chunking)

작동 원리: 텍스트의 복잡도에 따라 청크 크기를 동적으로 조정하는 가장 발전된 방법이에요.

Databricks의 연구에서 소개된 방법으로, 간단한 섹션은 큰 청크로, 복잡한 섹션은 작은 청크로 나눠요. 예를 들어:

• 어휘 밀도(Lexical Density)가 높은 부분 → 작은 청크

• 평균 문장 길이가 긴 부분 → 작은 청크

• 반복적인 설명 부분 → 큰 청크

로컬독스(LocalDocs)의 Adaptive Chunking 사례:

로컬독스(LocalDocs)는 단순히 토큰 수로 자르지 않고, 문서의 구조를 인식한 뒤 의미적으로 연결된 덩어리를 하나의 청크로 묶어요:

• 표 + 표 설명

• 본문 + 주석

• 섹션 헤더 + 해당 내용

이 방식은 문서의 구조(Structure)와 의미(Semantics)를 모두 고려해서 AI가 이해하기 최적화된 단위로 자동 분할해요.

🟢 장점:

• 복잡한 문서에서 최고의 성능을 발휘해요

• 토큰을 효율적으로 사용해요

• 문맥 보존과 정보 밀도의 균형이 뛰어나요

🔴 단점:

• 구현 복잡도가 가장 높아요

• 처리 시간이 가장 길어요 (복잡도 분석 필요)

• 설정할 파라미터가 많아요

💙 적합한 경우:

• 복잡도가 다양한 혼합 문서 (연구 보고서, 백과사전)

• 정확도가 최우선인 경우

• 처리 시간보다 품질이 중요한 경우

실무 적용 가이드라인

이제 실제로 어떻게 적용할지 구체적인 가이드를 제시할게요.

문서 유형별 추천 전략

실전에서 사용할 수 있는 문서 유형별 청킹 전략을 정리했어요:

성능 vs 지연시간 트레이드오프

실무에서는 항상 정확도와 속도 사이의 균형을 고려해야 해요. Arize.ai 실험 결과를 바탕으로 두 가지 시나리오를 제시할게요:

시나리오 1: 빠른 응답이 필수인 경우 (실시간 챗봇, 고객 지원)

• 청크 크기: 300 토큰

• K값: 4

• 검색 방법: 단순 벡터 검색 (re-ranking 없음)

• 예상 지연시간: ~1초

• 정확도: 평균 수준 (Precision ~80%)

시나리오 2: 정확도가 최우선인 경우 (전문가 시스템, 법률/의료 조언)

• 청크 크기: 500~1024 토큰

• K값: 6

• 검색 방법: HyDE + Re-ranking

• 예상 지연시간: ~5초

• 정확도: 높음 (Precision ~95%)

실험 데이터에 따르면, HyDE + Re-ranking은 정확도를 약 15% 개선하지만 응답 시간이 5배 증가했어요. 따라서 사용자 경험을 고려해 신중히 선택해야 합니다.

청킹 실험 프레임워크

자신의 데이터에 맞는 최적 설정을 찾으려면 체계적인 실험이 필요해요. 다음 3단계 프레임워크를 추천해요:

1단계: 기준선 설정

• 고정 크기 청킹으로 시작: 300~500 토큰

• K=4, 오버랩 없음

• 단순 벡터 검색

• 이 설정으로 현재 성능을 측정하세요

2단계: 메트릭 정의

• Precision: 검색된 청크 중 관련 있는 비율

• Recall: 관련 있는 청크를 얼마나 찾아냈는가

• IoU (Intersection over Union): 토큰 레벨의 정확도 (Chroma Research 방법)

• 응답 시간: 평균/중앙값 지연시간

• 사용자 만족도: 실제 답변 품질 평가

3단계: 반복 개선

1. 청크 크기 조정: 200, 300, 500, 1024 토큰으로 테스트

2. 전략 변경: 고정 → 재귀적 → 의미 기반 순으로 시도

3. K값 최적화: 3, 4, 6, 8로 비교

4. 고급 기법 적용: Re-ranking, HyDE 등 (필요시)

5. 문서 특성 반영: 표, 코드 블록 등 특수 요소 처리

Phoenix LLM Evals나 RAGAS 같은 오픈소스 평가 라이브러리를 사용하면 이 과정을 자동화할 수 있어요.

결론 - 좋은 청킹은 맥락을 보존하는 기술이다

지금까지 여러 연구 기관의 실증 데이터를 바탕으로 RAG 청킹 전략을 깊이 있게 살펴봤어요. 핵심을 다시 정리하면:

핵심 메시지: "얼마나 잘 나눴는가"가 성능을 결정한다

RAG의 답변 품질은 결국 "얼마나 잘 검색했는가"보다 "얼마나 잘 나눴는가"에 달려 있어요.

나누는 순간 문맥이 깨지면, 아무리 정교한 검색·생성 기술을 써도 정확한 답을 내기 어려워요. NVIDIA, LlamaIndex, Arize.ai의 실험 결과가 모두 이를 뒷받침하고 있죠.

실용적 권고사항

1. 250~500 토큰에서 시작하세요

   • 대부분의 문서 유형에서 이 범위가 최적이에요

   • 한국어는 500~1,000자 정도가 적당해요

   • 너무 작거나(128) 크면(2048) 성능이 떨어져요

2. 문서 구조를 고려하세요

   • 표와 주석, 섹션 헤더와 본문은 함께 묶어야 해요

   • 코드 블록은 독립적으로 처리하세요

   • 의미적으로 연결된 정보는 분리하지 마세요

3. 자신의 데이터로 반드시 실험하세요

   • 문서 특성마다 최적 설정이 달라요

   • Precision, Recall, 응답 시간을 함께 측정하세요

   • K=4~6에서 시작해서 점진적으로 조정하세요

맥락을 보존하는 청킹의 실천

좋은 청킹은 단순히 문서를 자르는 게 아니라 "맥락을 보존하는 기술"이에요.

LocalDocs 같은 시스템은 adaptive chunking을 통해 문서 구조를 자동으로 인식하고, 의미적으로 연결된 덩어리를 하나의 청크로 묶어요. 이렇게 하면 ChatGPT 같은 온라인 도구에서 놓쳤던 관계와 의미를 복원할 수 있죠.

더 중요한 것은, 이런 최적화된 청킹이 오프라인 환경에서도 가능하다는 점이에요. 데이터 보안이 중요한 조직에서는 외부로 문서를 보내지 않고도 정확한 RAG 시스템을 구축할 수 있어요.

즉, 좋은 RAG는 좋은 청킹에서 시작됩니다.

여러분의 문서로 직접 실험해보세요. 300 토큰, K=4로 시작해서 점진적으로 개선해나가면, 분명 더 정확하고 신뢰할 수 있는 AI 답변을 얻을 수 있을 거예요.

참고 자료

1. Databricks (2025). "The Ultimate Guide to Chunking Strategies for RAG Applications"

2. NVIDIA (2025). "Finding the Best Chunking Strategy for Accurate AI Responses"

3. Unstructured (2024). "Chunking for RAG: Best Practices"

4. Pinecone (2024). "Chunking Strategies for LLM Applications"

5. LlamaIndex (2023). "Evaluating the Ideal Chunk Size for a RAG System"

6. 요즘IT (2025). "RAG 애플리케이션 개발을 위한 Chunking 최적화"

7. Chroma Research (2024). "Evaluating Chunking Strategies for Retrieval"

8. Arize.ai (2023). "Benchmarking Evaluation of LLM RAG Chunking Strategy"