Claude Code –resume, 비용 11배 나온 이유

3월 한 달간 Claude Code 사용량 한도가 빨리 닳는다는 불만이 폭발했습니다.
그런데 많은 분들이 Anthropic이 한도를 줄였다고 생각했지만, 실제 원인은 달랐습니다.
프롬프트 캐시 버그가 세션 재개 첫 요청을 최대 11.5배 더 비싸게 만들고 있었고, 27일 동안 아무 안내도 없이 조용히 계속됐습니다.

캐시가 작동하면 얼마나 싸질까 — 정상 수치 먼저

Claude Code가 효율적으로 동작할 때 캐시 히트율은 90% 이상이 보통입니다.
실제로 MCP 서버 8개, 디퍼드 툴 110개로 세션을 운영한 개발자의 로컬 토큰 집계에서 캐시 히트율은 97.2%였습니다.
(출처: Petr Kindlmann, kindlmann.com, 2026.04.02)

Anthropic 공식 문서 기준으로 Claude Sonnet 4.6의 토큰 가격 구조는 아래와 같습니다.
(출처: Anthropic Prompt Caching 공식 문서, 2026.04.20 기준)

(출처: Anthropic Prompt Caching 공식 문서)

캐시가 잘 작동하면 동일한 프롬프트 접두어를 반복 전송해도 비용은 기본 입력 토큰의 10%만 나옵니다.
이게 유지돼야 Claude Code가 사용량 한도 안에서 긴 세션을 돌릴 수 있는 구조입니다.

기본 캐시 TTL은 5분이고, 캐시를 사용할 때마다 TTL이 무료로 갱신됩니다.
즉, 5분마다 세션이 이어지면 계속 히트를 받을 수 있습니다.
(출처: Anthropic 공식 문서, “By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used.”)

▲ 목차로 돌아가기

한도가 빨리 닳는 진짜 원인 — 캐시 미스

2026년 3월 내내 Reddit과 커뮤니티에는 “사용량 한도가 예상보다 훨씬 빨리 닳는다”는 글이 쏟아졌습니다.
대부분은 Anthropic이 한도 정책을 바꿨다고 생각했습니다. 실제로는 달랐습니다.

무엇이 캐시 키를 다르게 만들었나

소스코드 유출 후 커뮤니티가 분석한 결과, cli.js 안의 db8라는 함수가 세션 JSONL 파일에 저장할 때 deferred_tools_delta와 mcp_instructions_delta를 “첨부 타입 메시지”로 분류해 제거했습니다.
이 두 필드는 어떤 툴이 이미 모델에 전달됐는지를 추적하는 레코드입니다.

–resume 시 이 레코드들이 없으니 툴 목록을 처음부터 다시 구성합니다.
그러면 툴 스키마 배열이 달라지고 — 캐시 키는 배열의 정확한 바이트열로 계산하기 때문에 — 키가 바뀝니다.
키가 바뀌면 캐시 히트가 없습니다. 전체 컨텍스트가 새 쓰기 비용으로 청구됩니다.

MCP 서버 병렬 재연결 타이밍 문제도 겹쳤습니다.
첫 API 호출 전에 MCP 서버 연결이 완료되지 않으면 툴 배열에서 일부가 빠진 상태로 요청이 나갑니다.
없는 툴이 있으면 배열이 달라지고, 다시 캐시 미스입니다.

공식 changelog에 기록된 수정 내용은 다음과 같습니다.
(출처: Claude Code 공식 CHANGELOG)

“Cache miss regression fix — Fixed –resume causing a full prompt-cache miss on the first request for users with deferred tools, MCP servers, or custom agents (regression since v2.1.69)”

— Claude Code v2.1.90 changelog

v2.1.69 이후 27일, 22개 버전을 지나서야 패치됐습니다.

▲ 목차로 돌아가기

11.5배는 어떻게 나왔나 — 계산식 직접 확인

MCP 서버 8개 + 디퍼드 툴 110개 환경에서 –resume 시 첫 요청에 약 49,000 토큰이 재청구됩니다.
캐시 히트 때와 미스 때의 비용을 직접 계산해보면 차이가 명확해집니다.
(출처: Petr Kindlmann, kindlmann.com, 2026.04.02)

$0.1837 ÷ $0.0147 = 약 12.5배. 실측에서는 11.5배로 나왔는데, 시스템 프롬프트 일부는 정상 히트된 결과입니다.
그래도 “세션 재개 한 번 = 어제 하루 쓴 토큰과 비슷한 비용”이라는 결론은 달라지지 않습니다.

활동일 기준 하루 세션 재개 횟수가 약 10.9회이고, 버그 지속 기간이 27일이었으니 1인 기준 영향 세션은 약 258개입니다.
이 계산을 유저 규모로 확대하면 (활성 Claude Code 사용자 50,000~200,000명 중 15~25%가 MCP 서버 사용 가정):

※ 위 추정치는 개발자 공개 분석 기반 추정값. “약”으로 표기된 수치는 가정 포함. (출처: kindlmann.com, 2026.04.02)

Max 플랜 유저는 직접 달러 청구가 없는 대신 시간당 토큰 예산이 소진됩니다.
캐시 미스가 연속되면 사용량 한도를 11배 빠르게 태웁니다. 같은 작업을 하는데 한도에 더 빨리 걸리는 게 이 버그의 실질적 피해였습니다.

▲ 목차로 돌아가기

버그가 27일 동안 조용했던 이유

솔직히 말하면, 이 버그가 거의 한 달을 버틴 건 “보이지 않았기 때문”입니다.
세션은 멀쩡히 작동합니다. 오류 메시지가 없고, 응답 품질도 변함없습니다.
단지 토큰이 더 빨리 쓰입니다. 그리고 그게 버그인지 정책 변경인지 바깥에서는 알 수 없었습니다.

비슷한 시기(v2.1.85) –resume이 “tool_use ids found without tool_result blocks” 오류로 아예 터지는 버그도 있었는데, 이건 v2.1.86에서 빠르게 수정됐습니다.
눈에 보이는 오류는 빨리 잡히고, 조용한 비용 증가는 오래 갔습니다.
같은 v2.1.86에서는 Bedrock·Vertex·Foundry 유저들의 캐시 히트율을 개선하는 수정까지 들어갔는데, CLI 쪽 캐시 미스 버그는 그대로였습니다.

버그 타임라인을 정리하면 다음과 같습니다.

(출처: kindlmann.com, Claude Code 공식 CHANGELOG)

▲ 목차로 돌아가기

내 세션이 영향을 받았는지 확인하는 방법

Claude Code는 ~/.claude/stats-cache.json과 각 프로젝트별 세션 JSONL 파일에 토큰 사용 내역을 저장합니다.
여기서 cache_creation_input_tokens와 cache_read_input_tokens를 비교하면 됩니다.

빠른 확인법 (터미널)

# 최근 세션 파일에서 캐시 히트율 확인
cat ~/.claude/projects/*/[세션ID].jsonl | \
grep '"type":"usage"' | \
python3 -c "
import sys, json
read, write = 0, 0
for line in sys.stdin:
try:
d = json.loads(line)
usage = d.get('usage', {})
read += usage.get('cache_read_input_tokens', 0)
write += usage.get('cache_creation_input_tokens', 0)
except: pass
total = read + write
print(f'캐시 읽기: {read:,} | 캐시 쓰기: {write:,}')
print(f'히트율: {read/total*100:.1f}%' if total else '데이터 없음')
"

정상 세션이라면 히트율이 90% 이상이어야 합니다.
버그 영향 기간(2026.03.05 ~ 04.01) 세션에서 히트율이 30% 이하였다면 실제로 피해를 받은 것입니다.

이미 영향을 받았다면

v2.1.90 이상으로 업데이트하면 –resume 캐시 미스 버그는 수정된 상태입니다.
업데이트 후 –resume 첫 요청이 눈에 띄게 빨라지고, 일별 토큰 소모가 줄어들면 정상화된 것입니다.
업데이트 명령은 claude update 또는 npm install -g @anthropic-ai/claude-code입니다.

여전히 긴 세션(200턴 이상)에서 속도 저하가 느껴진다면 별도 이슈가 남아있을 수 있습니다.
v2.1.89·v2.1.90에서 관련 수정이 여러 건 들어갔는데도 지속된다면 GitHub Issues에 리포트하는 것을 고려해볼 수 있습니다.
(출처: anthropics/claude-code GitHub)

▲ 목차로 돌아가기

v2.1.90 수정 후에도 남은 문제

공식 changelog에는 없지만, 커뮤니티 패치 cc-cache-fix가 공식 수정과 동시에 배포됐을 때 한 가지 차이가 있었습니다.
커뮤니티 패치는 캐시 TTL을 5분 대신 1시간으로 강제 설정하는 수정을 포함했는데, 공식 v2.1.90에는 이 내용이 없습니다.

Anthropic 공식 문서에 따르면 1시간 캐시(TTL 1h)는 기본값의 2배 가격입니다.
반면 캐시 읽기 비용은 TTL과 무관하게 $0.30/MTok으로 동일합니다.
(출처: Anthropic Prompt Caching 공식 문서)

v2.1.108에서 ENABLE_PROMPT_CACHING_1H 환경변수로 1시간 TTL을 opt-in할 수 있게 됐습니다.
(출처: claudefa.st Claude Code Changelog, v2.1.108 항목)
세션이 5분 이상 비는 경우가 많다면 이 옵션을 검토해볼 수 있습니다.
단, 캐시 쓰기 비용이 올라가므로 히트율이 충분히 높을 때만 실익이 생깁니다.

참고로 Anthropic 공식 문서는 “5분보다 긴 주기로 쓰는 프롬프트”에는 1시간 캐시를, “5분 이내로 계속 사용하는 프롬프트”에는 5분 캐시를 권장합니다.
Claude Code 세션처럼 간헐적으로 재개하는 패턴이라면 1시간 TTL이 유리할 수 있습니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

이번 버그에서 기억해둘 포인트는 두 가지입니다.
첫째, 캐시 미스는 에러가 없습니다. 세션이 정상 작동해도 API 응답 안에 숫자가 조용히 달라집니다.
캐시 성능을 직접 모니터링하지 않으면 버그인지 정책 변경인지 구분이 안 됩니다.

둘째, 수정 changelog의 “fixed”라는 한 단어만으로는 무엇이 어떻게 고쳐졌는지 확인할 방법이 없습니다.
커뮤니티 분석이 메커니즘을 설명하고 테스트까지 제공했는데, 공식 채널은 그 정보를 제공하지 않았습니다.
AI 도구 비용이 복잡해질수록 툴 자체의 캐시 동작을 직접 들여다보는 습관이 필요합니다.

~/.claude/projects/ 경로의 JSONL 파일에는 모든 토큰 내역이 있습니다.
서비스 정책이 아닌 자신의 데이터로 직접 확인하는 게 가장 빠릅니다.

본 포스팅 참고 자료

1. Anthropic 공식 문서 — Prompt Caching
2. Petr Kindlmann — v2.1.90: 27 days, 22 versions, one expensive bug (2026.04.02)
3. Claude Code 공식 CHANGELOG (GitHub)
4. Reddit r/ClaudeAI — I investigated Claude Code’s –resume cache bug (2026.04.02)
5. Reddit r/ClaudeAI — PSA: Cache bugs in Claude Code, workarounds (2026.04.01)