Claude Sonnet 4.6 / Opus 4.6 기준
TECH
Claude API 프롬프트 캐싱,
90% 절감이 조건이 있습니다
“캐시 읽기는 90% 싸다”는 말은 사실입니다. 그런데 쓰기는 오히려 25% 더 비싸고, 기본 TTL은 5분입니다. 2026년 3월 현재 1M 컨텍스트가 기본 활성화되면서 이 구조가 어떤 결과를 만드는지 공식 요금표와 실제 청구 데이터로 확인했습니다.
캐시 쓰기가 더 비싸다는 게 무슨 뜻인가
Claude API 프롬프트 캐싱을 쓰면 비용이 줄어든다는 말은 캐시가 읽힐 때 맞습니다. 문제는 처음 캐시에 저장할 때입니다. Anthropic 공식 요금표에는 캐시 쓰기(cache write) 비용이 일반 입력 토큰보다 25% 높게 책정돼 있습니다. (출처: anthropic.com/pricing, 2026.03.22 기준)
Sonnet 4.6 기준으로 보면, 일반 입력이 1M 토큰당 $3.00인데 캐시 쓰기는 $3.75입니다. 절감이 아니라 추가 청구입니다. 캐시를 쓰고 나서 그 캐시를 충분히 많이 읽어야만 전체 비용이 줄어드는 구조입니다.
💡 공식 요금표와 실제 청구 내역을 같이 놓고 보니 이런 차이가 보였습니다. 많은 블로그가 “90% 절감”만 언급하지만, 그건 읽기 단가 기준입니다. 쓰기 비용을 합산한 순절감율은 워크로드에 따라 완전히 달라집니다.
캐시 쓰기 1회에 읽기 몇 번이 발생해야 비용이 본전인지 계산하면 이렇습니다. Sonnet 4.6 5분 TTL 기준으로 쓰기 $3.75, 읽기 $0.30이므로, 쓰기 초과분 $0.75(=$3.75−$3.00)를 읽기 절감분 $2.70(=$3.00−$0.30)으로 나누면 읽기가 최소 1.28회 이상 발생해야 손익이 맞습니다. 읽기가 단 1회라도 발생하면 충분히 유리한 구조입니다. 그런데 이 계산이 무너지는 상황이 있습니다.
공식 요금표로 직접 계산해봤습니다
모델별 캐싱 단가 (Anthropic 공식 요금, 2026.03.22 기준)
| 모델 | 일반 입력 ($/MTok) | 캐시 쓰기 ($/MTok) | 캐시 읽기 ($/MTok) |
|---|---|---|---|
| Opus 4.6 (≤200K) | $5.00 | $6.25 | $0.50 |
| Sonnet 4.6 (≤200K) | $3.00 | $3.75 | $0.30 |
| Haiku 4.5 | $1.00 | $1.25 | $0.10 |
| Opus 4.6 (>200K) | $10.00 | $12.50 | $1.00 |
(출처: anthropic.com/pricing — 2026.03.22 직접 확인)
200K 초과 구간에서는 단가 자체가 2배로 오릅니다. 캐시 쓰기는 $12.50/MTok. 1M 컨텍스트를 풀로 사용하면 200K 초과 구간 요금이 적용됩니다. 이걸 모르고 “1M 컨텍스트 쓰면서 캐싱도 하니까 싸다”고 생각하면 계산이 완전히 어긋납니다.
실제 청구 사례를 보면 더 직관적입니다. 하루 10개 에이전트를 돌린 한 개발자의 2026년 2월 19일 하루 Sonnet 4.6 청구 내역입니다. (출처: Reddit r/openclaw, 2026.02.20)
| 토큰 유형 | 사용량 | 단가 | 비용 | 비중 |
|---|---|---|---|---|
| 캐시 쓰기 | 16.7M | $3.75 | $62.64 | 61% |
| 캐시 읽기 | 79.0M | $0.30 | $23.69 | 23% |
| 출력 | 1.07M | $15.00 | $16.02 | 16% |
| 일반 입력 | 16.8K | $3.00 | $0.05 | 0% |
| 합계 | $109 | 100% |
캐시 쓰기가 하루 청구액의 61%를 차지했습니다. 하루 $109 중 $62가 캐시를 “저장”하는 데만 나갔습니다. 이 구조가 나온 이유는 바로 다음 섹션의 TTL 문제입니다.
5분 TTL이 실제로 어떤 문제를 만드는가
자동 갱신처럼 보이지만, 엄밀히 다릅니다
공식 문서에는 “캐시된 콘텐츠를 사용할 때마다 추가 비용 없이 캐시가 갱신된다”고 돼 있습니다. (출처: Claude API Docs — Prompt caching) 즉, 5분 안에 캐시를 읽으면 TTL이 리셋됩니다. 문제는 5분이 지나도록 캐시를 읽지 않으면 캐시가 만료되고, 다음 요청 때 전체 프롬프트를 다시 캐시에 쓰는 비용이 발생한다는 점입니다. 매번 쓰기 요금이 붙습니다.
TTL을 늘리면 쓰기 단가가 2배로 뜁니다
5분이 너무 짧다면 1시간 TTL을 쓸 수 있습니다. 그런데 공식 문서에는 1시간 TTL은 “추가 비용”이 발생한다고 나와 있습니다. 실제로 1시간 TTL 캐시 쓰기 단가는 기본 입력의 2배입니다. (출처: AWS Bedrock 공식 발표, 2026.01.26) 5분 TTL 캐시 쓰기($3.75)도 비싼데, 1시간 TTL이면 Sonnet 4.6 기준 약 $6.00/MTok이 됩니다. 절감을 위해 캐시를 쓰다가 오히려 더 많이 내는 상황이 생깁니다.
💡 “5분이면 충분하다”는 전제는 요청이 5분 간격 이내로 꾸준히 들어오는 워크로드에서만 맞습니다. 배치 처리, 스케줄링 작업, 사용자 세션 중 대기 구간이 있는 서비스는 캐시가 계속 만료되고 쓰기 비용이 중복 발생합니다.
여기에 실측에서 확인된 또 다른 문제가 있습니다. 2026년 2월 GitHub SDK 이슈(#1194)에서 Claude Sonnet 4.6 기준 캐싱 최소 토큰 임계값이 문서(1,024 토큰)와 달리 실제로는 2,048 토큰부터 동작한다는 보고가 제출됐습니다. (출처: anthropic-sdk-python issue #1194, 2026.02.20) Anthropic이 공식 답변을 내놓지 않은 부분입니다.
1M 컨텍스트 기본화 이후 달라진 비용 구조
2026년 3월 13일 기점으로 상황이 바뀌었습니다
Anthropic은 2026년 3월 13일 Opus 4.6 및 Sonnet 4.6의 1M 토큰 컨텍스트 윈도우를 Max·Team·Enterprise 플랜 기본으로 전환했습니다. (출처: Claude Code Changelog v2.1.75, 2026.03.13) 이전에는 별도 설정이 필요했던 기능이 기본값이 됐습니다.
이 변화가 캐싱 비용 구조에 직결됩니다. 대화 세션이 길어지면서 컨텍스트가 900K 토큰에 달했을 때 5분 동안 새 요청이 없으면 어떻게 될까요. 다음 요청 시 900K 토큰 전체가 캐시 미스 상태로 재전송됩니다. (출처: Reddit r/ClaudeCode, 2026.03.14) 900K × $3.75/MTok = 약 $3.38의 비용이 요청 한 번에 발생합니다. 컨텍스트가 클수록, 캐시 미스 1회의 충격이 커집니다.
💡 1M 컨텍스트가 기본화되면서 캐시 쓰기 비용의 절대금액도 커졌습니다. 컨텍스트를 크게 쓸수록 한 번의 캐시 만료가 더 큰 비용을 만들어냅니다. 이 점은 대부분의 캐싱 가이드에서 다루지 않습니다.
200K 초과 구간 요금도 함께 발동됩니다
컨텍스트가 200K를 초과하면 Opus 4.6 기준 입력 단가가 $5.00에서 $10.00으로 오릅니다. 캐시 쓰기는 $6.25에서 $12.50으로 2배가 됩니다. 1M 컨텍스트를 가득 채운 상태에서 캐시 미스가 발생하면 그 충격은 200K 이하 상황의 2배입니다. Claude Code Changelog v2.1.77 기준 Opus 4.6 최대 출력 토큰 한도가 64K로 상향됐고 Sonnet 4.6과 Opus 4.6 모두 128K 상한을 지원합니다. (출처: Claude Code Changelog v2.1.77, 2026.03.17) 더 긴 응답, 더 넓은 컨텍스트 — 비용 관리가 더 중요해진 환경입니다.
경쟁사 캐싱 구조와 비교하면 보이는 것
같은 자동화 워크로드를 다른 공급사로 처리했을 때 얼마나 차이가 나는지 실측 데이터가 있습니다. 위에서 언급한 하루 $109 사례(Sonnet 4.6)에서 동일 토큰 볼륨을 다른 플랫폼으로 재계산했습니다. (출처: Reddit r/openclaw, 2026.02.20)
| 공급사 | 캐시 쓰기 추가 비용 | 최대 TTL | 추정 일일 비용 |
|---|---|---|---|
| Anthropic (Sonnet 4.6) | +25% (5분) / +100% (1시간) | 1시간 | $109 |
| OpenAI GPT-5.1 | 없음 (무료) | 24시간 | 약 $28~41 |
| Google Gemini Flash | 없음 (저장료만) | 직접 설정 | 약 $31 |
OpenAI와 Gemini는 캐시 쓰기에 추가 요금을 부과하지 않습니다. OpenAI는 TTL이 기본 24시간이어서 하루에 한 번만 캐시를 쓰면 됩니다. 비용 절감 효과가 훨씬 직관적입니다. Anthropic 캐싱이 불리하다는 결론이 아닙니다. 단, 워크로드 유형에 따라 다른 공급사가 더 저렴할 수 있다는 점은 직접 계산해봐야 나오는 숫자입니다.
실제로 절감 효과를 내는 워크로드 조건
이 세 가지가 동시에 충족될 때 캐싱이 유리합니다
① 고정 프리픽스가 크고, 요청 빈도가 5분 이내로 꾸준한 경우입니다. RAG 파이프라인처럼 매 요청마다 같은 긴 시스템 프롬프트나 문서를 앞에 붙이는 구조에서 효과가 큽니다. 캐시를 쓰고 나서 5분 안에 읽기가 여러 번 발생하면 쓰기 초과분이 빠르게 회수됩니다.
② 시스템 프롬프트의 크기를 최소화하는 것이 캐싱 비용을 직접 줄입니다. 8K 토큰짜리 SOUL.md를 2K로 줄이면 캐시 쓰기 비용이 약 75% 줄어듭니다. 단순해 보이지만 하루 수십 회 반복되면 월 청구액에서 유의미한 차이가 납니다.
③ 배치 처리와 조합하면 절감율이 더 커집니다. Anthropic 공식 문서에서 배치 처리는 50% 할인을 제공합니다. (출처: anthropic.com/pricing) 배치 처리(50% 할인)와 캐시 읽기(90% 할인)를 동시에 적용하면 조합 절감율이 50~85%에 달할 수 있습니다. 단, 배치 처리는 비동기 처리이므로 실시간 응답이 필요한 서비스에는 적용할 수 없습니다.
💡 반대로 캐싱이 불리한 조건도 있습니다:
- 요청 사이 간격이 5분을 넘는 경우 (하트비트, 크론잡)
- 컨텍스트가 매 요청마다 크게 바뀌는 경우
- 1M 컨텍스트 대부분을 채운 상태에서 대기 구간이 있는 경우
- 캐시 최소 임계값(Sonnet 4.6 실측 기준 약 2,048 토큰) 미만 프리픽스
Q&A
캐시 쓰기가 일반 입력보다 25% 비싼데, 그러면 캐싱을 안 쓰는 게 나을까요?
아닙니다. 쓰기 1회 후 캐시를 2회 이상 읽으면 순비용은 캐싱 없이 매번 전체 입력을 보내는 것보다 저렴합니다. 단, 캐시를 쓰고 나서 5분 안에 사용하지 않으면 쓰기 비용만 지불하고 이점 없이 끝납니다. 워크로드 패턴 확인이 먼저입니다.
1시간 TTL과 5분 TTL, 어떤 상황에서 각각 더 유리한가요?
5분 TTL은 쓰기 비용이 +25%이고, 1시간 TTL은 +100%입니다. 5분 안에 여러 요청이 몰리는 워크로드라면 5분 TTL이 더 저렴합니다. 요청이 15~60분 간격으로 드문드문 들어오는 경우엔 1시간 TTL이 나을 수 있지만, 쓰기 단가가 2배라는 점을 감안하고 계산해야 합니다.
1M 컨텍스트를 기본으로 쓰면 캐싱 비용이 얼마나 커지나요?
Opus 4.6 기준, 컨텍스트가 200K를 초과하면 캐시 쓰기 단가가 $6.25에서 $12.50으로 오릅니다. 900K 세션에서 캐시 미스가 1회 발생하면 약 $11.25의 쓰기 비용이 순간적으로 발생합니다. 컨텍스트가 클수록 캐시 관리(수동 압축, 세션 분리)가 더 중요해집니다.
배치 처리와 캐싱을 동시에 쓸 수 있나요?
공식 문서 기준으로 배치 처리(50% 할인)와 프롬프트 캐싱은 별개의 기능이며 조합이 됩니다. (출처: anthropic.com/pricing) 배치 처리 내 캐시 읽기가 발생하면 캐시 읽기 단가(90% 할인)가 추가 적용됩니다. 단, 배치 처리는 비동기이므로 최대 24시간 지연이 발생할 수 있습니다.
캐싱 적용 여부를 API 응답에서 확인하는 방법이 있나요?
네. API 응답의 usage 필드에 cache_creation_input_tokens와 cache_read_input_tokens 값이 반환됩니다. 두 값이 모두 0이면 캐싱이 적용되지 않은 것입니다. GitHub SDK 이슈 #1194에서 확인된 것처럼, 프리픽스가 실제로 임계값을 충족하는지 이 필드로 직접 확인하는 것이 안전합니다.
마치며
Claude API 프롬프트 캐싱은 제대로 쓰면 비용을 크게 줄여주는 기능입니다. 그런데 공식 문서만 읽고 “캐시 읽기가 90% 싸다”는 것만 기억하면 쓰기 비용, TTL, 컨텍스트 규모라는 세 가지 변수를 빠뜨리게 됩니다.
솔직히 말하면, 5분 TTL이 기본인 상태에서 1M 컨텍스트까지 기본 활성화된 지금 환경은 부주의하게 쓰면 오히려 비용이 늘어나는 구조입니다. 배치 처리, 수동 컴팩션, 시스템 프롬프트 경량화처럼 작지만 유효한 조절을 같이 쓰는 쪽이 실제 청구액을 관리하는 데 더 효과적입니다.
1시간 TTL의 존재, 200K 초과 구간의 요금 점프, Sonnet 4.6의 실측 최소 임계값 이슈까지 — 공식 문서에 흩어져 있는 내용을 한 번에 확인하고 싶다면 Anthropic 공식 Prompt caching 문서에 직접 들어가보는 게 좋습니다. 이 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다.
📎 본 포스팅 참고 자료
- Anthropic 공식 요금표 — anthropic.com/pricing (2026.03.22 기준)
- Claude API 공식 프롬프트 캐싱 문서 — platform.claude.ai/docs
- Claude Code 공식 Changelog — code.claude.com/docs/en/changelog
- AWS Bedrock 1시간 TTL 캐싱 공식 발표 — aws.amazon.com (2026.01.26)
- GitHub SDK 이슈 #1194 (캐싱 임계값 불일치) — github.com/anthropics (2026.02.20)
- GitHub Claude Code 이슈 #29000 (할당량 비정상 소비) — github.com/anthropics (2026.02.26)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 수치는 2026.03.22 기준 Anthropic 공식 요금표 및 공개된 GitHub 이슈 데이터를 바탕으로 작성했습니다. 최신 정보는 anthropic.com/pricing에서 직접 확인하세요.
댓글 남기기