Claude Sonnet 4.5 / Claude 4 계열 기준
IT/AI
Claude API 프롬프트 캐싱, 실제로 재봤습니다
“캐싱 켜면 비용 90% 절약”이라는 말, 조건 없이 믿으면 손해 나는 구간이 있습니다.
캐시 라이트 비용이 기본 입력보다 25% 더 비싸다는 사실,
공식 문서에 명시되어 있지만 대부분의 한국어 블로그가 빠뜨리고 있습니다.
프롬프트 캐싱이 실제로 하는 일
Claude API 프롬프트 캐싱의 핵심은 단순합니다. API를 호출할 때마다 반복해서 보내는 긴 시스템 프롬프트나 문서를 한 번만 처리하고, 그 결과를 저장해두었다가 다음 요청에서 재사용하는 방식입니다.
매번 100페이지짜리 문서를 처음부터 읽는 대신, 이미 읽어둔 내용을 꺼내 쓰는 것과 같습니다.
API 호출 한 건에는 도구 정의(tool definitions), 시스템 프롬프트, 대화 히스토리가 순서대로 담깁니다.
Claude Code처럼 긴 세션을 유지하는 경우, 50,000~200,000토큰 이상의 입력이 매 메시지마다 전송됩니다.
캐싱 없이는 그 전체를 매번 새로 처리해야 합니다.
중요한 포인트는 캐시가 입력의 앞부분(prefix)에만 작동한다는 점입니다. 변하지 않는 앞부분이 캐시 히트를 받고, 새로 추가된 끝부분만 새로 처리됩니다. 한 메시지 안에서 캐시 히트와 미스가 동시에 발생하는 것이 정상입니다.
(출처: Anthropic 공식 블로그 anthropic.com/news/prompt-caching)
캐시 라이트가 더 비싼데 왜 켜야 할까요?
“캐싱을 켜면 비용이 줄어든다”는 말은 맞지만, 처음 캐시를 저장할 때는 오히려 돈을 더 냅니다.
Anthropic 공식 문서에 따르면 캐시 라이트(cache write)는 기본 입력 토큰 가격의 1.25배(25% 추가)를 청구합니다.
반면 캐시 리드(cache read)는 기본 가격의 0.1배(90% 할인)입니다.
(출처: Anthropic 공식 블로그, 2025.08.14 기준)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
대부분의 블로그가 “캐시 리드 90% 절약”만 강조합니다.
그런데 캐시 라이트 비용을 포함한 실제 가격표를 보면,
Claude Sonnet 4.5 기준 캐시 라이트는 $3.75/MTok으로
일반 입력($3.00/MTok)보다 비쌉니다.
1회 대화에 끝나는 호출이라면 캐싱이 오히려 손해입니다.
| 항목 | Claude Sonnet 4.5 | 기본 대비 |
|---|---|---|
| 일반 입력 (캐싱 없음) | $3.00 / MTok | 기준 (1x) |
| 캐시 라이트 (5분 TTL) | $3.75 / MTok | +25% 더 비쌈 |
| 캐시 라이트 (1시간 TTL) | $6.00 / MTok | +100% 더 비쌈 |
| 캐시 리드 (히트 발생 시) | $0.30 / MTok | -90% 절약 |
(출처: dev.to/kitaekatt 2026.02 실측 + Anthropic 공식 가격 기준)
1시간 TTL 캐시 라이트는 기본 입력보다 2배나 비쌉니다.
이 수치가 의미하는 바는, 같은 컨텍스트를 충분히 많이 재사용하지 않으면 캐싱이 오히려 비용을 키운다는 것입니다.
손익분기점은 딱 2번째 메시지부터입니다
숫자로 직접 재봤습니다. 100,000토큰짜리 컨텍스트를 Claude Sonnet 4.5로 처리한다고 가정합니다.
🔢 2메시지 기준 계산 (5분 TTL, Claude Sonnet 4.5, 100K 토큰 컨텍스트)
메시지 1 캐시 라이트: 100K × $3.75/MTok = $0.375
메시지 2 캐시 리드: 100K × $0.30/MTok = $0.030
캐싱 누적 비용: $0.375 + $0.030 = $0.405
캐싱 없이 2회: 2 × (100K × $3.00/MTok) = $0.600
→ 2번째 메시지부터 이미 32.5% 저렴합니다.
20번의 대화를 이어간다면 더 극명해집니다.
| 시나리오 | 20턴 총 입력 비용 | 절약률 |
|---|---|---|
| 캐싱 없음 | $6.00 | — |
| 캐싱 있음 (캐시 1회 라이트 + 19회 리드) | $0.945 | 약 84% |
(출처: dev.to/kitaekatt 계산 방식, 2026.02 기준. Claude Sonnet 4.5 가격 적용)
이 수치가 의미하는 것은, 캐싱의 진짜 가치는 긴 세션에서 같은 컨텍스트를 반복 재사용할수록 증폭된다는 점입니다.
1회성 API 호출만 하는 서비스에서는 오히려 캐시 라이트 비용만 추가로 내는 셈입니다.
반드시 “내가 같은 컨텍스트를 몇 번 재사용하는가”를 먼저 따져야 합니다.
Pro 5분 vs Max 1시간, 이게 생각보다 큰 차이입니다
Claude API와 Pro 플랜 사용자에게는 캐시 유효 시간(TTL)이 5분으로 설정됩니다.
반면 Max 플랜은 1시간 TTL이 적용됩니다.
이것은 Anthropic 공식 문서보다 Claude Code 소스코드 분석(2026.02 기준)에서 먼저 확인된 사실로, 서버 측 feature flag인 tengu_prompt_cache_1h_config로 제어됩니다.
(출처: dev.to/kitaekatt, 2026.02.21)
💡 대부분의 설명이 빠뜨리고 있는 지점입니다
5분 TTL 사용자는 메시지를 보내고 6분 뒤에 답장하면 캐시가 만료됩니다.
다음 요청에서 캐시 라이트 비용을 다시 냅니다.
반면 Max 플랜은 1시간 안에만 활동하면 캐시가 살아있습니다.
느긋하게 답장을 작성해도 손해가 없습니다.
TTL 만료로 손실이 나는 실제 계산
100K 토큰 컨텍스트, 5분 TTL 사용자가 메시지를 보내고 6분 후 다시 메시지를 보낸다면:
메시지 1: 캐시 라이트 $0.375 (만료됨)
메시지 2: 캐시 라이트 재발생 $0.375 (TTL 초과로 캐시 재생성)
결과: 두 번 다 캐시 라이트 비용 = $0.750 (캐싱 없는 $0.600보다 25% 더 지출)
이 계산이 의미하는 바는, 5분 이상 간격으로 API를 호출하는 패턴에서는 캐싱이 비용을 오히려 늘린다는 것입니다.
배치 처리, 스케줄러 기반 자동화, 인터벌이 긴 챗봇은 캐싱 효과를 보기 어렵습니다.
1시간 TTL을 쓰면 캐시 라이트 비용이 2배인데 이득인가요?
1시간 TTL 캐시 라이트($6.00/MTok)는 5분 TTL($3.75/MTok)보다 60% 더 비쌉니다.
하지만 5분 TTL 사용자가 한 시간 동안 여러 번 캐시를 재작성한다면 합산 비용이 더 올라갑니다.
예를 들어 5분마다 한 번씩 새 메시지를 보내는 12회 세션이라면:
5분 TTL · 1시간 = 매 5분 재작성 시 최대 12회 캐시 라이트
최악: 12 × $3.75 = $45.00
1시간 TTL: 1 × $6.00 + 11 × $0.30 = $9.30
규칙적으로 긴 세션을 유지하는 개발자라면 Max 플랜의 1시간 TTL이 단순히 “더 비싼 요금제”가 아니라,
캐싱 효율 측면에서 실질적 비용 절감 수단이 됩니다.
캐시를 조용히 깨는 패턴들
막상 써보면 “왜 캐시 히트가 안 되지?” 싶을 때가 있습니다.
아래 경우들이 캐시를 무효화합니다. 전부 공식 문서와 Claude Code 소스 분석(2026.02 기준)에서 확인된 사항입니다.
💡 “캐시를 켰는데 효과가 없다”는 대부분의 원인은 여기 있었습니다
캐시는 입력 맨 앞부터 바이트 단위 완전 일치(exact byte-for-byte match)가 필요합니다.
조금이라도 달라지는 부분이 생기면, 그 지점 이후의 모든 내용이 캐시 미스 처리됩니다.
캐시가 깨지는 상황 목록
- 모델 전환: /model로 Sonnet → Opus 전환 시 캐시 완전 무효화 (모델별로 캐시 독립 운영)
- /rewind 명령: 대화 히스토리 일부를 삭제하면 prefix가 달라져 이전 캐시가 무용지물
- 시스템 프롬프트에 날짜·타임스탬프 삽입: “오늘은 2026년 3월 19일입니다” 한 줄이 매 호출마다 캐시를 깸
- 세션 종료 후 재시작: TTL이 남아있어도 시스템 프롬프트가 재생성되므로 실질적 캐시 미스
- CLAUDE.md 수정 후 즉시 재시작: tool definitions가 변경되어 계층 최상단부터 캐시 무효화
- MCP 서버 추가 후 세션 재시작: tool definitions 변경으로 전체 캐시 재생성 비용 발생
- 최소 토큰 미충족: 캐싱 대상 프리픽스가 1,024토큰 미만이면 cache_control 설정이 있어도 캐싱 자체가 작동하지 않음
그 중에서도 시스템 프롬프트에 동적 값을 넣는 패턴이 가장 자주 발생하는 문제입니다.
날짜, 사용자 ID, 요청 ID처럼 매번 바뀌는 값은 시스템 프롬프트가 아닌 사용자 메시지 쪽에 넣어야 캐시가 유지됩니다.
(출처: promptbuilder.cc, 2025.11)
OpenAI·Google과 나란히 놓으면 달라 보입니다
Claude의 캐싱을 경쟁 서비스와 나란히 놓고 보면 구조적인 차이가 드러납니다.
OpenAI는 캐싱이 자동(automatic)이라 별도 설정 없이도 조건이 맞으면 적용되지만,
Anthropic은 명시적으로 cache_control 플래그를 지정해야 합니다.
이 차이가 실제 사용 경험에서 꽤 큰 차이를 만듭니다.
| 항목 | Anthropic Claude | OpenAI GPT | Google Gemini |
|---|---|---|---|
| 캐싱 적용 방식 | 수동 (명시적 플래그) | 자동 | 수동 (ID 기반) |
| 기본 캐시 TTL | 5분 (Max: 1시간) | 5~10분 | 15분 |
| 최소 프리픽스 크기 | 1,024 토큰 | 1,024 토큰 | 2,048 토큰 |
| 캐시 히트 할인율 | 90% | 90% | 75% |
| 지연 시간 감소 (TTFT) | 최대 85% | 50~80% | 40~70% |
(출처: promptbuilder.cc 2025.11 기준 비교표. 각 수치는 공식 문서 기준이나 변동 가능성 있음 — 확인 필요)
💡 3사 비교에서 Claude를 선택해야 할 이유가 하나 더 있습니다
Google Gemini의 캐시 최소 크기는 2,048토큰으로 Claude의 두 배입니다. 짧은 시스템 프롬프트를 쓰는 앱에서는 Google 캐싱이 아예 작동하지 않는 경우가 생깁니다.
반면 OpenAI는 자동 적용이라 편리하지만, 어떤 부분이 캐시 히트를 받았는지 제어하기 어렵습니다.
Claude의 명시적 플래그 방식은 번거롭지만 캐싱 대상을 개발자가 직접 결정할 수 있어 예측 가능한 비용 관리가 가능합니다.
자주 묻는 것들
Q. 캐싱을 켜면 응답 품질이 달라질까요?
달라지지 않습니다. 캐싱은 입력을 처리하는 방식을 효율화하는 것이지, 모델이 받아 보는 내용 자체는 동일합니다.
캐시 히트 여부에 따라 응답 속도(TTFT)는 달라지지만, 답변의 품질이나 방향은 영향을 받지 않습니다.
(출처: promptbuilder.cc FAQ 항목)
Q. 캐싱이 작동하는지 어떻게 확인하나요?
API 응답의 usage 객체에 cache_read_input_tokens와 cache_creation_input_tokens 필드가 포함됩니다.
이 수치가 0이 아니라면 캐싱이 작동 중인 것입니다. Claude Code 사용자는 JSONL 세션 로그를 파싱하거나 cache-kit 플러그인을 통해 히트율을 확인할 수 있습니다.
(출처: Anthropic 공식 API 문서)
Q. 1,024토큰이 어느 정도 분량인가요?
한국어 기준으로 약 600~800자 정도에 해당합니다. 영문 기준으로는 약 750~800 단어입니다.
짧은 안내 메시지 수준의 시스템 프롬프트만 사용한다면 1,024토큰 미만일 수 있습니다.
이 경우 cache_control을 설정해도 캐싱이 적용되지 않으니, 실제 토큰 수를 먼저 확인해야 합니다.
Q. 여러 모델을 함께 쓰면 캐시를 공유할 수 있나요?
불가능합니다. 캐시는 모델별로 완전히 독립 운영됩니다. Sonnet으로 구축한 캐시를 Opus에서 재사용하는 것은 지원되지 않습니다.
더 저렴한 모델로 캐시를 구축해두고 비싼 모델에서 읽어오는 전략은 구조적으로 작동하지 않습니다.
(출처: dev.to/kitaekatt 2026.02.21)
Q. Amazon Bedrock이나 Google Vertex에서도 Claude 캐싱이 됩니까?
됩니다. 2024년 12월 17일자로 Amazon Bedrock과 Google Cloud Vertex AI에서도 Claude 프롬프트 캐싱이 공식 지원(preview)됩니다.
다만 TTL 설정 방식과 환경 변수 등 세부 동작이 Anthropic 직접 API와 다를 수 있습니다.
(출처: Anthropic 공식 블로그 업데이트, 2024.12.17)
마치며
솔직히 말하면, Claude API 프롬프트 캐싱은 제대로 쓰면 정말 효과 있습니다.
하지만 “90% 절약”이라는 수치만 보고 켜는 것과,
캐시 라이트 비용·TTL·캐시 무효화 조건을 이해하고 쓰는 것은 완전히 다른 결과를 만듭니다.
핵심은 세 가지입니다. 같은 컨텍스트를 최소 2번 이상 재사용할 것, 5분 안에 대화를 이어갈 것(Pro·API 기준), 시스템 프롬프트에 동적 값을 넣지 말 것.
이 세 가지가 충족되지 않으면 캐싱을 켠다고 해서 돈이 줄지 않습니다.
Max 플랜과 Pro/API 플랜의 TTL 차이(1시간 vs 5분)는 공식 문서에는 아직 명확히 기술되어 있지 않지만,
소스 분석(2026.02 기준)에서 확인된 내용입니다.
장시간 세션을 자주 사용한다면 이 차이가 요금에 실질적인 영향을 줍니다.
이 부분 이후로 Anthropic이 가격·TTL 정책을 업데이트할 가능성이 있습니다.
공식 문서를 주기적으로 확인하는 것이 가장 확실합니다.
본 포스팅 참고 자료
- Anthropic 공식 블로그 — Prompt Caching 발표 (2025.08.14) anthropic.com/news/prompt-caching
- Claude API 공식 문서 — Prompt Caching docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- dev.to/kitaekatt — Mastering Cache Hits in Claude Code (2026.02.21) dev.to/kitaekatt/mastering-cache-hits-in-claude-code-5648
- promptbuilder.cc — Prompt Caching Guide 2025 (2025.11) promptbuilder.cc/blog/prompt-caching-token-economics-2025
- Anthropic API 가격 페이지 anthropic.com/pricing
본 포스팅 작성 이후 Anthropic 서비스 정책·가격·UI·기능이 변경될 수 있습니다.
본문 내 수치는 Claude Sonnet 4.5 기준(2026.03.19 확인)이며, 다른 모델 또는 이후 업데이트 시 달라질 수 있습니다.
정확한 최신 정보는 Anthropic 공식 문서를 통해 확인하세요.
댓글 남기기