
Claude Sonnet 5, 단가는 그대로지만 새로운 토크나이저(Tokenizer)로 인해 청구 금액이 약 30% 증가한다
요약
Claude Sonnet 5 출시와 함께 도입된 새로운 토크나이저로 인해 동일 텍스트 대비 토큰 소비량이 약 30% 증가하여 실질 비용이 상승했습니다. 또한 샘플링 파라미터 제한 및 적응형 사고(Adaptive Thinking) 도입 등 API 동작 방식의 변화에 따른 코드 수정이 필요합니다.
핵심 포인트
- 새로운 토크나이저 도입으로 토큰 소비량 약 30% 증가 및 비용 상승
- 기존 max_tokens 설정 시 출력 끊김 현상 주의 필요
- temperature, top_p 등 샘플링 파라미터 사용 시 400 에러 발생
- 수동 사고(Thinking) 대신 적응형 사고(Adaptive Thinking) 및 effort 파라미터 사용
6월 30일에 출시된 Claude Sonnet 5의 가격표를 보고, 많은 사람은 "그대로구나"라고 생각하며 그냥 지나쳤다. 입력 100만 토큰당 3달러, 출력 15달러. 이전 세대인 Sonnet 4.6과 동일하다. 도입 가격으로서 8월 31일까지 2달러/10달러의 할인도 적용된다.
하지만 실제로 운영 트래픽을 전환한 개발자들이 청구 대시보드의 숫자가 올라가고 있다는 사실을 알아차리기 시작했다. 단가는 1엔도 변하지 않았는데 말이다. 범인은 모델의 지능도, 숨겨진 과금 항목도 아닌, Anthropic이 이번 세대에서 몰래 교체한 **새로운 토크나이저 (Tokenizer)**에 있다.
과금은 "토큰 수 × 단가"로 결정된다. 단가가 같더라도 동일한 문장이 더 많은 토큰으로 분할되면 곱셈의 결과값은 커진다. 토크나이저 (Tokenizer)란 텍스트를 "dog", " the"와 같은 처리 단위(토큰 (Token))로 나누는 부품을 말한다. 이곳을 교체하면 1글자당 몇 토큰이 되는지의 환산율 자체가 바뀐다.
Anthropic은 공식 문서에서 다음과 같이 명시하고 있다.
Claude Sonnet 5 uses a new tokenizer. The same input text produces approximately 30% more tokens than on Claude Sonnet 4.6.
동일한 텍스트로 약 30% 더 많은 토큰을 소비한다는 의미다 (What's new in Claude Sonnet 5). 이는 API의 형태가 바뀐 것이 아니다. 요청(Request)도 응답(Response)도 스트리밍(Streaming)도 구조는 동일하며, 코드 변경은 필요 없다. 영향을 미치는 것은 "토큰으로 측정하거나 예측하는 모든 것"이다. 청구 금액은 물론이고, 1M 토큰의 컨텍스트 윈도우 (Context Window)에 들어가는 실제 텍스트 양이 줄어들며, Sonnet 4.6에 맞춰 아슬아슬하게 설정했던 max_tokens는 동일한 출력임에도 도중에 끊길 수 있다.
따라서 이행 시 가장 먼저 실행해야 할 것은 새 모델에 대한 count_tokens의 재측정이다. 과거에 측정했던 토큰 수를 그대로 사용하면 예측이 어긋나게 된다.
# 동일한 messages 임에도 Sonnet 5에서는 반환되는 수가 늘어남
count = client.messages.count_tokens(
model="claude-sonnet-5",
...
토크나이저 (Tokenizer) 외에도, Sonnet 4.6의 코드를 그대로 적용했을 때 400 에러로 거부되는 동작 변경 사항이 3가지 있다. 문서는 "드롭인 교체 (Drop-in replacement)"라고 표현하고 있지만, 이 3가지 포인트만큼은 조치가 필요하다.
첫째, 샘플링 파라미터 (Sampling Parameter)의 금지이다. temperature, top_p, top_k를 기본값 이외의 값으로 설정하면 400 에러가 반환된다. 출력의 다양성을 온도로 제어하던 코드는 파라미터를 제거하고 시스템 프롬프트 (System Prompt) 측의 지시로 돌리는 작업이 필요하다 (Opus 4.7에서 먼저 도입된 제약이 드디어 Sonnet 계열에도 내려온 형태다).
둘째, 수동 확장 사고 (Extended Thinking)의 폐지이다. thinking: {type: "enabled", budget_tokens: N}은 삭제되었으며, 이 역시 400 에러를 유발한다. 대신 사용하는 것이 기본적으로 활성화된 적응형 사고 (Adaptive Thinking)이며, 사고의 깊이는 effort 파라미터 (기본값 high)로 조정한다.
셋째, 그 적응형 사고 (Adaptive Thinking)가 기본적으로 활성화되었다는 사실 자체가 은근히 영향을 미친다. Sonnet 4.6에서는 thinking 필드를 넣지 않으면 사고 없이 실행되었지만, Sonnet 5에서는 동일한 요청이 사고를 포함하여 동작한다. max_tokens는 "사고 + 응답 텍스트"의 합계에 대한 상한선이므로, 사고가 없음을 전제로 타이트하게 설정했던 워크로드(Workload)는 응답이 끊기기 쉬워진다. 이행의 실체는 대체로 다음과 같다.
# Before (Sonnet 4.6)
resp = client.messages.create(
model="claude-sonnet-4-6",
...
사고를 멈추고 싶을 뿐이라면 thinking={"type": "disabled"}로 명시적으로 끌 수 있다.
여기서 한 가지, 소스 간의 차이점을 언급해 두고 싶다. 공식 문서는 "약 30% 증가"라고 단일 수치로 기술하는 반면, 발표 블로그는 "콘텐츠 유형에 따라 대략 1.0~1.35배"라고 범위를 두고 기술하고 있다. 그리고 독립적으로 실측한 Simon Willison 씨의 기록은 이 상한선을 더욱 초과하는 수치를 보여주고 있다.
| 입력 종류 | Sonnet 4.6 대비 토큰 배율 |
|---|---|
| 영어 산문 (English Prose) | 약 1.4배 |
| ... | |
| 영어 산문에서 약 1.4배라는 실측값은 Anthropic 스스로가 제시한 '최대 1.35배'의 범위를 벗어나고 있다. 즉, '30%'는 가이드라인일 뿐 보장된 수치가 아니다. 배율은 언어와 콘텐츠 형태에 강하게 의존하며, 자연어일수록 증가하고 이미 세밀하게 나누어져 있던 표의 문자(Ideogram)는 크게 변하지 않는다는 경향을 읽을 수 있다. |
실무적인 함의는 명확하다. 당신의 프롬프트가 영어 문서로 채워져 있다면 3~4할 증가를 각오해야 하며, 코드 중심이라면 3할 미만으로 예상할 수 있다. 참고로 공개된 실측 데이터에 일본어는 포함되어 있지 않으므로, 일본어가 섞인 프롬프트를 다룬다면 '아마 3할 정도겠지'라고 단정 짓지 말고, 자신의 워크로드(Workload)에서 count_tokens를 돌려 측정하는 것이 유일하게 제대로 된 방법이다.
Sonnet 5는 코딩과 에이전트(Agent) 계열 태스크에서 4.6을 명확히 능가하면서도 가격은 동결했다는 것이 솔직한 평가다. 1M 토큰의 컨텍스트(Context)와 128k의 최대 출력(Max Output)을 지원하며, 벤치마크상으로는 Opus 4.8에 육박한다고 Anthropic은 설명하고 있다. 전환할 이유는 충분하다.
걸리는 점은 가격 인상이 '단가'가 아니라 '토큰 수의 증가'라는 눈에 보이지 않는 경로로 이루어진다는 점이다. 가격표만 본 사람들은 알아차릴 수 없다. 따라서 전환 순서는 모델 ID를 교체하기 전에, 대표적인 프롬프트 몇 개를 신구 모델의 count_tokens에 통과시켜 월간 비용이 얼마나 변동하는지 먼저 확인하는 것이다. 그 후에 temperature 계열을 제거하고, thinking을 적응적 사고(Adaptive Thinking)로 수정하며, max_tokens를 사고 과정을 포함하여 다시 설정한다. 이 세 가지 조치와 한 번의 실측을 마친다면, 청구 대시보드를 보고 놀라는 일은 없을 것이다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기