Claude Code의 주간 이용 한도가 '가벼운 작업'만으로 하루 만에 소진되는 진짜 이유 — 소비의 99%는 코드가 아닌 문맥 재읽기였다

• 코드를 별로 쓰지도 않았는데, 주간 이용 한도가 하루 만에 100%에 도달한다
• 「가벼운 작업만 하고 있다」고 생각했는데, 오후에는 한도가 다 되어 차단된다
• 서포트에 문의해도 「한도는 리셋할 수 없습니다」라는 자동 답장만 돌아온다
• 비싼 요금을 내고 있는데, 정작 중요한 순간에 사용할 수 없다

이는 실제로 여러 이용자가 보고하고 있는 현상으로, 「확장 기능이 배경에서 워크스페이스를 계속 다시 읽고 있는 것 아닌가」, 「토큰 (Token) 계산이 틀린 것 아닌가」라며 버그를 의심하는 목소리가 많다.

하지만 이것이 버그인지, 아니면 자신의 사용 방식에 따른 결과인지 여부는 자신의 로컬 로그를 읽어보면 구분할 수 있다. 그리고 대부분의 경우, 원인은 의외의 곳에 있다. 코드의 양이 아니라, 문맥 (Context)의 재읽기다.

이 기사에서는 소비 내역을 스스로 측정하는 방법과, 「버그인가 아니면 기대한 대로인가」를 반증 가능한 형태로 구분하는 절차를 보여준다.

Claude Code는 각 요청의 토큰 (Token) 사용량을 ~/.claude/projects/**/*.jsonl에 전부 기록하고 있다. 각 행의 message.usage에는 다음 4가지 수치가 들어 있다.

• input_tokens: 새로 보낸 입력
• cache_creation_input_tokens: 캐시 (Cache)로의 쓰기
• cache_read_input_tokens: 캐시 (Cache)로부터의 읽기
• output_tokens: 모델이 생성한 출력

이 부분을 일별, 세션 (Session)별로 합산하면 무엇이 한도를 갉아먹고 있는지 눈에 보인다. 다음 스크립트는 읽기 전용이며, 아무것도 수정하지 않는다.

import json, os, glob, collections, sys
root = os.path.expanduser(sys.argv[1] if len(sys.argv) > 1 else "~/.claude/projects")
day, sess, msgs = collections.defaultdict(collections.Counter), collections.defaultdict(collections.Counter), collections.Counter()
...

실행하면 다음과 같은 형태의 출력이 나온다. 이것은 실제로 1주일 분량을 집계한 결과다.

2026-06-06 in=788,643 cache_write=18,908,737 cache_read=1,235,216,305 out=7,461,998
重いセッション msgs=927 cache_read=496,248,446 out=1,242,439

숫자를 보면 한눈에 알 수 있다. 하루 평균 cache_read가 12억 토큰 (Token) 규모인 것에 비해, output_tokens는 700만, cache_creation (쓰기)은 1,900만에 불과하다. 토큰 (Token) 양의 약 99%가 cache_read, 즉 캐시 (Cache)로부터의 읽기다.

왜 이렇게 되는가. Claude Code는 대화의 각 턴 (Turn)마다 그때까지 쌓인 문맥 (Context) 전체를 매번 다시 한번 모델에 보낸다. 시스템 지시 사항, 읽어들인 파일, 지금까지의 대화 이력——그 전부가 새로운 메시지마다 cache_read로서 재전송된다.

이 부분이 핵심이다. 소비는 「문맥의 크기 × 턴 (Turn) 수」로 결정된다. 작성한 코드의 행 수로는 결정되지 않는다.

따라서 「가벼운 작업만 했는데 한도가 소진된다」는 것은 모순도 무엇도 아니다. 큰 워크스페이스를 안고 있는 긴 세션 (Session)에서는, 사용자가 한 줄의 지시를 입력할 때마다 수백만 토큰 (Token)의 문맥 (Context)이 다시 읽힌다. 코드를 한 줄도 쓰지 않더라도 턴 (Turn)을 거듭할수록 소비는 불어난다. 「배경에서 항상 다시 읽고 있다」는 체감은 정확하며, 그것은 대부분의 경우 버그가 아니라 문맥 창 (Context Window)이 그런 구조이기 때문이다.

여기까지로 「설계대로의 소비」 가능성이 보였지만, 진짜 이상 현상을 부정하는 것은 아니다. 위 스크립트의 출력에서 다음 두 가지 점을 확인하면 구분할 수 있다.

• 무거운 세션이나 날짜가 자신이 실제로 사용한 시간과 일치하는가. 일치한다면 문맥 주도형 소비다. 당신의 사용 방식으로 설명이 가능하다 (대처법은 후술). 반면, 자신이 전혀 사용하지 않은 시간대나 세션에서 큰 소비가 나타난다면 그것은 진짜 이상 현상이다. 일별 표를 증거로 삼아 서포트에 보고할 가치가 있다. 「왠지 이상하다」보다 구체적인 표가 훨씬 더 잘 통한다.
• output_tokens (실제 생성)가 작은데 cache_read...

가 cache_read가 거대한가. 그렇다면 비용은 모델이 멋대로 대량 생성한 것이 아니라, 문맥 (Context)의 재읽기 때문이라고 확정할 수 있다.

메커니즘을 알면, 효과적인 대처법도 결정된다.

• 작업의 구분점에서 /clear를 사용한다. 이것이 가장 효과적이다. /clear는 쌓여있는 문맥을 버리기 때문에, 매 턴 (Turn) 재전송되는 양이 리셋된다. 하나의 거대한 세션 (Session)을 끊임없이 이어가는 것이 한도를 가장 빠르게 소진하는 사용법이다.
• 작업하는 폴더를 좁혀서 연다. 거대한 모노레포 (Monorepo)의 루트가 아니라, 지금 만지는 부분의 디렉토리 (Directory)에서 열면 문맥에 포함되는 양이 줄어든다.
• 초반 단계에서 읽어들인 거대한 파일에 주의한다. 한 번 문맥에 들어온 큰 파일은 그 이후의 매 턴마다 다시 읽힌다. 생성물이나 로그 중 거대한 파일이 섞여 있지 않은지 확인한다.

한 가지 오해하지 않았으면 하는 점이 있다. 가공되지 않은 cache_read의 수는 '양'이지, 달러나 한도 비용 그 자체는 아니다. 캐시 (Cache)로부터의 읽기는 출력 (Output)에 비해 토큰 (Token)당 가중치가 훨씬 가볍다. 그러니 '12억'이라는 숫자를 그대로 요금으로 읽지 말 것. 이 진단의 가치는 절대값이 아니라 귀속에 있다. 어떤 세션이 소비했는지, 그것이 자신의 실제 이용량과 일치하는지——그것을 확인하기 위한 도구다.

그럼에도 불구하고, 이용하지 않는 시간에 소비가 발생하고 있다면 그것은 당당하게 이상 현상으로 보고해도 좋다.

안전한 운용을 확인하는 패턴 (파괴적인 명령 방지, 설정 리뷰, 월간 체크리스트 등)은 무료인 cc-safe-setup에 모아서 두었다. 비용 사고도, 데이터 소실도, 우선 '자신의 로그로 사실을 확인하는 것'부터 시작하는 것이 가장 멀리 돌아가는 것 같지만 가장 빠른 길이다.