Claude Sonnet 4.6 / Opus 4.6 기준
Anthropic 공식 문서 기반
Claude API 프롬프트 캐싱,
비싸지는 조건이 따로 있습니다
결론부터 말씀드리면, 프롬프트 캐싱은 잘 쓰면 비용을 60~90% 줄여주는 기능입니다. 그런데 캐시 설정을 잘못 잡으면 0원 절감에 쓰기 비용만 추가로 내는 구조가 됩니다. 게다가 2026년 3월, Anthropic이 Claude Code의 기본 캐시 유지 시간을 1시간에서 5분으로 조용히 되돌리면서 월 $200 구독자들 사이에서 쿼터 소진 신고가 급증했습니다. 이 글은 공식 가격표와 실제 장애 리포트를 교차해서 확인한 내용입니다.
(base 대비 0.1x)
추가 비용 (base 대비 2x)
캐시 토큰 수
캐시 읽기는 싸지만, 캐시 쓰기는 다릅니다
프롬프트 캐싱을 처음 접하면 “캐시 적용하면 무조건 저렴하다”고 생각하기 쉽습니다. 실제로 캐시에서 읽어오는 비용은 기본 입력 토큰 가격의 0.1배, 즉 90% 절감입니다. 그런데 캐시에 처음 쓰는 비용은 얘기가 다릅니다.
Anthropic 공식 가격표에 따르면, 5분짜리 캐시를 처음 쓸 때는 기본 입력 가격의 1.25배, 1시간짜리 캐시를 처음 쓸 때는 2배가 청구됩니다. Claude Sonnet 4.6 기준으로 숫자를 바꿔보면, 기본 입력이 $3/MTok인데 5분 캐시 쓰기는 $3.75/MTok, 1시간 캐시 쓰기는 $6/MTok입니다. (출처: Anthropic 공식 문서, 2026.04.21 기준)
💡 공식 가격표와 실제 청구 흐름을 같이 놓고 보니 이런 패턴이 보였습니다. 캐시 쓰기가 발생하는 첫 요청에서 비용이 올라가고, 이후 읽기가 충분히 일어나야 전체 평균이 낮아지는 구조입니다. 읽기 횟수가 적으면 쓰기 프리미엄만 내고 끝납니다.
한마디로, 캐싱의 손익분기는 “읽기가 몇 번 발생하느냐”에 달려 있습니다. 5분 캐시는 3회 이상 읽어야 손익분기, 1시간 캐시는 5회 이상 읽어야 본전이 됩니다. 단 한 번 쓰고 다시 읽지 않는 요청에는 캐싱이 오히려 손해입니다.
5분 vs 1시간, 어느 쪽이 유리한지 직접 계산해봤습니다
| 조건 | 5분 캐시 | 1시간 캐시 |
|---|---|---|
| 첫 요청 (쓰기) | $3.75/MTok × 4,000 = $0.015 | $6.00/MTok × 4,000 = $0.024 |
| 이후 1회 읽기 | $0.30/MTok × 4,000 = $0.0012 | $0.30/MTok × 4,000 = $0.0012 |
| 캐시 미사용 시 1회 비용 | $3.00/MTok × 4,000 = $0.012 | |
| 손익분기 (읽기 횟수) | 3회 | 5회 |
(출처: Anthropic 공식 가격표 기준 직접 산출, 2026.04.21)
읽기 횟수가 3회 미만이면 5분 캐시조차 손해입니다. 5분 안에 같은 시스템 프롬프트로 3번 이상 요청하지 않는 서비스라면, 캐싱을 끄고 기본 입력 요금을 내는 게 더 저렴합니다.
💡 1시간 캐시는 쓰기 비용이 2배이기 때문에, “자주 사용하면 사용할수록 이득”이 아니라 “자주 사용할 때만 이득”입니다. 일 1~2회 호출 수준이면 1시간 캐시의 프리미엄을 상쇄하지 못합니다.
캐시가 작동하지 않는 상황들 — 공식 문서에 딱 나와 있습니다
설정을 붙였는데도 캐시가 전혀 동작하지 않는 경우가 있습니다. Anthropic 공식 문서에 정리된 주요 무효화 조건들인데, 실무에서 자주 겪는 패턴들입니다.
첫 번째, 가변 내용이 캐시 구간에 들어가는 경우. 시스템 프롬프트 안에 "현재 시각: 2026-04-21T10:32:00Z"처럼 매 요청마다 바뀌는 값이 포함되면, 해시값이 항상 달라지므로 캐시 히트가 절대로 발생하지 않습니다. 쓰기 비용만 매번 청구됩니다. 마찬가지로 사용자 이름, 세션 ID 같은 사용자별 고유값도 같은 문제를 만듭니다.
두 번째, 도구 정의(tool definition)가 바뀌는 경우. 캐시는 tools → system → messages 순서로 계층이 구성됩니다. 도구 정의를 조금이라도 수정하면 시스템 프롬프트 캐시와 메시지 캐시까지 전부 무효화됩니다. 에이전트 개발 중 툴 스키마를 자주 조정하면서 캐싱을 동시에 기대하는 경우, 두 가지를 병행하기 어렵습니다.
세 번째, 캐시 포인트 위치를 잘못 잡는 경우. cache_control을 고정 내용이 아닌 변경되는 블록에 붙이면, 쓰기는 발생하되 다음 요청에서 읽기는 일어나지 않습니다. 공식 문서에서는 이 경우를 “가장 흔한 실수”로 명시하고 있습니다. 캐시 포인트는 요청 간 내용이 동일하게 유지되는 마지막 블록에 붙여야 합니다. (출처: Anthropic 공식 Prompt Caching 문서)
⚠️ 캐시가 실제로 작동했는지 확인하는 방법은 응답의 usage 객체 안에 있는 cache_creation_input_tokens와 cache_read_input_tokens 값입니다. 두 값이 모두 0이라면 캐싱이 적용되지 않은 것입니다. 최소 토큰 미달이 원인일 가능성이 높습니다.
2026년 3월 Claude Code TTL 변경과 쿼터 소진 사태
2026년 2월 1일경, Anthropic은 Claude Code의 기본 캐시 TTL을 1시간으로 상향했습니다. 그리고 같은 해 3월 7일경, 이를 다시 5분으로 되돌렸습니다. The Register가 2026년 4월 13일 보도한 내용과 GitHub Issues #46829 리포트에 이 과정이 상세히 기록되어 있습니다.
💡 이 흐름을 1월부터 순서대로 정리하니 이런 그림이 나왔습니다. 1시간 TTL → 5분 TTL 전환 이후 쿼터 소진 신고가 급증했고, 이는 TTL 자체의 문제가 아니라 1M 토큰 컨텍스트 창과 캐시 미스가 결합한 결과였습니다.
Anthropic 측 Claude Code 개발자 Boris Cherny는 공개 이슈에서 이렇게 설명했습니다. “1M 토큰 컨텍스트 창을 사용하는 상태에서 1시간 이상 자리를 비운 후 세션을 재개하면, 전체 캐시 미스가 발생한다. 이 경우 비용이 폭발적으로 올라간다.” (출처: GitHub anthropics/claude-code Issues #45756, 2026.04.13) 즉, TTL이 5분이든 1시간이든, 세션이 중단된 상태에서 대용량 컨텍스트를 재로드하면 캐시 미스 비용이 고스란히 청구됩니다.
이에 대한 Anthropic의 대응은 기본 컨텍스트 창을 40만 토큰으로 줄이고, 사용자가 필요 시 1M 토큰으로 옵션을 선택하는 방식입니다. 이미 Claude Code 설정에서 조정이 가능합니다. API를 직접 사용하는 경우라면, 세션 길이와 캐시 TTL의 관계를 설계 단계에서 고려해야 합니다.
| 시기 | 변경 내용 | 영향 |
|---|---|---|
| 2026년 2월 1일 | Claude Code 기본 TTL → 1시간 | 장시간 세션 쿼터 안정 |
| 2026년 3월 7일 | 기본 TTL → 5분으로 롤백 | 쿼터 소진 신고 급증 |
| 2026년 4월 ~ | 컨텍스트 창 기본값 40만 토큰 검토 | 캐시 미스 비용 완화 목적 |
(출처: The Register 2026.04.13, GitHub Issues #46829 & #45756)
모델별 최소 캐시 토큰 — 이 숫자를 놓치면 설정이 무의미합니다
프롬프트 캐싱에는 모델마다 최소 캐시 가능 토큰 수가 설정되어 있습니다. 이 숫자보다 짧은 프롬프트에 cache_control을 붙여도 캐싱이 조용히 무시됩니다. 에러도 반환되지 않습니다.
| 모델 | 최소 캐시 토큰 |
|---|---|
| Claude Opus 4.5 / 4.6 / 4.7 | 4,096 토큰 |
| Claude Sonnet 4.6 | 2,048 토큰 |
| Claude Sonnet 4.5 / 4 / Opus 4.1 / 4 | 1,024 토큰 |
| Claude Haiku 4.5 | 4,096 토큰 |
| Claude Haiku 3.5 | 2,048 토큰 |
(출처: Anthropic 공식 Prompt Caching 문서, 2026.04.21 기준)
여기서 주목할 점이 있습니다. Haiku 4.5는 Sonnet 4.5보다 저렴한 모델인데, 최소 캐시 토큰이 4,096으로 Sonnet 4.5의 4배입니다. 가벼운 작업에 Haiku를 쓰면서 “짧은 시스템 프롬프트도 캐시되겠지”라고 기대하면 틀립니다. Haiku로 캐싱 효과를 보려면 4,000토큰 이상의 프롬프트가 필요합니다.
💡 가격이 싸다고 Haiku를 선택했는데 최소 토큰 조건 때문에 캐싱을 못 쓰는 경우가 생깁니다. 반대로 Sonnet 4.5는 1,024 토큰부터 캐시가 가능하므로, 짧은 시스템 프롬프트를 많이 반복 사용하는 서비스에서는 Sonnet 4.5가 실질 비용이 더 낮게 나올 수 있습니다.
실제로 절약이 일어나는 패턴 3가지
이론보다 실제로 어떤 상황에서 얼마나 줄어드는지를 보는 게 더 빠릅니다. 프로덕션 워크로드를 분석한 외부 사례 3건을 정리했습니다. 모두 Claude Sonnet 4.6 기준입니다. (출처: AI Magicx 프롬프트 캐싱 실사례 분석, 2026.04.17)
고객 지원 챗봇 (일 5만 요청)
시스템 프롬프트 3,200 토큰 + 지식베이스 1.5만 토큰 구성. 캐싱 적용 전 월 $8,820 → 적용 후 월 $3,105. 절감률 65%. 요청이 워낙 많아 캐시 읽기 비율이 99% 이상 확보된 사례입니다.
코드 리뷰 에이전트 (월 800 PR)
Claude Opus 4.6 기준. 시스템 프롬프트 1,800 + PR diff 1.4만 + 코드베이스 5,000 + 도구 정의 7,000 토큰. 캐싱 전 월 $2,190 → 적용 후 $642. 절감률 71%. Opus 계열은 캐시 단가 자체가 높으므로 절감 효과도 비례해 커집니다.
리서치 어시스턴트 (월 1만 세션, 평균 4.5턴)
대화가 누적되면서 후반부엔 4만 토큰까지 증가. 캐싱 전 월 $4,140 → 적용 후 $1,650. 절감률 60%. 대화 이력이 누적되는 멀티턴 구조일수록 뒷부분의 읽기 비용 절감이 커집니다.
세 사례의 공통점은 고정 내용(시스템 프롬프트, 지식베이스, 도구 정의)의 비중이 높고 요청 빈도가 충분하다는 것입니다. 반대로 요청마다 내용이 크게 바뀌거나, 하루에 수십 건 이하로만 호출되는 서비스라면 절감 효과가 훨씬 작을 수 있습니다.
Q&A
Q1. 프롬프트 캐싱을 적용하면 응답 품질이 달라지나요?
달라지지 않습니다. Anthropic 공식 문서에서 “캐시에서 읽은 응답은 캐시가 없을 때와 완전히 동일하다”고 명시하고 있습니다. 출력 토큰 생성 방식 자체는 영향을 받지 않습니다.
Q2. 캐시 포인트를 최대 몇 개까지 설정할 수 있나요?
명시적 캐시 브레이크포인트는 최대 4개까지 허용됩니다. 자동 캐싱과 병행할 경우 자동 캐싱이 슬롯 1개를 차지하므로, 자동 캐싱을 쓰면서 명시적 포인트를 사용한다면 최대 3개입니다. 5개 이상을 설정하면 API가 400 에러를 반환합니다.
Q3. 워크스페이스를 여러 개 운영하면 캐시가 공유되나요?
2026년 2월 5일부터 캐시 격리가 조직 단위에서 워크스페이스 단위로 변경됐습니다. 같은 조직 내 다른 워크스페이스 간에는 캐시가 공유되지 않습니다. Amazon Bedrock, Google Vertex AI는 기존 조직 단위 격리를 유지합니다. (출처: Anthropic 공식 Prompt Caching 문서)
Q4. 이미지가 포함된 프롬프트도 캐시가 가능한가요?
가능합니다. 이미지를 포함한 유저 턴 콘텐츠 블록도 캐시 대상입니다. 단, 이미지를 추가하거나 제거하면 메시지 캐시가 무효화됩니다. 이미지가 고정된 문서 분석 용도에서는 효과적이고, 매 요청마다 이미지가 바뀌는 경우는 캐시 효과가 없습니다.
Q5. 자동 캐싱과 명시적 캐시 브레이크포인트를 병행해도 되나요?
됩니다. 다만 자동 캐싱과 명시적 포인트가 같은 블록에서 다른 TTL을 지정하면 API가 400 에러를 반환합니다. 일반적으로 시스템 프롬프트와 도구 정의에는 명시적 포인트를 쓰고, 대화 이력에는 자동 캐싱을 적용하는 방식이 안정적입니다.
마치며
Claude API 프롬프트 캐싱은 제대로 설계하면 강력한 비용 절감 수단입니다. 다만 “붙이면 줄어든다”는 전제가 틀린 경우가 생각보다 많습니다. 쓰기 비용 구조, 최소 토큰 조건, 캐시 포인트 위치, TTL과 세션 패턴의 조합을 설계 단계에서 고려하지 않으면 비용이 오히려 늘어나거나 아무 효과가 없는 상태가 됩니다.
2026년 3월의 TTL 변경 사태는 이 기능이 아직 설정의 투명성이 충분하지 않다는 점도 보여줬습니다. Anthropic이 현재 컨텍스트 창 기본값 조정을 검토 중이고, 캐시 관련 청구 메트릭 개선도 논의 중인 상황입니다. 당분간 응답의 usage 필드에서 직접 캐시 히트 여부를 확인하고, 히트율이 60% 미만이면 설정을 재검토하는 것이 현실적인 접근입니다.
시작점은 간단합니다. 가장 큰 시스템 프롬프트 하나에 캐시 포인트를 붙이고, 응답 메타데이터에서 실제로 캐시 히트가 발생하는지 먼저 확인해보는 것입니다.
본 포스팅 참고 자료
- Anthropic 공식 Prompt Caching 문서 — https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Anthropic 공식 블로그 Prompt Caching 발표 (2024.08.14, GA 2024.12.17) — https://www.anthropic.com/news/prompt-caching
- The Register — “Claude Code cache chaos creates quota complaints” (2026.04.13) — https://www.theregister.com/2026/04/13/claude_code_cache_confusion/
- GitHub anthropics/claude-code Issues #46829 — Cache TTL regression report — https://github.com/anthropics/claude-code/issues/46829
- AI Magicx — “Prompt Caching for Claude: Cut Your API Bill 60% in Production” (2026.04.17) — https://www.aimagicx.com/blog/prompt-caching-claude-api-cost-optimization-2026
본 포스팅은 2026년 4월 21일 기준 Anthropic 공식 문서와 공개된 GitHub 이슈를 바탕으로 작성됐습니다. Claude API 가격, 캐시 정책, 모델별 사양은 Anthropic의 업데이트에 따라 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 정보는 Anthropic 공식 문서를 직접 확인하시기 바랍니다.
댓글 남기기