Claude Code의 토큰 96.3%가 '재읽기'였다는 사실 — 효과적인 대책과 정확한 측정 방법
요약
Claude 사용 시 토큰 소비의 대부분(96.3%)이 실제 작성된 내용이 아닌 '과거 문맥 재읽기'에서 발생한다는 사실을 측정했습니다. 이는 대화가 길어질수록 턴당 재읽기량이 증가하는 구조적 문제이며, 단순히 프롬프트나 문서 길이를 줄이는 방식으로는 해결하기 어렵습니다.
핵심 포인트
- 토큰 소비의 주범은 '과거 문맥 재읽기'입니다 (96.3%).
- 대화가 길어질수록 턴당 재읽기량이 증가하는 구조적 문제입니다.
- 소비량 관리는 전체 평균보다 '특정 세션의 편중도'를 분석해야 합니다.
- 효율 개선을 위해서는 가장 많은 토큰이 사용된 상위 세션을 집중적으로 관리해야 합니다.
정액 플랜인데 주간 상한에 도달한다. 혹은 API 청구가 생각보다 늘어나 있다.
이럴 때, "무엇에 토큰을 사용했는지"를 한 줄로 설명할 수 있습니까?
저는 할 수 없었습니다. 그래서 측정했습니다. 결과는 상당히 의외였고, 그리고 제가 의심했던 범인은 모두 헛수고였습니다.
먼저 결론부터 말씀드립니다. 제 소비의 **96.3%는 제가 작성하게 한 글이 아니라 '과거 문맥의 재읽기'**였습니다.
그리고 5주 후, 운영을 검토한 뒤 Claude에게 다시 측정하게 하니 "86% 감소했습니다. 운영 개선이 효과가 있었습니다"라고 보고해 왔습니다.
하지만 저는 "그 주에는 애초에 많이 사용하지 않았던 것 아닌가?"라는 의문이 들었습니다.
측정 기준을 바꿔서 다시 측정하자, 개선은 진짜였습니다. 다만 86%가 아니라 약 2할이었습니다.
이 글의 후반부는 효과를 정확하게 재측한 기록입니다.
📊 먼저 내역을 봐주세요
ccusage로 7일간 집계했을 때의 실측치입니다(2026-08-03~09).
| 항목 | 비율 | 내용 |
|---|---|---|
| cache read | 96.3% | 과거 대화 기록・CLAUDE.md・도구 정의 재읽기 |
| cache write | 3.3% | 새로 캐시한 분 |
| output | 0.4% | Claude가 실제로 작성한 글 |
| input | 0.0% | 제가 입력한 글 |
총 토큰 756,517,508 중, cache read가 728,779,326입니다.
제가 입력한 글은 반올림하면 0.0%입니다. 7.5억 토큰 중, 인간이 입력한 분은 오차였습니다.
# 자신의 환경에서 측정하기(설치 불필요)
npx ccusage@latest daily --since 20260908
# 세션별 편중까지 보기
...
주: 저는 정액 플랜이므로, ccusage가 보여주는 금액은 청구액이 아니라 API 환산 상당액입니다.
봐야 할 것은 금액보다 비율 쪽입니다.
🔍 왜 '재읽기'가 9할을 넘는가
한 번 캐시에 올라간 문맥은 다음 턴에서 0.1배의 단가로 재읽힙니다. 단가는 저렴합니다.
문제는 횟수입니다.
cache read ≒ 컨텍스트 양 × 턴 수
30번째 턴의 한 번 답변에서도, 그까지의 전체 기록을 재읽습니다. 그래서 같은 세션을 계속할수록,
1턴당 재읽기량이 늘어갑니다. 토큰 소비는 대화 길이에 비례하여
2차적으로 작용합니다.
여기서 제가 오해했던 것을 고백합니다. 저는 범인을 "CLAUDE.md가 길다는 것"과 "외부 도구를 너무 많이 호출하는 것"이라고 생각했습니다. 둘 다 틀렸습니다.
- CLAUDE.md는 확실히 매 턴 과금되지만, 수백 토큰에 불과합니다. 96.3%에는 전혀 미치지 못합니다 -
- 출력(0.4%)을 줄여도 의미가 없습니다. 애초에 소비하지 않고 있는
cache read와 output의 비율은 307배였습니다. 1토큰 작성하게 하려면, 307토큰을 재읽고 있습니다.
줄일 대상을 잘못 잡으면, 노력해도 비율은 1밀리도 움직이지 않습니다.
⚠️ 진짜 문제는 '평균'이 아니라 '편중'이었습니다
여기서 이 글에서 가장 전하고 싶은 것입니다. 세션별로 분해하면, 소비는 균등하지 않았습니다.
| 지표 | 실측 | |
|---|---|---|
| 단일 세션의 cache read | 4억 토큰 = 전체의 41.6% | |
| ... | ||
| 단 하나의 세션이, 그 주의 4할을 차지하고 있었습니다. |
이런 형태라면, "전체를 옅게 하는" 종류의 시책은 거의 효과가 없습니다. CLAUDE.md를 절반으로 하거나,
프롬프트를 짧게 해도, 효과가 있는 것은 남은 18% 쪽뿐입니다. 효과를 보고 싶다면, 상위 5개 마라톤 세션을 어떻게든 해야 합니다.
저는 이 숫자를 보고, 검토하던 "다른 회사의 유료 AI 플랜을 추가하는" 것을 그만두었습니다.
소비의 96.3%는, 엔진을 늘려도 줄지 않습니다. 줄어드는 것은 output과 input, 즉 합쳐서 0.4% 쪽뿐입니다.
🛠️ 그래서, 효과가 있는 순서는 이렇습니다
실측에서 도출한 우선순위입니다.
- 세션을 끊기 (— 단독으로 최대. 길이에 비례하여 2차적으로 작용하는 것을 선형으로 되돌리는
/clear)
)
- 검색을 서브 에이전트에게 위임— 조사 과정에서 메인 컨텍스트를 오염시키지 않고, 결론만 받아낸다.
- CLAUDE.md를 간결하게 유지하고 MCP의 원본 JSON을 줄인다— 효과는 좋지만, 자릿수가 한 자리 작아진다.
두 번째에 주의할 점이 있습니다. 서브 에이전트가 무조건적으로 좋은 것은 아닙니다.
1만 토큰을 읽게 하고 8천 토큰의 상세 보고서를 받았다면, 얻는 것은 고작 2천 토큰 분량입니다.
'무엇을 판단하고 싶은지'를 지정하여 결론만 받아내는 것이 전제 조건입니다.
그리고 1~2 파일로 끝나는 자명한 작업에서는 에이전트 구동 비용 자체가 더 높게 나갑니다.
임계치(Threshold)가 필요합니다.
⏱️ 5주 후, Claude는 '86% 감소했습니다'라고 말했습니다
여기부터가 이번의 새로운 내용입니다.
위의 우선순위에 따라 운영 방식을 바꾼 후, 5주 뒤에 Claude에게 동일한 집계를 요청했습니다. 결과는 다음과 같았습니다.
| 지표 | 2026-08-09 | 2026-09-15 |
|---|---|---|
| 주당 총 토큰 | 7.57억 | 1.06억(-86%) |
| cache read 비율 | 96.3% | 91.2% |
| cache read / output 비율 | 307배 | 89배 |
Claude의 보고는 이렇습니다. “비율은 작업량에 의존하지 않는 지표이므로, 307배에서 89배로 줄어든 것은 운영 개선의 성과입니다”.
논리적으로 맞습니다. 기사 초안에도 일단 그대로 작성했습니다.
하지만 제 체감과는 맞지 않았습니다. 이번 주에는 애초에 Claude Code를 많이 열지 않았기 때문입니다.
“그거, 우연히 한가했던 주였잖아?”라고 답하고 다음 주도 재측정했습니다.
🔍 자(物差し)를 '세션당'으로 바꿔서 다시 측정하다
다음 주(2026-09-15~21)에도 측정했고, 배열 방식을 바꿨습니다. 총량이 아니라, 세션 수와 세션 '당' 읽기 양으로 봅니다.
| 기간 | 세션 수 | 세션당 cache read | read/output 비율 |
|---|---|---|
| 2026-08-0309 | 34 | 2,896만 | 296배 |15 | 11 | 701만 | 131배 |
| 2026-09-08
| 2026-09-15~21 | 13 | 2,301만 | 186배 |
읽는 방법은 이렇습니다.
- 총 토큰의 −86% 감소는 대부분 세션 수 감소(34 → 11) 때문입니다. 그 주는 사용한 양 자체가 적었던 평범한 주들(8월과 9/15~21)을 비교하면, 세션당 읽기 양은 2,896만에서 2,301만으로 약 2할 감소했고, read/output 비율도 296배에서 186배로 약 4할 하락했습니다.
개선은 진짜였습니다. 다만 Claude가 말한 '86%'가 아니라, 약 2할입니다.
1주 단위 비교이므로 이 2할에도 편차가 있습니다. 그래도 앞서 언급했던 대책들은 효과를 보는 방향으로 움직이고 있었습니다.
왜 첫 번째 자(物差し)는 과장되었나
read/output 비율은 (컨텍스트 양 × 턴 수) / 출력량입니다.
여기에 세션의 **'길이'**가 들어갑니다.
- 한가한 주 = 짧은 질문 세션이 많음 = 턴 수가 적음 =
비율은 자연스럽게 하락-
바쁜 주 = 마라톤 세션이 진행됨 =
비율은 자연스럽게 상승
즉, read/output 비율은 **운영의 좋고 나쁨뿐만 아니라, 그 주의 작업
같은 주를 측정해도 96.3%와 96.5%로 차이가 납니다. 비교하는 표는 집계 방법을 통일해 주세요.
참고로 전체 기간(207 세션, 약 27.9억 토큰)에서는 cache read가 **94.9%**였습니다.
역대 최고 기록의 세션은 4억 토큰으로, 여전히 전체의 **15.1%**를 단 한 번의 세션으로 차지하고 있습니다.
이 1회성 세션을 만든 것은 8월 4일이며, 한 달 반이 지났는데도 통계에서 사라지지 않습니다.
💡 요약
- Claude Code의 소비는
**9할 이상이 cache read(과거 문맥 재읽기)**입니다. 출력은 0.5% 미만-
cache read ≒ 컨텍스트 양 × 턴 수
따라서, 긴 세션이 간접적으로 효과적입니다. 소비가 균등하지 않고
편향되어 있습니다. 상위 5개 세션에서 약 8할을 차지합니다. 평균을 낮추는 방안은 효과가 없습니다 - 효과적인 순서는 ①세션을 끊기 ②탐색을 위임하기 ③CLAUDE.md나 MCP를 줄이기
실제로 효과가 있었습니다. 다만 세션당 약 2할 정도입니다. 총 토큰의 86% 감소는 그 주에 사용한 양이 적었기 때문입니다 -
AI의 '개선되었습니다'라는 말은, 해당 주의 문맥을 모른 채 나옵니다. 체감과 다르다면 의심하세요 -
'비율로 했으니 작업량에 의존하지 않는다'는 함정입니다. 분모에 자신이 바꾸고 싶은 변수가 섞여 있지는 않은지 확인해야 합니다
측정 전의 저는 범인을 '긴 CLAUDE.md'라고 생각했지만, 그것은 틀렸습니다.
다시 측정하기 전의 Claude는 '86% 감소했다'고 말했는데, 그것은 과장되었습니다. 두 경우 모두, 기준을 확인하지 않고 말한 부분만 차이가 납니다.
먼저 npx ccusage@latest daily
를 한 번 쳐보세요. 1분이면 끝납니다.
그리고 효과를 볼 때는, 총량이 아니라 세션당으로 봐야 합니다. 일주일 단위로 결론을 내리지 말고,
AI가 '크게 줄었습니다'라고 말한다면, 그 주의 자신을 떠올려 보세요.
💬 당신의 비율은 어땠나요?
cache read의 비율과, 상위 1개 세션이 차지하는 비중을 꼭 알려주세요.
만약 '저희는 output이 더 많다'라는 환경이라면, 무엇이 다른지 정말 알고 싶습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기