데이터 청킹: 컨텍스트 윈도우가 커져도 여전히 필요한 이유

LLM 기반 애플리케이션을 개발하면서 문서 처리 파이프라인을 설계할 때 가장 먼저 부딪히는 기술적 장벽이 바로 데이터 청킹(Data Chunking)이다. GPT-4나 Claude 같은 최신 모델들이 수십만 토큰의 컨텍스트 윈도우를 지원함에도, 실제 프로덕션 환경에서 모든 문서를 통째로 모델에 넘기는 방식은 성능과 비용 양쪽에서 심각한 문제를 일으킨다. 청킹은 단순히 긴 텍스트를 자르는 기술이 아니라, LLM이 정보를 효과적으로 인식하고 활용할 수 있도록 데이터를 재구조화하는 핵심 엔지니어링 작업이다.

컨텍스트 윈도우가 커져도 청킹이 필요한 이유

데이터 청킹(Data Chunking)은 대용량 텍스트 문서나 데이터를 LLM이 처리하기에 적합한 크기의 더 작은 단위(청크)로 분할하는 과정이다. 이 "더 작은 단위"가 정확히 어떤 의미인지는 청킹의 목적과 방식에 따라 달라진다. 단순히 글자 수나 토큰 수로 자르는 방법부터, 문서의 의미적 구조를 파악하고 그에 맞게 경계를 설정하는 방법까지 다양한 전략이 존재한다. 청킹의 궁극적 목표는 하나다. 각 청크가 독립적으로 의미를 가지면서도, LLM이 특정 쿼리에 대한 응답을 생성할 때 가장 관련성 높은 정보를 포함하도록 하는 것이다. 이 목표를 얼마나 잘 달성하느냐가 RAG(Retrieval-Augmented Generation) 시스템의 품질을 결정하는 핵심 변수 중 하나다.

가장 직접적인 이유는 컨텍스트 윈도우 제한이다. GPT-4o가 128K 토큰, Claude 3.5 Sonnet이 200K 토큰의 컨텍스트를 지원한다고 해도, 실제 기업 환경의 문서들은 이를 쉽게 초과한다. 법률 계약서, 기술 매뉴얼, 연구 논문 모음, ERP 시스템의 로그 데이터 등은 수백만 토큰에 달하는 경우가 많다.

Lost in the Middle: 길어질수록 가운데는 안 보인다

더 중요한 것은 컨텍스트가 길어질수록 발생하는 "Lost in the Middle" 문제다. 2023년 Stanford 연구팀의 연구에서 확인된 바와 같이, LLM은 긴 컨텍스트의 앞부분과 끝부분에 있는 정보를 중간에 있는 정보보다 훨씬 잘 활용한다. 10만 토큰의 문서를 통째로 컨텍스트에 넣으면, 5만 번째 토큰 근방의 정보는 사실상 모델에게 보이지 않는 것과 같다.

⤢✕

검색 품질과 비용을 가르는 청크 크기

RAG 시스템에서 청킹은 검색 품질과 직결된다. 벡터 검색(Vector Search)은 쿼리와 문서 청크 간의 의미적 유사도를 계산하여 가장 관련성 높은 청크를 검색한다. 이때 청크가 너무 크면 다양한 주제를 포함하게 되어 특정 쿼리에 대한 집중적인 관련성이 낮아진다. 반대로 너무 작으면 중요한 맥락 정보가 잘려 나가 검색된 청크만으로는 완전한 답을 구성하기 어렵다. 예를 들어, 10페이지짜리 기술 문서를 통째로 하나의 벡터로 만들면, "메모리 누수를 어떻게 디버깅하나요?"라는 질문에 대해 설치 방법, 기본 사용법, 고급 기능, 트러블슈팅이 모두 섞인 거대한 청크가 검색된다. 이 문서를 섹션별로 청킹하면 "트러블슈팅" 섹션만 정확하게 검색된다.

비용과 지연 시간도 걸려 있다. LLM API는 대부분 토큰 수 기준으로 과금되는데, 사용자의 질문과 관련 없는 수만 토큰의 문서 내용을 컨텍스트에 포함하는 것은 비용 낭비다. 적절한 청킹과 검색을 통해 실제로 필요한 2,000~4,000 토큰의 관련 컨텍스트만 LLM에 전달하면, 품질은 유지하면서 비용을 90% 이상 절감할 수 있다. 컨텍스트 길이가 늘어날수록 LLM의 추론 시간도 증가하므로, 사용자가 기다리는 실시간 서비스에서는 이 지연이 사용자 경험에 직접적인 영향을 미친다.

자르는 방식에 따라 갈리는 전략들

가장 단순한 방법인 **고정 크기 청킹(Fixed-Size Chunking)**은 문서를 고정된 토큰 수 또는 문자 수 단위로 분할한다. 구현이 쉽고 예측 가능하지만, 문장이나 단락 중간에서 잘릴 수 있어 의미 단위가 깨진다는 단점이 있다. 내용이 균질하고 구조가 단순한 문서(짧은 뉴스 기사들의 배치 처리 등)나 빠른 프로토타이핑 단계에서 기준선(baseline)을 설정할 때 적합하다. 주요 파라미터는 청크당 최대 토큰 수인 chunk_size(일반적으로 256~~1024)와 인접 청크 간 겹치는 토큰 수인 chunk_overlap(일반적으로 chunk_size의 10~~20%)이다.

**재귀적 청킹(Recursive Chunking)**은 고정 크기 청킹의 단점을 보완한 방법으로, 단락 구분자 → 문장 구분자 → 단어 단위 순서로 재귀적으로 분할 기준을 낮춰가며 청크를 생성한다. LangChain의 RecursiveCharacterTextSplitter가 이 방식의 대표적 구현체다. 문서의 자연스러운 구조를 우선적으로 존중하면서도 크기 제약을 지킬 수 있어, 일반 산문 형식의 문서나 명확한 단락 구조를 가진 문서, 특별한 도메인 지식 없이 빠르게 구현해야 할 때 좋은 성능을 보인다.

**의미적 청킹(Semantic Chunking)**은 텍스트의 의미적 유사도를 기반으로 청크 경계를 결정하는 방법이다. 문장 임베딩을 생성하고, 인접 문장 간의 의미 유사도가 급격히 낮아지는 지점을 경계로 삼는다. 즉, 주제가 바뀌는 지점을 자동으로 감지한다. 계산 비용이 높지만, 각 청크가 하나의 일관된 주제나 아이디어를 담게 되어 검색 관련성이 크게 향상된다. LlamaIndex의 SemanticSplitterNodeParser가 이 방식을 지원하며, 복잡한 기술 문서·학술 논문·다양한 주제를 다루는 긴 보고서, 검색 정확도가 중요한 프로덕션 시스템에 적합하다.

**문서 기반 청킹(Document-Based Chunking)**은 문서의 내재적 구조(헤더, 섹션, 표, 코드 블록 등)를 인식하고 이에 맞게 청킹하는 방법이다. Markdown 문서는 헤더 레벨로, HTML 문서는 태그 구조로, PDF는 레이아웃 분석을 통해 논리적 섹션을 파악한다. 문서 유형에 특화된 파서(parser)가 필요하지만 해당 문서 형식에 최적화된 청크를 생성하며, 일관된 구조를 가진 기업 문서나 Markdown/HTML/PDF 형식의 기술 문서, 헤더와 섹션이 명확히 정의된 매뉴얼에서 뛰어난 성능을 발휘한다.

⤢✕

RAG 파이프라인에서 청킹이 하는 일

RAG 파이프라인에서 청킹은 검색(Retrieval)과 생성(Generation) 모두에 영향을 미친다. 검색 단계에서는 청크의 의미적 밀도가 검색 정확도를 결정하고, 생성 단계에서는 검색된 청크들이 LLM의 컨텍스트를 구성하므로 청크의 완결성이 중요하다. 실험적으로 검증된 사실은, 동일한 RAG 시스템에서 청킹 전략만 변경해도 최종 응답 품질이 30~50% 차이 날 수 있다는 것이다. 이는 청킹이 단순한 전처리 단계가 아니라 시스템 품질을 결정하는 핵심 컴포넌트임을 의미한다.

겹쳐야 잃지 않는다: 오버랩과 계층적 구조

청크 간 오버랩은 청크 경계에서 발생하는 정보 손실을 방지하는 핵심 파라미터다. 오버랩이 없으면 문장의 앞부분이 한 청크에, 뒷부분이 다른 청크에 분리될 때 양쪽 청크 모두 완전한 맥락을 잃는다. 일반적으로 chunk_size의 10~~20%를 오버랩으로 설정하는 것이 권장되지만, 이는 문서의 특성에 따라 조정이 필요하다. 기술 문서나 법률 문서처럼 선행 맥락 의존도가 높은 경우 20~~30%까지 오버랩을 높이는 것이 유리하다.

고급 RAG 시스템에서는 계층적 청킹 구조를 활용한다. 동일 문서를 두 가지 이상의 크기로 청킹해 각각 다른 목적으로 활용하는 방식이다. 부모-자식 청킹(Parent-Child Chunking)은 작은 청크(예: 128 토큰)로 정밀 검색을 수행하고, 검색 결과와 연결된 큰 청크(예: 512 토큰)를 LLM 컨텍스트에 삽입해 검색의 정확도와 LLM에게 전달되는 맥락의 풍부함을 동시에 확보하는 방법이다. 요약 인덱스(Summary Index)는 각 청크의 요약 임베딩과 원본 청크를 함께 저장하고, 쿼리는 요약 임베딩과 매칭해 더 의미적으로 포괄적인 검색을 가능하게 한다.

문서 유형별로 크기를 다르게 잡아야 하는 이유

청킹 크기는 "얼마나 세밀한 검색이 필요한가"와 "얼마나 많은 맥락이 필요한가" 사이의 균형점을 찾는 문제다.

문서 유형	권장 청크 크기	권장 오버랩	이유
짧은 Q&A, FAQ	128~256 토큰	0~20 토큰	각 항목이 독립적, 맥락 의존 낮음
일반 기사/블로그	256~512 토큰	50~100 토큰	단락 수준 이해 필요
기술 문서/매뉴얼	512~1024 토큰	100~200 토큰	절차적 맥락 유지 필요
법률/계약 문서	512~2048 토큰	200~400 토큰	선행 조건 참조 빈번
학술 논문	256~512 토큰 + 섹션 기반	50~100 토큰	섹션 경계 존중 필요
코드/소스파일	함수/클래스 단위	컨텍스트 라인	논리 단위 분리 필수

임베딩 모델의 최대 입력 길이를 무시하면 생기는 일

청킹 크기는 사용하는 임베딩 모델의 최대 입력 길이와도 연동해야 한다. 임베딩 모델의 최대 입력보다 긴 청크를 생성하면, 모델이 청크를 잘라내거나 압축하여 정보 손실이 발생한다. OpenAI의 text-embedding-3-small은 최대 8,191 토큰을 지원해 청크를 1,000~~2,000 토큰 이하로 설정하는 것이 권장되고, 오픈소스 all-MiniLM-L6-v2는 최대 256 토큰까지만 지원해 청크를 128~~256 토큰으로, BAAI의 bge-large-en은 최대 512 토큰을 지원해 청크를 256~512 토큰으로 설정하는 것이 좋다.

이론보다 실험: 무엇을 측정할 것인가

이론적 가이드라인보다 중요한 것은 실제 데이터와 쿼리로 실험하는 것이다. 검색된 청크가 실제로 LLM의 응답에 활용되었는가를 보는 Faithfulness(할루시네이션 방지), 생성된 응답이 원래 질문과 얼마나 관련 있는가를 보는 Answer Relevance, 검색된 청크들 중 실제로 관련 있는 청크의 비율을 보는 Context Precision, 관련 있는 청크가 검색 결과에 포함된 비율을 보는 Context Recall이라는 평가 메트릭을 활용해 청킹 전략의 효과를 정량적으로 비교한다.

자주 하는 실수들

모든 문서에 동일한 청크 크기를 적용하는 것은 대부분 최적이 아니다. 문서 유형에 따라 청킹 전략을 다르게 적용해야 한다. 오버랩 없이 청킹하면 경계 부근의 문장들이 문맥 없이 고립되며, 특히 인과관계나 순차적 설명이 많은 기술 문서에서 치명적이다. 청크에 원본 문서 ID, 페이지 번호, 섹션명 등의 메타데이터를 포함하지 않으면 검색 결과의 출처를 추적하거나 관련 청크들을 연결하기 어렵다. 원본 문서의 불필요한 헤더/푸터, 페이지 번호, HTML 태그 등을 제거하지 않으면 임베딩 품질이 저하되므로 청킹 전 반드시 텍스트 정규화 과정을 거쳐야 한다. 임베딩 모델의 최적 처리 길이를 무시하고 지나치게 크거나 작은 청크를 생성하는 것도 임베딩 품질을 떨어뜨린다.

데이터 청킹은 LLM 기반 애플리케이션에서 가장 기초적이지만 가장 큰 영향력을 가진 설계 결정 중 하나다. 컨텍스트 윈도우 제한 대응, 검색 정확도 향상, 비용 최적화라는 핵심 이유에서 청킹은 선택이 아닌 필수이며, 어떤 전략을 선택하느냐에 따라 최종 시스템 품질이 크게 달라진다.