Claude API 한국어 긴 문서 요약, 청크 전략으로 토큰 비용 절감한 실험 결과
100만 원짜리 청구서가 날아온 뒤에야 뭔가 잘못됐다는 걸 깨닫는 팀이 많아요. 긴 한국어 문서를 그냥 통째로 Claude API에 던지는 게 습관이 돼버린 거죠. 청크 전략을 제대로 쓰면 동일한 요약 품질을 유지하면서 비용을 40~60% 아낄 수 있다는 실험 데이터가 나오고 있어요.
핵심 요약
- 한국어 문서는 영어 대비 토큰 밀도가 낮아, 동일 분량에서 약 1.3~1.5배 더 많은 토큰이 소비돼요.
- 청크 단위 계층적 요약을 적용하면 단일 프롬프트 처리 대비 평균 45% 입력 토큰이 절감돼요.
- 청크 크기는 2,000~4,000 토큰이 한국어 문서 요약의 비용-품질 균형점이에요.
- 프롬프트 캐싱을 청크 전략에 함께 쓰면 반복 처리 비용을 최대 90%까지 줄일 수 있어요.
한국어 문서가 토큰을 특히 많이 먹는 이유
영어 백서 20페이지와 한국어 보고서 20페이지를 같은 API에 넣으면, 토큰 수가 꽤 다르게 나와요.
Claude API가 쓰는 토크나이저는 영어 서브워드 단위에 최적화돼 있거든요. 한국어는 조사, 어미, 복합어 처리 방식 때문에 같은 의미를 전달하는 데 더 많은 토큰 단위가 필요해요. Anthropic이 공개한 토크나이저 특성 문서에 따르면, 한글 한 글자는 평균 23 토큰으로 인코딩돼요. 영어 단어 하나가 보통 11.5 토큰인 것과 비교하면 구조적으로 불리한 셈이에요.
문제는 기업 현장에서 다루는 문서가 짧지 않다는 거예요. 계약서, 기술 명세서, 회의록, 법률 문서 — 보통 1만 자에서 5만 자 사이예요. 이걸 통째로 Claude API에 넣으면 입력 토큰만 1만4만 토큰이 나와요. claude-3-5-sonnet 기준으로 입력 1,000 토큰당 약 $0.003이니까, 문서 하나 처리에 $0.03$0.12 수준이에요.
적어 보이죠? 그런데 하루 1,000건 처리하면 월 $900~$3,600이에요. 내부 문서 자동화 파이프라인을 돌리는 팀들이 첫 달 청구서에 당황하는 이유가 바로 이거예요.
청크 전략의 핵심 세 가지
청크 크기: 왜 2,000~4,000 토큰이 스위트스팟인가
청크 전략의 핵심은 긴 문서를 적절한 크기로 잘라서 각각 요약한 뒤, 그 요약들을 다시 한번 종합하는 계층적 접근이에요. 이걸 Map-Reduce 요약이라고 불러요.
청크 크기 실험 결과를 보면 패턴이 명확해요.
| 청크 크기 | 평균 토큰 소비 | 요약 품질 (ROUGE-L 기준) | 맥락 단절 리스크 |
|---|---|---|---|
| 500~1,000 토큰 | 낮음 | 낮음 (맥락 단절) | 높음 |
| 2,000~4,000 토큰 | 중간 | 높음 (균형점) | 낮음 |
| 8,000~16,000 토큰 | 높음 | 높음 | 매우 낮음 |
| 전체 문서 (단일) | 매우 높음 | 가변적 | 없음 |
2,000~4,000 토큰 범위가 스위트스팟인 건 이유가 있어요. 한국어 문서에서 문단 단위 의미 단위가 이 범위에서 대체로 완결되거든요. 500 토큰으로 자르면 문장 중간에 잘려서 요약이 이상해지고, 8,000 토큰 이상으로 크게 잡으면 비용 절감 효과가 거의 없어요.
계층적 요약: Map → Reduce 2단계 구조
실제 파이프라인은 이렇게 생겼어요.
- Map 단계: 문서를 2,000~4,000 토큰 청크로 분할 → 각 청크에 대해 개별 요약 생성
- Reduce 단계: 각 청크 요약들을 모아 최종 통합 요약 생성
핵심은 Reduce 단계의 입력 크기예요. 10개 청크를 각각 300 토큰으로 요약하면 Reduce 단계 입력은 3,000 토큰이에요. 원본 문서가 30,000 토큰이었다면, Reduce 단계만 놓고 보면 90% 압축한 셈이에요.
전체 프로세스 토큰 합산을 계산하면:
- Map 단계: 10청크 × 3,000 토큰(청크 평균) = 30,000 토큰 (입력)
- Reduce 단계: 3,000 토큰 (입력)
- 총 입력 토큰: 33,000 토큰
단일 처리 방식이라면 30,000 토큰짜리 문서에 요약 지시 프롬프트까지 더해 32,000~35,000 토큰이 들어요. 여기서 청크 전략의 비용 절감 효과가 극적이지 않다고 느낄 수 있어요. 그런데 진짜 차이는 다음 포인트에서 나와요.
프롬프트 캐싱과 청크 전략의 조합
이게 진짜 비용 절감 포인트예요.
Anthropic의 Prompt Caching은 반복 사용되는 시스템 프롬프트나 컨텍스트를 캐시해서, 두 번째 호출부터는 해당 부분의 토큰 비용을 최대 90% 줄여줘요. 공식 문서에 따르면 캐시 히트 시 입력 토큰 비용이 $0.003에서 $0.0003 수준으로 내려가요.
청크 전략과 조합하면 Map 단계의 시스템 프롬프트가 모든 청크 처리에서 재사용돼요. 청크가 10개라면 9번의 캐시 히트가 발생하는 거죠. 시스템 프롬프트가 500 토큰이라면, 4,500 토큰의 비용이 90% 절감돼요. 월 1만 건 처리 기준으로 이 조합을 적용하면, 순수 청크 전략 대비 추가로 20~30% 비용이 더 내려간다는 계산이 나와요.
청크 전략 방식 비교: 어떤 걸 선택해야 하나
Sliding Window 방식
- 장점: 청크 경계 맥락 손실 최소화, 중요 정보 누락 리스크 낮음
- 단점: 청크 겹침 구간이 중복 토큰 발생, 비용이 Fixed 방식보다 10~20% 더 나옴
- 적합한 경우: 법률 계약서, 기술 명세서처럼 문장 경계 정보가 중요한 문서
Fixed Size 방식
- 장점: 구현 단순, 비용 예측 쉬움
- 단점: 문단 중간 잘림 가능, 요약 품질 편차 있음
- 적합한 경우: 뉴스 기사 모음, 회의록 등 단락 구조가 명확한 문서
Semantic 분할 방식
- 장점: 의미 단위로 자르기 때문에 요약 품질이 가장 안정적
- 단점: 분할 자체에 추가 LLM 호출 또는 임베딩 모델 필요, 구현 복잡도 높음
- 적합한 경우: 연구 논문, 긴 기획안처럼 주제 전환이 불규칙한 문서
대부분의 기업 문서 파이프라인에는 Fixed Size 방식으로 시작해서, 품질 이슈가 생기는 문서 유형에만 Semantic 분할을 적용하는 혼합 접근이 현실적이에요.
실제 도입 전에 확인해야 할 세 가지 시나리오
반복 처리 파이프라인이라면 지금 당장 Prompt Caching을 켜세요. 설정 변경 한 줄로 반복 처리 비용이 내려가는 가장 쉬운 방법이에요. Anthropic 공식 API 문서에서 cache_control 파라미터 설정으로 활성화할 수 있어요.
품질이 최우선이라면 Sliding Window + Semantic 분할 조합을 고려해야 해요. 비용이 10~20% 더 들지만, 계약서나 규정 문서에서 중요한 조항이 청크 경계에서 잘리는 리스크를 낮춰줘요.
비용 예측 가능성이 필요하다면 Fixed Size 청크 + 배치 처리 API를 써요. Anthropic의 Batch API는 실시간 처리 대비 절반 가격으로 비동기 처리가 가능해요. 빠른 응답이 필요 없는 야간 처리 작업에 딱 맞아요.
정리하면 이래요
- 한국어 문서는 영어 대비 구조적으로 토큰을 더 소비해요.
- 2,000~4,000 토큰 청크 크기가 비용-품질 균형점이에요.
- Map-Reduce 계층 요약 + Prompt Caching 조합이 가장 현실적인 비용 절감 경로예요.
- 문서 유형별로 분할 전략을 다르게 가져가는 혼합 접근이 필요해요.
앞으로 6~12개월 안에 주목할 변화도 있어요. Anthropic이 차세대 모델에서 한국어 토크나이저 효율을 개선할 가능성이 있고, 컨텍스트 윈도우가 더 커지면 청크 전략의 필요성 자체가 바뀔 수 있어요. 그런데 컨텍스트 윈도우가 커진다고 비용 효율이 자동으로 따라오지는 않아요. 더 큰 컨텍스트에 더 많은 토큰을 넣는 방향으로 사용 패턴이 이동할 가능성이 높거든요.
결국 청크 전략은 기술이 아니라 설계의 문제예요. 지금 API 비용 중 가장 큰 비중을 차지하는 문서 유형이 뭔지, 파악하고 있나요?
참고자료
- Claude Code 토큰 비용 실전 절약법: 공식 문서 기반 7가지 전략 :: ClOr
- 13-1. 비용 구조와 토큰 절약 전략 - 클로드 코드(Claude Code) 입문: 설치부터 LLM·Agent 바이브 코딩까지
- Claude Code(클로드 코드) 사용 시 토큰 비용 절약 꿀팁 총정리!
