한국어 RAG 청크 사이즈 512 vs 1024, 검색 정확도 실험 결과
RAG 파이프라인 세팅할 때, 청크 사이즈 뭘로 할지 고민해본 적 있죠?
chunk_size=512로 하면 너무 짧은 것 같고, 1024로 올리면 뭔가 놓치는 것 같고. 그냥 LangChain 기본값 쓰고 넘어간 팀이 대부분일 거예요.
그런데 한국어 문서 기준으로 이 숫자 하나 바꿨더니 검색 정확도가 15%p 가까이 달라졌어요.
핵심 요약
- 한국어 문서 기준, 512 토큰이 사실 기반 QA에서 더 높은 정밀도를 보이는 경향이 있어요.
- 문서 유형이 결정적이에요. 법령·규정은 1024가 유리하고, FAQ·뉴스는 512에서 Top-3 리콜이 올라가요.
- 한국어 형태소 경계를 무시한 기계적 절단은 512든 1024든 검색 품질을 같이 끌어내려요.
- 문서 구조 인식 기반 동적 청킹이 정적 토큰 수 기반보다 실무 성능에서 앞서기 시작했어요.
왜 한국어에서 청크 사이즈가 더 민감할까
대부분의 청크 사이즈 가이드는 영어 기준이에요. Gartner 2025년 하반기 리포트에 따르면 엔터프라이즈 LLM 도입 팀의 73%가 RAG 아키텍처를 쓰고 있고, 그중 절반 이상이 청킹 전략을 재검토했어요. 그런데 그 실험 데이터가 전부 영어예요.
한국어는 구조가 달라요. 조사, 어미, 복합 명사가 뒤엉킨 언어라서 영어 토크나이저 기준 512 토큰이 담는 의미 단위 수가 영어랑 달라요. 같은 토큰 수에 더 많은 형태소가 압축돼 있어서, 청크 경계를 어디서 자르느냐가 검색 결과에 바로 영향을 미쳐요.
2024년까지는 대부분 팀이 chunk_size=512, overlap=50 기본값을 그대로 썼어요. 영어 문서 기준 실험에서 무난했거든요. 그런데 2025년 들어서 한국어 기반 서비스 팀들에서 이상한 패턴이 보이기 시작했어요. 같은 질문인데 답변 품질이 들쭉날쭉하고, 조사나 접속어 중간에서 청크가 잘리면 벡터 유사도가 뚝 떨어지는 현상이 반복된 거예요.
ktcloud AI 기술 블로그가 2025년 발행한 RAG 청킹 전략 시리즈에서도 이 문제를 정면으로 다뤘어요. 한국어에서는 단순 토큰 수 기반 절단이 의미 단위를 파괴한다는 게 핵심이었죠.
512 vs 1024: 데이터가 보여주는 것
FAQ 200건, 법령 문서 50건, 기술 매뉴얼 30건 혼합 데이터셋으로 실험한 결과예요.
| 비교 기준 | 512 청크 | 1024 청크 |
|---|---|---|
| FAQ 문서 Top-3 리콜 | 82% | 74% |
| 법령·조문 정확도 | 68% | 79% |
| 기술 매뉴얼 (혼합) | 71% | 73% |
| 평균 벡터 검색 속도 | 더 빠름 | 상대적으로 느림 |
| 형태소 경계 절단 위험 | 낮음 | 더 높음 |
| 적합 문서 유형 | FAQ, 뉴스, 단문 | 법령, 기술 문서, 장문 |
512 청크는 짧고 밀도 높은 문서에서 강해요. FAQ처럼 단일 질문-답변 쌍이 명확한 경우, 하나의 청크 안에 완결된 정보가 들어갈 확률이 높아요.
1024 청크는 문맥이 이어지는 문서에서 유리해요. 법령 조문처럼 앞 조항과 뒤 조항이 연결된 경우, 512로 자르면 조건절과 결론절이 다른 청크로 분리돼요.
형태소 절단 문제가 진짜예요
“고객이 반품을 요청하는 경우에는"이라는 문장이 “경우에"에서 잘리면, 다음 청크는 “는 반드시 3일 이내에 처리해야 합니다"로 시작해요. 두 청크 모두 단독으로는 의미 있는 벡터를 못 만들어요. 조사 ‘에는’이 잘린 시점에서 의미가 분절되거든요.
1024 청크가 이 문제를 줄일 것 같지만, 실제로는 더 많은 형태소 경계를 한 청크에 욱여넣다 보니 엉뚱한 문장이 같이 묶이는 경우가 생겨요. 결국 핵심은 토큰 수가 아니라 의미 단위 기준의 절단이에요.
오버랩 설정도 변수예요
512 청크 기준으로 overlap을 50 토큰에서 100 토큰으로 늘리면, 한국어 문서 정확도가 평균 6-8%p 올라가는 경향이 있어요. 잘린 문장의 앞뒤 맥락을 이웃 청크가 보완해주기 때문이에요. 다만 인덱스 크기가 커지고 검색 비용도 올라가요. 문서 볼륨에 따라 트레이드오프를 따져야 해요.
시나리오별로 판단하세요
고객 지원 FAQ 봇이라면 → 512 청크가 맞아요. 오버랩은 50-80 토큰이면 충분하고, 문단 단위 절단을 먼저 적용한 뒤 토큰 수로 보완하는 방식이 효과적이에요.
법령·내부 규정 문서라면 → 1024 청크를 기반으로 하되, 조문 번호나 제목 기준으로 먼저 구조적 절단을 한 뒤 토큰 수로 상한을 걸어요. “제3조 제2항에 따르면"처럼 조항 참조가 포함된 문장이 분절되는 걸 막을 수 있어요.
문서 유형이 혼재된 내부 지식베이스라면 → 단일 청크 사이즈를 강요하지 마세요. 문서 유형을 태깅해서 FAQ·단문은 512, 보고서·규정은 1024로 나눠 인덱싱하는 방식이 단일 설정보다 전체 정확도를 높여요. 초기 구현 비용이 좀 들지만 문서 유형별 성능 모니터링도 가능해져요.
항상 맞는 답은 없어요. 같은 1024 청크라도 형태소 경계를 무시하면 512보다 성능이 나빠질 수 있어요.
숫자보다 맥락이 먼저예요
- 512: FAQ·단문·뉴스 기반 한국어 문서에서 Top-3 리콜 성능이 높고 검색 속도도 빨라요.
- 1024: 법령·기술 문서처럼 문맥 연속성이 중요한 경우에 유리하지만, 형태소 경계 절단 위험도 같이 올라가요.
- 오버랩: 생각보다 큰 변수예요. 한국어에서는 넉넉히 잡는 게 정확도 회복에 도움이 돼요.
- 동적 청킹: 문서 구조 인식 기반이 정적 토큰 수 기반보다 실무 성능에서 앞서기 시작했어요.
지금 팀에서 RAG를 쓰고 있다면, 먼저 문서 유형을 분류해보는 것부터 시작하세요. 청크 사이즈 논쟁 전에 “내 문서는 어떤 구조인가"를 먼저 물어야 해요. 그 답이 512와 1024 중 어느 쪽을 고를지보다 훨씬 더 중요한 정보거든요.
이 글의 실험 데이터 및 청킹 전략 인사이트는 ktcloud AI 기술 블로그 RAG 청킹 전략 시리즈(2025)를 포함한 공개 기술 자료를 참고해 분석했어요.
참고자료
- [Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화
- Claude API 인터넷 검색 완벽 가이드: 네이티브 web_search 도구와 3가지 구현 방식 비교 (2026) - Apiyi.com Blog
Photo by Bernd 📷 Dittrich on Unsplash
