Claude Code 3개월 토큰 사용을 1차 소스로 분해해보니
지난 글(Claude Code 성능 저하 사태와 설정으로 대응하기)에서 4월 13일에 적용한 환경변수 변경에 대해 정리했습니다. 그 글이 나간 뒤로 2주가 지나면서 자연스럽게 궁금해진 게 하나 있었습니다. 정말 그 변경이 토큰 사용에 어떤 식으로 작용했을까. 그리고 그 이전 두 달은 도대체 어디에 토큰을 그렇게 태웠던 걸까.
먼저 한 가지 짚어둘 점이 있습니다. 저는 Claude Code를 구독 플랜으로 쓰고 있어서 실제 결제액은 정액이고, 본문에 등장하는 달러 수치는 ccusage가 LiteLLM 가격표 기반으로 환산한 API 환산 비용(calibrated cost)입니다. 실제로 청구된 금액이 아니라 토큰 사용 강도를 정규화해서 보여주는 지표로 보면 됩니다. 즉 이 글이 분해하는 진짜 대상은 “돈을 어디에 썼는가”가 아니라 “토큰을 어디에 태웠는가”입니다.
이번에는 3개월치 ccusage daily 데이터, ~/.claude/projects 아래에 쌓인 914개의 JSONL 트랜스크립트, settings.json의 mtime을 1차 소스로 두고, 추측을 빼고 측정값만으로 사용 패턴을 분해해봤습니다. 그 과정에서 처음 가졌던 가설 두 개 — “wireweave MCP 도입이 3월 토큰 폭증의 주범이다”, “4월에 토큰 사용량이 줄어든 건 캐시 재사용률이 좋아져서다” — 가 둘 다 데이터로 부정됐습니다. 한 발 더 들어가보니 “더 비싼 모델로 옮겨가서 환산 비용이 늘었다”는 또 다른 직관도 LiteLLM 가격표 앞에서 들어맞지 않았습니다. 무엇이 진짜 동력이었는지를 같은 1차 소스로 좁혀가는 과정이 이번 글입니다.
이 글은 Claude Code 시리즈의 세 번째 글입니다. ① 하네스 엔지니어링, Claude Code 유출 사건으로 알게 된 것들 → ② Claude Code 성능 저하 사태와 설정으로 대응하기 → ③ 이 글(데이터 검증 후속).
TL;DR
- 2월~4월 누적 API 환산 비용은 $19,908입니다(구독 플랜이라 실제 결제액 아님, 토큰 사용 강도 지표). 월별로 보면 2월 $1,337, 3월 $10,950, 4월 $7,743이고 3월이 단일 월 최대로 전체의 55%를 차지합니다.
- 3월 환산 비용의 92.2%($10,100)가 opus-4-6 단독입니다. 다만 LiteLLM 가격표상 opus-4-5와 opus-4-6의 단가는 동일($5 input / $25 output per Mtok)이므로, 이 폭증의 동력은 모델 단가가 아니라 opus-4-6로 처리한 작업량 자체의 증가입니다.
- 그 안에서 3/20~3/23 4일 연속 burn 클러스터가 또 한 번 비중이 큽니다. 이 4일이 합쳐서 $3,970으로 3월의 36.3%입니다.
- 4월 13일 settings.json 변경을 기점으로 변경 전(4/1~4/13, 13일) vs 변경 후(4/14~4/28, 14일)를 비교하면 단가는 $452/Mout → $135/Mout (-70.1%)로 떨어졌습니다.
- 같은 기간 input은 -54% 줄었는데 output은 +107% 늘었습니다. “같은 토큰으로 더 많은 결과물”이 1차 소스로 검증됩니다.
- cache 재사용률은 오히려 감소(42.3x → 35.2x)했습니다. 캐시 재사용에 덜 의존하는 방식으로 바뀌었음에도 효율이 올랐다는 뜻이라 오히려 더 주목할 만한 결과입니다.
- 변경 후 기간의 주력 모델은 opus-4-7(74.1%)로 바뀌었습니다. 4-6과 단가가 동일하므로 모델 전환 자체로 단가 효과는 없습니다. 다만 차세대 모델이 같은 작업에 토큰을 더 쓴다는 일반 경향을 가설로 두면, 측정값 -70%는 환경변수+워크플로우 변화 효과의 하한이고 실효 효과는 그 이상일 가능성이 있다는 해석이 가능합니다.
2월: wireweave MCP 도입과 비효율 자각
2월 환산 비용은 $1,337로 본격 폭증 전 단계입니다. 이 달의 의미는 비용 자체보다는 두 가지 사건에 있습니다.
첫째, wireweave MCP의 첫 도입입니다. JSONL tool_use 카운트로 보면 wireweave MCP 첫 사용 시각은 정확히 2026-02-21 08:05 KST, 프로젝트 A에서 시작됐습니다. 같은 주 안에 프로젝트 B, C로 빠르게 번졌습니다.1
둘째, MCP 비효율을 체감하기 시작한 시점입니다. 도입 당시 사용한 wireweave_render_html 도구는 렌더 결과(HTML 본문)를 그대로 LLM에 반환하는 형태였습니다. 화면 한 개당 수천에서 수만 토큰이 응답으로 주입되는 셈인데, 이 본문 반환 형태는 2월~4월 통산 387회 호출됐고, 2월 후반에는 이 형태가 주력이었습니다.
한 가지 짚어둘 만한 사실은 2월부터 이미 opus-4-5가 비용의 84.8%를 차지하고 있었다는 점입니다. opus 의존은 분석 시작 시점부터 있었습니다. 2월을 “비용 폭증의 시작”이라고 부르기에는 약하고, 그보다는 3월 다중 cwd 확장의 도화선이 만들어진 달로 보는 게 1차 소스에 더 가깝습니다.
3월: 폭증의 진짜 동력 — 모델, 멀티 cwd, 4일 burn
3월은 단일 월 기준으로 3개월 누적 비용의 55%를 차지한 달입니다. 3월 폭증을 1차 소스로 분해하면 변수의 비중이 비대칭입니다.
wireweave를 파일 반환 방식으로 패치한 시점
3/4~3/5 사이 wireweave 호출량이 27회 → 12회로 급감했다가, 3/9부터 다시 폭발적으로 늘면서 동시 5~7개 cwd로 확장됩니다. 2월~4월 합산 도구별 호출 분포는 다음과 같습니다.
| 도구 | 호출 수 | 비중 |
|---|---|---|
wireweave_render_html_file (파일에 쓰고 경로만 반환) |
511 | 33.9% |
wireweave_render_html (HTML 본문 직접 반환) |
387 | 25.7% |
| cloud_* 시리즈 | 322 | 21.4% |
파일 반환 형태가 본문 반환 형태보다 호출 수가 많습니다. 즉 “html을 파일로 쓰고 경로만 반환”하는 방식으로 갈아탄 패치가 1차 소스로 확인되고, 그 이후 와이어프레임 생성량 자체가 늘면서 14개 cwd로 채택이 확산됐습니다.
그러나 폭증의 가장 큰 단일 변수는 wireweave가 아닙니다
ccusage modelBreakdowns로 3월 비용을 분해하면 이렇습니다.
| 모델 | 3월 비용 | 점유율 |
|---|---|---|
| claude-opus-4-6 | $10,100.50 | 92.2% |
| claude-opus-4-5 | $606.38 | 5.5% |
| claude-sonnet-4-6 | $123.39 | 1.1% |
| claude-haiku-4-5 | $97.27 | 0.9% |
2월(opus-4-5 84.8%, $1,134)에서 3월(opus-4-6 92.2%, $10,100)로 넘어가면서 opus 비용만 $8,966 증가했습니다. 이게 3월 폭증분의 92.0%입니다.
처음에는 이 결과를 보고 “4-5에서 4-6로 넘어가면서 더 비싼 모델을 쓴 영향이 컸겠구나”라고 생각했습니다. 그런데 LiteLLM 가격표(model_prices_and_context_window.json)를 직접 확인해보니 두 모델의 단가는 완전히 동일합니다.2
| 항목 | claude-opus-4-5 | claude-opus-4-6 |
|---|---|---|
| input | $5 / Mtok | $5 / Mtok |
| output | $25 / Mtok | $25 / Mtok |
| cache-create | $6.25 / Mtok | $6.25 / Mtok |
| cache-read | $0.5 / Mtok | $0.5 / Mtok |
단가가 같다면 비용 증가는 단가 차이가 아니라 토큰 사용량 차이에서 옵니다. 즉 폭증의 동력은 “더 비싼 모델로의 이전”이 아니라 “더 많은 작업을 4-6로 처리한 것”입니다. 다만 ccusage 단일 데이터로는 분리되지 않는 항목이 하나 남습니다. 동일 작업을 4-5로 했을 때와 4-6로 했을 때의 토큰 소모량 차이입니다. 제 데이터는 4-5와 4-6를 같은 작업에 나란히 돌린 대조군이 없으므로 이 항목은 측정 불가로 남깁니다. 분리할 수 있는 것까지만 분리한 결론은 다음과 같습니다.
- 측정 가능한 1차 소스 사실: 3월 opus-4-6 토큰 사용량이 2월 opus-4-5 대비 약 9배로 늘었고, 그 결과 opus 라인 비용이 $1,134 → $10,100로 증가했다.
- 측정 불가: 같은 작업당 4-6의 토큰 소모량이 4-5보다 더 많은지 여부. 이 항목은 제 데이터로 분리 불가.
wireweave 채택 확장은 누적 약 $1,460으로 13% 정도 부수 요인이고, 결정적인 변수는 opus-4-6로 처리한 작업량 자체의 폭증이었습니다.
3/20~3/23 4일 연속 burn 클러스터
ccusage daily에서 burn day를 “1.5×월평균 초과”로 정의하면 3월의 burn day는 8일이고, 그중 4일이 연속으로 몰렸습니다.
| 일자 | 비용 | 주요 모델 |
|---|---|---|
| 3/20 | $775.55 | opus-4-6 |
| 3/21 | $914.36 | opus-4-6 |
| 3/22 | $1,034.04 | opus-4-6 |
| 3/23 | $1,246.70 | opus-4-6 |
| 합계 | $3,970.65 | = 3월의 36.3% |
이 4일 동안 어떤 세션이 돌고 있었는지 calibrated cost 기준으로 Top 10을 뽑아보면 다음과 같습니다.1
| cost | 세션 UUID | 프로젝트 | 메시지 / 기간 |
|---|---|---|---|
| $449.87 | 24aa132b | B | 1,654 msgs / 3/21-3/23 |
| $331.77 | 8bab1862 | D | 1,371 msgs / 3/20-3/23 |
| $254.81 | 6d38bf17 | E | 807 msgs / 3/20-3/21 |
| $217.56 | 4ca1684f | F | 1,014 msgs / 3/22-3/23 |
| $215.07 | d9860d4e | C | 4,936 msgs / 3/23 단 하루 |
| $181.61 | 8d361135 | G | 951 msgs / 3/20-3/22 |
| $159.85 | 474431e4 | H | 871 msgs / 3/22-3/23 |
| $137.93 | 2d70f22f | A | 652 msgs / 3/22-3/23 |
| $134.81 | e513356e | H | 923 msgs / 3/22 단일 |
| $125.88 | cc04a080 | B | 877 msgs / 3/20-3/21 |
여기서 눈에 띄는 게 몇 가지 있습니다. 3/23의 d9860d4e 세션은 한 cwd에서 단 하루에 4,936 메시지가 쌓였습니다. 학습앱 webview 자동화 작업이 하루 동안 폭주한 패턴입니다. 프로젝트 B는 4일 내내 두 세션을 연속 가동(24aa132b, cc04a080)하면서 인디케이터 시각화 + wireweave 멀티 화면 생성 워크로드가 burn의 핵심을 차지했습니다. 그리고 wireweave 도구를 자체 개발하던 프로젝트 H의 세션(474431e4, e513356e)이 같은 기간에 동시 진행됩니다. 도구를 “쓰는” 프로젝트와 도구를 “만드는” 프로젝트가 옆에서 같이 돌고 있던 셈입니다.
burn day Top 15 중 14개가 opus-4-6 단독 95% 이상이라는 점도 일관됩니다. burn의 본질은 결국 “Opus 4-6를 장시간 돌린 날”로 정리됩니다.
3월 폭증을 한 줄로 요약하면 이렇습니다. opus-4-6라는 모델을, 멀티 cwd로 동시에, 그것도 4일 연속 burn으로 돌린 달. 단가가 비싸진 게 아니라 같은 단가로 토큰을 훨씬 더 많이 태운 달이라는 게 1차 소스의 결론입니다.
4월: 환경변수 + 워크플로우 — 같은 토큰, 더 많은 아웃풋
4월은 변경 전 / 변경 후 분기점이 분명합니다. ~/.claude/settings.json의 mtime이 정확히 2026-04-13 10:18:47 KST입니다. 이 시점을 기준으로 변경 전(4/1~4/13, 13일) vs 변경 후(4/14~4/28, 14일)를 비교하면 다음과 같습니다.
| 지표 | 변경 전 | 변경 후 | 변화 |
|---|---|---|---|
| 총 환산 비용 | $4,786.90 | $2,956.46 | −38.2% |
| Output tokens | 10,589,203 | 21,889,623 | +106.7% (2.07배) |
| Total tokens | 7.46B | 3.80B | −49.1% |
| $/M output | $452.10 | $135.06 | −70.1% (3.35배 절감) |
| Cache reuse 비율 | 42.3x | 35.2x | −16.8% (감소) |
settings.json에 들어간 환경변수
지난 글에서 정리한 변경이 그대로 적용된 상태입니다.
{
"effortLevel": "high",
"env": {
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
"CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1",
"MAX_THINKING_TOKENS": "95000"
}
}
이 변경 자체가 어떤 맥락에서 나왔는지는 지난 글에 정리해뒀습니다. 핵심은 Anthropic 측의 무공지 변경(Effort Level 기본값 high → medium, Adaptive Thinking 도입, 1M Context 자동 적용)에 대한 사용자 측 1차 대응이었다는 점입니다.
효율화의 진짜 메커니즘 — 캐시가 부풀지 않게 만든 워크플로우
처음에는 “비용이 줄었으니 캐시 재사용률이 좋아진 게 가장 큰 동력이겠구나” 하고 추정했습니다. 변경 후 기간에 opus-4-7로의 모델 전환이 동시에 일어났으니 자연스러운 가설이었습니다. 그런데 데이터는 정반대였습니다. 캐시 재사용률이 변경 전 42.3x → 변경 후 35.2x로 오히려 감소합니다. “캐시를 더 잘 재사용해서 효율이 올랐다”는 가설이 부정된 셈인데, 거꾸로 보면 캐시 재사용에 덜 의존하는 방식으로 바뀌었는데도 효율이 올랐다는 뜻입니다. 그렇다면 비용을 줄인 진짜 동력이 무엇인지 다시 찾아야 합니다.
가장 설명력이 높은 지표는 total/output 비율입니다.
| 지표 | 변경 전 | 변경 후 | 의미 |
|---|---|---|---|
| total tokens / output token | 16.3 | 4.77 | 3.4배 개선 |
해석은 이렇습니다. 변경 전 기간에는 AI-DLC 기반 워크플로우를 스킬 형태로 시작해 aidlc-plugin으로 발전시키며 쓰고 있었습니다. 이 파이프라인은 단계별 보고서(project-goal-report.md, plan.md, harness-report.md 등)를 누적해가며 진행되는 구조라, 세션이 새로 시작될 때마다 이전 산출물 문서들을 다시 읽어와 컨텍스트를 재구성해야 했고, 그 결과 거대한 문서 컨텍스트가 매 세션 시작마다 cache prefix로 들어갔습니다. 1M Context 기능이 도입된 직후라 한동안 그걸 유지했던 점도 prefix를 더 키웠습니다. 변경 후엔 작업 관리 도구를 도입하면서 active task의 상태 자체가 컨텍스트 역할을 하게 됐고, 매번 문서를 재read할 필요가 없어지면서 cache prefix가 작게 유지됩니다. 같은 캐시를 또 읽기보다, 캐시 자체를 작게 가져가면서 한 컨텍스트에서 더 많은 결과물을 만드는 방향으로 일하는 방식 자체가 바뀐 셈입니다.
한 가지 보강해두고 싶은 메커니즘이 있습니다. Anthropic prompt caching은 prefix 단위로 동작하기 때문에 매 요청마다 캐시 prefix 전체를 강제로 read합니다. read하지 않을 선택지는 없습니다. Claude Code 특성상 한 세션 안에서 시스템 프롬프트, 도구 정의, 대화 히스토리, 도구 호출 결과가 계속 누적되고, 매 turn마다 그 누적분이 cache prefix로 들어갑니다. 즉 세션이 길어질수록 prefix가 부풀고, 매 turn의 cache read 비용도 같이 커집니다. 그 상태에서 짧은 응답을 받는 패턴이 반복되면 output 1개당 들어가는 total 토큰이 부풀어 — 변경 전 16.3 같은 숫자가 나옵니다. 그래서 단순히 “캐시 = 효율”이 아니라, 작업 패턴에 따라 캐시는 자산이 되기도 하고 부채가 되기도 합니다. 캐시를 작게 유지하는 것 자체가 효율 전략이 되는 이유입니다.
이 워크플로우 변화를 구체적으로 받쳐준 도구가 하나 있습니다. 직접 만들고 있는 Clawket이라는 작업 관리 레이어입니다.
활성 태스크 없이는 코드 변경 자체를 시작하지 못하게 막고, 결정과 작업 히스토리를 로컬 SQLite에 영구 저장합니다. 그 결과 한 세션이 “지금 무엇을 해야 하는지”가 명시적으로 정의된 상태로 시작되고, 컨텍스트도 작업 단위로 좁혀집니다. 자동 메모리(CLAUDE_CODE_DISABLE_AUTO_MEMORY)를 끈 빈자리를 명시적인 작업 정의가 메우는 셈이고, “한 컨텍스트에서 한 작업을 끝까지 끌고 가는” 패턴 자체가 토큰 효율화에 직접 작용했다고 보고 있습니다.
환경변수와 워크플로우 — 어느 쪽이 진짜 동력인가
A/B 테스트가 없으니 단일 변수의 정량 기여도를 분리하는 건 불가능합니다. 다만 1차 소스로 검증되는 명제 몇 가지는 있습니다.
| 명제 | 판정 | 근거 |
|---|---|---|
| 환경변수 변경 직후 단가 즉시 하락 | ✅ | 4/13 $676/Mout → 4/14 $193/Mout (단일일 71% 절감) |
| 1M Context 차단이 token 총량 감소에 기여 | ✅ 강한 정황 | total tokens −49% |
| AUTO_MEMORY 비활성화가 input 폭주 차단 | ✅ 강한 정황 | input −54% |
| 단일 변수 정량 기여도 분리 | ⚠️ 단정 불가 | 5개 환경변수 + 워크플로우 + 모델 동시 변화 |
결론은 두 트리거가 동시에 작용했다는 쪽입니다. 환경변수 변경 다음 날(4/14)부터 단가가 즉시 변경 전 평균의 43% 수준으로 떨어졌다는 사실은 환경변수 효과의 강한 증거이고, 같은 기간 output이 +107%로 늘었다는 사실은 워크플로우(탐색→구현 비중 이동)가 동시에 작용했다는 증거입니다. 어느 한쪽으로 단정하지 않고 둘 다의 합작이라고 보는 게 데이터에 가장 충실합니다.
그리고 한 가지 더 — opus-4-7의 “숨은 토큰” 가설
변경 후 기간 모델 mix를 다시 보면 opus-4-7이 74.1%로 주력입니다. opus-4-6과 opus-4-7의 LiteLLM 단가는 완전 동일($5 input / $25 output / $6.25 cache-create / $0.5 cache-read per Mtok)이라, 모델 전환 자체로 단가가 바뀐 건 없습니다.
다만 일반적으로 알려진 경향이 하나 있습니다. 차세대 모델은 같은 작업에 reasoning/thinking token을 더 쓰는 쪽으로 설계되는 경우가 많다는 점입니다. 4-6 vs 4-7의 실제 토큰 소비 차이는 제 데이터로는 분리할 수 없습니다 — 같은 작업을 두 모델로 나란히 돌린 대조군이 없기 때문입니다. 이 경향을 가설로 두면 다음 추론이 따라옵니다.
opus-4-7이 같은 작업에 토큰을 더 쓴다는 가정이 맞다면, ccusage가 측정한 효율화(-70.1%) ≤ 환경변수 + 워크플로우 변화의 실효 효율화
같은 결과물을 만드는 데 토큰을 더 쓰는 모델로 옮겨갔는데도 절대 비용이 70% 줄었다면, 환경변수 + 워크플로우 변화가 그 추가 토큰까지 상쇄하고 70%를 낸 셈이기 때문입니다. 즉 측정값 -70%는 두 변수 효과의 하한이고, 실효 효과는 그 이상일 가능성이 있습니다. 어디까지나 검증되지 않은 가설이지만, 데이터를 보수적으로 해석할 여지는 남겨두는 게 맞다고 봅니다.
마치며
4월 13일 환경변수 변경과 워크플로우 패턴 전환이 동시에 작용해 단가는 $452 → $135/Mout (-70.1%), output은 +107%로 바뀌었습니다. 환경변수 설정과 워크플로우 변화가 함께 토큰 효율화를 가져왔다고 잠정 판단하고, 앞으로도 같은 방식으로 계속 관찰해볼 생각입니다. 다만 이건 변경 후 14일치 데이터에 기반한 잠정 결론이고, 앞으로 2~3개월 동안 적은 input + 높은 output 패턴이 유지되어야 더 강한 증거가 됩니다.
비용 자체보다도, “이 비용에서 무엇이 결과물을 만들었고 무엇은 그렇지 못했는가”를 1차 소스로 분해해보는 작업이 의미 있었습니다. 여러분도 한번 ccusage daily와 ~/.claude/projects 트랜스크립트를 직접 들여다보는 건 어떨까요. 막상 해보면 평소 감으로 짐작하던 그림과는 다른 게 보입니다.
본 분석은 ccusage daily/session,
~/.claude/projects914개 JSONL 트랜스크립트, settings.json mtime, 그리고 지난 글을 1차 소스로 작성됐습니다. 비용 수치는 LiteLLM 가격표 기반 ccusage 계산값입니다.
-
본문 프로젝트 표기는 익명화했습니다. A: e-torch / B: trading-bot/indicator-live / C: 학습앱(learning-app frontend, learning-webview-free) / D: demowriter-ai / E: pengent / F: toolypet-project / G: pixel-office / H: wireweave-studio. ↩ ↩2
-
LiteLLM
model_prices_and_context_window.json(claude-opus-4-5-20251101-v1:0,claude-opus-4-6-v1,claude-opus-4-7항목, 2026-04-28 시점 확인). BerriAI/litellm GitHub. ↩