🔥 월 100달러짜리 Claude Code, 90분 만에 쿼터가 바닥난다

#Claude Code#Anthropic#프롬프트 캐싱#AI 개발도구#토큰

1171자

15분

강의 목차

이슈 #45756: 숫자로 보는 현장
커뮤니티가 뒤집어 놓은 진단
캐시가 왜 깨지는가
Anthropic의 공식 응답
커뮤니티가 만든 자체 수정 도구
2026년 3월, Claude Code의 긴 위기
당장 할 수 있는 것
이걸 쓰면서 든 생각
참고 자료

content image
출처: GitHub — anthropics/claude-code#45756

월 100달러를 내고 있는데 1시간 반 만에 "쿼터 소진"이 뜬다면 어떤 기분일까. 4월 9일, GitHub에 올라온 이슈 하나가 정확히 그 상황을 데이터와 함께 증명했다. 이 글을 쓰는 시점에서 109개의 👍과 17명의 참여자가 붙었고, Anthropic 팀원의 공식 응답까지 나왔다. 단순한 불만 글이 아니다. 커뮤니티가 Anthropic의 제품을 직접 디버깅한 기록이다.

이슈 #45756: 숫자로 보는 현장

작성자 molu0219는 Claude Code CLI를 Pro Max 5x 플랜(월 100달러)으로 사용하고 있었다. 쿼터가 리셋된 직후, 가벼운 질의응답과 간단한 개발 작업만 했는데 1시간 30분 만에 쿼터가 바닥났다.

그가 제출한 데이터가 꽤 치밀하다. ~/.claude/projects/ 하위의 JSONL 세션 파일에서 API 응답마다 기록되는 usage 객체를 직접 파싱했다.

쿼터 리셋 전 (5시간, 헤비 개발):

API 호출 2,715회
캐시 읽기 10.4억 토큰
출력 115만 토큰
피크 컨텍스트 966,078 토큰

이건 Express 서버와 iOS 앱 전체 구현, 멀티 에이전트 파이프라인까지 돌린 작업이니 쿼터를 다 쓴 게 이해가 된다.

쿼터 리셋 후 (1.5시간, 가벼운 작업):

API 호출 691회 (백그라운드 세션 포함)
캐시 읽기 1.04억 토큰
출력 38.7만 토큰

문제는 여기다. 캐시 읽기(cache_read) 토큰이 공식 과금에서는 1/10 가격이다. 그러면 실효 토큰은 1,310만 정도인데, 이 양으로 5x 쿼터가 소진될 리가 없다. 반면 캐시 읽기를 풀 요금으로 치면 1억 570만 토큰이고, 시간당 7,050만 토큰이다. 이러면 쿼터 소진이 설명된다.

molu0219의 초기 가설은 이랬다: cache_read 토큰이 과금에서는 할인되지만, 쿼터 한도에서는 풀 요금으로 카운트된다.

커뮤니티가 뒤집어 놓은 진단

여기서 이야기가 재밌어진다. cnighswonger라는 사용자가 약 1,500건의 API 호출 로그를 통계적으로 분석했다. 6번의 쿼터 리셋 윈도우에 걸쳐 세 가지 가설을 검증했는데, 결과가 의외였다.

가설	변동계수(CV)	판정
cache_read = 0.0x (쿼터에 안 잡힘)	34.4%	최적
cache_read = 0.1x (공식 과금율)	101.6%	불일치
cache_read = 1.0x (풀 요금)	123.7%	불일치

cache_read가 쿼터에 0배로 카운트된다는 게 가장 잘 맞았다. 즉 molu0219의 초기 가설은 틀렸다. cache_read 자체가 문제가 아니라, 캐시가 깨져서 cache_read가 아예 발생하지 않는 것이 진짜 문제였다.

캐시가 깨지면 매 API 호출마다 전체 컨텍스트가 cache_creation으로 처리된다. cache_read의 1/10 가격이 아니라, 풀 가격의 1.25배를 내는 셈이다. 1M 컨텍스트 윈도우에서 한 번의 호출이 96만 토큰을 cache_creation으로 태우면, 200번만 호출해도 쿼터가 증발한다.

캐시가 왜 깨지는가

1. TTL 5분 회귀

2026년 3월 6일경, Anthropic은 프롬프트 캐시의 기본 TTL(Time-to-Live)을 1시간에서 5분으로 변경했다. 공지 없이. Hacker News에서 상당한 논란이 됐다.

5분이면 커피 한 잔 타 오는 시간이다. 화장실 다녀와서 다음 프롬프트를 보내면 캐시는 이미 만료되어 있고, 수십만 토큰의 컨텍스트가 통째로 cache_creation으로 재전송된다. henu-wang의 분석에 따르면, cache_creation은 cache_read보다 12.5배 비싸기 때문에 5분 이상 쉬었다 돌아올 때마다 비용 폭탄이 터지는 구조다.

2. 세션 재개 캐시 버그 (v2.1.69~v2.1.89)

TTL만이 아니었다. Claude Code의 --resume 기능에서 캐시 히트가 아예 발생하지 않는 회귀 버그가 v2.1.69부터 20개 이상의 버전에 걸쳐 존재했다. 한 사용자는 Max 20x 플랜에서 70분 만에 100% 소진을 경험했고, 세션 로그를 분석해보니 캐시 읽기 비율이 36.1%밖에 안 됐다. 90% 이상이어야 정상이다.

v2.1.68로 다운그레이드하자 캐시 히트율이 97.6%로 즉시 복구됐다. 버전 특정 회귀가 확인된 셈이다. 이 문제는 v2.1.91에서 수정됐다.

3. 시스템 프롬프트 불안정

wadabum이 지적한 더 근본적인 문제가 있다. Claude Code는 매 턴마다 git status 결과를 시스템 프롬프트에 포함하는데, 파일 하나만 바뀌어도 시스템 프롬프트가 달라진다. 프롬프트 캐싱은 프리픽스 매칭으로 작동하므로, 시스템 프롬프트가 바뀌면 그 뒤의 모든 캐시가 무효화된다.

거기에 스킬과 CLAUDE.md 블록의 순서가 세션마다 비결정적으로 바뀌는 문제까지 겹치면, 캐시 프리픽스가 절대 안정화될 수 없다. TTL이 5분이든 1시간이든, 프리픽스 자체가 매번 바뀌면 캐시는 처음부터 무용지물이다.

Anthropic의 공식 응답

Claude Code 팀의 Boris(bcherny)가 4월 12일에 핀 고정된 응답을 남겼다. 32개의 👍을 받았다.

요약하면 이렇다. 1M 컨텍스트 윈도우와 캐시 미스의 조합이 주범이다. 1시간 이상 자리를 비우면 전체 캐시가 만료되고, 복귀하는 순간 비용이 폭증한다. 이걸 완화하기 위해 오래된 세션에 /clear를 권유하는 UX 개선을 이미 출시했고, 기본 컨텍스트 윈도우를 400K로 낮추는 방안도 검토 중이다. 당장은 CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude로 조절할 수 있다. 스킬이나 플러그인, 백그라운드 자동화가 많을수록 예상 밖의 토큰 소비가 생긴다는 것도 인정했다. 적응형 사고(adaptive thinking)나 하네스 회귀, 모델/추론 회귀는 원인에서 배제했다.

대응 자체는 빠른 편이다. 다만 커뮤니티가 아쉬워하는 건, 3월의 TTL 변경이 사전 공지 없이 이루어졌다는 점이다.

커뮤니티가 만든 자체 수정 도구

이 사건에서 가장 눈에 띄는 건 커뮤니티의 대응이다. cnighswonger는 분석에 그치지 않고 claude-code-cache-fix라는 인터셉터를 직접 만들었다. 이 도구는 세션 재개 시 메시지 블록 순서를 안정화하고, 도구 호출 순서를 정규화하고, 핑거프린트를 안정화하고, 오래된 도구 결과에서 이미지를 제거한다.

한 사용자는 이 인터셉터로 7.5시간 세션에서 98.4% 캐시 히트율을 달성했다고 보고했다. 또 다른 사용자는 v2.1.81로 버전을 고정하는 것만으로 Max 20x 쿼터가 3~4배 개선됐다고 했다.

월 200달러를 내는 사용자가 제품의 버그를 분석하고, 수정 도구를 만들고, 통계적 검증까지 하는 상황이다. 오픈소스 생태계의 힘이라고 하기엔, 이건 좀 씁쓸하다.

2026년 3월, Claude Code의 긴 위기

이 이슈는 고립된 사건이 아니다. 3월 23일부터 모든 유료 티어에서 비정상적인 쿼터 소진 보고가 쏟아졌다. The Register는 "Anthropic이 Claude Code 쿼터가 너무 빨리 소진된다는 것을 인정했다"라고 보도했고, The New Stack과 DevOps.com도 이 문제를 다뤘다.

같은 시기인 3월 31일에는 Claude Code의 전체 소스 코드가 npm 패키징 오류로 유출되는 사건도 터졌다. v2.1.88의 소스맵 파일에 약 51만 줄의 TypeScript가 포함되어 있었다. Anthropic은 "릴리스 패키징 이슈로 인한 사람의 실수"라고 해명했다. 아이러니하게도 이 유출 덕분에 커뮤니티가 캐시 버그의 내부 메커니즘을 더 깊이 분석할 수 있었다.

Anthropic은 이 기간에 적어도 네 가지 문제가 동시에 겹쳤다고 파악한다: 피크 시간대 스로틀링(3월 26일 확인), 프롬프트 캐싱 버그 두 건(10~20배 비용 인플레이션), 세션 재개 버그, 그리고 3월 28일의 오프피크 2배 프로모션 종료.

당장 할 수 있는 것

이 글을 읽고 "나도 그랬다"라고 고개를 끄덕이고 있다면, 시도해볼 만한 것들이 있다.

v2.1.91 이상으로 업데이트 — --resume 캐시 회귀 버그가 수정됐다
컨텍스트 윈도우 제한 — CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude로 실행하면 자동 압축이 400K에서 발동한다
안 쓰는 세션 정리 — 백그라운드에 열려 있는 세션이 공유 쿼터를 잡아먹는다
5분 이상 자리 비울 때 — 돌아와서 /clear를 먼저 치자. 만료된 캐시 위에 작업을 이어가면 비용이 폭증한다

이걸 쓰면서 든 생각

이 이슈를 쭉 읽으면서 두 가지가 계속 머릿속에 맴돌았다.

하나는, 프롬프트 캐싱이 "비용 절감" 기능으로 마케팅되지만 실제로는 인프라의 복잡성을 사용자에게 떠넘기는 구조라는 것이다. 캐시 TTL이 예고 없이 바뀌고, 시스템 프롬프트가 불안정하고, 세션 재개에서 버그가 터지면 — 사용자가 이걸 모니터링하고 디버깅해야 한다. 개발 도구를 쓰려고 돈을 냈는데, 도구의 비용 구조를 디버깅하고 앉아 있다.

다른 하나는 좀 더 긍정적인 쪽이다. 이 이슈 스레드의 품질이 대단하다. JSONL 파싱, 변동계수 기반 가설 검증, 오픈소스 인터셉터 배포까지. 제품 팀이 해야 할 일을 커뮤니티가 대신했고, Anthropic이 결국 그 분석을 기반으로 대응했다. 이게 2026년에 상용 AI 도구가 디버깅되는 방식이라면, 적어도 지금은 작동하고 있다.

다만 월 100~200달러를 내는 사용자에게 "캐시 히트율을 직접 모니터링하세요"가 답이 되어서는 안 된다. 이 문제의 근본 해결은 Anthropic이 쿼터 소비 현황을 실시간으로 보여주고, 캐시 상태를 사용자가 의식하지 않아도 되게 만드는 데 있다. v2.1.91의 수정과 Boris의 응답이 그 방향의 첫걸음이길 바란다.