데이터·DB

Chunking

청킹

긴 문서를 검색·임베딩에 알맞은 크기의 조각으로 잘라 나누는 전처리 작업입니다. RAG에서 원문을 통째로 넣을 수 없으므로, 문단·문장·토큰 단위로 나눠 각 조각을 벡터로 저장합니다. 너무 크게 자르면 관련 없는 내용이 섞이고, 너무 잘게 자르면 앞뒤 문맥이 끊깁니다. 조각 크기와 겹침(overlap) 설정이 검색 정확도를 좌우해, RAG 품질의 첫 단추로 꼽힙니다.

쉽게 말하면?

청킹(chunking)은 긴 자료를 검색하기 좋은 크기로 토막 내는 작업입니다. AI에 문서를 한 번에 다 넣을 수 없으니, 문단이나 정해진 길이로 잘라 조각마다 따로 저장해요. 두꺼운 규정집을 통째로 주는 대신 조항별로 나눠 색인해 두는 것과 비슷합니다. 너무 크게 자르면 엉뚱한 내용이 섞이고, 너무 잘게 자르면 앞뒤 맥락이 끊겨서 답이 부정확해져요. 그래서 조각 크기와 겹치는 부분을 얼마로 둘지가 RAG 품질을 좌우하는 첫 단추입니다. 같은 문서라도 어떻게 나누냐에 따라 검색 결과가 달라집니다.

한 줄로 비유하면?

두꺼운 규정집을 조항별로 잘라 색인해 두는 문서 정리입니다.

어디에 쓰이나?

케이스 1Anthropic — 문맥을 붙인 청킹으로 검색 실패율 감소

Anthropic은 2024년 각 조각 앞에 그 조각의 맥락을 요약해 붙이는 '컨텍스추얼 리트리벌'을 공개했습니다 [1]. 조각이 문맥을 잃어 검색이 빗나가는 문제를 겨냥했습니다 [1]. 문맥 임베딩과 문맥 BM25를 함께 쓰고 리랭킹까지 얹어 측정했습니다 [1]. 상위 20개 조각 안에 정답이 없을 확률을 기준으로 비교했습니다 [1].
도입효과: 상위 20개 검색 실패율 67% 감소(5.7%→1.9%, 문맥 임베딩+BM25+리랭킹), 문맥 임베딩 단독은 35% 감소(5.7%→3.7%) [1]

케이스 2NVIDIA — 청킹 전략별 정확도 벤치마크

NVIDIA는 2025년 페이지 단위·구획 단위·토큰 단위 청킹을 5개 RAG 데이터셋에서 비교했습니다 [3]. 토큰 크기를 128부터 2048까지 바꿔 가며 15% 겹침으로 실험했습니다 [3]. 너무 작거나(128) 너무 큰(2048) 조각은 성능이 떨어졌습니다 [3]. 페이지 단위가 대부분의 데이터셋에서 가장 좋았습니다 [3].
도입효과: 페이지 단위 청킹 평균 정답 정확도 0.648(최고)·표준편차 0.107(최저) — 토큰 단위 0.603~0.645 대비 [3]

케이스 3Chroma — 청킹 방식별 검색 성능 실측

벡터DB 업체 Chroma는 2024년 여러 청킹 방식을 재현율·정밀도 기준으로 비교했습니다 [4]. OpenAI 기본값(800토큰·400겹침) 설정을 기준선으로 삼았습니다 [4]. LLM으로 의미 단위를 잘라 주는 방식이 재현율이 가장 높았습니다 [4]. 기본값 설정은 오히려 하위권이었다고 밝혔습니다 [4].
도입효과: LLM 의미 청킹 재현율 91.9%(최고) vs 기본값 800토큰·400겹침 설정 하위권 (동일 검색 벤치마크 기준) [4]

케이스 4업스테이지(한국) — 문서 파싱으로 청킹 경계 잡기

한국 AI 기업 업스테이지의 Document Parse는 표·머리글·구획을 인식해 청킹 경계를 잡아 줍니다 [5]. 100쪽 문서를 1분 안에 LLM이 읽기 좋은 조각으로 변환합니다 [5]. 레이아웃·표 구조 인식 정확도를 벤치마크로 공개했습니다 [5]. 청킹 앞단인 문서 해석 품질을 끌어올린 사례입니다 [5].
도입효과: 레이아웃·표 인식 정확도 TEDS 93.48·TEDS-S 94.16, 처리 속도 Unstructured·AWS Textract 대비 10배·LlamaParse 대비 4배 [5]

주의할 점은?

오늘 바로 해보기
01. LangChain 또는 LlamaIndex의 텍스트 스플리터로 사내 문서 한 건을 512·1024 토큰 두 크기로 각각 잘라 봅니다.
02. 겹침(overlap)을 0과 15%로 바꿔 색인한 뒤 같은 질문의 검색 결과를 비교합니다.
03. 정답이 조각 경계에서 잘려 검색이 실패하는 사례를 세 개 찾아 메모합니다.
04. 표·목록이 많은 문서는 문단 단위와 페이지 단위 중 어느 쪽이 나은지 눈으로 확인합니다.
05. Anthropic 컨텍스추얼 리트리벌 글에서 실패율 49%·67% 감소가 각각 어떤 조합의 결과인지 확인합니다 [1].

한계와 진화
청킹의 한계는 모든 문서에 통하는 정답 크기가 없다는 점입니다. NVIDIA 벤치마크에서 보듯 좋은 조각 크기는 문서 종류와 질문에 따라 달라집니다 [3]. 정해진 길이로 기계적으로 자르면 문장이나 표가 조각 경계에서 잘려 문맥이 끊깁니다 [4]. Chroma 실측에서는 자주 쓰이는 기본값(800토큰·400겹침)이 오히려 하위권이었습니다 [4]. 표나 코드, 목록처럼 구조가 있는 콘텐츠는 문장 단위로 자르면 의미가 깨지기 쉬워 별도 처리가 필요합니다 [5]. 겹침을 늘리면 경계에서 잘리는 문제를 줄이지만, 같은 내용이 여러 조각에 중복 저장돼 색인 크기가 커집니다 [4]. 한 번 정해도 문서 종류가 바뀌면 다시 맞춰야 하는 지속 관리 항목입니다 [3]. 즉 조각 크기·겹침·경계 규칙을 자료마다 맞춰 봐야 하는 반복 작업입니다 [3].
진화 방향은 두 갈래입니다.

  1. 의미 단위로 자르는 시맨틱·LLM 기반 청킹입니다. Chroma 비교에서 LLM으로 의미를 잘라 준 방식이 재현율이 가장 높았습니다 [4].
  2. 조각에 맥락을 덧붙이거나 문서 구조를 먼저 해석하는 방향입니다. Anthropic은 각 조각에 문맥을 붙여 검색 실패율을 낮췄고, 국내에서는 업스테이지가 표·레이아웃을 인식해 청킹 경계를 잡아 주는 문서 파싱을 제공합니다 [1][5]. 단순 분할에서 문맥을 살리는 분할로 무게중심이 옮겨가는 흐름입니다 [1]. NVIDIA와 Chroma의 비교처럼 데이터셋별로 최적 전략을 실측해 고르는 접근이 늘고 있습니다 [3][4]. 조각마다 제목이나 상위 절 정보를 함께 저장해 문맥을 보존하는 방식, 검색 뒤 인접 조각을 이어 붙여 맥락을 복원하는 방식도 함께 표준 기법으로 자리 잡고 있습니다 [1][5]. 문서를 잘 나누는 일이 곧 검색 품질로 이어지는 RAG의 기초 공정입니다 [1].

참고 자료

  1. Introducing Contextual Retrieval — 공식 기술블로그·Anthropic·2024 — https://www.anthropic.com/engineering/contextual-retrieval
  2. Chunking Strategies for LLM Applications — 공식 학습가이드·Pinecone·2026 접속 — https://www.pinecone.io/learn/chunking-strategies/
  3. Finding the Best Chunking Strategy for Accurate AI Responses — 공식 기술블로그·NVIDIA·2025 — https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
  4. Evaluating Chunking Strategies for Retrieval — 기술 리포트·Chroma·2024 — https://www.trychroma.com/research/evaluating-chunking
  5. Document Parse: Let LLMs read your documents with speed and accuracy — 공식 제품블로그·Upstage(업스테이지)·2024 — https://www.upstage.ai/blog/en/let-llms-read-your-documents-with-speed-and-accuracy
  6. Node Parser Modules — 공식 문서·LlamaIndex·2026 접속 — https://developers.llamaindex.ai/python/framework/module_guides/loading/node_parsers/modules

대표 출처

공식 기술블로그 (2024) · Anthropic, Introducing Contextual Retrieval