한국어 본문은 토큰이 늘지 않았습니다 — 토크나이저 교체 후 비용, 테스트 텍스트 10종 측정

핵심 요약

4.7에서 토크나이저가 바뀌었습니다

토크나이저는 글자를 모델이 처리하는 단위인 토큰으로 자르는 규칙입니다. 요금이 토큰 단위로 매겨지므로, 같은 글이라도 자르는 규칙이 바뀌면 청구되는 토큰 수가 바뀝니다.

Claude Opus 4.7에서 새 토크나이저가 들어갔고, 그 이후 모델이 같은 것을 씁니다. 경계는 모델 이름이 아니라 4.7입니다 — 이름만 보면 Sonnet 4.6과 Sonnet 5가 한 줄로 보이지만 토크나이저는 서로 다릅니다.

Fable 5.1, Mythos 5.1, Fable 5, Mythos 5는 Opus 4.7에서 도입된 토크나이저를 공유합니다. 개발사 문서에 "A prompt counts the same on all four"라고 적혀 있습니다.

개발사 수치가 세 개이고 서로 다릅니다

배수를 찾아보면 공식 문서 안에서만 세 가지 표현이 나옵니다. 셋이 같은 값을 가리키지 않습니다.

셋은 서로 모순되지 않습니다. 앞의 둘은 대표값 하나를 적은 것이고, 세 번째만 범위와 조건을 적었습니다. 쓸모가 가장 큰 것은 세 번째입니다 — 하한이 1배라고 밝혀 두었기 때문입니다. 내용에 따라 전혀 늘지 않는 경우가 있다는 뜻입니다.

모델 개요의 1.351배는 이 글이 문서의 단어 수(75만 → 55.5만)에서 계산한 파생값입니다. 같은 문서의 Haiku 4.5 항목(200K 토큰 ≈ 15만 단어)과 맞으므로 문서 안에서는 일관됩니다.

직접 세어 봤습니다

개발사가 지정한 절차를 그대로 따랐습니다 — 같은 요청을 지금 쓰는 모델과 옮겨 갈 모델로 한 번씩 세어 input_tokens를 비교하는 것입니다. 토큰 카운팅은 과금되지 않습니다.

고정 오버헤드를 먼저 걷어냈습니다

count_tokens가 돌려주는 값에는 본문 외에 모델마다 다른 고정량이 섞여 있습니다. 문서도 "개발사가 시스템 최적화를 위해 더한 토큰이 포함될 수 있고 그 부분은 청구되지 않는다"고 적고 있습니다. 실제로 한 글자짜리 메시지를 세어 보니 모델별로 6에서 11까지 달랐습니다. 이 값을 그대로 두면 짧은 텍스트일수록 배수가 1에 가깝게 왜곡됩니다.

그래서 같은 글을 1회 넣은 요청과 5회 넣은 요청을 각각 세고 차이를 4로 나누었습니다. 고정량은 두 요청에 똑같이 들어가므로 뺄셈에서 사라집니다. 아래 표의 값은 전부 이렇게 구한 사본 1개당 순수 토큰 수입니다.

테스트 텍스트 10종의 측정값

ASCII 비중은 공백을 뺀 글자 중 ASCII 문자의 비율입니다. 토큰 수는 사본 1개당 순수 값이며, 구 토크나이저 열은 Haiku 4.5·Sonnet 4.6·Opus 4.6에서, 신 토크나이저 열은 Opus 4.7·Sonnet 5·Opus 5·Fable 5.1에서 각각 같은 값이 나왔습니다. 측정일 2026-09-21.

배수는 한글 비중이 낮을수록 높았습니다

표를 배수 순으로 정렬하면 ASCII 비중도 함께 올라갑니다. 테스트 텍스트 10종에서 두 값의 상관계수는 0.899였습니다. 한글로만 이루어진 네 종은 예외 없이 1.000이고, ASCII로만 이루어진 세 종은 예외 없이 1.2를 넘었습니다.

덤으로 확인된 것 — 한국어는 글자당 토큰이 많습니다

한국어는 글자 하나가 거의 토큰 하나입니다. 측정한 한국어 긴 산문은 두 토크나이저 모두에서 439자에 459토큰이었습니다. 영어 산문은 386자에 구 토크나이저 97토큰, 신 토크나이저 127토큰이었습니다. 글자 하나당 토큰 수로 옮기면 이렇습니다(파생값).

글자 수 기준으로 한국어가 영어보다 훨씬 많은 토큰을 쓴다는 사실은 그대로입니다. 다만 이번 변경으로 그 격차는 4.16배에서 3.18배로 좁혀졌습니다 — 한국어가 좋아져서가 아니라 영어 쪽 토큰이 늘었기 때문입니다.

두 테스트 텍스트는 내용이 다르므로 같은 정보량을 견준 것이 아닙니다. 글자 수당 토큰 수를 견준 값이며, 이 표만으로 한국어 서비스의 토큰 비용이 항상 더 높다고 말할 수는 없습니다.

단가에 곱하면 순서가 바뀝니다

실측 토큰 수에 2026-09-21 공식 단가를 곱하면, 같은 모델 교체가 내용에 따라 다른 결과를 냅니다. 아래 값은 같은 글을 보낼 때의 입력 비용 변화이며 이 글이 계산한 파생값입니다.

음수는 같은 글을 보낼 때 더 싸졌다는 뜻입니다. 출력 토큰과 캐시는 빼고 입력만 계산했습니다.

읽는 법

• Sonnet 4.6 → Sonnet 5는 단가가 $3에서 $2로 33.3% 내렸습니다. 측정한 한국어 본문 네 종에서는 그 인하가 그대로 실현됐습니다. JSON 로그에서는 5.3%만 남았습니다.
• Opus 4.6 → Opus 5는 입력 단가가 $5로 같습니다. 단가표만 보면 비용이 그대로여야 하는데, 한국어는 실제로 그대로이고 JSON 로그는 42.0% 오릅니다. 단가가 바뀌지 않은 교체에서 비용이 오를 수 있다는 것이 이 표에서 가장 주의할 부분입니다.
• Haiku 4.5 → Sonnet 5는 단가가 두 배지만 실제 부담은 두 배에서 시작해 최대 2.84배까지 갑니다.

캐시 읽기 배수도 모델마다 다릅니다

프롬프트 캐싱은 여러 요청에 반복되는 프롬프트 앞부분의 처리 결과를 저장해 두고 재사용하는 기능입니다. 저장하는 쪽을 캐시 쓰기, 저장해 둔 것을 재사용하는 쪽을 캐시 읽기라고 합니다. 오랫동안 캐시 읽기 단가는 어느 모델에서나 기본 입력 단가의 0.1배였습니다. 지금은 아닙니다.

Fable 5.1의 기본 입력이 100만 토큰당 $10이므로 캐시 읽기는 $0.25입니다. 같은 세대인 Fable 5는 $1이었으니, 읽기만 놓고 보면 4분의 1입니다. 긴 시스템 프롬프트를 여러 번 재사용하는 에이전트 작업에서는 이 항목이 청구서의 대부분을 차지할 수 있습니다.

사고 토큰이 출력에 붙습니다

입력만 바뀐 것이 아닙니다. Opus 5와 Sonnet 5는 thinking 항목을 지정하지 않고 보낸 요청도 적응형 사고로 실행됩니다. 적응형 사고는 모델이 요청에 맞춰 추론에 들일 분량을 스스로 조절하는 방식입니다. 이전 세대에서는 같은 요청이 추론 단계 없이 실행됐습니다.

사고 토큰은 모델이 답을 만들기 위해 내부적으로 추론하면서 쓰는 토큰입니다. 이 토큰은 응답에 돌려주지 않아도 출력 토큰으로 청구됩니다. 마이그레이션 가이드의 표현은 이렇습니다 — "although per-token pricing is unchanged, a workload that ran without thinking on Claude Opus 4.8 can produce more output tokens per request on Claude Opus 5."

출력 단가는 입력 단가의 다섯 배입니다. 사고가 켜지면서 늘어난 출력 비용이 입력 단가 인하로 아낀 금액보다 클 수 있습니다. 이 변화는 토크나이저와 무관하므로 따로 계산해야 합니다. 예전 동작으로 돌리려면 thinking: {type: "disabled"}를 넘기면 되지만, 문서는 이 경우 모델이 도구 호출을 평문으로 내보내거나 내부 태그를 노출하는 일이 가끔 있다고 적고 있습니다.

1M은 예전 1M이 아닙니다

입력 한도는 모델이 한 번에 받을 수 있는 토큰의 총량입니다. 숫자는 그대로 100만인데, 그 안에 들어가는 글의 양이 줄었습니다.

이 환산은 개발사가 단어 기준으로 적은 것이라 영어를 전제한 값으로 보입니다. 4장에서 측정한 한국어 본문 네 종은 토큰 수가 그대로였으므로, 그런 입력만 넣는 작업이라면 한도에 닿는 시점도 그대로일 것입니다. 토큰 수가 늘어나는 입력에서는 컨텍스트 압축이 더 일찍 돌고, 한 번에 넣을 수 있는 파일 수가 줄어듭니다. 컨텍스트 압축은 한도에 닿기 전에 대화를 줄여 자리를 확보하는 동작입니다. 문서도 출력 상한을 정하는 max_tokens에 여유를 더 두고, 압축이 시작되는 기준을 다시 잡으라고 적고 있습니다.

가격 쪽에서는 반대 방향의 변화도 있습니다. Claude 4.6 이후 모델은 100만 토큰 컨텍스트 전체를 기본 단가로 쓰고, 20만 토큰을 넘겨도 장문 할증이 붙지 않습니다.

오늘 할 수 있는 것

순서대로 하면 30분 안에 끝납니다. 토큰 카운팅은 과금되지 않으므로 비용 걱정 없이 돌릴 수 있습니다.

1. 내 프롬프트를 두 모델로 각각 세어 보세요. 개발사가 지정한 절차가 이것입니다 — 같은 요청을 지금 쓰는 모델과 옮겨 갈 모델로 한 번씩 세어 input_tokens를 비교합니다. 문서가 밝힌 범위는 1~1.35배이고 이 글의 측정은 1.000~1.420배였습니다. 어느 쪽이든 대표값을 가져다 쓰는 것보다 내 것을 재는 쪽이 정확합니다.

   curl -s https://api.anthropic.com/v1/messages/count_tokens \
     -H "x-api-key: $ANTHROPIC_API_KEY" \
     -H "anthropic-version: 2023-06-01" \
     -H "content-type: application/json" \
     -d '{"model":"claude-sonnet-4-6","messages":[{"role":"user","content":"내 실제 프롬프트"}]}'
   
   # 같은 내용을 옮겨 갈 모델로 한 번 더
   #   "model":"claude-sonnet-5"
   # 두 input_tokens 의 비가 내 작업 부하의 배수입니다

   한 문장이 아니라 실제로 보내는 프롬프트 전체로 재세요. 시스템 프롬프트, 도구 정의, 붙이는 파일까지 넣어야 실제 배수가 나옵니다.
2. 짧은 프롬프트를 잰다면 고정 오버헤드를 걷어내세요. 위 응답에는 모델마다 다른 고정량(측정 당시 6~11)이 섞여 있어, 짧을수록 배수가 1에 가깝게 왜곡됩니다. 같은 글을 1회와 5회 넣어 차이를 4로 나누면 그 고정량이 상쇄됩니다. 이 글의 표는 전부 이렇게 구했습니다.

   #!/usr/bin/env python3
   import json, os, urllib.request
   
   KEY  = os.environ["ANTHROPIC_API_KEY"]
   PAIR = ("claude-sonnet-4-6", "claude-sonnet-5")   # (지금 쓰는 모델, 옮겨 갈 모델)
   TEXT = open("my_prompt.txt", encoding="utf-8").read()
   
   def count(model, text):
       req = urllib.request.Request(
           "https://api.anthropic.com/v1/messages/count_tokens",
           data=json.dumps({"model": model,
                            "messages": [{"role": "user", "content": text}]}).encode(),
           headers={"x-api-key": KEY,
                    "anthropic-version": "2023-06-01",
                    "content-type": "application/json"})
       with urllib.request.urlopen(req, timeout=45) as r:
           return json.load(r)["input_tokens"]
   
   def net(model, text):                      # 고정 오버헤드를 상쇄한 사본 1개당 토큰
       one  = count(model, text)
       five = count(model, "\n\n".join([text] * 5))
       return (five - one) / 4
   
   old, new = (net(m, TEXT) for m in PAIR)
   print(f"{PAIR[0]}: {old:.0f} 토큰")
   print(f"{PAIR[1]}: {new:.0f} 토큰")
   print(f"배수: {new/old:.3f}")

   이 글의 테스트 텍스트 10종은 4장 표에 이름·글자 수·ASCII 비중으로 구성을 적어 두었습니다. 같은 절차를 자기 프롬프트에 그대로 적용하면 됩니다.
3. 비교하려는 두 모델이 4.7 경계를 넘는지 확인하세요. 같은 쪽에 있으면 토큰 수가 같으므로 단가를 그대로 비교해도 됩니다. 경계를 넘으면 단가에 배수를 곱한 뒤에 비교해야 합니다.
4. 캐시 읽기 단가를 모델별로 다시 확인하세요. "입력의 10%"는 이제 전부에 통하는 규칙이 아닙니다. 캐시 읽기가 청구서의 큰 몫을 차지하는 작업이라면 이 항목만으로 모델 선택이 뒤집힐 수 있습니다.
5. 사고가 켜지는지 확인하고 출력 토큰을 다시 재세요. 이전 세대에서 thinking 없이 돌던 요청이 5 세대에서는 사고와 함께 돕니다. 입력만 보고 계산하면 늘어난 출력을 놓칩니다.
6. max_tokens와 컨텍스트 압축 기준을 다시 잡으세요. 앞 단계에서 잰 배수가 1보다 컸다면, 같은 100만 토큰에 들어가는 분량이 그만큼 줄어 예전 기준으로 잡아 둔 임계값이 더 일찍 걸립니다. 배수가 1이었다면 그대로 두어도 됩니다.
7. 옛 모델로 재 둔 토큰 수를 근거로 만든 예산·한도는 버리세요. 문서가 명시적으로 경고하는 항목입니다. 다시 세는 데 드는 비용은 0입니다.

아직 결론이 아닌 것

• 테스트 텍스트는 제가 만든 것이고 실제 작업 부하가 아닙니다. 10종 모두 141~559자로 짧고, 실제 서비스의 프롬프트는 시스템 프롬프트·도구 정의·첨부 파일이 섞여 구성이 다릅니다. 표의 배수를 그대로 쓰지 말고 §9의 절차로 자기 프롬프트를 재세요.
• JSON 로그의 1.420배는 문서가 적은 상한 1.35배를 넘었습니다. 문서가 "roughly"와 "varying by content"라고 적었으므로 문서와 모순되지는 않지만, 1.35를 천장으로 삼고 예산을 잡으면 모자랄 수 있습니다. 왜 이 테스트 텍스트가 더 높았는지는 확인하지 못했습니다.
• ASCII 비중과 배수의 상관계수 0.899는 표본 10개에서 나온 값입니다. 방향은 분명하지만 계수로 예측에 쓸 수준이 아닙니다. ASCII 100%인 세 테스트 텍스트가 1.227·1.309·1.420으로 서로 달랐다는 점이 그 한계를 그대로 보여 줍니다. 한글 비중이 배수를 결정한다고 말할 근거는 이 측정에 없습니다 — 함께 움직였다는 것까지가 확인된 것입니다.
• count_tokens의 값은 개발사가 밝힌 대로 추정치입니다. 실제 요청에서 몇 토큰 차이가 날 수 있습니다. 다만 구 토크나이저 3종과 신 토크나이저 4종이 각각 완전히 같은 값을 냈으므로, 이 측정 안에서 값이 흔들리지는 않았습니다.
• 출력 토큰은 재지 않았습니다. 사고가 기본으로 켜지면서 출력 토큰이 늘어난다는 7장의 내용은 개발사 문서를 옮긴 것이고 자체 측정이 아닙니다. 출력 단가가 입력의 다섯 배이므로, 실제 청구서에서는 이쪽이 더 크게 움직일 수 있습니다.
• 고정량을 걷어낸 뺄셈에도 가정이 있습니다. 같은 글을 다섯 번 이어 붙이면 글과 글이 맞닿는 자리에서 토큰이 조금 달라질 수 있습니다. 한 글자 메시지로 잰 오버헤드(6~11)와 대조해 값이 일관되는 것은 확인했지만, 뺄셈이 오버헤드를 정확히 0으로 만들었다고 증명한 것은 아닙니다.
• 다른 개발사 모델은 재지 않았습니다. OpenAI·Google의 토크나이저는 이 글의 범위 밖입니다. 그쪽에서도 같은 함정이 있는지는 확인하지 않았습니다.
• 가격과 모델 사양은 2026-09-21 기준입니다. 이 항목들은 자주 바뀌므로 도입 시점에 공식 문서를 다시 확인하세요.

참고자료

1차 출처는 전부 2026-09-21에 직접 열어 확인했습니다. 가격·모델 사양·토크나이저는 자주 바뀌므로 확인 날짜를 함께 적습니다.

이 글의 측정은 /v1/messages/count_tokens 응답의 input_tokens만 씁니다. 문서가 밝혔듯 이 값은 추정치이며, 실제 요청에서 몇 토큰 차이가 날 수 있습니다. 또한 개발사가 시스템 최적화를 위해 더한 토큰이 포함될 수 있고 그 부분은 청구되지 않습니다.