저는 Claude Code 청구 금액을 볼 때마다 계속 놀라곤 했습니다. "충격적"이라기보다는 "의외"라는 표현이 맞을 것 같습니다. 짧은 리팩터링 (refactor)은 예상했던 만큼의 비용이 들었지만, 긴 디버깅 (debugging) 세션은 조용히 그보다 10배나 더 많은 비용을 발생시켰고, 대시보드만 봐서는 그 _이유_를 알 수 없었습니다. 총액만으로는 설명이 되지 않으니까요.

그래서 저는 지루한 작업을 시작했습니다. 제 로그를 직접 파싱 (parse)한 것입니다. Claude Code는 ~/.claude/projects/ 경로 아래의 모든 세션에 대해 JSONL 트랜스크립트 (transcript)를 작성하며, 그 안의 모든 모델 턴 (model turn)에는 입력 (input), 출력 (output), 그리고 결정적으로 캐시 읽기 (cache-read) 및 캐시 쓰기 (cache-write) 횟수를 포함한 토큰 수가 기록됩니다. 이 수치들에 공시된 가격을 곱하면 턴당, 세션당 비용 배분을 얻을 수 있습니다. 저는 실제 세션 66개를 대상으로 이를 실행했습니다 (비용이 발생한 세션, 즉 cost > 0 이면서 최소 3번 이상의 모델 턴이 있는 세션으로 필터링함).

그 결과는 다음과 같으며, 이는 단순히 "AI는 비싸다"라는 말보다 훨씬 흥미롭습니다.

모두가 인용하는 그 수치는 사실 서로 다른 두 가지 숫자입니다

Claude Code 비용에 관한 스레드를 읽어보셨다면, "지출의 대부분은 재전송된 컨텍스트 (re-sent context)이다"라는 주장을 보셨을 것입니다. 그것은 사실입니다. 하지만 얼마나 사실인지는 가중치를 세션 (session) 기준으로 두느냐, 아니면 달러 (dollar) 기준으로 두느냐에 따라 완전히 달라지며, 거의 아무도 자신이 어떤 기준을 말하는지 밝히지 않습니다.

제 데이터에 따르면:

• 중간값(median) 세션은 지출의 약 24%만을 캐시된 컨텍스트 (cached context)로 재전송합니다. 대부분의 세션은 짧습니다. 약 29번의 모델 턴을 거치며, 컨텍스트는 45k 토큰 근처에서 정점을 찍습니다. 짧은 세션에서는 컨텍스트가 아직 그렇게 많이 재전송되지 않았기 때문에, 모델의 실제 _출력 (output)_과 새로 작성된 컨텍스트가 상대적으로 더 큰 비중을 차지합니다. 재전송된 컨텍스트는 소수입니다.
• 66개 세션 전체를 통합했을 때, 재전송된 컨텍스트는 총 지출액의 60%를 차지합니다. 달러 기준으로 가중치를 두면, 소수의 매우 긴 롱 컨텍스트 (long-context) 세션들이 전체 금액을 압도하게 됩니다. 그리고 그러한 세션에서는 동일한 대규모 컨텍스트가 턴마다 반복해서 재전송되므로, 재전송된 컨텍스트 비용이 급격히 불어납니다.

두 수치 모두 실제입니다. 다만 서로 다른 질문에 답할 뿐입니다. "나의 전형적인 세션은 어떤 모습인가?" → 24%. "이번 달에 쓴 돈은 어디로 갔는가?" → 60%. 만약 누군가 다른 하나를 언급하지 않고 하나만 인용한다면, 그들은 이야기의 절반만 말하고 있는 것입니다.

다음은 66개 세션 전체를 통합한 분할 내역입니다 (총합: 4,339회의 모델 턴 (model turns) 동안 $2,650.90 지출):

제 총 지출 중 모델이 글을 쓰는 데 사용된 비용은 단 **15%**뿐이었습니다. 압도적인 대다수는 컨텍스트를 앞뒤로 주고받는 데 사용되었습니다.

왜 이런 일이 발생하는가 (신비로운 현상이 아니라 기계적인 원리입니다)

모델은 상태가 없는 (stateless) 특성을 가집니다. 턴 (turn) 사이에는 어떠한 기억도 유지하지 않습니다. 따라서 매 턴마다, 모델이 내용을 "기억"할 수 있도록 당신이 읽은 모든 파일, 모든 도구 결과, 모든 이전 메시지를 포함한 **전체 누적 대화 컨텍스트 (entire accumulated conversation context)**가 다시 전송됩니다.

프롬프트 캐싱 (Prompt caching)이 충격을 완화해 주기는 합니다. 즉, 재전송 시 전체 입력 비용이 아닌 할인된 캐시 읽기 (cache-read) 요율(전체 입력 가격의 약 10분의 1)로 청구됩니다. 하지만 여전히 매 턴마다, 전체 컨텍스트에 대해 비용을 지불해야 합니다. 따라서 세션이 길어질수록 다음과 같은 현상이 발생합니다:

• 컨텍스트 크기가 커지고,
• 턴당 재전송 비용도 함께 상승하며,
• 긴 세션에서는 턴의 횟수도 더 많아지기 때문에, 증가하는 턴당 비용에 증가하는 턴 횟수를 곱하게 됩니다.

이러한 복리 효과 때문에 비용이 집중되는 것입니다. 제 데이터 세트에서 세션의 중앙값은 컨텍스트 약 45k 토큰에서 정점을 찍었지만, 가장 무거웠던 단일 세션은 999,541 토큰에 달했습니다. 모든 세션의 평균 정점은 251,371 토큰이었습니다. 긴 세션은 일반적인 세션보다 한 자릿수(order of magnitude) 더 높은 수준에 도달하며, 해당 컨텍스트의 모든 토큰은 이어지는 모든 턴에서 재전송됩니다. 이들은 비용이 조금 더 드는 수준이 아니라, 청구서 그 자체를 결정합니다.

실제로 유용한 교훈

정직한 헤드라인은 "Claude Code는 비싸다"가 아닙니다. 다음과 같습니다:

몇몇 긴 세션이 비용을 많이 발생시키며, 그 과정에서 재전송된 컨텍스트가 청구서의 핵심이다.

그러한 관점의 전환은 대응 방식 자체를 바꿉니다. 저렴하고 짧은 세션들을 미세 최적화(micro-optimize)할 필요는 없습니다. 그것들은 이미 저렴하고 균형 잡혀 있기 때문입니다. 핵심적인 레버리지(leverage)는 전적으로 긴 컨텍스트 마라톤(long-context marathons)에 있습니다:

• 긴 세션에서는 /compact를 공격적으로 사용하세요. 이 명령은 누적된 컨텍스트를 요약하고 삭제하여, 매 턴마다 다시 비용을 지불하게 만드는 요소를 직접적으로 줄여줍니다. 긴 세션에서 더 빨리 컴팩트(compact)할수록, 더 큰 사이즈의 데이터를 다시 전송(re-send)하는 상황을 더 많이 피할 수 있습니다.
• 작업이 바뀌면 새로운 세션을 시작하세요. 200k 토큰의 컨텍스트를 관련 없는 새로운 작업으로 가져가는 것은, 새로운 작업의 매 턴마다 관련 없는 200k 토큰에 대해 다시 비용을 지불한다는 의미입니다. 새로운 세션을 시작하면 재전송 측정기(re-send meter)를 거의 0에 가깝게 시작할 수 있습니다.
• 누적 총액뿐만 아니라 컨텍스트의 증가량을 주시하세요. 총액은 이미 발생한 일을 알려주지만, *턴당 컨텍스트 크기(per-turn context size)*는 각 미래의 턴이 얼마만큼의 비용을 발생시킬지 알려줍니다. 컨텍스트가 수십만 토큰 단위로 올라가는 것이 보인다면, 그것은 컴팩트하거나 분할해야 한다는 신호입니다. 사후 처리가 아닌 사전에 조치해야 합니다.
• 캐시 효율성(cache efficiency)에 과도하게 매몰되지 마세요. 저의 중간 캐시 효율성은 약 83%(풀링 시 98%)였으며, 이는 매우 훌륭하게 들립니다. 하지만 캐시 효율성은 단지 재전송 비용이 얼마나 저렴한지를 알려줄 뿐, 얼마나 많이 재전송하고 있는지를 알려주지는 않습니다. 캐시 효율성이 98%라 하더라도 엄청난 양의 컨텍스트를 백 번씩 효율적으로 재전송하고 있다면 여전히 돈을 낭비하고 있는 것일 수 있습니다. 주시해야 할 지표는 캐시 히트율(cache hit rate)이 아니라, *지출액 중 재전송된 컨텍스트가 차지하는 비중(share of spend)*입니다.

제가 강력하게 강조하고 싶은 주의 사항

이것은 헤비 유저(heavy user) 한 명의 데이터 — 즉, 일련의 프로젝트들을 구축하며 발생한 저의 데이터입니다. 이것은 하나의 _참조 세트(reference set)_일 뿐, 모든 Claude Code 사용자를 대상으로 한 전수 조사나 대표성 있는 설문 조사가 아닙니다. 구체적인 수치(중앙값 $4.08, 24%/60%의 비율)는 사용량이 적은 사용자, 다른 기술 스택, 또는 다른 가격 정책에 따라 달라질 것입니다. 저는 어떠한 편집, 조정, 큐레이션도 하지 않았습니다. 이것은 도구의 가공되지 않은 출력값(raw output)입니다. 다만, 개인이 직접 측정한 단일 소스는 본질적으로 범위가 좁으므로, 데이터의 _형태(shape)_를 결과로 받아들이고 _수치(numbers)_는 본인의 로그와 대조하여 검증하시기 바랍니다.

구조적인 부분 — 즉, 비용이 몇 개의 긴 세션에 집중되며, 재전송된 컨텍스트(re-sent context)가 이를 지배한다는 점 — 은 상태 비저장 모델(stateless models)과 턴당 컨텍스트 재전송(per-turn context re-send)의 특성입니다. 이 점은 광범위하게 적용될 것입니다. 정확한 백분위수는 단지 저의 세션 결과일 뿐입니다.

직접 측정하고 싶다면

저는 이 분석을 수행하기 위해 작은 CLI(Command Line Interface) 형태의 파서(parser)를 작성했으며, 이는 오픈 소스로 공개되어 있습니다. 여러분의 지출이 어디로 가는지 확인하려면 다음을 실행하세요:

npx @wartzar-bee/tokenscope

이 도구는 사용자의 Claude Code 로그를 로컬에서 읽습니다 — 읽기 전용이며, 네트워크 연결이나 텔레메트리(telemetry)가 없고, 아무것도 사용자의 기기를 벗어나지 않습니다 — 그리고 동일한 분석 결과(출력(output) vs 재전송된 컨텍스트(re-sent context) vs 새로운 컨텍스트(new context), 턴당 컨텍스트 성장 곡선, 그리고 위 66개 세션 참조 세트 대비 사용자의 세션이 어느 백분위에 해당하는지)를 출력합니다. --share 옵션은 스레드에 붙여넣을 수 있는 개인정보 보호가 보장된 요약본(집계된 수치만 제공하며, 파일 경로, 프롬프트 또는 응답 내용은 포함하지 않음)을 생성합니다. 이 도구는 MIT 라이선스이며 Anthropic과 관련이 없습니다. 전체 비용 모델은 위의 몇 문단에 설명되어 있으므로, 직접 파서를 작성하고 싶다면 ~/.claude/projects/에 있는 로그를 확인하면 되며, 무엇을 찾아야 할지도 이제 알고 계실 것입니다.

(공개 사항: 저는 tokenscope를 유지 관리합니다. 이 도구를 링크하는 이유는 제가 이 정확한 수치들을 도출하기 위해 사용한 도구이기 때문이지, 여러분에게 반드시 필요하기 때문은 아닙니다. JSONL 데이터는 여러분의 것이며 계산 방식은 간단합니다.)

전체 데이터 세트 — 모든 백분위수 표, SVG 차트, 전체 방법론 및 솔직한 한계점 섹션 — 는 여기에 게시되어 있습니다: https://tokenscope.pages.dev/benchmark/

핵심 요약 (Takeaway)

평균 세션 (average session)을 최적화하려고 하지 마세요. 그것은 괜찮은 수준입니다. 대신 수십만 토큰을 넘어서 조용히 정점을 찍었던 몇 안 되는 롱 컨텍스트 마라톤 (long-context marathons) 세션들을 찾아내어, _그것들_을 압축하거나 분할하세요. 비용의 60%가 바로 그곳에 존재합니다.