Claude Code 월 20만원 요금제가 90분에 바닥나는 이유

Claude Code를 진지하게 쓰는 사람이라면 요즘 이 말이 전혀 과장이 아니라는 걸 체감했을 거다.

“월 20만원짜리 요금제가 왜 90분 만에 끝나지?”

이건 단순히 한 사용자가 운이 나빴던 사건이 아니다. 오히려 지금 AI 개발 도구 시장이 어디서 무너질 수 있는지를 아주 선명하게 보여주는 사례다. 그동안 많은 사람들은 Claude Code를 “비싸지만 강력한 도구” 정도로 받아들였다. 문제는 비싼 것 자체가 아니다. 비싼데도 예측 가능해야 한다는 점이다. 그런데 이번 이슈는 그 예측 가능성을 완전히 흔들었다.

핵심은 명확하다. Anthropic은 프롬프트 캐싱을 통해 비용을 크게 줄일 수 있다고 말해 왔지만, 실제 할당량 계산에서는 cache_read 토큰이 사실상 정가로 반영되는 정황이 강하게 드러났다. 여기에 캐시 TTL까지 조용히 낮춘 흔적이 겹치면서, 사용자는 “분명 캐시를 썼는데 왜 체감상 더 빨리 소진되지?”라는 불신을 갖게 됐다.

이 글은 단순히 “Claude Code 욕하기”가 목적이 아니다. 오히려 나는 이 사건이 AI 도구를 실무에서 고를 때 무엇을 봐야 하는지를 다시 알려주는 사례라고 본다. 모델 품질만으로는 더 이상 설명이 안 된다. 이제는 가격 구조, 캐시 정책, 사용량 계산 방식, 운영 투명성까지 같이 봐야 한다.

이게 왜 이렇게 크게 터졌나

이번 이슈가 커진 이유는 단순히 돈이 비싸서가 아니다. 사용자가 기대한 것과 실제 경험한 것이 정면으로 충돌했기 때문이다.

Claude Code Pro Max 5x는 월 200달러다. 한국 돈으로 대략 20만원이 넘는 가격이다. 이 가격을 내는 사람들은 당연히 “비싸지만 일하는 시간이 줄어든다”는 기대를 갖는다. 문제는 이 플랜에서조차 moderate usage, 즉 가벼운 질의응답과 평범한 개발 작업만 했는데도 90분 만에 할당량이 바닥났다는 보고가 나왔다는 점이다. Reddit 쪽에서는 19분 사례도 돌았다.

이건 단순한 UX 불만이 아니다. AI 도구를 팀 단위로 쓰는 순간, 이건 바로 운영 계획 문제로 바뀐다.

하루에 몇 시간 쓸 수 있는가
한 달에 몇 명이 동시에 붙을 수 있는가
캐시가 실제로 비용을 줄여주는가
리셋 이후 사용 가능량이 일관적인가

이 질문들에 답이 안 나오면, 아무리 모델 품질이 좋아도 팀 도구로는 불안하다.

특히 한국 개발자들한테 이 문제가 더 크게 느껴지는 이유가 있다. 지금 국내에선 Claude Code가 “실무형 AI 코딩도구”로 거의 표준처럼 소비되고 있다. 블로그 비교글, 생산성 팁, 업무 자동화 글 대부분이 Claude Code를 중심으로 돈다. 그러니까 이 과금 논란은 일부 파워유저만의 문제가 아니라, 한국 개발자 생산성 도구 생태계 전체에 닿는 문제가 된다.

핵심은 cache_read 토큰이 진짜 할인받고 있느냐는 점이다

이 사건의 가장 중요한 포인트는 여기다.

Anthropic은 프롬프트 캐싱을 비용 절감 장치로 계속 강조해왔다. 문서나 마케팅 표현을 따라가면, 이미 읽은 컨텍스트는 다시 읽을 때 훨씬 싸게 처리되는 것처럼 이해된다. 이건 굉장히 중요한 약속이다. 왜냐하면 Claude Code 같은 도구는 긴 컨텍스트와 반복 호출이 기본이기 때문이다. 한 세션에서 같은 파일, 같은 시스템 프롬프트, 같은 프로젝트 문맥을 계속 읽는다. 이때 캐시가 제대로 할인되지 않으면, 장시간 사용은 구조적으로 비싸질 수밖에 없다.

문제는 GitHub 이슈와 사용자 분석에서 cache_read_input_tokens가 사실상 정가처럼 할당량에 반영되는 것 아니냐는 정황이 나왔다는 점이다. 이게 사실이면 사용자가 기대한 “캐시 덕분에 실제 비용 감소”가 할당량 계산에선 무력화된다.

예를 들어 이런 식이다.

usage = {
    "input_tokens": 120_000,
    "cache_creation_input_tokens": 80_000,
    "cache_read_input_tokens": 1_044_000_000,
    "output_tokens": 32_000,
}

# 사용자가 기대하는 방식:
# cache_read는 아주 낮은 비율로 계산

# 사용자가 의심하는 실제 방식:
# cache_read가 사실상 full rate로 quota에 반영

만약 cache_read_input_tokens가 정말로 거의 정가처럼 quota에 반영된다면, 캐싱은 사용량을 줄이는 기술이 아니라 오히려 **“보이지 않게 quota를 녹이는 구조”**가 된다. 그리고 사용자는 당연히 이렇게 묻게 된다.

“그럼 캐싱이 절약 장치가 아니라 quota 함정 아닌가?”

이건 단순 계산 실수 논란이 아니다. 서비스 신뢰의 문제다.

캐시 TTL을 몰래 낮춘 건 왜 더 치명적이었나

여기서 더 민감한 포인트가 하나 나온다. 같은 시기에 Anthropic이 캐시 TTL을 3월 6일에 조용히 낮췄다는 이야기가 HN에서 크게 돌았다. 이게 왜 중요하냐면, 캐시 TTL이 짧아질수록 캐시는 더 자주 무효화되고, 무효화될수록 더 많은 입력 토큰이 다시 full-price 경로로 들어갈 가능성이 커지기 때문이다.

즉 구조는 이렇게 된다.

캐시 TTL 단축
캐시 적중 시간 짧아짐
같은 작업에서도 더 자주 재계산
입력 토큰/읽기 토큰 증가
quota 더 빨리 소진

이 과정이 사용자에게 명확히 고지되지 않았다면 문제는 더 커진다. 왜냐하면 사용자는 자기 사용 습관이 바뀌지 않았는데도 quota 소진 속도가 갑자기 달라졌다고 느끼게 되기 때문이다.

실무에선 이런 차이가 정말 크다. 나는 AI 도구에서 “성능 향상”보다 “정책 변경을 얼마나 명확히 설명하느냐”가 더 중요할 때가 있다고 본다. 캐시 TTL 같은 운영 변수는 모델 데모 슬라이드보다 덜 화려하지만, 실제 사용자의 생산성에는 훨씬 큰 영향을 준다.

한국 개발자 입장에서 이 문제를 어떻게 봐야 하나

이 이슈를 한국 개발자 관점에서 보면 포인트는 훨씬 현실적이다. 대부분의 팀은 Claude Code를 논문처럼 평가하지 않는다. 그냥 이렇게 묻는다.

이걸 팀 구독으로 붙여도 되나
월말에 예산 통제가 되나
Gemini CLI나 Codex보다 확실히 나은가
긴 세션에서 믿고 계속 쓸 수 있나

지금까지 Claude Code의 가장 강한 무기는 모델 품질 + 캐싱을 통한 실질 효율이었다. 그런데 만약 캐시가 체감 효율을 올리면서도 quota 계산에서는 할인되지 않는다면, 이 무기는 반쯤 무너진다. 그 순간 비교 기준은 바로 바뀐다.

Gemini CLI는 무료 혹은 훨씬 낮은 비용으로 시작 가능하고,
OpenAI Codex는 경쟁적인 가격과 다른 생태계 장점을 주고,
Claude Code는 “비싸지만 일 잘한다”에서 “비싼데 quota 예측도 어렵다”로 인식이 밀릴 수 있다.

특히 한국 시장은 입소문이 빠르다. 한 번 “이거 quota 너무 빨리 닳는다”는 공감대가 생기면, 성능 평가보다 운영 불만이 더 오래 남는다. 도구는 감탄보다 불신이 더 빨리 퍼진다.

당장 실무에서 확인해야 할 체크포인트

지금 Claude Code를 쓰고 있다면, 감정적으로만 반응하기보다 실제 데이터를 먼저 보는 게 맞다. 최소한 아래는 체크해보는 게 좋다.

1. usage 로그에서 cache_read 비중 확인

가능하면 세션별 usage 로그나 billing 로그를 모아서 cache_read_input_tokens 비율을 보자.

sessions = [
    {"name": "session-a", "cache_read": 120_000_000, "input": 80_000, "output": 15_000},
    {"name": "session-b", "cache_read": 340_000_000, "input": 150_000, "output": 40_000},
]

for s in sessions:
    ratio = s["cache_read"] / max(s["input"], 1)
    print(s["name"], f"cache_read/input ratio = {ratio:.1f}x")

이 비율이 과도하게 높고 quota 소진도 빠르다면, 지금 겪는 문제는 “많이 써서”가 아니라 과금 구조가 기대와 다를 가능성이 있다.

2. 긴 세션과 짧은 세션을 분리

캐시 TTL이 짧아졌다면 한 세션에 모든 걸 몰아넣는 방식이 오히려 손해일 수 있다. 프로젝트를 잘게 나누고, 진짜 긴 문맥이 필요한 작업만 Claude Code에 넣는 편이 나을 수 있다.

3. 대체 경로 준비

지금은 한 도구에 올인하기보다 작업 종류별 라우팅이 현실적이다.

긴 설계/리팩토링: Claude Code
짧은 반복 작업: Gemini CLI 또는 Codex
문서 변환/정리: 별도 저비용 경로

도구를 모델 IQ로만 비교하지 말고, 작업당 비용 예측 가능성으로도 봐야 한다.

이 사건이 보여주는 더 큰 문제

내가 보기에 이건 Claude Code 하나의 사건으로 끝나지 않는다. 오히려 AI 서비스 전반의 오래된 문제를 다시 드러낸다.

바로 가격 투명성과 운영 투명성은 다르다는 점이다.

많은 서비스가 “토큰 단가”는 공개한다. 하지만 실제 사용자가 체감하는 비용은 토큰 단가만으로 결정되지 않는다.

캐시가 어떻게 계산되는지
TTL이 얼마나 유지되는지
quota가 어떤 식으로 차감되는지
background 작업이 어떤 비용으로 잡히는지
리셋 후 정책이 어떻게 반영되는지

이런 운영 레이어까지 보이지 않으면, 사용자는 결국 숫자를 믿지 못하게 된다.

AI 도구 시장이 성숙하려면 이제 단순 성능 경쟁을 넘어서야 한다. “누가 더 잘 쓰냐” 못지않게 “누가 더 예측 가능하게 과금하냐”도 중요해진다. 나는 오히려 이 문제가 앞으로 더 커질 거라고 본다. 성능 차이가 줄어들수록, 신뢰와 투명성의 가치가 더 커지기 때문이다.

결론: 지금 무너진 건 quota가 아니라 신뢰다

Claude Code 월 20만원 요금제가 90분 만에 바닥나는 사건은 웃고 넘길 버그가 아니다. 이건 Anthropic의 캐시 정책, quota 계산, 커뮤니케이션 방식이 동시에 시험대에 오른 사건이다.

사람들이 정말 화가 나는 이유는 비싸서가 아니다. 비싼데도 예측이 안 되기 때문이다. 그리고 캐시를 비용 절감 장치로 홍보하면서 실제 할당량 계산에선 그런 혜택이 체감되지 않는다면, 그건 단순 오해가 아니라 구조적 신뢰 손상에 가깝다.

한국 개발자 입장에서도 이건 꽤 큰 분기점이 될 수 있다. Claude Code가 계속 강한 도구인 건 맞다. 하지만 이제는 “제일 똑똑한가?”보다 “제일 믿고 예산을 짤 수 있는가?”가 더 중요한 질문이 된다.

내가 보기엔 이번 논란의 핵심은 결국 하나다.

이제 AI 도구는 성능만 좋다고 선택되지 않는다. 가격 구조와 운영 정책까지 설명 가능해야 선택된다.