청킹

쉽게 말하면, 청킹은 긴 글을 검색하기 좋은 크기의 조각으로 잘라 두는 일이다. 임베딩 모델이 한 번에 읽을 수 있는 길이에는 한계가 있어서, 긴 글을 그대로 넣으면 뒷부분이 잘리거나 의미가 흐려진다. 그래서 자르는 크기와 방식이 검색 결과와 답변 품질에 영향을 준다.

1. 개요

청킹은 문서 색인과 검색 증강 생성(RAG) 시스템에서 긴 문서나 문서 묶음을 '청크(chunk)'라는 작은 단락으로 나눈 뒤, 각 청크를 임베딩하여 벡터 데이터베이스에 저장하고 검색에 쓰는 전처리 단계다.

청킹이 필요한 이유는 임베딩 모델과 대규모 언어 모델이 입력 길이를 유한하게 제한하기 때문이다. 대부분의 Sentence-BERT 변형은 최대 512 서브워드 토큰까지 받고, 기본값인 all-MiniLM-L6-v2 모델은 256토큰에서 입력을 자른다. OpenAI의 text-embedding-3-large처럼 긴 문맥을 다루는 인코더도 입력을 8,192토큰으로 제한한다.^2,3,7

청크 크기, 겹침, 경계 정책이라는 청킹 결정은 검색 재현율과 이후 답변의 충실도에 실질적인 영향을 준다. 작은 청크는 관련 구간을 집중시키지만 주변 문맥을 잃고, 큰 청크는 문맥을 보존하는 대신 관련 없는 내용이 섞여 임베딩 신호가 희석된다.^8,9

흔히 쓰이는 전략은 글자 수나 토큰 수로 자르는 고정 크기 분할에서 시작한다. 문단, 문장, 단어 경계를 차례로 시도하는 재귀 분할, 임베딩으로 주제가 바뀌는 지점을 찾는 의미 기반 청킹이 있고, 2024년과 2025년에 Anthropic, Jina AI, Voyage AI가 소개한 문맥 청킹과 후기 청킹 방법도 있다.^4,5,6

2. 배경과 필요성

밀집 벡터 검색(dense retrieval) 파이프라인은 텍스트를 고정 차원의 벡터로 바꾸어, 질의 벡터와 문서 벡터의 코사인 유사도나 내적으로 의미 유사성을 근사한다. 청킹을 피할 수 없게 만드는 공학적 제약은 두 가지다.⁸

첫째, 밀집 검색기의 바탕이 되는 트랜스포머 인코더에는 최대 시퀀스 길이가 있고, 그 길이를 넘는 토큰은 조용히 잘린다. 가장 널리 쓰이는 Sentence-BERT 체크포인트 중 하나인 all-MiniLM-L6-v2는 기본적으로 256 서브워드 토큰을 넘는 입력을 자르며, 학습 시퀀스도 128토큰으로 제한되었다. 그래서 기반 BERT 설정이 512개 위치를 허용하더라도 긴 단락에는 잘 일반화되지 않는다. OpenAI의 3세대 임베딩 모델인 text-embedding-3-small과 text-embedding-3-large는 모두 8,192토큰까지 받으며, 각각 최대 1,536차원과 3,072차원 벡터를 만든다. 그보다 긴 입력은 잘라내거나 나눠야 한다.^2,3,10

둘째, 임베딩 모델의 문맥 창이 길더라도 생성 단계에서 검색된 청크를 읽는 대규모 언어 모델은 자체 컨텍스트 창 한계를 가진다. 지나치게 긴 청크를 몇 개 골라 프롬프트에 채워 넣으면, 관련 없는 텍스트를 리랭커와 생성기가 처리하느라 낭비된다.⁸

입력 길이 한계 말고도 청킹은 품질을 위한 기능을 한다. 임베딩 하나는 문단 전체를 벡터 하나로 압축하므로, 문단이 길수록 세부 의미가 흐려진다. 예를 들어 1,000토큰짜리 청크가 세 가지 하위 주제를 다루면 결과 벡터는 그 주제들의 중심에 가까워져, 그중 한 주제에 관한 질의와 잘 맞지 않을 가능성이 크다. 따라서 작은 청크는 관련 구간이 벡터를 지배해 검색 정밀도를 높이지만, 답의 근거가 되는 정보가 옆 청크에 들어가 놓칠 위험도 커진다. Pinecone의 청킹 가이드는 이 상충 관계를 명시적으로 정리한다. 작은 청크는 세밀한 의미를, 큰 청크는 넓은 문맥을 담으며, 알맞은 크기는 문서 유형, 임베딩 모델의 학습 방식, 예상 질의의 복잡도에 따라 달라진다.^8,9,11

3. 고정 크기 청킹

고정 크기 청킹은 가장 단순한 방법으로, N글자나 N토큰마다 텍스트를 자르며 인접한 청크 사이에 겹침을 둘 수도 있다. RAG 실무자들 사이에서 영향력이 큰 자료인 Greg Kamradt의 튜토리얼 「5 Levels of Text Splitting」은 고정 크기 글자 분할을 '레벨 1'로 부른다. 이 튜토리얼은 청킹 문제를 이해하는 출발점으로는 유용하지만 실서비스에 권할 방법은 아니라고 설명한다. Amazon Bedrock Knowledge Bases는 고정 크기 청킹을 기본 옵션으로 제공하며, 청크당 최대 토큰 수와 연속 청크 사이의 겹침 비율을 설정하게 한다. 반면 Bedrock의 '기본 청킹' 모드는 문장 경계를 지키면서 청크당 약 300토큰을 목표로 한다. 그래서 청크 길이가 정확히 같지는 않지만 문장을 반으로 자르지는 않는다.^5,12,13

고정 크기 방식에는 잘 알려진 실패 모드가 두 가지 있다. 첫째, 문장·표·코드 구조를 가로지른다. 문단 중간에서 시작한 512토큰 창은 한 문장 중간에서 시작해 다른 문장 중간에서 끝날 수 있어, 주어나 서술어가 빠진 조각을 임베딩하게 된다. 둘째, 크기 매개변수를 감으로 고르기 어렵다. Pinecone 가이드와 많은 커뮤니티 가이드는 200~512토큰, 10~20% 겹침을 기본 범위로 모으지만, NVIDIA가 1,024토큰 청크로 FinanceBench를 평가한 결과에서는 15% 겹침이 10%와 20%보다 나았다. Chroma의 평가 프레임워크에서는 OpenAI Assistants의 기본값인 800토큰과 400토큰 겹침이 여러 말뭉치 벤치마크에서 평균 이하의 재현율을 보였다.^8,14,15

청크 겹침은 한 청크의 끝부분을 다음 청크의 앞머리에 반복해 넣는 방식이다. 이렇게 하면 경계 근처의 정보가 잘리지 않고 두 청크에 모두 들어간다. 업계에서 흔히 쓰는 어림값은 청크 크기의 10~20%로, 1,000자 청크라면 100~200자를 겹치는 셈이다. 목적은 질의의 답이 경계에 걸쳐 한 청크의 끝과 다음 청크의 시작에 나뉘어, 두 청크 모두의 임베딩 유사도를 떨어뜨리는 최악의 경우를 줄이는 것이다. 다만 겹침은 공짜가 아니다. 저장하는 벡터 수와 검색 비용이 늘어나며, 약 30%를 넘으면 재현율 이득이 저장 공간과 지연 시간의 부담에 비해 작아진다.¹⁴

4. 재귀 청킹

가장 널리 쓰이는 범용 청커는 LangChain의 RecursiveCharacterTextSplitter다. Greg Kamradt는 이를 '분할기의 스위스 아미 나이프(swiss army knife of splitters)'라 부르며, 프로토타입을 만들 때 보통 가장 먼저 고른다고 했다. 이 재귀 분할기는 목표 chunk_size와 순서가 있는 구분자 목록을 받는다. 기본 구분자는 아래와 같다.^4,5,16

["\n\n", "\n", " ", ""]

분할기는 가장 강한 구분자인 문단 나눔으로 먼저 입력을 나눈다. 결과 조각이 여전히 chunk_size를 넘으면 그 안에서 다음 구분자로 재귀하고, 글자 단위까지 이 과정을 반복한다. 목적은 가능한 한 문단을 함께 두고, 문단 자체가 목표 크기를 넘을 때만 더 작은 단위로 쪼개는 것이다.¹⁶

LangChain API에는 인접한 출력 청크 사이의 겹침을 정하는 chunk_overlap 매개변수와 length_function이 있다. length_function의 기본값은 글자 수지만, 임베딩 모델의 토크나이저에 맞춰 토큰 계수기로 바꿀 수 있다. 중국어, 일본어, 태국어처럼 단어 사이에 공백이 없는 언어에는 구두점과 영너비 공백을 포함한 사용자 구분자를 넣으라고 권한다. 그래야 단어 중간에서 끊기지 않는다. Chroma의 내부 시험에서는 기본 매개변수의 RecursiveCharacterTextSplitter가 합성 질의 평가에서 '상대적으로 낮은 성능(relatively poorly)'을 보였다. 저자들은 이 원인을 재귀 방식 자체의 결함보다는 글자 기준 기본 크기와 토크나이저 기준 크기의 차이로 본다.^4,15,16

LlamaIndex에도 비슷한 구성요소인 SentenceSplitter가 있다. 기본 chunk_size는 1,024토큰, chunk_overlap은 200토큰이며, 문장과 문단을 함께 묶으려 해서 예전 TokenTextSplitter보다 청크 경계에 걸쳐 남는 문장 조각이 적다.¹⁷

5. 문장·구조 기반 청킹

두 번째 계열의 전략은 글자 수 대신 언어나 구조의 경계에서 자른다.

문장 기반 분할기는 NLTK의 sent_tokenize나 spaCy의 통계적 문장 분절기로 먼저 문서를 문장으로 나눈 뒤, 인접한 문장을 목표 토큰 예산에 닿을 때까지 묶는다. NLTK는 구두점 패턴에 기반한 결정적 규칙 토크나이저를 쓰고, spaCy는 약어처럼 모호한 경우를 더 견고하게 처리하는 학습된 통계 모델을 쓴다. LangChain은 두 방식을 NLTKTextSplitter와 SpacyTextSplitter 어댑터로 감싼다. 문장 단위 청킹은 고정 크기 방식의 가장 눈에 띄는 결함인 문장 중간 분할을 피하지만, 청크가 의미상 일관됨을 보장하지는 않는다. 관련된 두 문장 사이에 경계가 놓이면 한 생각이 여전히 두 청크로 나뉠 수 있다.¹⁸

문서에 명시적인 계층 구조가 있으면 분할기가 그 구조를 단서로 쓸 수 있다. LangChain의 MarkdownHeaderTextSplitter는 설정 가능한 헤더 수준 목록을 받으며, 기본값은 '#'과 'Header 1', '##'과 'Header 2', '###'과 'Header 3'의 쌍이다. 섹션마다 청크 하나를 만들고, 둘러싼 상위 헤더 체인을 메타데이터로 붙여 이후 검색이 섹션 기준으로 거르거나 재정렬할 수 있게 한다. 기본적으로 헤더 줄은 청크 본문에서 빠지며, 이는 strip_headers 매개변수로 조절한다. 겹침은 섹션 경계를 넘지 않는다. 흔한 파이프라인은 MarkdownHeaderTextSplitter에 RecursiveCharacterTextSplitter를 연결해, 아주 긴 섹션만 더 나누고 짧은 섹션은 그대로 둔다. HTML, LaTeX, PDF 문서에도 해당 구조 표지를 활용하는 비슷한 분할기가 있다.^8,19,20

소스 코드는 글자 기준 청킹과 잘 맞지 않는다. 함수, 클래스, 제어 구조가 고정 토큰 창과 좀처럼 맞지 않기 때문이다. 2025년 6월 Carnegie Mellon University와 Augment Code 연구진이 발표한 cAST는 tree-sitter로 소스 파일을 추상 구문 트리(AST)로 파싱한다. 그다음 설정된 청크 크기를 지키며 인접한 AST 노드를 탐욕적으로 합치고, 지나치게 큰 노드는 재귀적으로 나눈다. 크기는 공백이 아닌 글자 수로 잰다. cAST는 구문적 완전성(청크가 완전한 구문 단위에 대응), 높은 정보 밀도, tree-sitter가 지원하는 100개 넘는 문법에 걸친 언어 불변성, 청크를 이어 붙이면 원본 파일이 복원되는 plug-and-play 동작을 목표로 한다. RepoEval, CrossCodeEval, SWE-bench 실험에서 cAST는 줄 단위 기준선과 비교해 RepoEval Recall@5를 4.3점, SWE-bench Pass@1을 2.67점, CrossCodeEval 정확 일치를 4.3점 높였다. 가장 큰 단일 이득(5.5점)은 StarCoder2의 RepoEval 결과에서 나왔다.²¹

6. 의미 기반 청킹

의미 기반 청킹은 Greg Kamradt의 틀에서 레벨 4로 소개되었으며, 고정 토큰 수 대신 주제가 바뀌는 지점에 청크 경계를 둔다. 기본 알고리즘은 먼저 문서를 문장으로 나누고 각 문장을 임베딩한다. 이어서 인접한 문장 묶음의 코사인 유사도를 차례로 계산해, 두 묶음의 유사도가 설정된 임계값 아래로 떨어지면 청크 경계를 정한다. LlamaIndex는 이를 SemanticSplitterNodeParser로 구현하며, 주요 매개변수는 다음 세 가지다.^5,22,23

• buffer_size: 임베딩 전에 묶는 주변 문장 수(기본값 1).
• breakpoint_percentile_threshold: 청크 경계를 두는 문장 간 거리의 백분위수 기준으로, 보통 80~95.
• embed_model: 유사도 계산에 쓸 임베딩 제공자를 가리킨다.²³

의미 기반 청킹은 단순함을 내주고 적응성을 얻는다. 주제를 자주 바꾸는 문서는 청크가 많이 생기고, 한 주제를 길게 논하는 문서는 큰 청크 몇 개가 된다. 대신 수집 단계에서 문장마다(또는 작은 문장 묶음마다) 임베딩 모델을 호출해야 하므로 문서당 지연과 비용이 늘어난다. Bedrock 문서는 의미 기반 청킹이 고정 또는 계층 청킹보다 수집 중 파운데이션 모델 비용을 추가로 발생시킨다고 명시한다.

AWS Bedrock Knowledge Bases도 비슷한 매개변수를 제공한다. 청크당 최대 토큰 수, 주변 문장 버퍼 크기, 백분위수 임계값이며, 임계값을 높이면 청크가 더 적고 더 커진다.¹³

Kamradt는 레벨 5로 '에이전트형(agentic)' 청커도 설명한다. 이는 대규모 언어 모델에 분할 지점을 찾게 지시하는 방식으로, 청킹을 유사도 계산이 아니라 추론 과제로 본다. 또 토큰 비용이 0에 가까워지는 상황을 위한 '실험적' 레벨도 있다.⁵

Chroma의 열린 평가 프레임워크는 비슷한 발상을 LLMChunker로 구현한다. OpenAI의 text-embedding-3-large로 상위 5개 청크를 검색했을 때, 시험한 모든 청커 가운데 재현율이 91.9%로 가장 높았다. 다만 정밀도는 3.9로, 같은 200토큰 목표 크기의 ClusterSemanticChunker 기준선(정밀도 8.0, 재현율 91.3%)보다 낮았다.¹⁵

7. 문맥 검색(contextual retrieval)

2024년 9월 Anthropic은 「Introducing Contextual Retrieval」을 발표하며, 임베딩과 BM25 색인을 만들기 전에 각 청크 앞에 문서를 고려한 짧은 문맥 문자열을 붙이는 방법을 설명했다. 동기는 청크가 검색에 필요한 선행 정보를 잃는다는 점이다. 예를 들어 '회사의 매출이 전 분기 대비 3% 늘었다'는 문장은 회사 이름과 시점이 없어서, 특정 회사의 매출 성장을 묻는 질의와 단독으로 맞지 않는다.

Anthropic 방식은 Claude(공개 쿡북에서는 Claude 3 Haiku)를 써서, 전체 원문서를 보고 청크마다 한두 문장의 문맥을 만든다. 그다음 문맥을 청크에 붙인 뒤 임베딩과 BM25 역색인을 만든다. Anthropic은 코드베이스, 소설, ArXiv 논문, 기타 과학 논문으로 이루어진 벤치마크에서 검색 실패율이 줄었다고 보고했다. 문맥 임베딩만 쓰면 실패율이 5.7%에서 3.7%로 줄어 35% 감소했고, 문맥 임베딩과 문맥 BM25를 함께 쓰면 2.9%로 49% 감소했다. 여기에 리랭커를 더하면 1.9%로 67% 감소했다. 비용 모델은 800토큰 청크, 8,000토큰 문서, 50토큰 문맥 생성 지시문, 청크당 약 100토큰의 생성 문맥을 가정한다. 프롬프트 캐싱으로 같은 문서의 청크들이 문서 내용을 공유하는 조건에서 백만 문서 토큰당 1.02달러의 일회성 수집 비용이 든다고 밝혔다.²⁴

AWS는 이 기법을 구현한 Amazon Bedrock Knowledge Bases 연동을 발표했다. Anthropic의 공개 쿡북에는 참조 구현이 포함되어 있다.²⁵

8. 후기 청킹(late chunking)

같은 2024년 9월 Jina AI의 논문 「Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models」(Michael Günther, Isabelle Mohr, Daniel James Williams, Bo Wang, Han Xiao)은 같은 문맥 손실 문제에 다른 해법을 제시했다. 후기 청킹은 연산 순서를 바꾼다. 먼저 긴 문서 전체를 장문맥 임베딩 모델에 한 번에 통과시켜 토큰마다 벡터를 얻고, 그 벡터열을 청크 단위로 나눈 뒤 청크별로 평균 풀링을 한다. 순전파 중 모든 토큰이 서로를 참조했으므로, 각 청크 벡터는 청크 자신뿐 아니라 주변 문서의 정보도 담는다.^5,26

Jina의 BeIR 데이터셋 평가에서는 같은 인코더로 단순 청킹보다 일관된 이득이 나타났다. SciFact의 nDCG@10은 64.20에서 66.10으로, TRECCOVID는 63.36에서 64.70으로, NFCorpus는 23.46에서 29.98로 올랐다. 저자들은 문서가 길수록 후기 청킹의 효과가 커진다고 밝혔다.²⁷

이 기법은 추가 학습이 필요 없고, 평균 풀링을 쓰는 장문맥 임베딩 모델이라면 어떤 모델과도 작동한다. Jina는 자사의 Jina Embeddings v3와 그 전신인 v2-base-en(둘 다 8,192토큰 창)을 기준 대상으로 제시했다. 이후 Milvus, Elasticsearch 등 벡터 검색 업체들의 연동 글은 후기 청킹을 실제 검색 스택에 넣는 방법을 설명한다.^26,27

9. 문맥화 청크 임베딩(voyage-context-3)

2025년 7월 Voyage AI(당시 MongoDB의 자회사)는 voyage-context-3을 공개했다. 이 임베딩 모델은 문맥화 단계를 별도 전처리로 두지 않고 모델 내부에 넣었다. 같은 원문서에서 온 청크 목록을 받아 교차 청크 어텐션으로 한 번에 순전파하고, 문서의 나머지에 조건화된 청크별 임베딩을 하나씩 낸다. Voyage는 이를 '문맥화된 청크 임베딩'이라 부르며, 사용자가 메타데이터를 따로 덧붙일 필요가 없는 표준 임베딩 API의 대체재로 소개했다.^6,28

Voyage는 웹 리뷰, 법률, 의학, 긴 문서, 기술 문서, 코드, 금융, 대화, 다국어 텍스트의 아홉 개 영역에 걸친 93개 검색 데이터셋으로 평가했다. 이는 Voyage의 자체 평가 결과다. NDCG@10 기준으로 voyage-context-3은 청크 수준 검색에서 text-embedding-3-large보다 14.24%, 문서 수준 검색에서 12.56% 높았다. Cohere embed v4보다는 각각 7.89%와 5.64%, Jina v3 후기 청킹보다는 23.66%와 6.76%, Anthropic의 문맥 검색보다는 20.54%와 2.40% 높았다고 보고되었다.

모델은 2048, 1024, 512, 256차원 출력과 32비트 부동소수점, 부호 있는 8비트 정수와 부호 없는 8비트 정수, 이진 양자화를 지원한다. Voyage는 512차원 이진 변형이 저장 공간을 약 0.5%만 쓰면서 검색 품질이 text-embedding-3-large와 맞먹는다고 밝혔다.⁶

10. 청크 크기와 겹침의 어림값

청크 크기 문제는 실험으로 연구되었으며 답은 말뭉치마다 다르다. 다만 Pinecone, NVIDIA, Chroma와 LangChain 커뮤니티 가이드에서 몇 가지 일반론이 반복된다. 아래 표는 임베딩 모델별 최대 입력과 실무 청크 크기를 정리한 것이다.

겹침 비율은 청크 크기의 10~20%가 널리 인용되는 기준이다. NVIDIA의 FinanceBench 실험은 1,024토큰 청크에서 15%가 최적이며, 이는 10%와 20% 사이라고 밝혔다. 겹침이 30%를 넘으면 수익이 빠르게 줄어드는 반면 인덱스 크기는 선형으로 커진다.¹⁴

11. 평가

청킹은 다른 RAG 구성요소보다 앞 단계에 있으므로, 질적 검토만으로는 품질을 평가할 수 없고 측정 가능한 검색 과제가 필요하다. 표준 지표는 Recall@K로, 테스트 질의 가운데 상위 K개 검색 결과에 관련 청크가 하나 이상 나온 질의의 비율이다. 검색기 평가에 널리 쓰이는 벤치마크인 BEIR는 아홉 개 검색 과제에 걸친 18개 데이터셋을 묶고 nDCG@10, MAP, Precision@K, Recall@K를 함께 보고한다. 청킹 전략 연구자들은 흔히 BEIR 일부와 자체 도메인 말뭉치에서 결과를 낸다. MTEB(Massive Text Embedding Benchmark)는 임베딩 모델 비교에서 보완 역할을 한다.²⁹

Chroma의 청킹 평가는 2024년에 발표되었다. GPT-4 Turbo로 다섯 개 말뭉치, 총 328,208토큰에서 합성 질의를 만들고 임베딩 유사도로 거른 뒤, 토큰 수준의 정밀도, 재현율, IoU(Intersection over Union)를 계산했다. 관련 구간을 찾았는지와 검색된 청크에 불필요한 내용이 얼마나 섞였는지를 함께 본다. 이 프레임워크로 같은 임베딩 모델과 통제된 청크 크기에서 재귀, 의미 기반, LLM 기반 청커를 직접 비교할 수 있다. Chroma의 핵심 발견은 인기 라이브러리의 기본 매개변수가 최적과 거리가 멀다는 것이다. OpenAI Assistants의 기본값인 800토큰과 400토큰 겹침은 더 작은 설정과 잘 조정된 대안 모두에 뒤처졌다.¹⁵

Pinecone의 실무 지침은 대표성 있는 소규모 테스트 세트로 200, 400, 600토큰 청크 크기를 시험하고 Recall@5를 측정한 뒤, 해당 말뭉치에서 이를 최대화하는 설정을 고르라는 것이다.⁸

12. 계층형·부모-자식 청킹

계층형 청킹(부모-자식 청킹이라고도 한다)은 두 입도를 동시에 색인한다. 임베딩 유사도로 구분하기 충분히 작은 '자식' 청크와, 주변 문맥을 담은 더 큰 '부모' 청크다. 검색 시 시스템은 질의를 임베딩하고 벡터 유사도 상위 K개의 자식 청크를 찾은 뒤, 각 자식의 부모를 LLM에 실제 문맥으로 넘긴다. 작은 청크의 정밀도와 큰 청크의 문맥 완결성을 함께 얻으려는 것이다. Amazon Bedrock Knowledge Bases는 두 단계 계층형 청킹을 지원하며, 부모와 자식의 토큰 크기와 겹침을 설정하게 한다. 여러 자식이 같은 부모에 대응하면 반환 결과 수가 요청보다 적을 수 있다고 경고한다.¹³

LlamaIndex는 비슷한 발상을 두 가지로 구현한다. '자동 병합 검색기(auto-merging retriever)'는 말단 청크를 검색하고, 형제 청크가 충분히 반환되면 부모로 합친다. '문장 창 검색기(sentence-window retriever)'는 개별 문장을 임베딩하되, 검색된 문장을 주변 고정 창의 문장들과 함께 생성기에 준다.¹⁷

13. 주요 라이브러리 구현

LangChain은 텍스트 분할기를 langchain_text_splitters 패키지로 묶는다. 기본 제공 항목은 CharacterTextSplitter(레벨 1), RecursiveCharacterTextSplitter(레벨 2이자 일반 텍스트의 권장 기본값), OpenAI와 HuggingFace 모델용 TokenTextSplitter 및 토크나이저별 변형, 구조화 문서용 MarkdownHeaderTextSplitter와 HTMLHeaderTextSplitter(레벨 3), 문장 단위 분할을 위한 NLTK와 spaCy 연동이다.^16,19

LlamaIndex의 대응 개념은 '노드 파서(node parser)'로, 청크에 해당하는 Node 객체를 만든다. 라이브러리는 SentenceSplitter(기본 chunk_size=1024, chunk_overlap=200), TokenTextSplitter, SentenceWindowNodeParser, MarkdownNodeParser, 임베딩을 차례로 따라가며 나누는 SemanticSplitterNodeParser를 제공한다.^17,23

벡터 데이터베이스 업체들은 대부분 관리형 수집 파이프라인 안에 청킹 기능을 넣는 쪽으로 모였다. Pinecone의 「Chunking Strategies」 가이드는 대부분의 응용에서 고정 크기 청킹을 출발점으로 권하고, 내용 인식, 구조 인식, 의미 기반, LLM을 쓴 문맥 청킹 예시를 제공한다. Weaviate와 Qdrant도 청킹 가이드와 LangChain·LlamaIndex 연동을 공개했다. Anthropic의 Claude Cookbook에는 문맥 검색의 참조 구현이 있어, 실무자가 자체 말뭉치에 맞게 고칠 수 있다.^8,25

14. 한계와 미해결 과제

10년에 걸친 밀집 검색 연구에도 청킹은 대부분의 RAG 파이프라인에서 자동화가 덜 된 단계로 남아 있다. 여러 조사와 평가에서 반복되는 한계는 세 가지다.

첫째, 청크 크기는 말뭉치와 질의에 따라 달라지며 보편적으로 최적인 크기는 없다. Pinecone, NVIDIA, Chroma는 모두 기본값보다 실험적 튜닝을 권하지만, 이에는 라벨이 붙은 평가 세트나 합성 평가 세트가 필요하고 많은 실무 팀에는 이것이 없다. AI21의 2024년 다중 스케일 검색 연구는 최적 청크 크기가 질의 유형에 따라 다르다고 주장하며, 같은 말뭉치를 여러 입도로 색인해 각 질의를 알맞은 규모로 보내자고 제안했다.^8,14,15,30

둘째, 청크 경계는 문맥을 잃는다. 이는 문맥 검색, 후기 청킹, 문맥화 청크 임베딩이 모두 해결하려는 핵심 문제다. 각 해법에는 비용이 따른다. 문맥 검색은 수집 때 청크마다 LLM을 한 번 거쳐야 하고(프롬프트 캐싱으로 싸지만 0은 아니다), 후기 청킹은 모든 언어나 도메인에 존재하지 않을 수 있는 장문맥 인코더에 의존하며, 문맥화 청크 임베딩은 사용자를 특정 임베딩 제공자에 묶는다.^6,24,26

셋째, 평가 인프라가 아직 성숙하지 않았다. Chroma의 IoU 같은 토큰 수준 지표는 문서 수준 Recall@K보다 충실한 그림을 주지만, 이를 위한 합성 질의 생성 파이프라인은 LLM 프롬프트와 말뭉치에 민감하다. 같은 청킹 방법도 평가 데이터셋, 임베딩 모델, 고려한 청크 크기에 따라 몇 퍼센트포인트씩 이기기도 지기도 한다. 그러므로 공급자 간 단일 수치 비교는 신중하게 다뤄야 한다.¹⁵