Claude Code 캐시 TTL 변경과 구독자 쿼터 대란 — 무엇이 바뀌었나
Claude Code 캐시 TTL 변경과 구독자 쿼터 대란 — 무엇이 바뀌었나
Anthropic이 Claude Code의 프롬프트 캐시 TTL을 조용히 변경하면서 구독자들의 쿼터 소진 속도가 급격히 빨라졌습니다. 한 개발자의 3개월치 세션 로그 분석이 그 실체를 드러냈습니다.
2026년 3월 이후 Claude Code 사용자 커뮤니티에서 이상한 패턴이 감지되기 시작했습니다. 월 $200을 지불하는 Max 구독자들이 갑자기 쿼터 한도에 도달하고, Pro 플랜($20/월) 사용자는 5시간 동안 프롬프트 2개만 실행할 수 있는 극단적인 상황이 벌어진 것입니다. 원인은 Anthropic이 공지 없이 변경한 캐시 설정 하나에 있었습니다.
캐시 TTL 변경 사건의 전말
개발자 Sean Swanson은 JSONL 형식의 세션 파일 3개월치를 분석해 핵심 사실을 밝혀냈습니다(GitHub Issue #46829). 2026년 2월 1일경 Anthropic은 Claude Code의 프롬프트 캐시 TTL(Time-To-Live)을 1시간으로 설정했습니다. 그러나 약 한 달 뒤인 3월 7일경, 이 값을 다시 5분으로 롤백했습니다.
문제는 이 변경이 사용자에게 아무런 공지 없이 이루어졌다는 점입니다. 사용자들은 갑작스러운 쿼터 소진 가속을 경험하면서도 원인을 알 수 없었고, Swanson의 데이터 분석이 있기 전까지는 추측만 난무했습니다.
캐시 TTL이 비용에 미치는 기술적 영향
Claude Code에서 프롬프트 캐시는 반복되는 시스템 프롬프트, 규칙 파일, 대화 기록 등을 캐싱하여 재사용하는 메커니즘입니다. TTL은 이 캐시가 유효한 시간을 결정합니다.
캐시 비용 구조:
| 작업 | 비용 (기본 토큰 가격 대비) |
|---|---|
| 5분 캐시 쓰기 | 1.25배 |
| 1시간 캐시 쓰기 | 2배 |
| 캐시 읽기 | 0.1배 |
핵심은 쓰기 대비 읽기가 10배 이상 저렴하다는 것입니다. TTL이 5분이면 개발자가 코드를 읽거나 잠시 자리를 비운 뒤 돌아올 때마다 캐시가 만료되어 다시 쓰기가 발생합니다. 반면 1시간 TTL에서는 같은 상황에서 캐시 읽기로 처리되므로 비용이 최대 12.5배 절감됩니다.
Swanson의 분석에 따르면, 3개월간 220M 토큰이 5분 캐시 계층에 쓰여졌으며, 1시간 TTL이었다면 대부분 읽기로 처리됐을 것입니다. 이로 인한 캐시 생성 비용 증가율은 **20-32%**로 추정됩니다.
사용자 반발의 규모
쿼터 변화의 영향은 구독 등급을 가리지 않고 광범위하게 나타났습니다.
보고된 주요 사례:
- Max 구독자($200/월): "3월 이후 처음으로 쿼터 한도에 도달했습니다"
- Pro 사용자($20/월): "5시간에 프롬프트 2개만 가능한 상황"
- 엔터프라이즈 팀: "3월에는 하루 종일 Opus를 사용했는데, 3월 말부터 2시간 만에 세션 한도 초과"
- AMD AI 디렉터: 유사한 쿼터 제한 불만을 공개적으로 제기
이러한 불만은 GitHub Issue와 Reddit, X(Twitter)를 통해 급속히 확산되었습니다.
Anthropic의 공식 입장
Anthropic 측에서는 두 명의 핵심 엔지니어가 입장을 밝혔습니다.
Jarred Sumner(Bun 창시자, 현 Anthropic 소속)는 "Claude Code 요청의 상당수가 1회성(one-shot) 호출이라 5분 TTL이 오히려 저렴하다"고 설명했습니다. 글로벌 TTL 설정을 사용자에게 노출할 계획은 없다고 밝혔습니다.
Boris Cherny(Claude Code 창시자)는 보다 기술적인 맥락을 제공했습니다. "1M 토큰 컨텍스트 윈도우에서 캐시 미스가 발생하면 비용이 매우 크다"며, "1시간 이상 자리를 비운 후 세션을 재개하면 풀 캐시 미스가 발생한다"고 설명했습니다. 기본 컨텍스트 윈도우를 400K로 줄이는 방안을 검토 중이라고 덧붙였습니다.
캐싱 코드 버그 문제
논쟁의 와중에 캐싱 코드에서 버그 2건이 발견되었다는 점도 주목할 만합니다. 커뮤니티에서는 "이 버그가 수정되기 전에는 5분 대 1시간 TTL 논쟁 자체가 무의미하다"는 지적이 나왔습니다. 버그로 인해 캐시가 의도대로 작동하지 않는 경우가 존재했기 때문입니다.
또한 AWS Bedrock 환경에서도 TTL이 5분으로 하드코딩되어 있다는 별도 이슈(#32671)가 보고되어, 문제가 CLI 버전에 국한되지 않음이 확인되었습니다.
더 큰 그림 — 쿼터 축소 의혹
The Register는 이 사태를 분석하면서 주목할 만한 시각을 제시했습니다. "캐시 최적화에 집중하는 것은 겉으로 드러나지 않게 Anthropic의 쿼터가 예전보다 적은 처리 시간을 제공하고 있다는 증거일 수 있다"는 것입니다.
실제로 사용자 체감으로는 동일한 구독료를 내면서 처리할 수 있는 작업량이 줄어든 셈입니다. 가격 인상 없이 실질적인 서비스 축소가 이루어진 것 아니냐는 의구심이 커뮤니티에 퍼지고 있습니다.
Claude Code 사용자를 위한 대응 방안
캐시 TTL 문제를 인지한 상태에서 사용자가 취할 수 있는 조치가 있습니다.
- 세션 연속성 유지: 5분 이상 작업을 중단하지 않도록 세션을 유지합니다
- 컨텍스트 최적화: 불필요한 시스템 프롬프트나 규칙 파일을 정리해 캐시 크기를 줄입니다
- 쿼터 모니터링: 일일 사용량을 추적하여 한도 도달 전에 작업 우선순위를 조정합니다
- GitHub Issue 참여: #46829에 사용 패턴과 데이터를 공유하여 커뮤니티 논의에 기여합니다
자주 묻는 질문 (FAQ)
Q: 캐시 TTL은 무엇인가요?
캐시 TTL(Time-To-Live)은 저장된 캐시 데이터가 유효한 시간입니다. Claude Code에서는 시스템 프롬프트와 대화 기록의 캐시 유효 시간을 의미하며, 만료되면 전체를 새로 쓰기해야 합니다.
Q: 5분 TTL과 1시간 TTL의 비용 차이는 얼마나 되나요?
사용 패턴에 따라 다르지만, 5분 이상 간격으로 작업하는 일반적인 개발 패턴에서는 캐시 생성 비용이 20-32% 증가할 수 있습니다. 캐시 읽기가 쓰기보다 10배 이상 저렴하기 때문입니다.
Q: Anthropic이 TTL 설정을 사용자에게 공개할 계획이 있나요?
현재까지 공식적으로 글로벌 TTL 설정을 사용자에게 노출할 계획은 없다고 밝혔습니다. 다만 기본 컨텍스트 윈도우를 400K로 줄이는 방안은 검토 중입니다.
Q: API 사용자(직접 결제)에게도 동일한 문제가 발생하나요?
API 사용자는 캐시 TTL을 직접 설정할 수 있어 영향이 제한적입니다. 다만 AWS Bedrock을 통해 사용하는 경우 TTL이 5분으로 하드코딩되어 있어 동일한 문제가 발생할 수 있습니다.
마무리
Claude Code 캐시 TTL 변경 사건은 AI 코딩 도구의 가격 투명성 문제를 수면 위로 올렸습니다. 기술적으로는 캐시 설정 하나의 변경이지만, 사용자 체감으로는 구독 서비스의 실질적 가치가 달라지는 중대한 변화였습니다.
Anthropic이 이 문제에 어떻게 대응하느냐에 따라, AI 코딩 도구 시장에서의 신뢰도가 결정될 것입니다. 사용자로서는 캐시 동작 방식을 이해하고, 쿼터 관리에 더 주의를 기울일 필요가 있습니다.
참고 자료:
