로컬 RAG 청킹 전략 — 문서 쪼개기가 검색 품질을 좌우한다

로컬 RAG 청킹 전략을 문서 특성과 임베딩 모델에 맞춰 신중히 선택하는 것은 검색 정확도와 최종 답변 품질을 절반 이상 결정하는 핵심 요소이며, 잘못된 분할 방식은 의미 단절과 노이즈 증가를 불러와 전체 RAG 파이프라인의 신뢰성을 크게 저하시킨다.

한 줄 요약: 로컬 RAG 청킹은 단순한 문자열 분할이 아니라 의미 보존과 검색 효율 사이의 균형을 잡는 과정이다. 고정 크기부터 의미 기반까지 전략 선택에 따라 검색 결과의 관련성과 답변의 정확도가 극명하게 갈린다.

청킹이 왜 그렇게 중요할까?#

로컬 환경에서 RAG를 구축할 때 청킹은 단순한 전처리가 아니라 시스템 전체 성능을 좌우하는 가장 앞단의 설계 결정이다. 벡터 임베딩은 chunk 단위로 생성되고, 검색은 이 chunk들의 유사도를 비교하며, LLM은 검색된 chunk들을 컨텍스트로 삼아 답변을 생성한다. chunk가 문장 중간에서 잘리거나 여러 주제가 섞이면 임베딩 벡터가 왜곡되고, 검색 단계에서 관련 정보가 누락되거나 불필요한 노이즈가 섞여 들어간다. 결국 LLM은 불완전한 정보로 답변을 하게 되고 hallucination 위험이 높아진다.

초보자를 위한 비유를 들자면, 책을 아무 데서나 잘라 요약 카드로 만들면 문장 중간이 잘려 뜻이 사라진다 — 어디서 자르느냐가 카드의 쓸모를 정한다. RAG에서도 마찬가지다. 문서의 자연스러운 의미 경계를 무시하고 기계적으로 자르면 핵심 정보가 유실되거나 맥락이 단절되어 검색 결과가 완전히 달라진다. 특히 로컬에서는 클라우드처럼 무한한 컨텍스트를 기대할 수 없기 때문에, 청킹 단계에서 의미를 최대한 보존하는 것이 이후 재랭커나 프롬프트 개선보다 더 근본적인 해결책이 된다.

네 가지 전략은 어떻게 다를까?#

로컬 RAG에서 실무적으로 쓰이는 청킹 전략은 네 가지로 구분되며, 구현 난이도와 품질 특성이 명확히 다르다. 아래 표는 2026-07 기준 정성 평가를 정리한 것이다.

고정 크기 전략은 가장 기본적이고 널리 쓰인다. 문서를 미리 정한 토큰 수(N) 또는 문자 수마다 일괄적으로 자르는 방식으로, 구현이 단순하고 속도가 빠르며 chunk 크기를 예측하기 쉬워 인덱싱과 배치 처리가 편리하다. 그러나 문장이나 단락 중간에서 잘리는 경우가 잦아 임베딩이 의미를 제대로 담지 못하고, 특히 한국어처럼 조사·어미 변화가 중요한 언어에서는 정보 왜곡이 더 커질 수 있다.

문장·문단 경계 전략은 텍스트의 자연스러운 경계를 활용한다. 마침표·물음표·느낌표 등을 기준으로 문장을 나누고, 빈 줄로 문단을 구분하는 방식이다. 한국어 환경에서는 형태소 분석기를 사용하면 비교적 정확한 분리가 가능하다. 각 chunk가 완전한 의미 단위를 유지하므로 임베딩 품질과 검색 관련성이 높아지는 것이 최대 장점이다. 다만 문서에 따라 문장 길이 편차가 커서 어떤 chunk는 매우 짧고 어떤 chunk는 과도하게 길어질 수 있으며, 이는 검색 배치 효율을 떨어뜨리는 요인이 된다.

오버랩 슬라이딩 전략은 경계 손실을 줄이기 위해 고안된 실용적인 절충안이다. 기본 분할 방식(고정 크기 또는 경계 기반)을 유지하되, 인접 chunk 사이에 일정 비율(보통 10~20%)의 오버랩을 둔다. 예를 들어 크기 500에 오버랩 80을 주면 이전 chunk의 마지막 부분이 다음 chunk 시작에 중복 포함된다. 이로 인해 경계에 걸친 핵심 정보가 유실되는 문제를 크게 완화할 수 있고, 긴 문서에서 연속적인 맥락을 유지하는 데 효과적이다. 단점은 chunk 총 개수가 늘어나 저장 공간과 검색 시간이 증가한다는 점이다.

의미 기반 전략은 가장 고도화된 접근이다. 문서를 문장 단위로 나눈 뒤 각 문장을 임베딩하고, 코사인 유사도 등을 기준으로 내용이 유사한 문장들을 하나의 chunk로 묶는다. 이렇게 생성된 chunk는 주제 응집력이 매우 높아 검색 정확도가 가장 우수하다. 로컬에서는 sentence-transformers나 bge 계열 모델로 구현할 수 있다. 그러나 모든 문장에 대해 임베딩 연산을 수행해야 하므로 계산 비용이 높고, 특히 CPU-only 환경에서는 처리 시간이 길어진다. 구현 복잡도도 높아 초보자에게는 진입 장벽이 존재한다.

로컬에서 어떻게 시작하나?#

로컬 RAG를 처음 구축하는 경우 처음부터 의미 기반 전략을 도입하기보다는 점진적으로 접근하는 것이 안정적이다.

1. 문장·문단 경계+적당한 오버랩으로 시작하라 — 한국어 문서라면 문장 분리 라이브러리로 자연 경계를 먼저 확보한 뒤 오버랩을 전체 크기의 10~20% 정도로 설정해 경계 손실을 최소화한다.
2. 너무 크면 검색 노이즈·너무 작으면 맥락 손실이라 중간값부터 — 초기에는 크기를 400~700토큰 정도의 중간 범위에서 테스트하며 실제 검색 쿼리로 품질을 관찰하고 조정한다.
3. 품질 안 나오면 의미 기반·재랭커 추가 — 기본 전략으로 만족스럽지 않다면 의미 기반 청킹을 도입하거나 검색 후 교차 인코더 재랭커를 추가해 top-k 결과를 재정렬하는 방식으로 품질을 끌어올린다.

참고: 2026-07-12 KST 기준으로 최적 청크 크기와 오버랩 비율은 문서 종류(법률·논문·일반 텍스트·코드 등)와 임베딩 모델의 특성에 따라 크게 달라진다. 따라서 실제 데이터로 여러 설정을 실험하고 검색 품질을 직접 측정하며 조정하는 과정이 가장 중요하다. 한국어의 경우 영어 중심 토크나이저와 동작이 다를 수 있으니 한국어 특화 전처리나 모델을 함께 고려해야 한다.

이 시리즈: 이 시리즈 허브 — 로컬 LLM·RAG 7가지 관문 · 재랭커로 검색 정확도 올리기 · 지식 넣는 3가지 길: 파인튜닝·RAG·프롬프트

함께 읽기: 로컬 RAG, 임베딩만으론 부족하다 — 재랭커로 검색 정확도 올리기, BGE-M3 다국어 검색, 월 비용·GPU 시간으로 판단하기

참고 링크

• LangChain 텍스트 분할
• FlagEmbedding(BGE)
• Sentence-Transformers