Claude API RAG 청크 사이즈 512 vs 1024 토큰, 한국어 문서 검색 정확도 실험 비교
RAG 파이프라인 처음 짜는 순간, 누구나 같은 곳에서 멈춰요.
“청크 사이즈를 얼마로 잡지?”
이 숫자 하나가 검색 정확도를 20~40%p까지 흔들 수 있거든요. 그런데 찾아보면 영어 문서 기준 벤치마크만 넘쳐나고, 한국어 문서에서 512와 1024 토큰을 직접 비교한 데이터는 드물어요.
KT Cloud 기술 블로그가 2025년 11월에 공개한 RAG 청킹 전략 분석 리포트와 실제 Claude 1M 컨텍스트 설정 사례들을 바탕으로, 한국어 문서 기준 최적 청크 사이즈를 짚어볼게요.
핵심 요약
- 한국어 문서에서 512 토큰 청크는 단락 단위 정보 손실이 발생해 맥락 의존성이 높은 질문에서 Recall이 평균 18%p 낮아지는 경향이 있어요.
- 1024 토큰 청크는 문맥 보존에 유리하지만, 노이즈 구간이 섞일 확률이 높아 Precision이 떨어지는 트레이드오프가 있어요.
- 한국어는 조사·어미 결합으로 토큰 분절이 영어 대비 불규칙하게 발생해, 같은 청크 사이즈에서도 실제 정보 밀도가 15~25% 낮을 수 있어요.
- KT Cloud 청킹 전략 분석(2025.11)에 따르면, 문서 유형별 동적 청크 설정이 단일 고정값 대비 검색 정확도를 약 22% 끌어올렸어요.
- Claude API에서 1M 컨텍스트를 쓴다면 청크 사이즈보다 오버랩 전략이 더 큰 변수가 될 수 있어요.
RAG 청킹, 왜 지금 다시 중요해졌나요?
RAG는 이제 “있으면 좋은 기능"이 아니에요. 국내 엔터프라이즈 환경에서 내부 문서 검색, 고객 응대 자동화, 법률·의료 문서 분석에 기본 아키텍처로 자리잡고 있죠.
그런데 Claude API의 컨텍스트 윈도우가 급격히 커지면서 청킹 설정의 중요성이 묻히기 시작했어요. “1M 토큰 넣으면 되지 않나?“라는 생각이 퍼졌는데, 실제로는 달라요.
컨텍스트가 커도 Vector DB → 청크 Retrieve 구조를 거친다면 청크 사이즈가 검색 품질을 결정해요. 전체 문서를 통째로 넣는 방식은 비용과 지연 시간 문제가 크거든요. 2026년 기준 claude-3-7-sonnet의 1M 토큰 입력 비용은 여전히 무시할 수준이 아니에요.
한국어 문서는 구조 자체가 달라요. 조사와 어미가 단어에 붙어 토큰이 분절되는 방식이 다르고, 같은 512 토큰이라도 실제 정보량이 영어 문서보다 적을 수 있어요. KT Cloud 리포트(2025.11)는 이 점을 명확히 짚었는데, 한국어 문서에서는 의미 단위가 청크 경계에 걸쳐 잘리는 빈도가 영어 대비 30% 이상 높다고 분석했어요.
512 vs 1024: 한국어에서 무슨 차이가 생기나요?
한국어 토크나이저와 청크 경계
영어 “retrieval accuracy"는 23개 토큰으로 처리되는 반면, 한국어 “검색 정확도"는 형태소 분리 방식에 따라 47개 토큰이 될 수 있어요. 이 차이가 청크 경계에서 문제를 만들어요.
512 토큰 청크에서는 단일 단락이 두 청크에 걸쳐 잘리는 상황이 자주 생겨요. “A 조건이 충족되는 경우에만 B 절차를 따른다"는 규정 문장이 “A 조건이 충족되는 경우에만"과 “B 절차를 따른다"로 쪼개지면, 양쪽 청크 모두 맥락을 잃게 되죠. “B 절차는 언제 적용되나요?“라고 물었을 때 두 청크 중 하나만 검색돼도 답변이 틀려질 수 있어요.
1024 토큰은 이 문제를 상당 부분 줄여줘요. 단락 전체가 한 청크 안에 들어올 가능성이 높아지니까요. 그러나 길이가 길수록 무관한 정보가 섞일 확률도 올라가요. 벡터 임베딩이 여러 주제의 평균값으로 수렴하면서 검색 정밀도가 떨어지는 거예요.
검색 지표로 본 실험 결과
| 기준 항목 | 512 토큰 | 1024 토큰 | 비고 |
|---|---|---|---|
| Precision (정밀도) | 상대적으로 높음 | 중간 | 짧을수록 노이즈 적음 |
| Recall (재현율) | 낮음 | 높음 | 맥락 보존 유리 |
| 맥락 연속성 (한국어) | 취약 | 양호 | 조사·어미 분절 이슈 |
| 임베딩 품질 | 집중도 높음 | 희석 가능 | 주제 혼합 시 저하 |
| 비용/토큰 소비 | 낮음 | 상대적으로 높음 | Retrieve 수에 따라 변동 |
| 적합 문서 유형 | FAQ, 단문 정책 | 기술 문서, 법령 | 문서 구조에 따라 다름 |
맥락 의존성이 높은 질문 유형(예: “이 조항은 어떤 예외 조건에서 적용되지 않나요?")에서는 1024 토큰이 Recall 기준 약 1823%p 높은 수치를 보였어요. 반면 단문 사실 확인 질문(“이 상품의 가격은?")에서는 512 토큰이 Precision 기준 1015%p 앞섰어요.
오버랩 전략이 판을 바꿔요
512 토큰의 약점을 보완하는 가장 현실적인 방법은 오버랩(overlap)이에요. 인접 청크 간 50~100 토큰을 겹치게 설정하면 경계 잘림 문제를 상당히 완화할 수 있거든요.
KT Cloud 리포트에서도 고정 청크 사이즈보다 오버랩 설정이 검색 품질 변수로 더 큰 영향을 미쳤다는 결과가 나왔어요. 512 토큰 + 128 토큰 오버랩 조합이 오버랩 없는 1024 토큰과 비슷한 Recall을 보인 사례도 있었고요.
문서 유형별로 뭘 써야 하나요?
단일 청크 사이즈로 모든 문서 유형을 커버하려 하면 반드시 성능 저하 구간이 생겨요.
사내 규정/정책 문서: 조항 간 의존성이 높고, 맥락이 끊기면 답변 품질이 급격히 떨어져요. 권장 설정은 1024 토큰 + 128 토큰 오버랩. 단락 경계 기준 분할(Paragraph-aware chunking)을 함께 쓰면 효과가 좋아요.
FAQ/제품 설명서: 각 항목이 독립적이고 단문 위주라 검색 정밀도가 우선이에요. 권장 설정은 512 토큰, 오버랩 최소화(32 토큰 이하). 이 유형에선 256 토큰도 충분히 효과적이에요.
기술 문서/논문: 수식, 코드, 용어 정의가 섞여 맥락이 넓게 퍼져 있어요. 권장 설정은 1024 토큰 + 256 토큰 오버랩. 섹션 헤딩을 메타데이터로 포함해서 검색 시 필터링에 쓰면 정밀도를 보완할 수 있어요.
결론: 숫자 하나보다 전략이 먼저예요
정리하면 이래요.
- 한국어 문서에서 512 토큰은 단락 잘림으로 Recall이 낮아지는 구조적 약점이 있어요
- 1024 토큰은 맥락 보존에 유리하지만 Precision 희석 문제가 따라와요
- 오버랩 설정이 청크 사이즈 선택보다 더 큰 영향을 미칠 수 있어요
- 문서 유형에 따라 동적으로 다른 청크 사이즈를 쓰는 게 단일 설정보다 실질적으로 효과적이에요
앞으로 Anthropic이 컨텍스트 캐싱을 개선하면서 대형 청크의 비용 부담이 줄어들 가능성이 있고, 한국어 특화 임베딩 모델들도 토크나이저 수준에서 형태소를 반영하는 방향으로 발전하고 있어요. 그 시점이 오면 지금의 512 vs 1024 논쟁 자체가 달라질 수도 있어요.
지금 당장 Claude API RAG 파이프라인을 구성하고 있다면, 청크 사이즈 설정 전에 한 가지만 먼저 확인해 보세요. 내 문서에서 “하나의 답"이 몇 줄 안에 있나요, 아니면 단락 전체에 걸쳐 있나요? 그 답이 512와 1024 중 어디로 갈지 가장 빠르게 알려줄 거예요.
참고: KT Cloud 기술 블로그 “AI 검색 증강 생성(RAG) #3: 청킹 전략과 최적화” (2025.11), 갓대희의 작은공간 “Claude Code 1M Context 설정 가이드” (2025)
참고자료
- [Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화
- Claude Code 1M Context 설정 가이드 - beta header 없이 자동 활성화 하기(Claude Code 1M Context 정식 출시) :: 갓대희의 작은공간
Photo by Vitaly Gariev on Unsplash
