Claude 프롬프트 캐싱, 2번째 요청부터 아낍니다
Anthropic이 공식 발표한 “최대 90% 절감”은 맞습니다. 그런데 이 수치에는 전제 조건이 있습니다. 5분 안에 다음 요청을 보내야 하고, 캐시 쓰기 비용은 기본 입력 단가의 1.25배가 붙습니다. 첫 번째 요청만 보내고 끝내면 오히려 더 비쌉니다.
프롬프트 캐싱이 실제로 어떻게 작동하는가
Claude API는 요청을 보낼 때마다 시스템 프롬프트, 도구 정의, 대화 이력 전체를 함께 전송합니다. 긴 문서를 참조하는 코딩 어시스턴트라면 요청 한 번에 50,000~200,000 토큰이 들어가는 일도 생깁니다. 프롬프트 캐싱은 이 반복 전송 비용을 줄이는 기능입니다.
원리는 접두사 일치(prefix matching)입니다. Anthropic 서버가 이전 요청에서 처리한 내용 중 현재 요청과 앞부분이 동일한 구간을 찾아내, 그 구간의 연산 결과를 재사용합니다. 이렇게 저장된 구간을 읽어 오는 비용은 일반 입력 단가의 10% — 즉 90% 절감입니다.
(출처: Anthropic 공식 블로그 “Prompt Caching with Claude”, claude.com/blog/prompt-caching)
그런데 처음 캐시를 저장할 때는 반대로 비용이 추가됩니다. 5분 TTL 기준으로 기본 입력 단가의 1.25배, 1시간 TTL을 선택하면 2배입니다. 저장만 하고 재사용하지 못하면 손해가 납니다.
캐싱은 “한 번 저장하고 여러 번 읽는” 구조에서만 이득입니다. 단발성 요청이나 매번 컨텍스트가 바뀌는 구조에서는 쓰기 비용만 추가로 나갑니다.
2번 요청부터 아끼는 이유 — 손익분기 계산
“90% 절감”이라는 숫자만 보면 무조건 켜야 할 것 같습니다. 그런데 실제로는 몇 번째 요청부터 이득이 나는지가 더 중요합니다. 직접 계산해봤습니다.
Sonnet 4.5 기준, 50,000 토큰 시스템 프롬프트 시나리오
| 요청 횟수 | 캐싱 없음 | 캐싱 있음 | 절감액 | 절감률 |
|---|---|---|---|---|
| 1회 | $0.150 | $0.188 | -$0.038 | -25% |
| 2회 (손익분기) | $0.300 | $0.203 | +$0.097 | 33% |
| 10회 | $1.500 | $0.323 | +$1.177 | 78% |
| 100회 | $15.00 | $1.670 | +$13.33 | 89% |
* Sonnet 4.5 기준: 기본 입력 $3.00/MTok, 캐시 쓰기(5분 TTL) $3.75/MTok, 캐시 읽기 $0.30/MTok
* 50,000 토큰 시스템 프롬프트, 5분 TTL 내 연속 요청 가정
(출처: aifreeapi.com “Claude API Pricing Per Million Tokens”, 2026.01 기준 공식 요금 인용)
손익분기는 딱 2번째 요청입니다. 1번째 요청은 캐시 쓰기 비용 때문에 일반 입력보다 25% 더 나갑니다. 2번째 요청부터는 캐시 읽기 비용(90% 절감)이 첫 번째 추가 비용을 상쇄하고 이득으로 전환됩니다.
“90% 절감”은 캐시 읽기 단계의 단가 기준입니다. 처음 쓰기 비용을 포함하면 100회 요청 기준 누적 절감률은 89%입니다. 같은 수치처럼 보이지만, 1회성 요청에서는 방향이 반대입니다.
5분 TTL의 진짜 의미 — 절약이 순식간에 비용이 됩니다
캐싱에서 가장 자주 간과되는 부분이 TTL(Time-To-Live)입니다. Anthropic API의 기본 캐시 유지 시간은 5분입니다. 마지막 캐시 히트 이후 5분이 지나면 캐시가 만료되고, 다음 요청은 다시 캐시 쓰기 비용(1.25배)을 냅니다.
TTL 만료 시 비용 흐름 예시 (Sonnet 4.5, 100K 토큰 컨텍스트)
TTL이 만료된 채로 캐싱을 계속 켜두면, 매 요청마다 캐시 쓰기 비용(1.25배)만 반복해서 냅니다. 요청 간격이 5분을 넘는 구조라면 캐싱이 없는 것보다 25% 더 비쌉니다. 이 문제는 GitHub 이슈로도 보고됐는데, 2025년 12월 중순부터 실제 TTL이 문서상 5분보다 짧은 약 3분으로 줄어든 사례가 있었습니다.
(출처: GitHub anthropics/claude-code issues #14628, 2025.12.19 보고)
Claude가 답변을 내놓고 결과를 검토하다 보면 5분은 생각보다 짧습니다. 특히 복잡한 코드를 리뷰하면서 다음 질문을 구성할 때 이 시간이 지나기 쉽습니다.
Max 플랜과 API 사용자의 캐싱 비용이 다릅니다
여기서부터는 대부분의 블로그가 다루지 않는 부분입니다. Claude Code 소스코드 분석(2026년 2월 기준)에 따르면, Max 플랜 구독자는 1시간 TTL이 자동으로 적용됩니다. 서버 측 기능 플래그(`tengu_prompt_cache_1h_config`)로 제어되며, Max 플랜으로 캐시를 쓸 때는 자동으로 1시간 TTL 단가(2배)로 청구됩니다.
(출처: dev.to/kitaekatt “Mastering Cache Hits in Claude Code”, 2026.02.21 — 소스코드 분석 기반)
| 항목 | Pro 플랜 / API | Max 플랜 |
|---|---|---|
| 캐시 TTL | 5분 | 1시간 |
| 쓰기 단가 배수 | 1.25x | 2.0x |
| 읽기 단가 배수 | 0.1x | 0.1x |
| 손익분기 요청 수 | 2회 | 3회 |
| 실제 운용 이점 | 5분 내 응답 필수 | 1시간 내 여유 |
* Sonnet 4.5 기준, 5분 TTL 쓰기: $3.75/MTok, 1시간 TTL 쓰기: $6.00/MTok, 읽기: $0.30/MTok
(출처: Anthropic 공식 Pricing 페이지, amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-one-hour-duration-prompt-caching/)
Max 플랜은 쓰기 단가가 더 높지만, 답변을 검토하고 다음 메시지를 구성하는 데 한 시간의 여유가 생깁니다. Pro/API 사용자는 5분 안에 다음 요청을 보내지 않으면 캐시가 만료됩니다. 긴 코드를 리뷰하거나 복잡한 문서를 분석하는 작업에서 이 차이가 실제 비용으로 나타납니다.
AWS Bedrock도 2026년 1월 26일부터 Claude Haiku 4.5, Sonnet 4.5, Opus 4.5에 한해 1시간 TTL 옵션을 정식 지원하기 시작했습니다. Bedrock을 통해 API를 쓰는 경우에는 별도로 1시간 TTL을 요청해야 합니다.
캐시를 부수는 5가지 행동
캐싱은 입력의 앞부분이 정확히 일치할 때만 작동합니다. 앞부분이 바뀌면 캐시가 깨지고, 그 이후 전체가 새로 처리됩니다. 생각보다 쉽게 캐시가 무효화됩니다.
공식 발표를 교차 분석하니 보이는 것들
Anthropic이 캐싱을 발표하면서 내세운 사례가 Notion입니다. Notion AI는 캐싱으로 비용을 최대 90%까지 줄이고 응답 속도를 높였다고 밝혔습니다. 그런데 Notion의 구조는 일반 개발자와 다릅니다. 수백만 명의 사용자가 수백만 번의 요청을 보내는 고빈도 구조입니다. 캐시 쓰기 비용이 충분히 분산되어 사실상 무시할 수 있는 수준이 됩니다.
(출처: Anthropic 공식 블로그 “Prompt Caching with Claude”, claude.com/blog/prompt-caching)
반면, 하루에 수십 건만 처리하는 소규모 API 사용자 입장에서는 얘기가 다릅니다. 요청 빈도가 낮으면 TTL 만료로 캐시 쓰기가 반복되고, 결국 캐싱 없이 쓰는 것과 비용이 같아지거나 더 나올 수 있습니다.
같은 50,000 토큰 시스템 프롬프트를 쓰더라도 5분 안에 요청이 몰리는지, 흩어지는지에 따라 실제 절감액이 완전히 달라집니다.
캐싱이 실제로 유리한 구조 vs 그렇지 않은 구조
| 구조 | 캐싱 효과 | 이유 |
|---|---|---|
| 대화형 코딩 어시스턴트 (활성 세션) | 매우 높음 | 연속 대화로 캐시 히트율 90%+ |
| 고정 문서 Q&A (높은 트래픽) | 높음 | 다수 사용자가 같은 컨텍스트 공유 |
| 단발성 배치 분석 | 낮음 | 재사용 없음, 쓰기 비용만 발생 |
| 간헐적 자동화 작업 (1시간 이상 간격) | 낮음 | TTL 만료, 매 실행마다 캐시 재쓰기 |
| 매 요청마다 컨텍스트가 바뀌는 RAG | 제한적 | 시스템 프롬프트만 캐싱 가능 |
또 하나 놓치기 쉬운 부분이 있습니다. Anthropic이 2025년 2월 발표한 캐시 인지 ITPM 한도 업데이트에 따르면, 캐시 읽기 토큰은 분당 입력 토큰 한도(ITPM)에서 차감되지 않습니다. 이는 Claude 3.7 Sonnet 이후 모델에 적용된 기능으로, 고트래픽 환경에서 처리량을 크게 높일 수 있습니다. 단, 모든 모델에 동일하게 적용되지 않으므로 사용 모델을 반드시 확인해야 합니다.
(출처: Anthropic 공식 블로그 “Token-Saving Updates on the Anthropic API”, anthropic.com/news/token-saving-updates)
Q&A
캐시 히트율 90%가 진짜 가능한가요?
배치 API와 프롬프트 캐싱을 동시에 쓸 수 있나요?
캐시 브레이크포인트는 직접 설정해야 하나요?
cache_control: {type: "ephemeral"}을 명시해야 합니다. Anthropic은 최대 4개의 캐시 브레이크포인트를 지원합니다. 브레이크포인트를 설정한 위치까지의 입력이 캐시 대상이 됩니다.
최소 캐시 가능한 토큰 수가 있나요?
캐시가 실제로 히트했는지 어떻게 확인하나요?
usage 필드에 cache_read_input_tokens 값이 담겨 있습니다. 이 값이 0보다 크면 캐시가 히트된 것입니다. Claude Code를 사용할 경우 홈 디렉토리의 JSONL 세션 파일(~/.claude/projects/)에 요청마다 이 값이 기록됩니다. GitHub에 공개된 cache-kit 플러그인으로 세션 전체 히트율을 집계할 수 있습니다.
마치며
Claude 프롬프트 캐싱은 구조만 맞으면 확실히 비용을 줄입니다. 손익분기는 딱 2번째 요청이고, 100번 이상 재사용하면 89%에 가까운 절감이 실제로 나옵니다. 이건 Anthropic이 공식 발표한 수치 그대로입니다.
다만 캐싱이 항상 이득인 건 아닙니다. 5분 TTL을 지키지 못하면 절약이 아닌 비용이 됩니다. Max 플랜 구독자는 1시간 TTL이 자동으로 붙지만 쓰기 단가가 2배입니다. 배치 분석처럼 한 번만 쓰고 끝나는 구조에서는 캐싱을 끄는 게 맞습니다.
결론부터 말씀드리면, 연속 대화 구조나 같은 시스템 프롬프트를 여러 사용자가 공유하는 고트래픽 구조라면 캐싱은 즉시 켜야 합니다. 반면 산발적으로 요청이 들어오는 구조라면 실제 요청 패턴을 먼저 측정하고 나서 결정하는 게 훨씬 안전합니다.
본 포스팅 참고 자료
- Anthropic 공식 블로그 “Prompt Caching with Claude” —
anthropic.com/news/prompt-caching - Anthropic 공식 블로그 “Token-Saving Updates on the Anthropic API” —
anthropic.com/news/token-saving-updates - AWS 공식 발표 “Amazon Bedrock now supports 1-hour duration for prompt caching” (2026.01.26) —
aws.amazon.com/about-aws/whats-new - Claude API 공식 프롬프트 캐싱 문서 —
docs.anthropic.com/en/docs/build-with-claude/prompt-caching - GitHub anthropics/claude-code issues #14628 (TTL 축소 버그 보고, 2025.12.19) —
github.com/anthropics/claude-code/issues/14628 - dev.to/kitaekatt “Mastering Cache Hits in Claude Code” (2026.02.21) —
dev.to/kitaekatt/mastering-cache-hits-in-claude-code-5648
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 모든 요금 수치는 2026년 3월 21일 기준이며, 공식 Anthropic 가격 페이지에서 최신 정보를 반드시 확인하세요. 본 포스팅은 투자·재무 조언이 아닙니다.
댓글 남기기