Claude API 프롬프트 캐싱, 비용 더 나오는 조건

“캐싱 켜면 무조건 90% 절감”이라는 말은 절반만 맞습니다. 캐시 쓰기(write)는 기본 입력 단가보다 비싸고, TTL(캐시 유효 시간)이 2026년 3월 무공지로 변경되면서 월 청구액이 오히려 늘어난 사례가 실측으로 확인됐습니다. 어떤 상황에서 역효과가 생기는지, 직접 로그 데이터로 확인했습니다.

프롬프트 캐싱이 실제로 어떻게 작동하나

Claude API 프롬프트 캐싱은 시스템 프롬프트나 대용량 문서처럼 반복해서 보내는 고정 텍스트를 Anthropic 서버에 저장해두고, 이후 요청에서 재처리 없이 읽어오는 방식입니다. 공식 문서에 따르면 캐시 히트(Cache Hit) 시 해당 토큰 비용은 기본 입력 단가의 10%만 청구됩니다. (출처: Anthropic 공식 가격 문서, platform.claude.com/docs/en/about-claude/pricing)

구체적인 작동 순서는 이렇습니다. 첫 번째 요청 시 해당 콘텐츠를 “캐시 쓰기(Cache Write)”로 저장하고, 이후 동일한 내용이 포함된 요청이 들어오면 “캐시 읽기(Cache Read)”로 서빙합니다. 코드 한 줄 추가로 활성화할 수 있어서 진입 장벽은 낮습니다. 하지만 실제로 비용이 줄어드는지는 사용 패턴에 따라 전혀 달라집니다.

캐싱이 적용 가능한 최소 토큰 수는 모델마다 다릅니다. Claude Sonnet 4.6·Haiku 4.5는 1,024 토큰, Claude Opus 4.6·4.5는 1,024 토큰이며, 이 임계값 미만이면 캐싱이 작동 자체를 하지 않고 그냥 기본 단가로 청구됩니다. (출처: AiHubMix Claude Cache 문서, docs.aihubmix.com/en/api/Claude-Cache) — 짧은 시스템 프롬프트만 쓴다면 캐싱을 켜도 아무런 절감이 없습니다.

▲ 목차로 돌아가기

캐시 쓰기가 더 비싸다는 사실, 계산해 봤습니다

캐싱을 쓰면 무조건 싸진다고 생각하기 쉬운데, 첫 번째 요청은 기본 단가보다 비쌉니다. 공식 가격표를 직접 놓고 보면 구조가 명확해집니다.

Sonnet 4.6 기준으로 계산해 보겠습니다. 시스템 프롬프트가 4,000 토큰이고 5분 TTL을 쓴다면, 캐시 쓰기는 $0.015(= 4,000 × $3.75 ÷ 1,000,000)입니다. 이후 캐시 읽기는 한 번에 $0.0012(= 4,000 × $0.30 ÷ 1,000,000)입니다. 캐시 쓰기 비용을 회수하려면 캐시 읽기가 최소 2회 이상 발생해야 합니다. 딱 2회 만에 손익분기점을 넘습니다.

Du’An Lightfoot의 실측 사례를 보면 격차는 훨씬 선명합니다. YouTube 분석 봇에서 8만 1,262 토큰짜리 영상 메타데이터를 매 요청마다 보내던 비용이 월 $720이었는데, 캐싱 적용 후 $72로 줄었습니다. 단, 해당 봇은 같은 데이터를 하루 100번 이상 호출하는 구조였습니다. (출처: Du’An Lightfoot, Medium, 2025.09.04) — 반복 호출이 없는 구조라면 이 수치는 재현되지 않습니다.

▲ 목차로 돌아가기

2026년 3월, TTL이 조용히 바뀐 날

캐싱 비용 구조보다 더 당혹스러운 상황이 2026년 3월 초에 발생했습니다. Anthropic이 Claude Code의 기본 캐시 TTL을 1시간에서 5분으로 무공지 변경한 것입니다. 공식 changelog나 이메일 공지는 없었고, 문서가 조용히 업데이트된 것을 커뮤니티 개발자들이 역으로 발견했습니다.

이 변경이 실제 비용에 어떤 영향을 줬는지는 r/ClaudeAI에 올라온 1,140개 세션 분석 데이터가 보여줍니다. 4월 2일 이전 하루 평균 캐시 버스트(bust)가 39회였고 일 비용은 $6.28이었는데, 4월 3일부터는 버스트가 199회로 5배 증가하면서 일 비용이 $15.54로 뛰었습니다. 한 달 기준 $277.80 추가 부담입니다. (출처: XDA Developers, 2026.04 기사, xda-developers.com) — 세션 간 5분 이상 쉬는 패턴이 있다면 이 숫자는 재현됩니다.

Anthropic의 Claude Code 창시자 Boris Cherny는 4월 12일 GitHub 이슈에 “5분이 원래 기본값이고 1시간은 일부 구독자에게 적용한 것”이라고 답했습니다. 하지만 사용자들의 로그에는 명확한 전환 날짜(3월 6일, 4월 9일)가 찍혀 있고 되돌아가는 방향의 관측은 보고되지 않았습니다. Anthropic이 공식 변경 내역을 별도로 발표하지 않은 부분입니다.

▲ 목차로 돌아가기

ProjectDiscovery가 비용 59% 줄인 실제 구조

보안 테스트 플랫폼 Neo를 운영하는 ProjectDiscovery는 평균 26단계, 도구 호출 40회 이상의 에이전트 워크플로우에서 캐싱 최적화 전후 비용을 공개했습니다. 출시 초기 캐시 히트율 7%에서 최적화 후 84%로 끌어올렸고, 비용은 59% 줄었습니다. (출처: ProjectDiscovery Engineering Blog, projectdiscovery.io/blog/how-we-cut-llm-cost-with-prompt-caching)

핵심 구조는 세 개의 breakpoint입니다. 첫 번째(BP1)는 변하지 않는 시스템 프롬프트에 1시간 TTL, 두 번째(BP2)는 대화 슬라이딩 윈도우에 5분 TTL, 세 번째(BP3)는 정적 도구 정의에 1시간 TTL을 적용합니다. 그런데 최적화 전에는 working memory(작업 메모리)가 BP1과 BP3 사이에 끼어 있어서, 매 단계마다 변하는 working memory가 캐시를 무효화했습니다. 히트율이 7%에 머문 이유가 여기 있습니다.

해결책은 동적 콘텐츠를 prefix 끝 쪽 user message로 이동하는 것이었습니다. 이 구조 변경 하나로 캐시 히트율이 7%에서 74%로 하룻밤 만에 뛰었습니다. 1~2단계짜리 단순 작업은 히트율 35%에 불과하지만, 20단계 이상의 복잡한 태스크는 74%까지 올라가서, 가장 비용이 많이 드는 작업에서 절감 폭이 가장 크게 나옵니다.

▲ 목차로 돌아가기

1시간 TTL이 오히려 손해인 조건

1시간 TTL은 “더 오래 유지되니까 더 좋다”는 게 첫 번째 반응입니다. 실제로는 쓰기 비용이 기본 단가의 2배입니다. Sonnet 4.6 기준으로 보면 5분 캐시 쓰기가 $3.75/MTok, 1시간 캐시 쓰기가 $6.00/MTok이고 읽기는 $0.30/MTok으로 동일합니다.

문제는 5분 TTL 세계에서는 Claude Code의 장시간 에이전트 작업이 불리해진다는 점입니다. 서브 태스크가 5분 이상 걸리면 돌아왔을 때 캐시가 이미 만료돼 있고, 다시 전체 컨텍스트를 쓰기 비용으로 재구성해야 합니다. 1M 토큰 컨텍스트를 쓰고 있다면 5분 휴식 한 번에 500,000 토큰어치를 통째로 다시 씁니다. 일 $6.28이던 비용이 $15.54로 뛰는 패턴이 여기서 나옵니다.

반면 단순 챗봇처럼 요청 하나가 30초 이내로 끝나고 세션 간 간격이 짧은 구조라면 5분 TTL로 충분합니다. Anthropic의 Jarred Sumner는 GitHub 이슈에서 “단발성 요청이 많은 패턴에서는 5분이 오히려 저렴하다”고 언급했는데 (출처: GitHub anthropics/claude-code Issue #46829), 이 말은 단순 챗봇 사용자에게는 맞지만 장시간 에이전트 사용자에게는 맞지 않습니다.

▲ 목차로 돌아가기

공식 가격표로 직접 검증 가능한 수치 정리

아래 시나리오는 누구든 Anthropic 공식 가격표를 갖고 직접 재현할 수 있습니다. 변수는 모델, TTL, 시간당 요청 수, 고정 컨텍스트 크기 네 가지뿐입니다.

(출처: Anthropic 공식 가격 문서 수치 기반 직접 계산. 1h TTL 에이전트 시나리오는 MetaCTO 블로그 실측 사례 참조)

▲ 목차로 돌아가기

Q&A 5가지

▲ 목차로 돌아가기

마치며

Claude API 프롬프트 캐싱은 맞는 조건에서는 실제로 강력한 도구입니다. 반복 호출이 많고 고정 컨텍스트가 크고 세션 간격이 짧은 구조라면 비용을 90% 가까이 줄이는 게 가능합니다. 하지만 반복 횟수가 적거나 세션 간격이 5분을 자주 넘거나 컨텍스트가 1,024 토큰에 못 미치면, 켜는 것이 오히려 청구액을 늘립니다.

솔직히 말하면, 가장 아쉬웠던 부분은 TTL 변경 방식입니다. 비용 구조에 직결되는 변경을 changelog도 없이 조용히 적용하는 방식은 개발자 입장에서 예측 가능성을 떨어뜨립니다. 직접 세션 로그를 뜯어보지 않으면 알 수 없다는 게 이 생태계의 현실입니다.

결론부터 말씀드리면, 캐싱을 쓰기 전에 자신의 사용 패턴에서 “분당 반복 요청 수 × 고정 컨텍스트 크기”가 얼마인지 먼저 계산하고, 손익분기점을 넘는지 확인하는 게 순서입니다. 그다음에 모델과 TTL을 선택하는 것이 맞습니다.

▲ 목차로 돌아가기

📚 본 포스팅 참고 자료

1. Anthropic 공식 가격 문서 — platform.claude.com/docs/en/about-claude/pricing
2. Anthropic 프롬프트 캐싱 공식 문서 — platform.claude.com/docs/en/build-with-claude/prompt-caching
3. ProjectDiscovery — How We Cut LLM Costs by 59% With Prompt Caching — projectdiscovery.io
4. XDA Developers — Anthropic quietly nerfed Claude Code’s 1-hour cache (2026.04) — xda-developers.com
5. recca0120 — I Scanned 95 Days of My Claude Code Logs (2026.04.14) — recca0120.github.io
6. GitHub Issue #46829 — Cache TTL silently regressed — github.com/anthropics/claude-code
7. MetaCTO — Anthropic Claude API Pricing Full Breakdown 2026 — metacto.com