한국어 RAG 파이프라인 청크 사이즈 512 vs 1024: LangChain·Chroma 검색 정확도 실험

한국어 RAG 파이프라인을 만들다 보면, 어느 순간 이 질문 앞에서 멈추게 돼요.

“청크를 512로 잘라야 할까, 1024로 잘라야 할까?”

단순해 보이는 숫자 하나가 검색 정확도를 20~35%까지 흔들어요. 실험으로 확인된 수치예요. LangChain + Chroma 조합에서 이 차이는 특히 크게 나타나는데, 한국어 문서의 특성 때문이에요.

이 글에서 다룰 내용은 네 가지예요:

• 청크 사이즈가 검색 정확도에 미치는 실증 데이터
• 한국어 문서에서 512와 1024가 각각 어떻게 작동하는지
• LangChain + Chroma 환경에서의 실전 설정
• 문서 유형별로 어떤 크기를 골라야 하는지

핵심 요약

• 로컬 RAG 파이프라인에서 청크 사이즈 512는 단문 위주 FAQ·고객 응대 문서에서 Recall@5 기준 약 78%를 기록한 반면, 1024는 기술 문서·보고서처럼 맥락이 긴 문서에서 동일 지표 약 85%를 기록했다. (피카부랩스, 2025)
• 한국어는 조사·어미 변화로 인해 토큰 밀도가 영어보다 낮아서, 같은 청크 사이즈라도 실제 담기는 의미 단위가 달라지는 문제가 생긴다.
• LangChain의 RecursiveCharacterTextSplitter는 기본값이 영어 기준이라, 한국어 문서에는 chunk_overlap을 최소 10~15%로 늘리는 게 실험적으로 더 나은 결과를 줬다. (youngju.dev, 2026)
• Chroma에서 청크 사이즈 변경은 반드시 컬렉션 재생성을 수반하므로, 초기 설계 단계에서 결정하는 게 운영 비용 면에서 훨씬 유리하다.

청킹이 왜 갑자기 이렇게 중요해졌나

RAG 파이프라인의 원리는 간단해요. 문서를 잘게 자르고, 벡터로 변환해서 저장한 뒤, 쿼리와 가장 비슷한 청크를 꺼내 LLM에 넘기는 거죠. 여기서 “잘게 자르는” 기준이 청크 사이즈예요.

문제는 이 기준이 모든 문서, 모든 언어에 똑같이 적용되지 않는다는 거예요.

kt cloud 기술 블로그(2025)에 따르면, 청킹 전략을 잘못 잡으면 벡터 검색 단계에서 관련 문서를 아예 못 찾는 경우가 생겨요. LLM이 아무리 좋아도, 검색에서 놓친 정보는 답변에 반영이 안 돼요. 이게 RAG 품질 문제의 핵심 원인 중 하나예요.

2026년 기준으로 로컬 RAG를 구축하는 환경은 두 가지 조합이 가장 많이 쓰여요.

• LangChain — 파이프라인 오케스트레이션
• Chroma — 로컬 벡터스토어

오픈소스라 비용이 없고, 로컬에서 돌아서 데이터가 외부로 나가지 않으며, 설정이 비교적 간단해요. 그런데 LangChain의 기본 청킹 도구인 RecursiveCharacterTextSplitter의 기본값은 영어 중심으로 설계됐어요. 한국어 문서에 그대로 쓰면 어색한 위치에서 문장이 잘리는 일이 자주 생겨요. youngju.dev의 2026년 3월 실험에서도 이 점이 명확히 확인됐어요.

512 vs 1024: 실험 데이터가 보여주는 것

검색 정확도: 숫자로 보기

피카부랩스(2025)의 실증 실험을 기준으로 정리하면, Recall@5(상위 5개 검색 결과 중 정답이 포함될 확률)에 미치는 영향은 문서 유형에 따라 크게 달라져요.

단문 위주 문서에서 512가 강한 이유는 명확해요. 짧은 청크가 쿼리의 의미와 더 정밀하게 맞아떨어지거든요. 반대로 맥락이 중요한 문서에서 512로 자르면, 하나의 개념이 여러 청크에 쪼개져서 어느 청크도 쿼리에 충분히 대응하지 못하는 상황이 생겨요.

한국어의 특수성: 토큰 밀도 문제

영어 기준의 청크 설정을 한국어에 그대로 쓰면 안 되는 이유가 여기 있어요.

한국어는 “검색한다"라는 하나의 의미를 “검색하다”, “검색했을 것이다”, “검색하게 되면” 등 다양한 형태로 표현해요. 조사와 어미 변화가 많은 언어라는 거죠. 그 결과, 동일한 토큰 수(예: 512 토큰)에 담기는 실제 의미 단위가 영어보다 적어요.

실험적으로 확인된 해결책은 chunk_overlap을 늘리는 거예요. LangChain 기본값인 050 토큰 대신, 한국어 문서에서는 전체 청크의 1015% 수준을 겹치게 설정하면 문장 경계에서 의미가 잘리는 문제를 줄일 수 있어요. youngju.dev(2026) 실험에서 chunk_overlap=100(청크 사이즈 512 기준) 설정이 overlap 없는 경우보다 Recall@5에서 약 8~12%p 높은 결과를 보였거든요.

LangChain + Chroma 실전 설정

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 한국어 문서 권장 설정 (기술 문서 기준)
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1024,
    chunk_overlap=150,  # 약 15% overlap
    separators=["\n\n", "\n", "。", ".", " ", ""]
)

separators에 한국어 문장 종결 패턴을 넣어주는 게 포인트예요. 기본값에는 마침표(。)가 없어서 문장 중간에서 잘리는 일이 생겨요. 이 설정 하나로 청크 품질이 눈에 띄게 달라져요.

Chroma에서 주의할 점도 있어요. 청크 사이즈를 바꾸려면 기존 컬렉션을 지우고 다시 만들어야 해요. 운영 중인 시스템에서 바꾸면 이미 저장된 벡터와 새 쿼리 사이에 불일치가 생기거든요. 초기 설계 단계에서 문서 유형을 꼼꼼히 분석하고 결정하는 게 나중에 재작업을 피하는 방법이에요.

실전에서 어떻게 결정할까

시나리오 1: 사내 FAQ 챗봇 질문이 짧고 답도 짧아요. 각 문서 항목이 독립적으로 완결돼요. 청크 512, overlap 50~80 조합이 맞아요. 문서 간 맥락 연결이 필요 없고, 정밀한 매칭이 더 중요하거든요.

시나리오 2: 기술 문서 / API 레퍼런스 검색 하나의 개념이 여러 단락에 걸쳐 설명되는 경우가 많아요. 청크 1024, overlap 100~150이 적합해요. “이 파라미터가 무엇을 하나요?“라는 쿼리에 관련 맥락이 같은 청크 안에 있어야 제대로 된 답변이 나와요.

시나리오 3: 혼합 문서 (FAQ + 상세 설명) 현실에서 가장 자주 마주치는 케이스예요. 문서를 유형별로 나눠 각각 다른 청크 사이즈로 처리하거나, 1024로 통일하되 overlap을 충분히 주는 방식 중에 선택하면 돼요. 문서 양이 많지 않다면 전자가 낫고, 운영 복잡도를 줄이고 싶다면 후자가 현실적이에요.

그리고 주시할 신호 세 가지:

• sentence-transformers/paraphrase-multilingual-mpnet-base-v2 같은 한국어 지원 임베딩 모델의 최적 입력 길이가 512 토큰 내외라는 점 — 1024 청크를 쓰면 임베딩 모델이 뒤쪽 내용을 잘라낼 수 있어요.
• LangChain 0.3+에서 추가된 SemanticChunker — 고정 사이즈 대신 의미 단위로 자르는 방식인데, 한국어 실험 데이터가 아직 충분히 쌓이지 않았어요.
• Chroma 0.5+의 메타데이터 필터링 — 청크 사이즈 결정 전에 문서 유형 태깅을 미리 해두면, 나중에 유형별 검색 전략을 적용하기 쉬워요.

지금 할 수 있는 것

“뭐가 더 낫다"를 데이터 없이 결정하기는 어려워요. 문서 유형, 쿼리 패턴, 임베딩 모델이 모두 변수거든요.

그래도 출발점을 정리하면:

• FAQ, 짧은 단락 위주 → 512 + overlap 80
• 기술 문서, 보고서 위주 → 1024 + overlap 150
• 한국어 문서라면 → separators에 "\n\n", "。" 추가

앞으로 6~12개월 안에 주목할 변화는 두 가지예요. 시맨틱 청킹이 한국어 문서에서도 검증 데이터가 쌓이기 시작할 거고, 임베딩 모델 자체의 한국어 처리 능력이 올라오면 청크 사이즈 선택의 비중이 지금보다 줄어들 수 있어요.

그때까지는, 직접 실험하는 게 가장 정직한 방법이에요. Recall@5를 기준 지표로 잡고, 문서 50~100개로 A/B 테스트를 돌려보세요. 하루면 충분해요. 데이터 없이 청크 사이즈를 고르는 건, 지도 없이 길을 고르는 것과 같거든요.

어떤 문서 유형에서 청킹 문제를 겪고 있나요?

참고자료

1. [Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화
2. LLM RAG 파이프라인: 청킹 전략과 임베딩 최적화 실전 2026 | Chaos and Order
3. RAG 답변 품질을 좌우하는 청킹 전략: 실증 데이터로 검증한 최적 크기와 방법 - 피카부랩스 블로그

Photo by Tekton on Unsplash