Claude API 프롬프트 캐싱, 이 횟수 전엔 손해입니다
프롬프트 캐싱 켜면 바로 저렴해질 거라 생각하셨다면, 잠깐 멈춰야 합니다.
캐시 write 비용은 기본 입력가보다 25% 더 비쌉니다.
같은 캐시를 몇 번이나 read해야 본전인지 — 이걸 모르면 오히려 손해입니다.
캐싱을 켜면 바로 절약된다는 말이 절반만 맞는 이유
Claude API 공식 문서를 보면 프롬프트 캐싱은 “비용을 최대 90% 줄일 수 있다”고 나옵니다. 맞습니다. 그런데 이 문장 앞에 조건이 빠져 있습니다. 캐시를 충분히 많이 읽어야만 절약이 됩니다.
캐시를 저장하는 행위, 즉 cache write는 기본 입력 토큰 가격의 1.25배입니다. Claude Sonnet 4.5 기준 일반 입력이 $3/MTok인데, cache write는 $3.75/MTok입니다. (출처: Anthropic 공식 요금표, platform.claude.com/docs/en/about-claude/pricing)
💡 공식 요금표와 실제 청구 흐름을 같이 놓고 보니 이런 차이가 보였습니다.
캐시 write 자체는 비용이 추가로 발생하는 작업입니다. 캐시를 한 번만 쓰고 아무도 다시 읽지 않으면, write 비용만 남고 절약은 없습니다.
정확히 말하면, 캐싱의 절약 효과는 cache read에서 옵니다. Read는 기본 입력가의 10%입니다. Sonnet 4.5 기준 $0.30/MTok. 이 gap이 얼마나 빠르게 write 비용을 회수하는지가 핵심입니다.
손익분기를 계산할 수 있는 공식
직접 따라서 계산해볼 수 있습니다. Sonnet 4.5 기준으로 설명합니다.
| 항목 | 단가 ($/MTok) | 일반 대비 |
|---|---|---|
| 일반 입력 (Input) | $3.00 | 기준 |
| Cache Write (5분 TTL) | $3.75 | +25% |
| Cache Read | $0.30 | -90% |
| 출력 (Output) | $15.00 | 캐싱 미적용 |
출처: Anthropic 공식 요금표 (platform.claude.com/docs/en/about-claude/pricing)
시나리오: 5,000토큰짜리 시스템 프롬프트를 캐싱하는 경우
📌 캐싱 없이 10회 요청할 때
5,000 토큰 × $3.00/MTok × 10회 = $0.15
📌 캐싱 적용 후 10회 요청할 때
Cache Write 1회: 5,000 × $3.75/MTok = $0.01875
Cache Read 9회: 5,000 × $0.30/MTok × 9회 = $0.0135
합계: $0.03225 → 약 78% 절약
💡 같은 요청을 공식 수치로 직접 계산해보면, read가 9회 이상일 때 78% 절약이 됩니다. 반대로 write 1회 후 read가 1회뿐이라면 캐싱 쪽이 더 비쌉니다.
정확한 손익분기점: cache read 2회 이상이면 캐싱이 유리합니다.
산출 근거: Write $3.75 + Read 1회 $0.30 = $4.05 vs 일반 입력 2회 $6.00. Read 2회 시점부터 총비용이 역전됩니다.
모델별 캐싱 단가 — 선택이 비용을 바꿉니다
같은 캐싱 구조를 써도 모델에 따라 절약 금액의 절대값이 크게 달라집니다. 아래가 2026년 3월 현재 공식 단가입니다.
| 모델 | 일반 입력 | Cache Write | Cache Read | 출력 |
|---|---|---|---|---|
| Opus 4.1 / 4 | $15 | $18.75 | $1.50 | $75 |
| Sonnet 4.5 (≤200K) | $3 | $3.75 | $0.30 | $15 |
| Sonnet 4.5 (>200K) | $6 | $7.50 | $0.60 | $22.50 |
| Haiku 4.5 | $1 | $1.25 | $0.10 | $5 |
출처: Anthropic 공식 요금표 (platform.claude.com/docs/en/about-claude/pricing)
Opus 모델에서 캐싱의 절대 절약액이 가장 큽니다. Read 1회당 $15 → $1.50으로 떨어지니, 100만 토큰 기준으로 회당 $13.50을 아낍니다. 실제 대규모 운영에서는 모델 티어를 내리는 것과 캐싱을 병용하는 쪽이 가장 효율적입니다.
실제로 90%를 절감하는 구조가 따로 있습니다
ksred.com의 8개월간 Claude Code 사용 실측 데이터를 분석하면, 진짜 90% 절감이 어떤 상황에서 나오는지 보입니다. 전체 토큰 약 100억(10B) 중 90% 이상이 cache read 토큰이었습니다. (출처: ksred.com, 2026.02.23)
📊 실측 토큰 분포 (8개월, 약 10B 토큰)
| 토큰 유형 | 비중 | API 환산 비용 |
|---|---|---|
| Cache Read | 약 90%+ | $6,750 |
| Cache Write | 약 6% | $1,500 (추정) |
| Input/Output | 1% 미만 | 잔여 |
출처: ksred.com 실측 분석 (2026.02.23). 비용은 Sonnet 기준 추정치 포함.
Claude Code는 코드베이스 전체를 읽고 파일 구조를 이해하는 작업을 반복합니다. 같은 파일을 여러 번 참조하고, 맥락을 유지하는 과정에서 cache read가 폭발적으로 쌓입니다. 파일 1개를 10번 참조하면 write 1회 + read 9회 → 그게 100개 파일이면 write 100회 + read 900회.
💡 같은 프롬프트 구조를 직접 비교해보면 이런 패턴이 보입니다.
캐싱의 90% 절감은 “단일 요청”이 아니라 반복 참조가 많은 구조에서 나옵니다. RAG 시스템, 긴 시스템 프롬프트, 코드 분석 에이전트가 대표적입니다.
참고로 위 실측에서 Max Plan($100/월) 8개월 비용은 약 $800이었는데, 동일 사용량을 API로 청구했을 때는 $15,000 이상이었습니다. 93% 절약의 핵심은 캐싱 구조였습니다.
TTL 5분 — 이 조건에서 캐싱은 작동하지 않습니다
Anthropic 공식 문서 기준, 프롬프트 캐시의 기본 TTL은 5분입니다. 최대 1시간 TTL 옵션도 있지만, 기본값은 5분입니다. (출처: DigitalOcean/Anthropic 공식 문서, 2026.03.18)
이게 생각보다 짧습니다. 요청 간격이 5분을 넘으면 캐시가 만료되어, 다음 요청에서 다시 write 비용이 발생합니다. 사용자 응답을 기다리거나, 배치 작업 사이에 간격이 있는 경우 캐시가 매번 초기화됩니다.
1시간 TTL 옵션을 사용하면 요청 간격이 길어도 캐시를 유지할 수 있습니다. 단, Amazon Bedrock 경로에서는 2026년 1월부터 1시간 TTL 옵션이 별도 지원됩니다. (출처: AWS, 2026.01.26)
캐싱이 불리해지는 3가지 패턴
캐싱이 무조건 유리한 게 아니라는 걸 공식 수치로 직접 확인했습니다. 아래 3가지 상황에서는 켜지 않는 게 낫습니다.
요청 빈도가 낮은 서비스
하루 수십 건 이하의 저빈도 서비스에서는 TTL 5분이 만료되기 전에 재요청이 오지 않는 경우가 많습니다. Write 비용만 반복적으로 발생하고 Read는 거의 없어 총비용이 올라갑니다.
매 요청마다 시스템 프롬프트가 달라지는 구조
사용자별로 동적으로 시스템 프롬프트가 조립되는 경우, 캐시 prefix가 일치하지 않아 매번 write만 발생합니다. 이 경우 write 25% 추가 비용만 쌓입니다. 캐싱은 앞부분 prefix가 정확히 동일할 때만 작동합니다.
캐시 블록이 1,024 토큰 미만인 경우
Anthropic 공식 최소 캐시 블록은 1,024 토큰입니다. 시스템 프롬프트가 짧거나, 캐싱 대상 구간이 이 기준 미만이면 캐싱 자체가 적용되지 않고 일반 입력으로 처리됩니다. 그런데도 cache_control을 붙이면 write 비용만 발생할 수 있습니다. Anthropic이 공식 답변을 내놓지 않은 부분이지만, 최소 블록 미만 구간은 캐싱 적용 여부를 API 응답의 usage 필드에서 반드시 확인해야 합니다.
자주 묻는 질문
프롬프트 캐싱은 자동으로 켜지나요, 아니면 설정을 해야 하나요?
+
cache_control 파라미터를 붙여야 합니다. OpenAI와 달리 자동으로 적용되지 않습니다. 반면 클로드 콘솔(claude.ai)의 채팅 인터페이스에서는 Anthropic이 내부적으로 캐싱을 적용하지만, API 호출에서는 개발자가 직접 제어해야 합니다.
캐시가 실제로 hit됐는지 어떻게 확인하나요?
+
usage 필드를 확인하면 됩니다. 캐시가 적중됐다면 cache_read_input_tokens 값이 0보다 크게 나옵니다. 처음 write된 경우에는 cache_created_input_tokens가 기록됩니다. 이 두 필드가 별도로 집계되므로 실제 write/read 토큰을 분리해 비용을 추적할 수 있습니다.
캐싱을 적용하면 응답 속도도 빨라지나요?
+
대화 히스토리도 캐싱되나요?
+
Claude Max Plan 구독과 API 캐싱 중 어떤 게 유리한가요?
+
마치며
결론부터 말하면, 프롬프트 캐싱은 무조건 켜는 게 아니라 설계에 맞게 켜야 합니다.
같은 prefix를 하루에도 수십~수백 번 읽는 구조라면 캐싱은 압도적으로 유리합니다. RAG 어시스턴트, 코딩 에이전트, 긴 정책 문서를 기반으로 답변하는 챗봇이 대표적입니다. 반면 요청마다 프롬프트가 조금씩 다르거나, 하루 호출이 50건 이하라면 write 비용이 오히려 고정 오버헤드로 작용합니다.
개인적으로 가장 중요하다고 본 포인트는 TTL 5분입니다. “캐싱을 켰는데 왜 절약이 안 되지?”라고 느끼는 경우 대부분은 이 TTL이 만료된 상황입니다. 실제로 클리앙 커뮤니티에서도 이 문제로 캐싱을 걷어낸 사례가 확인됩니다. 1시간 TTL 옵션 사용 여부를 먼저 체크하시기 바랍니다.
공식 콘솔에서 usage 필드의 cache_read_input_tokens와 cache_created_input_tokens를 직접 모니터링하면서 write/read 비율을 확인하는 것, 이게 캐싱 최적화의 시작입니다.
📎 본 포스팅 참고 자료
- Anthropic 공식 요금표 — platform.claude.com/docs/en/about-claude/pricing
- Anthropic 프롬프트 캐싱 공식 문서 — platform.claude.com/docs/en/build-with-claude/prompt-caching
- DigitalOcean — Prompt Caching for Anthropic and OpenAI Models (2026.03.18)
- ksred.com — Claude Code Pricing Guide 실측 분석 (2026.02.23)
- AWS — Amazon Bedrock 1시간 TTL 프롬프트 캐싱 지원 (2026.01.26)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 수록된 가격 정보는 Claude Sonnet 4.5 기준 2026년 3월 23일 시점의 공식 요금표를 바탕으로 하며, Anthropic의 가격 정책 변경에 따라 달라질 수 있습니다. 최신 정보는 platform.claude.com에서 확인하세요.
댓글 남기기