RAG 청킹을 처음 설정할 때 가장 많이 하는 실수가 있다. “일단 적당히 잘라보자”는 감각으로 시작하는 것이다. 그런데 RAG 청킹은 감각보다 기준이 먼저다. 어떤 문서를, 어떤 목적으로, 어떻게 쪼개느냐에 따라 검색 정확도가 완전히 달라진다. RAG 청킹이란 결국 “AI가 답하기 좋은 단위로 문서를 나누는 작업”이다.
이 글에서는 RAG 청킹 전략 4가지를 각각 언제 쓰는지 기준과 함께 정리한다. 청크 사이즈와 오버랩 설정 기준, 스플리터 선택 방법까지 한 흐름으로 정리한다.
RAG 청킹이란 무엇인가
RAG(Retrieval-Augmented Generation)는 문서를 검색해서 LLM의 답변 품질을 높이는 구조다. 이 구조에서 RAG의 핵심은 “어떤 조각을 검색하느냐”에 달려 있다.
문서를 그대로 AI에게 던지면 AI는 처리하지 못한다. AI는 숫자, 즉 벡터만 이해한다. 그래서 문서를 일정 단위로 분할하고, 그 단위를 벡터로 수치화해서 데이터베이스에 저장한다. 사용자가 질문하면 유사도가 높은 청크를 꺼내서 LLM에게 전달하는 구조다.
RAG 청킹은 이 분할 작업 전체를 가리킨다. 문서 로드 → 분할(청킹) → 벡터화(임베딩) → 저장 → 검색(리트리버) 순서로 파이프라인이 흐른다. 청킹은 그 흐름의 두 번째 단계이자, 검색 품질을 결정하는 핵심 지점이다.
현장에서 설비 이상을 진단할 때는 증상을 먼저 살피고 나서 진단 방법을 고른다. RAG 청킹도 순서가 같다. 문서의 성격을 먼저 진단하고 그에 맞는 전략을 고르는 것이지, 자르는 방법부터 정해놓고 문서를 거기에 끼워 맞추는 게 아니다.
청킹 전략 종류 4가지
RAG 청킹 전략은 크게 4가지로 나뉜다. 문서의 성격에 따라 골라 쓰는 것이 원칙이다.
| 전략 | 특징 | 적합한 문서 |
|---|---|---|
| 고정 길이 청킹 | 글자 수 기준으로 일정하게 자름 | 단순 텍스트, 뉴스, 공지 |
| 의미 중첩 청킹 | 문맥이 끊기지 않도록 겹치며 자름 | 기술 문서, 인과관계가 중요한 문서 |
| 계층적 청킹 | 헤더 구조를 기준으로 계층 단위로 자름 | 목차가 있는 문서, 매뉴얼 |
| 에이전틱 청킹 | LLM이 문서를 분석해 전략을 스스로 결정 | 문서 종류가 다양하거나 혼재된 환경 |
고정 길이 청킹
가장 단순한 방식이다. 글자 수나 토큰 수를 기준으로 일정하게 자른다. 구조가 없고 내용이 단순한 문서에 적합하다. 공지문, 단문 뉴스, 상품 설명처럼 각 문장이 독립적으로 의미를 가지는 경우에 잘 맞는다.
단점은 문맥이 끊길 수 있다는 점이다. 인과관계나 논리 흐름이 중요한 문서에서는 적합하지 않다.
의미 중첩 청킹
앞 청크의 마지막 일부를 다음 청크 앞에 겹쳐서 포함시키는 방식이다. 청크 오버랩(overlap)을 활용하는 전략이다. 문맥이 청크 경계에서 끊기는 문제를 완화한다.
기술 문서처럼 앞 내용이 뒤 내용의 전제가 되는 구조에서 효과적이다. “A를 설정했기 때문에 B가 이렇게 작동한다”는 인과관계가 청크 경계로 잘려도 오버랩 덕분에 문맥이 유지된다.
계층적 청킹
문서의 헤더 구조(H1 → H2 → H3)를 기준으로 계층 단위로 자르는 방식이다. 목차가 있는 문서, 섹션 단위로 내용이 구분된 매뉴얼이나 보고서에 적합하다. 큰 제목 단위로 먼저 나누고, 그 안에서 다시 소제목 단위로 쪼개는 식으로 진행한다.
헤더 구조가 명확한 문서일수록 검색 정확도가 높아진다.
에이전틱 청킹
LLM이 문서의 내용과 목적을 스스로 파악하고 청킹 전략을 결정하는 방식이다. FAQ는 짧게, 기술 분석 문서는 길게, 일반 문서는 중간으로 — 문서마다 다른 기준을 자동으로 적용한다.
문서 종류가 다양하거나, 매번 직접 전략을 고르기 어려운 환경에서 유용하다. 구현 복잡도가 높지만 유연성이 가장 뛰어나다.
청크 사이즈와 오버랩, 어떻게 설정하는가
RAG 청킹에서 청크 사이즈와 오버랩은 정밀도와 문맥 보존 사이의 트레이드오프를 결정한다.
청크 사이즈는 작을수록 정밀도가 높아지지만 문맥이 끊기고 저장 부담이 커진다. 클수록 문맥은 잘 유지되지만 관련 없는 내용이 섞여 정밀도가 낮아진다.
| 청크 사이즈 | 정밀도 | 문맥 보존 | 인프라 부담 |
|---|---|---|---|
| 작음 (200~400) | 높음 | 낮음 | 큼 |
| 중간 (600~800) | 중간 | 중간 | 중간 |
| 큼 (1000~1500) | 낮음 | 높음 | 적음 |
일반적인 시작점은 800 전후다. 이후 문서 특성에 따라 조정한다. FAQ나 용어집처럼 짧고 독립적인 문장이 나열된 문서는 청크를 작게 잡는 것이 유리하다. 소설이나 에세이처럼 흐름이 중요한 문서는 크게 잡아도 무방하다.
오버랩은 청크 경계에서 문맥이 잘리는 문제를 완화하는 설정이다. 청크 사이즈 기준 10~20%를 권장한다. 청크 사이즈가 800이라면 오버랩은 80~160 정도로 설정하는 식이다.
오버랩이 너무 크면 중복 저장이 늘어 인프라 부담이 커진다. 너무 작으면 경계 문맥 손실이 그대로 남는다. 오류 코드 매뉴얼처럼 “코드 + 해결 방법”이 하나의 세트로 묶여야 하는 문서는 오버랩보다 구분자 기반 분할이 더 효과적이다.
스플리터 선택 기준 — 모르겠으면 리커시브부터
스플리터는 실제로 청크를 잘라내는 도구다. 문서 특성에 따라 선택이 달라진다.
리커시브 스플리터는 문단 → 줄 → 문장 순으로 계층적으로 잘라내는 방식이다. 특별한 구분자가 없는 일반 문서에 가장 잘 맞는다. 모르겠으면 리커시브부터 돌려보는 것이 실무 기준이다.
구분자 기반 스플리터는 특정 기호나 패턴을 기준으로 자른다. 줄바꿈, 특수문자, 정규표현식 등을 구분자로 지정할 수 있다. 오류 코드 매뉴얼처럼 코드와 해결 방법이 반복되는 구조에서 강력하다. 구분자를 잘 설정하면 의미 단위가 자연스럽게 하나의 청크로 묶인다.
헤더 기반 스플리터는 계층적 청킹에서 쓰인다. H1, H2, H3 헤더를 기준으로 섹션 단위로 자른다.
검색 단계에서는 Top K 설정도 중요하다. 유사도 검색 결과가 수백 개 나오더라도 실제로 LLM에 전달하는 청크는 상위 3~5개로 제한하는 것이 정확도를 높이는 데 유리하다. Top K가 너무 크면 관련 없는 청크가 섞여 답변 품질이 오히려 떨어진다.
정리
RAG 청킹은 문서를 AI가 검색 가능한 단위로 분할하는 작업이다. 전략은 4가지 — 고정 길이, 의미 중첩, 계층적, 에이전틱. 문서가 단순하면 고정 길이, 인과관계가 중요하면 의미 중첩, 헤더 구조가 있으면 계층적, 문서 종류가 다양하면 에이전틱을 선택한다.
청크 사이즈는 800부터 시작해 조정하고, 오버랩은 10~20%, 스플리터는 리커시브가 기본값이다. 세 가지 설정이 잡혀야 RAG 청킹이 실제로 작동한다.
함께 읽으면 좋은 글
AI가 문서를 분석해 청킹 전략까지 결정하는 에이전틱 구조의 배경을 이해하고 싶다면 이 글이 이어진다.
LangChain RAG 공식 문서에서 청킹 관련 구현 세부 내용을 확인할 수 있다: LangChain Text Splitters
