"RAG 한국어 문서 청크 사이즈 몇으로 설정해야 하나요"

"Claude API 청크 사이즈별 RAG 검색 정확도 실험 한국어 문서 임베딩 비교 결과에 따르면, 한국어 문서는 300~500 토큰 구간에서 검색 정확도가 가장 안정적으로 나타납니다. 한국어 평균 문장이 50~80 토큰 수준이라 이 구간에서 4~6개 문장을 하나의 청크로 묶으면 의미 맥락이 충분히 확보되기 때문입니다. 반면 128 토큰 이하로 자르면 Top-5 검색 정확도가 평균 18~23% 하락하는 경향이 있어 주의가 필요합니다."

"RAG 파이프라인에서 청크 overlap 설정이 검색 정확도에 영향을 미치나요"

"청크 오버랩은 청크 크기 자체보다 검색 정확도에 더 큰 영향을 미치는 경우가 있습니다. 청크 크기의 10~15% 수준(예: chunk_size=400일 때 overlap=50~60 토큰)으로 설정하면 문장 경계에서 잘려나가는 정보 손실을 효과적으로 줄일 수 있습니다. 특히 한국어는 문장 끝 서술어가 전체 의미를 결정하는 구조가 많아 오버랩 없이 자를 경우 결론 부분이 다음 청크에 고아처럼 남는 문제가 자주 발생합니다."

"한국어 RAG에서 임베딩 모델 선택이 청크 전략보다 중요한가요"

"Claude API 청크 사이즈별 RAG 검색 정확도 실험 한국어 문서 임베딩 비교에서는 임베딩 모델 선택을 청크 전략보다 먼저 결정해야 할 변수로 꼽고 있습니다. data-dynamics.io의 한국어 임베딩 벤치마크에 따르면, 동일한 청크를 사용하더라도 임베딩 모델에 따라 MRR@10 기준 최대 31% 차이가 발생합니다. 아무리 청크를 잘 설계해도 임베딩 모델이 한국어를 제대로 처리하지 못하면 벡터 자체가 부정확하게 생성되기 때문입니다."

"청크 사이즈를 1024 이상으로 크게 설정하면 어떤 문제가 생기나요"

"청크 크기가 1024 토큰 이상이 되면 하나의 벡터에 너무 많은 주제가 포함되어 벡터가 평균화되는 문제가 발생합니다. 예를 들어 계약 조항과 해지 절차가 같은 청크에 묶이면, '해지 방법'을 검색할 때 관련 없는 계약 조항 내용이 노이즈로 섞여 검색 결과에 올라오게 됩니다. 이로 인해 Claude가 생성 단계에서 답변을 만들 때 맥락이 뒤섞이는 상황이 발생할 수 있어 한국어 문서에서는 일반적으로 비권장 설정입니다."

"Claude API 200K 컨텍스트 윈도우가 RAG 청크 설계에 어떤 영향을 주나요"

"Claude API의 200K 컨텍스트 윈도우는 검색 단계가 아닌 생성 단계에서 활용되는 기능입니다. 따라서 RAG 파이프라인에서 청크 크기 결정은 Claude API의 컨텍스트 윈도우 크기와 별개로, 검색 모델의 최적 입력 단위를 기준으로 독립적으로 설계해야 합니다. 컨텍스트 윈도우가 크다고 해서 청크를 무조건 크게 설정하면 벡터 평균화 문제로 검색 정확도가 오히려 낮아질 수 있습니다."

한국어 RAG 파이프라인 청크 사이즈별 검색 정확도 실험과 임베딩 모델 비교

May 28, 2026 5 min read 한국어

RAG 파이프라인을 직접 구축해봤다면 알 거예요. 같은 문서, 같은 모델을 써도 청크 사이즈 하나 바꿨을 뿐인데 검색 정확도가 확 달라지는 상황 말이에요. 특히 한국어 문서에서는 이 격차가 더 벌어져요. 한국어는 교착어라서 형태소 경계가 영어와 완전히 다르거든요. 청크를 잘못 자르면 의미 단위가 중간에 뚝 끊겨버려요.

kt cloud가 2026년 3월 자사 기술 블로그에서 RAG 임베딩·벡터 인덱싱 기술을 정리해 공개할 만큼, 이건 인프라 레벨에서도 진지하게 다루는 주제가 됐어요. 그런데 막상 청크 사이즈별로 실험을 해보면, 이론과 실제 사이에 꽤 큰 간극이 있어요.

핵심 포인트 미리 보면:

한국어 문서는 청크 사이즈 300~500 토큰 구간에서 검색 정확도가 가장 안정적
오버랩(overlap) 설정이 청크 크기 자체보다 정확도에 미치는 영향이 큰 경우가 있음
Claude API의 컨텍스트 윈도우 크기가 검색 청크 설계에 직접 영향
한국어 임베딩 모델 선택이 청크 전략보다 먼저 결정돼야 할 변수

핵심 요약
한국어 문서에서 청크 사이즈 200 토큰 이하는 의미 단위가 분리되면서 Top-5 검색 정확도가 평균 18~23% 하락하는 경향이 있어요.
오버랩 비율을 청크 크기의 10~15%로 설정할 때, 동일 청크 크기 대비 문장 경계 손실이 줄고 Recall이 유의미하게 개선돼요.
data-dynamics.io의 한국어 임베딩 벤치마크에 따르면, 같은 청크를 써도 임베딩 모델에 따라 MRR@10 기준 최대 31% 차이가 발생해요.
Claude API의 200K 컨텍스트 윈도우는 검색 단계보다 생성 단계에서 쓰이는 만큼, RAG 파이프라인에서 청크 크기 결정은 검색 모델 기준으로 독립적으로 설계해야 해요.

지금 이 실험이 필요한 이유

RAG(검색 증강 생성)는 더 이상 연구자들만의 이야기가 아니에요. 국내 기업 개발팀에서 Claude API나 OpenAI API를 붙여서 사내 문서 검색, 고객 지원 자동화, 법률·금융 문서 Q&A 시스템을 만드는 건 2026년 기준으로 꽤 흔한 일이 됐죠.

문제는 여기서 시작돼요. 영어 문서 기반 RAG 레퍼런스는 넘치는데, 한국어 문서에 맞는 청크 전략을 다룬 자료는 여전히 부족해요. 한국어는 조사와 어미가 결합하는 교착어라서, 단순히 chunk_size=500으로 고정하고 토큰 수 기준으로 자르면 “도서관에서” 같은 단위가 의미 없이 끊길 수 있어요. 조사만 남은 청크가 임베딩되면 벡터 공간에서 제대로 된 위치를 못 잡죠.

kt cloud 기술 블로그(2026년 3월)에서도 벡터 인덱싱 단계 이전에 청크 품질이 검색 전체 성능을 좌우한다고 명확히 짚었어요. 인덱싱을 아무리 잘해도 청크 자체가 의미를 담지 못하면 검색은 노이즈를 주워오는 셈이에요.

같은 파이프라인도 청크 설계가 다르면 결과가 완전히 달라지거든요.

청크 사이즈, 어떻게 정확도에 영향을 미치나

청크가 너무 작으면 생기는 문제

토큰 수 기준으로 chunk_size=128 이하로 자르면 어떻게 될까요?

짧은 청크는 임베딩 벡터가 담아야 할 의미 맥락이 너무 적어요. “계약서의 제3조에 따르면” 같은 문장에서 앞 문장의 주어나 주제어가 없으면, 이 청크만으로는 무슨 계약 조항인지 벡터로 표현할 방법이 없어요.

data-dynamics.io의 한국어 임베딩 벤치마크 분석에 따르면, 128 토큰 이하 청크에서 Top-5 검색 정확도(Recall@5)가 300~~500 토큰 구간 대비 평균 18~~23% 낮게 나오는 경향이 있어요. 전문 용어가 많은 법률·의료 도메인 문서일수록 이 격차가 더 벌어졌어요.

청크가 너무 크면 생기는 문제

반대로 chunk_size=1024 이상으로 키우면요? 이번엔 다른 문제가 생겨요.

벡터 하나에 너무 많은 주제가 들어가면 벡터가 평균화돼요. 계약 조항과 해지 절차가 같은 청크에 묶이면, 쿼리가 “해지 방법"을 물어볼 때 계약 조항 내용이 노이즈로 섞여서 올라오죠. 검색은 됐는데 생성 단계에서 Claude가 답변을 만들 때 맥락이 뒤섞이는 상황이 생겨요.

오버랩이 생각보다 중요하다

청크 크기 못지않게 overlap 설정이 결과를 크게 바꿔요. 청크 크기의 10~~15% 수준(예: chunk_size=400, overlap=50~~60 토큰)으로 설정하면, 문장 경계에서 잘려나가는 정보 손실을 많이 줄일 수 있어요.

특히 한국어는 문장 끝 서술어가 전체 의미를 결정하는 구조가 많아서, 오버랩 없이 자르면 결론 부분이 다음 청크 첫 머리에 고아처럼 남는 경우가 자주 생겨요.

한국어 임베딩 모델 비교: 청크보다 먼저 봐야 할 것

청크 전략을 짜기 전에, 사실 임베딩 모델부터 골라야 해요. 아무리 청크를 잘 잘라도 임베딩 모델이 한국어를 제대로 이해 못 하면 벡터가 엉터리로 만들어지거든요.

청크 사이즈별 성능 비교표

아래는 한국어 문서(법률·기술 도메인) 기준, 청크 크기별 주요 지표를 정리한 표예요. 수치는 data-dynamics.io 한국어 벤치마크 및 공개 RAG 실험 데이터를 참고한 추정 범위예요.

청크 크기 (토큰)	Recall@5 (추정)	MRR@10 (추정)	적합한 문서 유형	주요 리스크
128 이하	낮음 (↓18~23%)	낮음	짧은 FAQ	의미 단위 분리
256~384	보통	보통	뉴스·블로그	문장 경계 손실
400~512	높음 ✅	높음 ✅	법률·기술 문서	관리 복잡도 소폭 증가
512~768	보통	보통	장문 보고서	벡터 평균화 위험
1024 이상	낮음	낮음	비권장	과도한 주제 혼합

300~~500 토큰 구간이 한국어 문서에서 가장 안정적인 이유는, 한국어 평균 문장 하나가 약 50~~80 토큰 수준이기 때문이에요. 이 구간에서 4~6개 문장을 하나의 청크로 묶으면 의미 맥락이 충분히 포함되면서 벡터 평균화도 피할 수 있어요.

임베딩 모델 선택의 실제 영향

data-dynamics.io의 벤치마크를 보면, 동일한 청크 400 토큰 기준에서도 임베딩 모델에 따라 MRR@10이 최대 31% 차이가 났어요. 놀랍죠?

한국어 특화 모델(예: KoSimCSE, KLUE-BERT 기반 모델)과 다국어 범용 모델(text-embedding-3-large 등)의 차이가 여기서 갈려요. 일반 도메인 문서라면 다국어 범용 모델도 충분하지만, 법률·의료·금융처럼 한국어 전문 용어가 많은 도메인은 한국어 특화 모델이 명확히 유리해요.

실제 파이프라인에서 어떻게 적용할까

도메인별 권장 설정

법률·계약서 문서

청크 크기: 400~512 토큰
오버랩: 50~70 토큰
이유: 조항 간 연결 맥락이 중요. 오버랩 없으면 조항 번호와 내용이 분리될 위험

기술 매뉴얼·API 문서

청크 크기: 300~400 토큰
오버랩: 30~50 토큰
이유: 코드 블록과 설명문이 섞여 있어서 크게 자르면 코드 맥락이 흐려짐

고객 지원 FAQ

청크 크기: 200~300 토큰
오버랩: 20~30 토큰
이유: 질문-답변 한 쌍이 하나의 의미 단위. 이보다 크게 묶으면 오히려 노이즈

Claude API와 연동 시 추가로 볼 것

Claude API의 컨텍스트 윈도우는 200K 토큰이에요. 그런데 이건 생성 단계의 여유이지, 검색 단계와 직접 관계없어요. RAG 파이프라인에서 Claude를 쓴다면, 검색 모델(임베딩)과 생성 모델(Claude)은 독립적으로 설계해야 해요.

흔한 실수가 “Claude 컨텍스트가 크니까 청크도 크게 잡자"는 논리예요. 청크가 크면 검색 정확도가 떨어지는 건 임베딩 단계에서 이미 결정되거든요. Claude에게 큰 덩어리를 넣기 전에, 먼저 올바른 청크가 검색돼야 해요.

앞으로 주목할 흐름:

하이브리드 청킹 방식 확산: 고정 토큰 기준이 아닌 문장·단락 경계 기반 청킹 라이브러리(LangChain RecursiveCharacterTextSplitter의 한국어 separator 지원)가 성숙해지는 중이에요
문서 유형별 자동 청크 최적화: 2026년 하반기 기준으로, 문서 유형을 자동 분류해 청크 파라미터를 자동 조정하는 도구가 나오고 있어요
평가 지표 표준화: RAG 파이프라인 평가를 위한 한국어 벤치마크 데이터셋이 부족한 상황. 이 공백이 채워지면 청크 전략 비교도 훨씬 체계화될 거예요

정리하면

Claude API 청크 사이즈별 RAG 검색 정확도 실험에서 한국어 문서는 분명한 패턴이 있어요.

한국어 문서 최적 청크: 400~~512 토큰, 오버랩 10~~15%
임베딩 모델이 청크보다 먼저 결정돼야 할 변수
도메인이 전문적일수록 한국어 특화 임베딩 모델 우위가 커짐
Claude의 대형 컨텍스트 윈도우는 검색이 아닌 생성 단계용

앞으로 6~12개월 안에 문서 유형 자동 분류 기반의 동적 청크 설계가 표준이 될 가능성이 높아요. 지금 파이프라인을 만든다면, 청크 크기를 하드코딩하는 대신 도메인별로 파라미터를 분리해두는 게 나중에 훨씬 편해요.

한국어 RAG 파이프라인, 지금 어떤 청크 전략을 쓰고 있나요? 도메인별로 결과가 어떻게 다른지 댓글로 공유해주세요.

참고자료

Photo by Bernd 📷 Dittrich on Unsplash