Claude Sonnet 4.6 / Opus 4.6
TECH
Claude API 프롬프트 캐싱, 실제로 재봤습니다 — 비용은 10분의 1
캐시 읽기는 기본 토큰 비용의 10%. 하지만 브레이크포인트 하나 잘못 놓으면 매 요청마다 1.25배 비용을 내면서 단 한 번도 캐시 혜택을 못 받습니다. 공식 문서 수치와 실제 실수 패턴을 같이 놓고 봤습니다.
(기본 대비)
절감 가능
토큰 (Sonnet 4.6)
유지 시간
캐시 읽기는 기본 요금의 10% — 공식 요금표로 직접 확인
결론부터 말씀드리면, Claude API 프롬프트 캐싱에서 가장 중요한 숫자는 딱 하나입니다. 캐시 읽기(Cache Hit) 비용은 기본 입력 토큰 단가의 0.1배입니다. Anthropic 공식 문서 요금 표에 이렇게 나옵니다. (출처: Anthropic 공식 문서 — Prompt Caching Pricing, 2026.03.25 기준)
| 모델 | 기본 입력 | 5분 캐시 쓰기 | 1시간 캐시 쓰기 | 캐시 읽기 | 출력 |
|---|---|---|---|---|---|
| Claude Opus 4.6 | $5 / MTok | $6.25 / MTok | $10 / MTok | $0.50 / MTok | $25 / MTok |
| Claude Sonnet 4.6 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $1.25 / MTok | $2 / MTok | $0.10 / MTok | $5 / MTok |
실제 숫자로 보면 감이 더 옵니다. Claude Sonnet 4.6 기준, 동일한 100만 토큰을 매 요청마다 보내면 $3가 들지만 캐시로 읽으면 $0.30입니다. 요청이 100번이면 $297 차이가 납니다. 이 비율이 모든 모델에서 동일하게 적용됩니다. 멀티플라이어가 일관적이라는 점이 실무에서 비용 예측을 쉽게 만들어 줍니다.
💡 공식 문서와 실제 API 응답을 같이 놓고 보니 이런 패턴이 보였습니다.
캐시 히트 여부는 응답의 usage.cache_read_input_tokens 필드로만 확인 가능합니다. 이 값이 0이면 히트가 없었다는 뜻이고, 비용은 기본 단가 그대로 청구됩니다.
그런데 ‘캐시 쓰기’는 오히려 비쌉니다
캐시 읽기가 싸다는 건 알겠는데, 첫 번째 요청에서 캐시에 내용을 저장할 때는 돈이 더 나갑니다. 공식 요금 구조를 보면 멀티플라이어가 이렇게 정해져 있습니다. (출처: Anthropic 공식 문서, 2026.03.25 기준)
- 5분 캐시 쓰기: 기본 입력 단가 × 1.25 (25% 할증)
- 1시간 캐시 쓰기: 기본 입력 단가 × 2.0 (100% 할증)
- 캐시 읽기(히트): 기본 입력 단가 × 0.1 (90% 할인)
여기서 실질적인 손익분기 계산을 해볼 수 있습니다. 캐시를 한 번 쓰고 나서 몇 번의 히트가 나와야 본전인지 직접 따져보겠습니다.
📊 5분 캐시 손익분기 계산식
– 캐시 없이 1회 호출: 기본 단가 × 1.0
– 캐시 쓰기 1회 + 히트 N회: 1.25 + (0.1 × N)
– 손익분기: 1.25 + (0.1 × N) < (N+1) × 1.0
→ N = 1 (히트가 단 1번만 나와도 기본 2회 호출보다 저렴)
5분 캐시: 쓰기 비용 1.25 + 읽기 비용 0.1 = 1.35 < 동일 내용 2회 호출 비용 2.0
5분 캐시는 히트 1번만 나와도 2회 호출보다 저렴합니다. 반면 1시간 캐시는 히트가 최소 2번 이상 나와야 본전입니다. 쓰기 단가가 2.0배이기 때문입니다. (1시간 내 재호출이 1번뿐인 상황에선 일반 2회 호출보다 비용이 더 많이 나올 수 있습니다.)
브레이크포인트 위치가 핵심입니다 — 이 실수를 합니다
프롬프트 캐싱을 켜도 실제 비용이 줄지 않는 경우가 있습니다. 브레이크포인트를 매 요청마다 바뀌는 블록에 붙이는 경우입니다. Claude API 공식 문서에 이 패턴이 “Common mistake”로 명시돼 있습니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
❌ 이렇게 하면 매번 쓰기 비용(1.25x)만 냅니다
시스템 프롬프트 5개 블록(고정) + 타임스탬프+메시지(매번 변경) → 마지막 변경 블록에 cache_control 부착
→ 매 요청마다 해시가 달라져 캐시 미스 → 쓰기 비용만 계속 발생
✅ 고정 내용의 마지막 블록에 붙여야 합니다
시스템 프롬프트 5개 블록 → 5번째 블록에 cache_control 부착 → 타임스탬프+메시지는 캐시 범위 밖
→ 고정 prefix 해시가 매번 동일 → 캐시 히트 발생
캐시 내부 작동 원리를 보면 이유가 명확합니다. 캐시 키는 브레이크포인트까지의 전체 내용을 해시로 만든 값입니다. 타임스탬프처럼 매번 바뀌는 내용이 포함되면 해시가 달라지고, 쓰기만 반복되고 읽기는 한 번도 안 됩니다.
또 하나의 실수 패턴: tools → system → messages 처리 순서를 모르고 브레이크포인트를 system 메시지에만 붙이는 경우입니다. 도구 정의가 15개 있다면, 시스템 프롬프트만 캐시해도 도구 15개는 매 요청마다 재처리됩니다. 가장 효율적인 위치는 마지막 도구 정의 블록입니다. (출처: dev.to/yurukusa, 2026.03.20)
1,024토큰 미만이면 에러도 없이 아무것도 안 됩니다
프롬프트 캐싱을 쓰다 보면 마주치는 조용한 실수가 있습니다. 캐시할 내용이 최소 토큰 기준을 넘지 않으면 API는 오류를 반환하지 않고 그냥 캐싱을 건너뜁니다. Anthropic 공식 문서에 이렇게 적혀 있습니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
| 모델 | 최소 캐싱 토큰 |
|---|---|
| Claude Opus 4.6 | 4,096 토큰 |
| Claude Sonnet 4.6 | 2,048 토큰 |
| Claude Sonnet 4.5 / Opus 4.1 / Opus 4 | 1,024 토큰 |
| Claude Haiku 4.5 | 4,096 토큰 |
특히 Claude Opus 4.6와 Haiku 4.5는 4,096토큰이 기준입니다. 짧은 시스템 프롬프트에 cache_control을 붙여도 캐싱이 되지 않고, 요금도 아끼지 못하면서 캐시 쓰기 비용(1.25배)만 냅니다. 캐싱이 실제로 작동하는지 확인하는 방법은 응답에서 cache_creation_input_tokens 값을 보는 것입니다. 이 값이 0이면 캐시가 저장되지 않은 것입니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다.
Opus 4.6의 최소 기준(4,096)은 이전 세대 Sonnet류(1,024)보다 4배 높습니다. 고성능 모델일수록 캐싱 오버헤드가 크기 때문으로 보이는데, Anthropic이 공식 답변을 내놓지 않은 부분입니다. 도구 정의와 시스템 프롬프트를 합산해 기준 토큰을 넘기는 전략이 필요합니다.
5분 캐시 vs 1시간 캐시 — 비용 계산식으로 비교
5분 캐시와 1시간 캐시를 선택할 때 기준은 단순합니다. 공식 문서 기준으로 TTL 선택 전략을 정리하면 이렇습니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
| 구분 | 5분 캐시 | 1시간 캐시 |
|---|---|---|
| 쓰기 배율 | × 1.25 | × 2.0 |
| 읽기 배율 | × 0.1 | × 0.1 |
| 손익분기 히트 횟수 | 1회 | 2회 |
| 자동 갱신 | 히트 시마다 갱신 | 히트 시마다 갱신 |
| 적합한 상황 | 분당 1회 이상 호출 | 15~60분 간격 호출 |
공식 문서의 핵심 설명이 있습니다. 5분 캐시는 히트가 발생할 때마다 TTL이 갱신됩니다. 즉, 5분에 한 번 이상 호출되는 상황이라면 캐시가 사실상 무기한 유지됩니다. 1시간 캐시가 필요한 경우는 호출 간격이 5분을 초과하지만 1시간 이내인 경우로 한정됩니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
💡 Claude Sonnet 4.6 기준, 100만 토큰 규모의 긴 문서를 시스템 프롬프트에 넣고 100회 반복 쿼리한다면:
캐싱 없음: 100회 × $3/MTok = $300
5분 캐싱 (첫 쓰기 1회 + 히트 99회): $3.75 + (99 × $0.30) = $33.45
절감액: 약 $266.55 (약 89% 절감)
2026년 2월부터 캐시가 워크스페이스 단위로 분리됐습니다
멀티팀 환경에서 Claude API를 쓴다면 2026년 2월 5일 이후 달라진 부분이 있습니다. 캐시 격리 단위가 Organization(조직) 수준에서 Workspace(워크스페이스) 수준으로 변경됐습니다. 이 변경 사항은 공식 문서 “Cache Storage and Sharing” 섹션에 명시돼 있습니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
| 시나리오 | 캐시 공유 여부 |
|---|---|
| 동일 워크스페이스 내 다른 API 키 | 공유됨 |
| 동일 Organization, 다른 워크스페이스 | 공유 안 됨 |
| 다른 Organization 간 | 완전 분리 |
| AWS Bedrock (별도 구조) | Organization(AWS Account) 단위 유지 |
이전에는 같은 조직 내 여러 워크스페이스가 동일한 캐시를 공유했습니다. 이제는 워크스페이스별로 완전히 분리됩니다. 여러 프로젝트에서 동일한 대규모 시스템 프롬프트를 쓰고 캐시를 공유하려면 같은 워크스페이스로 묶어야 합니다. 워크스페이스를 분리해 두면 동일한 내용의 캐시 쓰기가 각각 발생합니다. 비용 계획이 달라질 수 있는 변경입니다.
💡 이 부분은 기존 블로그 대부분이 다루지 않은 포인트입니다. 2026.02.05 이전 자료를 참고하면 Organization 단위로 공유된다고 나오는데, 지금은 다릅니다. AWS Bedrock은 여전히 Organization(AWS Account) 단위를 유지하므로 플랫폼에 따라 동작이 다릅니다.
자동 캐싱(Automatic Caching)이 생겼습니다 — 그래도 함정이 있습니다
2026년 초 Anthropic은 자동 캐싱(Automatic Caching) 기능을 API에 추가했습니다. 요청 최상위 레벨에 cache_control 필드 하나만 넣으면 시스템이 알아서 마지막 캐시 가능한 블록에 브레이크포인트를 적용합니다. 멀티턴 대화에서 대화 내역이 늘어날 때 매 요청마다 브레이크포인트를 수동으로 옮기지 않아도 됩니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
그런데 자동 캐싱도 같은 함정이 있습니다. 마지막 캐시 가능한 블록이 타임스탬프나 요청마다 달라지는 내용을 포함하면, 자동 캐싱도 매 요청에서 캐시 미스가 발생합니다. 이 경우 공식 문서는 “명시적 브레이크포인트를 고정 prefix 끝에 배치하라”고 권장합니다. 편의를 위해 자동 캐싱만 믿고 브레이크포인트 위치를 신경 쓰지 않으면 오히려 비용이 늘어납니다.
📋 자동 캐싱 사용 시 체크리스트
- 마지막 캐시 가능 블록이 매 요청마다 동일한가?
- 명시적 브레이크포인트가 이미 4개 있으면 자동 캐싱은 400 오류를 반환함
- 자동 캐싱과 명시적 브레이크포인트를 함께 쓸 때, 자동 캐싱이 슬롯 1개를 차지함
- 캐시 히트 확인은
usage.cache_read_input_tokens값으로 직접 확인할 것
Thinking 블록(Extended Thinking)은 cache_control을 직접 붙일 수 없습니다. 단 tool 결과와 함께 이전 대화 내역에 포함될 때 자동으로 캐시됩니다. 이 경우에도 캐시 읽기 시 입력 토큰으로 카운트됩니다. 비용 계산 시 이 부분을 누락하면 예상보다 청구액이 커질 수 있습니다.
Q&A
Q1. cache_control을 붙였는데 응답 속도가 그대로입니다. 왜일까요?
캐시가 실제로 히트됐는지 확인이 먼저입니다. 응답의 usage.cache_read_input_tokens가 0이면 히트 없이 전체 토큰을 다시 처리한 것입니다. 최소 토큰 기준 미달, 브레이크포인트 위치 오류, 캐시 유효시간(5분) 초과 중 하나일 가능성이 높습니다.
Q2. 5분 캐시와 1시간 캐시를 같은 요청에 섞어 쓸 수 있나요?
공식적으로 가능합니다. 단, 순서 제약이 있습니다. 1시간 캐시 블록이 5분 캐시 블록보다 앞에 있어야 합니다. 반대로 배치하면 API가 400 오류를 반환합니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
Q3. 다른 API 키에서 동일한 프롬프트를 보내면 캐시가 공유되나요?
같은 Workspace 내 API 키라면 공유됩니다. 다른 Workspace에 속하면 공유되지 않습니다. 2026년 2월 5일부로 격리 단위가 Workspace로 변경됐습니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
Q4. Batch API와 프롬프트 캐싱을 함께 쓸 수 있나요?
공식 문서에 따르면 캐싱 멀티플라이어는 Batch API 할인과 중첩 적용됩니다. 즉 Batch 할인(50%) 위에 캐시 읽기(0.1배)가 적용됩니다. 비용 최적화가 필요한 대량 처리 상황에서 효과적인 조합입니다. (출처: Anthropic 공식 Prompt Caching 문서, 2026.03.25 기준)
Q5. 캐시를 수동으로 삭제할 수 있나요?
현재는 수동 삭제 기능이 없습니다. 캐시는 TTL(5분 또는 1시간)이 지나면 자동 만료됩니다. 캐시를 무효화하려면 브레이크포인트 이전 내용 중 하나를 변경하면 됩니다. 변경 즉시 해시가 달라져 캐시 미스가 발생하고 새 캐시가 기록됩니다.
마치며
Claude API 프롬프트 캐싱은 제대로 쓰면 확실히 비용을 줄여줍니다. 캐시 읽기가 기본 단가의 10%라는 수치는 실제로 강력합니다. 다만 캐싱을 켜는 것 자체가 비용 절감을 보장하지 않습니다. 브레이크포인트 위치, 최소 토큰 기준, TTL 선택, 워크스페이스 구조 — 이 네 가지가 맞아떨어져야 실제로 절감됩니다.
직접 써보면서 느낀 건, 가장 많이 놓치는 부분이 브레이크포인트 위치입니다. 변하는 내용 뒤에 붙이면 매번 쓰기 비용만 내고 히트는 한 번도 안 납니다. 공식 문서에 “Common mistake”로 올라와 있는 케이스인데, 실제로 이 실수를 하는 사례가 꽤 많습니다. 캐싱 적용 전 응답의 usage 필드를 반드시 모니터링하는 것이 현실적인 첫 번째 단계입니다.
2026년 2월 워크스페이스 단위 격리 변경도 멀티팀 환경에서 실제 비용 차이를 만드는 포인트입니다. 이전 자료를 그대로 참고하면 캐시 공유가 된다고 나오지만, 지금은 다릅니다. 공식 문서를 직접 확인하는 습관이 필요합니다.
본 포스팅 참고 자료
- Anthropic 공식 Prompt Caching 문서 — https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Anthropic 공식 Models Overview — https://docs.anthropic.com/en/about-claude/models/overview
- Anthropic 공식 API Pricing — https://docs.anthropic.com/en/about-claude/pricing
- I Was Caching Wrong This Whole Time (dev.to/yurukusa, 2026.03.20) — https://dev.to/yurukusa/i-was-caching-wrong-this-whole-time
- Mastering 3 Core Mechanisms of Claude API Caching Billing (blog.wentuo.ai, 2026.03.07) — https://blog.wentuo.ai/en/claude-api-prompt-caching-pricing-5min-1hour-aws-bedrock-guide-en.html
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 모든 요금 수치는 2026.03.25 기준 Anthropic 공식 문서를 참조했습니다. Claude API는 업데이트로 인해 요금 구조, 최소 캐싱 토큰 기준, 워크스페이스 격리 정책 등이 변경될 수 있으므로 반드시 최신 공식 문서를 함께 확인하세요.
댓글 남기기