Claude Code 비용, 제2막 — 거대한 숨겨진 비용은 어디에 있는가

캐시(cache)가 잘 유지되는 단일 모델 세션은 저렴합니다. 멀티 모델(multi-model) 청구서에서 가장 큰 변동을 일으키는 것은 단 한 가지 움직임, 즉 모델 전환 (switching models) 에서 발생합니다. 프롬프트 캐시(prompt cache)는 단일 모델에 귀속되기 때문입니다. 모델을 전환하는 순간, 이미 비용을 지불한 캐시는 버려지게 됩니다.

이것이 도움이 될지 해가 될지는 어떻게 전환하느냐에 달려 있습니다:

• 고정형 (Sticky) — 전체 대화(또는 서브 에이전트)를 하나의 모델에 유지합니다. 더 저렴한 모델이 자신만의 따뜻한 캐시(warm cache)를 구축하고 재사용하므로, 비용이 감소합니다.
• 턴당 전환 (Per-turn bouncing) — 대화 중간에 모델을 번갈아 가며 바꿉니다. 매번 완전히 차가운 상태(cold rebuild)로 다시 시작하는 것은 아닙니다. 각 모델에 대한 첫 번째 호출만 완전히 차가운 상태이며, 이미 사용했던 모델로 돌아가면 해당 모델의 따뜻한 접두사(warm prefix)를 다시 읽고 떠난 이후의 추격(catch-up) 부분만 작성합니다 (단, 아래의 첫 호출은 차갑고, 이후에는 따뜻한 추격 섹션에서 설명하는 ~20블록 / 1시간 재사용 범위 내에 있어야 합니다). 하지만 이 방식은 두 개의 캐시를 따뜻하게 유지해야 하며, 전환할 때마다 추격 쓰기(catch-up write) 비용이 발생하므로, 2배의 쓰기 속도로 인해 전환하지 않는 것보다 비용이 더 많이 들 수 있습니다.

우리의 25턴 실행 결과는 양극단을 보여줍니다. 턴의 20%를 Sonnet으로 전환했을 때는 약 2%를 손실한 반면, 전체 실행을 Sonnet으로 유지했을 때는 약 53%를 절약했습니다 (Haiku의 경우 약 85%) — 제3막을 참조하십시오. 따라서 목표는 전환을 피하는 것이 아니라, 올바른 방식으로 전환하는 것입니다. 비용이 많이 드는 버전은 실수로 끼어드는 방식입니다. 즉, 요청마다 모델을 선택하는 라우터(router)나 대화 중간에 수동으로 교체하는 방식입니다.

모델의 이전 추론 (reasoning) — 즉, 사고 블록(thinking blocks)은 어떨까요? 이를 두 번째 전환 비용으로 계산하고 싶은 유혹이 들겠지만, 기계적으로 그것은 단순히 컨텍스트 (context) 일 뿐입니다. 클라이언트는 전환 여부와 상관없이 매 턴마다 이를 다시 보냅니다 (Mental model 1). 전환은 오직 새로운 모델이 그것을 어떻게 다루느냐만을 바꿉니다. 즉, 추론을 입력으로서 재청구 (re-bills) 하거나 (비용 발생), 모델이 보기 전에 이를 제거 (strips) 하는 것(행동 변화) 중 하나입니다.

제거 (strip) 케이스는 주의 깊게 살펴봐야 할 사례이며, 이는 돈이 아니라 _행동 (behavior)_에 관한 문제입니다. 추론 (Reasoning)은 불투명하고 암호화된 서명 (signature)으로서 전달됩니다. 즉, 이를 읽거나 수정할 수 없으며, 있는 그대로 전달하거나 아니면 아예 잃어버릴 수밖에 없습니다. 만약 스위칭 (switch) 과정에서 이를 놓치게 되면, 모델은 이전의 사고 사슬 (chain of thought) 없이 동작을 계속하게 되며, 이전 턴들이 설정해 놓은 방식대로 더 이상 행동하지 않을 수 있습니다.

따라서 이 섹션에서는 먼저 스위칭 시 발생하는 캐시 비용 (cache cost)을 다룬 뒤, 스위칭 과정에서 추론 (reasoning)에 어떤 일이 발생하는지 살펴보겠습니다.

모델 스위칭: 모델 범위의 캐시 (the model-scoped cache)

멘탈 모델 3: 모델 범위의 키 (the model-scoped key)

캐시 엔트리 (cache entry)는 정확히 하나의 모델에만 속합니다. 다른 모델은 이를 읽을 수 없습니다.

이 규칙 때문에

Sonnet의 두 번째 호출은 자신의 따뜻한(warm) 엔트리를 읽습니다. Haiku의 첫 번째 호출은 — 동일한 바이트임에도 불구하고 — 0을 읽고 자신의 복사본을 차갑게(cold) 작성합니다. 두 모델은 엔트리를 공유할 수 없습니다.

실제적인 결과 — 혼합 세션에서의 중복된 캐시 작성 (Sonnet/Haiku가 50/50으로 섞인 실제 세션, 모델별 합계) [측정됨]:

Haiku는 Sonnet으로부터 절대 읽을 수 없었던 공유 접두사(prefix)의 57,739 토큰 중복본을 차갑게 작성했습니다 — 이는 단일 모델 세션에서는 지불하지 않았을 총 85,113 토큰의 순수 중복 cache_creation 비용에 해당합니다. 2배의 쓰기 속도(write rate)로 인해 쓰기 프리미엄(write premium)을 두 번 지불하게 되며, 경로가 바뀐 슬라이스에 대한 0.1배 읽기 할인(read discount)을 받지 못하게 됩니다. 저렴한 모델을 사용함으로써 얻는 절감액이 캐시 중복으로 인해 상쇄됩니다. 이것이 이 가이드 전체의 핵심적인 주의 사항입니다.

바이트(bytes) 또한 우연히 다릅니다 — 모델 간의 시스템 프롬프트(system prompt)를 비교해 보면 두 줄이 변경됩니다 (모델 이름 줄과 지식 컷오프(knowledge-cutoff) 줄, 예: Opus 4.7 / January 2026 → Haiku 4.5 / February 2025). 하지만 캐싱 관점에서는 이는 무의미합니다. 모델 범위의 키(model-scoped key)가 이미 결론을 내렸기 때문입니다. 아무리 바이트가 일치하더라도 Haiku가 Sonnet의 KV 상태(KV state)를 읽을 수는 없습니다. 따라서 텍스트가 다르다는 것을 두 번째 원인으로 생각하지 마세요. 그것은 동일한 벽입니다.

그리고 비용도 변합니다: 토크나이저(tokenizer)가 다름 [측정됨]

이것은 캐시와는 전혀 상관없는 문제로, 모델을 전환할 때마다 따라오는 별개의 비용 효과입니다. 모델 간에 토큰 수가 달라지기 때문에,

Anthropic은 공식적인 비율을 발표하지 않습니다 (count_tokens를 모델별로 사용하세요). 다만 4.7/4.8/Fable 토크나이저(tokenizer)가 이전 토크나이저보다 약 1배1.35배 정도라고 기록하고 있으며, 이는 이전 모델들이 Opus의 약 0.741.0배 수준임을 의미합니다.

멘탈 모델(Mental model) 정교화: 첫 호출은 콜드(cold), 이후는 웜(warm) 캐치업(catch-up)

좋은 소식은 모델 전환이 영원히 콜드 상태로 머물지는 않는다는 점입니다:

특정 모델에 대한 첫 번째 호출만 완전히 콜드(cold) 상태입니다. 해당 모델에 대한 각 이후 호출은 부분적으로 웜(partially warm) 상태입니다. 즉, 해당 모델 자체의 캐시를 읽고, 중간에 다른 모델을 통해 추가된 내용인 캐치업 차이(catch-up diff)만을 콜드 라이트(cold-write)합니다. 비용 = 1회의 콜드 스타트(cold start) + 재진입 시마다 발생하는 반복적인 캐치업 라이트(catch-up write)이며, 매 호출마다 콜드 스타트가 발생하는 것이 아닙니다.

두 가지 제한 사항이 적용됩니다: TTL (1시간, 해당 모델의 엔트리를 읽을 때마다 갱신됨)과 20블록 룩백(lookback, 약 7~10턴)입니다. 룩백 범위를 벗어나면 꼬리(tail) 부분은 다시 연결될 수 없지만, 앞부분의 중단점(breakpoints, 도구+시스템)은 여전히 적용됩니다. 따라서 시스템 접두사(system prefix)는 웜(warm) 상태로 다시 읽고, 메시지 기록(message history)만 콜드 라이트(cold-write)하게 됩니다. 2배의 쓰기 속도(write rate)가 적용될 경우, 콜드 스타트와 캐치업 라이트 모두 비용이 두 배로 발생하며, 이것이 바로 제3막에서 라우팅 경제성을 뒤집는 핵심 요소입니다.

⚠️ 실수 — 비용 절감을 위해 턴(turn)마다 라우팅하기. 대화 중간에 모델을 번갈아 사용하는 것은 첫 전환 시 콜드 접두사 라이트(cold prefix write) 비용을 지불할 뿐만 아니라, 재진입할 때마다 캐치업 라이트(catch-up write) 비용을 추가로 지불하게 됩니다. 쓰기 속도가 더 높은 모델(Sonnet)의 경우, 이는 단순히 Opus를 계속 사용하는 것보다 더 많은 비용이 들 수 있습니다.

✅ 해결책 — 스티키(sticky) 라우팅: 대화(conversation) 또는 하위 에이전트(sub-agent) 단위로 모델을 선택하고 그 모델을 유지하세요. (제3막의 수치화: 턴당 20% 확률로 Sonnet을 번갈아 사용하는 것은 2.1%의 손실을 보지만, 전체를 Sonnet으로 고정하는 스티키 방식은 53%를 절약합니다.)

실행 지침: 모델을 턴(turn) 단위가 아닌 대화(per-conversation) 단위의 결정으로 취급하는 것을 기본 원칙으로 삼으세요. 만약 여러 계층(tier)을 사용한다면, 각 계층이 고유의 웜 캐시(warm cache)를 유지할 수 있도록 별도의 서브 에이전트(sub-agents)나 대화로 격리하십시오. 수많은 상용 라우터(router)와 게이트웨이(gateway)가 요청(request)별로 자동 라우팅을 수행하며 비용을 절감해 줄 수 있지만, 그 이점은 워크로드(workload)에 따라 달라집니다. 또한 (위의 수치에서 보여주듯) 요청별 라우팅은 특히 쓰기 속도(write-rate)가 높은 모델의 경우 조용히 더 많은 비용을 발생시킬 수 있습니다. 따라서 맹목적으로 기능을 켜지 마십시오. 본인의 트래픽에서 증거를 확인할 수 있을 때만 도입하십시오. 즉, cache_read 대 cache_creation 비율과 실제 청구 비용을 측정하고, 왜 캐시가 모델 범위(model-scoped)로 제한되는지 이해하며, 이에 의존하기 전에 실제 순절감액(net saving)을 확인해야 합니다. 또한 비용 이상의 요소도 고려해야 합니다. 더 저렴한 계층은 더 오래된 지식 컷오프(knowledge cutoff)를 가질 수 있으며 (예: Haiku 4.5는 Opus보다 약 11개월 뒤처져 있음), 이는 가격 중심의 라우팅이 조용히 물려받게 되는 행동적(behavioral) 차이입니다.

모델 전환 시의 사고 블록 (Thinking blocks)

제1막에서는 클라이언트가 모델의 이전 추론 과정인 **사고 블록 (thinking blocks)**을 포함하여 매 턴마다 모든 것을 다시 전송한다는 점을 확인했습니다. 이를 전달하는 것은 일반적인 컨텍스트(context)이지만, 모델을 전환할 때는 두 가지 종류의 결과가 따르는 선택을 강요받게 됩니다. 대상 모델의 클래스(class)에 따라, 이 블록들은 대상 모델의 프롬프트(prompt)로 다시 렌더링되어 **입력 비용으로 청구(billed as input)**되거나(비용 발생), 전달되기 전에 **제거(stripped)**됩니다(행동적 변화 — 새 모델이 이전의 사고 사슬(chain of thought)을 잃게 됨). 이 중 어느 쪽이 나을지 판단하려면, 먼저 사고 블록이 무엇인지 알아야 합니다.

첫째: 모델의 "사고(thinking)"란 무엇인가

추론 모델(reasoning models)을 다뤄본 적이 없다면 여기서부터 시작하십시오. 경험이 있다면 멘탈 모델(Mental model) 4로 넘어가셔도 좋습니다.

추론 모델 (Reasoning model)은 즉시 답변하지 않습니다. 어려운 프롬프트(Prompt)가 주어지면, 모델은 먼저 중간 토큰 (Intermediate tokens)들을 생성하며 문제를 단계별로 풀어낸 뒤, 그제야 답변을 작성합니다. 이러한 풀이 과정이 모델의 사고 (Thinking) (또는 추론 (Reasoning), 확장된 사고 (Extended thinking), _생각의 사슬 (Chain of thought)_이라고도 불림)입니다. 이는 사람이 답변하기 전에 "이 문제를 한번 풀어보자"라며 거치는 연습장과 같지만, 모델은 토큰을 방출함으로써 이를 수행합니다.

모델이 이렇게 하는 이유: 답변하기 전에 추론에 토큰을 소비하는 것은 수학, 코드, 계획 수립 등 초기 단계의 단 한 번의 오류가 결과를 망칠 수 있는 모든 다단계 작업에서 정확도를 측정 가능한 수준으로 향상시킵니다. 이것이 바로 _테스트 시간 연산 (Test-time compute)_입니다. 즉, 더 나은 답변을 얻기 위해 토큰(그리고 지연 시간과 비용)을 맞바꾸는 것입니다. 최신 모델들은 **적응형 사고 (Adaptive thinking)**를 사용합니다. 모델은 요청마다 해당 문제가 생각할 가치가 있는지, 얼마나 깊게 생각해야 하는지를 스스로 결정하므로, 사소한 조회 작업에는 사고를 수행하지 않고 어려운 퍼즐에는 수천 개의 토큰을 할당합니다.

응답 시, 사고 과정은 답변에 섞이지 않습니다. 답변은 유형화된 **콘텐츠 블록 (Content blocks)**의 목록이며, 사고는 text 답변이 나오기 _전_에 방출되는 별도의 블록 유형입니다. 즉, 통신 규격(Wire) 상에서 모델의 비공개 풀이 과정과 사용자를 위한 단어를 분리하여 유지합니다. 이 분리된 블록이 매 턴마다 다시 전달되는 것이며, 모델 스위치(Model switch)가 결정을 내려야 하는 대상입니다. 다음 질문은 그 안에 무엇이 들어있는가입니다.

멘탈 모델 4: 암호화된 봉투

사고 블록은 당신이 들고 다니는 읽을 수 있는 텍스트가 아닙니다. 그것은 밀봉된 봉투입니다.

모델은 자신의 추론을 암호화된 **signature**로 봉인하여 당신이 열 수 없는 봉투를 건넵니다. 당신은 이를 매 턴마다 다시 가져갑니다 (무상태(Stateless) — 서버가 아닌 당신이 이를 보유함). 서버는 키를 가지고 있습니다. 서버는 시그니처를 복호화하여 모델을 위한 추론을 재구성합니다. 그 결과는 **비공개적 (Private)**이며 (당신은 읽을 수 없음), **무상태적 (Stateless)**이고 (콘텐츠가 당신의 요청에 실려 이동함), **연속적 (Continuous)**입니다 (서버가 매 턴마다 이를 재구성함).

항상 공개된 것은 아니었습니다. 초기 세대의 확장적 사고(extended thinking)는 생각의 흐름(chain of thought)을 일반적인 읽기 가능한 텍스트로 반환했습니다. 사용자는 모델이 작업한 내용을 그대로 받아 기록하고, 차이점 분석(diff)을 하거나, 다시 보내기 전에 직접 수정할 수 있었습니다. 이러한 개방성은 사라졌습니다. 현재 Claude 4.x는 추론 과정을 보호된 형태로만 반환합니다: 별도의 모델이 작성하는 _요약본(summary)_이거나 암호화된 서명(signature)뿐입니다. 그 의도는 **반추출 방지(anti-distillation)**입니다. 원시적인 생각의 흐름은 경쟁사가 자신의 모델에 추론 과정을 복제하는 데 필요한 정확한 훈련 신호이기 때문에, 읽기 쉬운 텍스트는 자신이 가지고 다닐 수는 있지만 검사할 수는 없는 서명으로 대체되었습니다. (요약본(summarized)은 보호된 형태일 뿐, 그 안을 들여다보는 것이 아닙니다—아래의 _생각의 흐름을 단순히 읽을 수 없는 이유_를 참조하세요.)

사용자가 여전히 제어할 수 있는 것과 할 수 없는 것. 몇 가지 설정값(knobs)이 전체적인 틀(envelope)을 형성하지만, 그 어떤 것도 그것을 열 수는 없습니다:

• 모델이 생각하는지, 그리고 얼마나 열심히 하는지. thinking 매개변수(adaptive, 또는 budget_tokens 상한선이 있는 enabled)와 노력 설정은 블록이 생성될지 여부와 추론 과정이 얼마나 오래 실행될지를 결정합니다. 더 많은 추론 → 더 큰 서명(아래 깊이표는 난이도에 따라 약 45배 차이를 보여줍니다).
• 얼마나 많이 볼 수 있는지. display는 정확히 두 가지 값, 즉 `