n=1 참고 사항. 이것은 평균이나 벤치마크가 아닌, 단 하나의 실제 세션에 대한 해부입니다. 구체적인 수치는 이 세션에서 실제로 측정된 수치입니다. 메커니즘 — 즉, 긴 세션에서 재전송되는 컨텍스트 (context)가 비용을 지배한다는 점 — 은 일반적입니다. 여러분의 수치는 워크플로우 (workflow)에 따라 달라질 것입니다. n=66개 세션에 대한 전체 데이터 세트 (백분위 테이블, 방법론, 차트)는 benchmark page에 있으며, 이 글은 저의 사고 모델 (mental model)을 깨뜨린 단 하나의 세션에 관한 것입니다.

제 로그에는 1,278달러가 소요된 세션이 하나 있습니다.

12.78달러가 아닙니다. 오타도 아닙니다. 단 한 번의 Claude Code 코딩 세션 동안, 약 1,270번의 모델 턴 (model turns)을 거치며 발생한 비용이 1,278달러였습니다. 이를 제대로 측정했을 때, 두 가지 사실이 명확해졌습니다.

1. 돈이 어디로 나가는지에 대해 제가 완전히 잘못된 사고 모델 (mental model)을 가지고 있었다는 것.
2. 일단 그 메커니즘을 이해하고 나면, 그것은 더 이상 미스터리가 아니라 실제로 제어할 수 있는 대상이 된다는 것.

다음은 솔직한 전체 내역입니다.

수치 (The numbers)

턴당 비용 (cost-per-turn) 수치만 봐도 무언가 잘못되었다는 것을 알 수 있습니다. 한 번의 주고받는 교환에 1.01달러라는 것은 모델이 매 턴 엄청난 양의 작업을 수행하고 있다는 뜻처럼 들립니다. 하지만 그렇지 않았습니다. 해당 세션은 긴 디버깅 (debugging) 및 빌드 (build) 작업이었으며, 이는 다른 세션들과 유형 면에서 크게 다르지 않았고 오직 _길이_만 달랐을 뿐입니다.

돈이 어디로 갔는가 (Where the money went)

모델이 코드를 작성하는 비용은 청구서의 14%에 불과했습니다. 세션 비용의 3분의 2는 모델이 이미 보았던 컨텍스트를 매 턴마다 반복해서 재전송하는 데 지불되었습니다.

이것이 바로 저의 사고 모델 (mental model)이 실패한 지점이었습니다. 저는 각 턴을 다음과 같이 생각했습니다: 질문 → 모델이 생각함 → 모델이 작성함 → 비용 청구. 하지만 실제 비용 구조는 다음과 같습니다: 질문 → 대화 전체를 재전송 → 모델이 작성함 → 이 모든 것에 대해 비용 청구. 그리고 재전송 부분은 할인된 캐시 읽기 (cache-read) 요율을 적용하더라도, 긴 세션에서는 비용을 지배하게 됩니다.

왜 이런 일이 발생하는가 (메커니즘은 간단합니다)

Claude는 stateless합니다. 즉, 턴(turn) 간에 메모리가 없습니다. 따라서 매번 클라이언트는 모델에게 컨텍스트를 제공하기 위해 축적된 전체 대화 내용—이전 모든 메시지, 읽은 모든 파일, 모든 도구 출력—을 전송해야 합니다. 이것은 Claude의 특성이라기보다는 아키텍처적인 현실입니다.

프롬프트 캐싱(Prompt caching)이 이 부담을 완화해 줍니다. 만약 서버가 해당 정확한 접두사(prefix)를 이전에 본 적이 있다면, 재전송 비용은 캐시 읽기 요율(cache-read rate)로 청구되는데, 이는 일반 입력 가격의 약 0.1배입니다. 이것이 바로 '98% 캐시 효율성' 수치인데, 거의 모든 재전송 토큰이 캐시에 도달하여 저렴한 요율을 적용받았다는 의미입니다.

문제는 여기에 있습니다: 토큰당 비용은 저렴하지만, 매 턴마다 전체 컨텍스트에 대해 지불해야 한다는 것입니다.

단일 턴에서 컨텍스트를 재전송하는 비용은 대략 다음과 같습니다:

cache_read_cost ≈ context_size × input_price × 0.1

그리고 세션 전체의 재전송 비용은 다음과 같습니다:

total_cache_read ≈ context_size × turns × input_price × 0.1

이번 세션에서는: 약 998,000개의 최대 컨텍스트 토큰 × 약 1,270턴 × 입력 가격 × 0.1입니다. 입력 요율의 10% 수준이라도 엄청난 수치입니다. 98%의 캐시 적중률(cache hit rate)은 소액을 효율적으로 지불하고 있다는 의미이지만—엄청난 양의 데이터에 대해 반복적으로 지불하는 것이기 때문에—그 효율성은 '20시간 세션의 전체 축적된 기록'이라는 분모를 깨닫는 순간까지 인상적으로 들립니다.

한편, 모델의 출력(output) — 실제로 작성한 코드나 제공한 설명—은 청구서의 약 14%에 불과했습니다. 출력은 입력보다 토큰당 가격이 더 높습니다. 하지만 모델이 한 턴 동안 재읽는 컨텍스트 양에 비해 훨씬 적은 토큰을 작성합니다. 출력이 생산적인 작업이지만, 가장 큰 비용 센터(cost center)는 아닙니다.

복리 문제 (The compounding problem)

컨텍스트는 선형적으로 증가하지 않습니다. 세션 초반에는 컨텍스트가 작아 재전송 비용이 저렴합니다. 하지만 세션이 계속되면서:

• 새로운 파일을 읽고, 도구 출력이 축적되며, 대화 기록이 길어지면서 컨텍스트가 커집니다.
• 매번 새로운 턴은 이전보다 더 큰 컨텍스트를 재전송합니다.
• 그리고 세션이 길어질수록 더 많은 턴을 진행하게 됩니다.

따라서 당신은 점점 커지는 턴당 비용(per-turn cost)에 점점 늘어나는 턴 수(turn count)를 곱하게 됩니다. 이것이 긴 세션에서 비용이 비례해서 증가하지 않고 가속화되는 이유입니다. 컨텍스트(Context)가 998k 토큰 근처에서 정점에 도달할 때쯤이면, 단 하나의 턴마다 엄청난 양의 데이터를 재전송하게 됩니다. 이번 세션 중에는 재전송 비용(re-send cost)만으로 모델의 전체 응답 비용보다 더 많은 금액이 발생한 턴도 있었습니다.

직관에 반하는 교훈들

98%의 캐시 히트율(cache hit rate)이 "캐싱이 문제를 해결했다"는 것과 동일하지는 않습니다. 높은 캐시 효율성(cache efficiency)은 당신이 컨텍스트를 저렴한 요율로 효율적으로 재전송하고 있음을 의미할 뿐입니다. 이는 당신이 얼마나 많이 재전송하고 있는지에 대해서는 아무것도 말해주지 않습니다. 거의 완벽한 효율성을 유지하면서도 여전히 돈을 낭비할 수 있는데, 그 이유는 거대한 컨텍스트를 수천 번 재전송하고 있기 때문입니다. 캐시 효율성은 토큰당 지표(per-token metric)인 반면, 청구 금액은 [해당 요율 × 재전송된 총 토큰 수 × 턴 수]의 결과물입니다.

출력 최적화(Output optimization)는 잘못된 레버(lever)입니다. 긴 세션의 비용을 줄이고 싶다면, 출력 토큰(output tokens)을 타겟팅해 봤자 비용의 최대 14% 정도만 줄일 수 있습니다. 그 선 아래의 모든 것들—모델 측면의 개선, 프롬프트 압축(prompt compression) 기술, 각 응답의 단어 수 줄이기 등—은 비용을 크게 변화시키지 못합니다. 돈이 새나가는 곳은 66%(재전송된 컨텍스트)와 20%(캐시 쓰기, cache-write) 영역입니다.

해결책은 평범합니다. 정답은 영리한 최적화가 아니라, 그저 컨텍스트를 작게 유지하는 것입니다:

• 긴 세션에서는 /compact를 더 일찍 사용하세요. 이 명령은 누적된 컨텍스트 (Context)를 요약하고 삭제합니다. 압축된 버전은 전체 히스토리를 다시 전송하는 것보다 비용이 훨씬 적게 듭니다. 1,200번째 턴에서 실행하는 것보다 200번째 턴에서 실행하는 것이 훨씬 효과적입니다. 컨텍스트가 컸던 모든 이후 턴에서 발생하는 재전송 비용 (re-send cost)을 제거할 수 있기 때문입니다.
• 작업이 바뀌면 새로운 세션을 시작하세요. 한 작업에서 발생한 800k 토큰의 컨텍스트를 관련 없는 다른 작업으로 가져가는 것은, 새로운 작업의 매 턴마다 관련 없는 800k 토큰을 다시 전송하는 비용을 지불한다는 의미입니다. 새로운 세션을 시작하면 재전송 미터기가 거의 0에 가까운 상태에서 시작됩니다.
• 누적 총액뿐만 아니라 컨텍스트의 증가량을 주시하세요. 누적 총액은 지금까지 얼마를 썼는지 알려줍니다. 턴당 컨텍스트 크기는 _미래_의 각 턴이 얼마의 비용이 들지를 알려줍니다. 컨텍스트가 200k 토큰을 넘어서고 앞으로 더 많은 턴이 남았다고 판단되면, 그것이 바로 압축 (compact)을 해야 할 신호입니다. 세션이 끝난 후나 청구서가 나온 후에 하면 늦습니다.
• 상주 파일 (Resident files)과 도구 (Tools)가 생각보다 많은 비용을 차지합니다. 3번째 턴에서 읽은 대용량 파일은 이후 모든 턴에서 다시 비용이 청구됩니다. 초기에 컨텍스트에 무언가를 추가하는 비용은 단순히 첫 번째 턴의 비용이 아니라, 이후 모든 턴에 걸친 재전송 비용의 합계입니다.

솔직한 한계점

이것은 n=1 — 단 하나의 실제 세션에 대한 결과입니다. 1,278달러와 66/20/14/0의 비율은 이 세션에서 실제로 측정된 수치입니다. 여러분의 세션은 얼마나 오래 실행하는지, 컨텍스트가 얼마나 커지는지, 그리고 무엇을 작업하고 있는지에 따라 달라질 것입니다.

일반화할 수 있는 부분은 그 메커니즘입니다: 컨텍스트 크기 × 턴 수가 재전송되는 컨텍스트 비용을 결정하며, 컨텍스트가 커지고 턴이 누적될 만큼 충분히 긴 세션에서는 재전송되는 컨텍스트가 비용의 지배적인 항목이 될 것입니다. 구체적인 비율은 변할 수 있지만, 그 구조는 변하지 않습니다.

제가 측정한 세션은 극단적인 사례였습니다. 피크 컨텍스트(peak context)가 거의 100만 토큰에 달했고, 1,000턴이 넘었습니다. 대부분의 세션은 이 정도로 길지 않습니다. 제가 수행한 66개의 세션 집합에서는 중앙값(median)이 약 45k 토큰이었고 약 29턴이었습니다. 이 경우, 재전송된 컨텍스트(re-sent context)는 중앙값 세션 지출의 소수(minority) (지출의 24%)에 불과했습니다. n=1 연구와 n=66 벤치마크를 통해 얻은 교훈은 다음과 같습니다. 일반적인 세션은 괜찮습니다. 주의해야 할 것은 긴 세션이며, 그런 세션에서는 재전송된 컨텍스트가 비용 청구서의 핵심입니다.

직접 확인하고 싶다면

저는 Claude Code의 로컬 로그를 읽는 작은 오픈 소스 CLI를 사용하여 이 세션을 측정했습니다:

npx @wartzar-bee/tokenscope

이 도구는 로컬에서 실행되며 — 읽기 전용이고, 아무것도 업로드되지 않으며, 텔레메트리(telemetry)도 없습니다 — 다음과 같은 동일한 상세 내역을 보여줍니다: 출력(output) vs 캐시 읽기(cache-read) vs 캐시 쓰기(cache-write), 턴당 컨텍스트 성장 곡선, 그리고 66개 세션 참조 집합과 비교했을 때 귀하의 세션이 어느 백분위수에 해당하는지 등을 보여줍니다. --share 명령은 스레드에 붙여넣을 수 있는 개인정보 보호가 보장된 요약 카드(합계 수치만 포함, 내용이나 파일 경로는 포함되지 않음)를 생성합니다.

직접 코딩한 SVG 비용 분할 차트, 컨텍스트 성장 곡선, 전체 데이터 테이블 및 방법론이 포함된 전체 연구 결과는 다음에서 확인할 수 있습니다: https://tokenscope.pages.dev/study/

(공개 사항: 저는 tokenscope를 관리합니다. 이 도구를 링크하는 이유는 이 세션을 측정한 도구이기 때문이지, 반드시 필요하기 때문은 아닙니다. Claude Code의 JSONL 로그는 ~/.claude/projects/에 있으며, cache_read_input_tokens를 확인해야 한다는 점만 알면 계산은 간단합니다.)

1,278달러가 든 세션은 버그나 사고가 아니었습니다. 그것은 크고 계속 커지는 컨텍스트를 가진 복잡한 프로젝트에서 작업한 긴 세션이었습니다. 비용을 발생시킨 모든 메커니즘은 문서화되어 있고 예측 가능하며, 일단 알고 나면 부분적으로 피할 수도 있습니다. 코드를 작성하는 모델의 비용은 전체의 14%였습니다. 나머지는 인프라 비용이었습니다. 즉, 모델이 가지고 있지 않은 기억을 계속해서 다시 보내기 위해 지불한 비용이었습니다.