Claude 4.7 토크나이저 실측 — 공식 상한 1.35배? 실제는 1.47배였다

• Anthropic이 Claude Opus 4.7 마이그레이션 가이드에서 "새 토크나이저는 4.6 대비 대략 1.0~1.35배 많은 토큰을 쓴다"고 안내했는데, 실측해보니 기술 문서 1.47배, 실제 CLAUDE.md 1.45배 — 공식 상한을 넘거나 턱밑까지 치솟음
  • 가격표는 그대로. 쿼터도 그대로. 근데 프롬프트당 토큰은 더 많아짐
  • Max 플랜 윈도우는 더 빨리 타들어가고, 캐시된 프리픽스는 턴당 비용이 더 비싸지고, 레이트 리밋은 더 빨리 걸림

측정 방법

• Anthropic의 무료 엔드포인트 POST /v1/messages/count_tokens로 같은 콘텐츠를 두 모델에 돌려 순수 토크나이저 차이만 뽑음
• 샘플 두 묶음
  • 실전 배치: Claude Code 유저가 실제 보내는 7종 (CLAUDE.md, 유저 프롬프트, 블로그 발췌, git 로그, 터미널 출력, 스택트레이스, 코드 diff)
  • 합성 배치: 12종 (영문 산문, 코드, 구조화 데이터, CJK, 이모지, 수학 기호 등)

실제 Claude Code 콘텐츠 실측치

콘텐츠	4.6 토큰	4.7 토큰	비율
CLAUDE.md (실파일 5KB)	1,399	2,021	1.445x
유저 프롬프트	1,122	1,541	1.373x
블로그 발췌(마크다운)	1,209	1,654	1.368x
git 커밋 로그	910	1,223	1.344x
터미널 출력(pytest)	652	842	1.291x
파이썬 스택트레이스	1,736	2,170	1.250x
코드 diff	1,226	1,486	1.212x

• 7개 가중 평균: 1.325배 (8,254 → 10,937 토큰)

합성 샘플에서 드러난 패턴

• 영문 기술문서 1.47배, 셸 스크립트 1.39배, TypeScript 1.36배 — 영어와 코드가 제일 크게 증가
• 일본어 1.01배, 중국어 1.01배 — CJK는 거의 변화 없음
• JSON, CSV, 툴 정의(JSON Schema) 같은 구조화 데이터는 1.07~1.13배로 영향 미미
• 영문+코드 서브셋 가중 평균은 1.345배

토크나이저에서 뭐가 바뀌었길래

• 영어의 토큰당 문자수가 4.33 → 3.60, TypeScript는 3.66 → 2.69로 하락 — 같은 텍스트를 더 작은 조각으로 표현
• CJK·이모지·기호는 거의 그대로 → 전체 어휘 교체가 아니라 **라틴 파트만 주로 수정됐다는 가설
• 코드는 키워드·임포트·식별자처럼 반복되는 고빈도 문자열이 많아서 BPE 어휘가 긴 머지로 뭉쳐놓기 좋음 → 머지를 짧게 줄이자 코드가 더 세게 영향 받음 (1.29~1.39배)

왜 이런 짓을? Anthropic의 논리

• 가이드 원문: "더 문자 그대로의 명령 추종**, 특히 낮은 effort 레벨에서. 모델이 한 항목의 지시를 다른 항목으로 암묵적으로 일반화하지 않음"
• 더 작은 토큰 = 개별 단어 위에 어텐션 강제 → 명령 추종·글자 단위 작업·툴 호출 정확도 향상이라는 주장
• Notion, Warp, Factory 같은 파트너들이 "긴 런에서 툴 에러 감소"를 보고

IFEval로 직접 검증

• IFEval은 구글이 2023년 낸 검증 가능 제약 벤치마크 ("정확히 N단어로 응답", "X 단어를 두 번 포함", "콤마 금지", "전부 대문자" 등 파이썬 채점기 내장)
• 541개 프롬프트 중 고정 시드로 20개 샘플링해서 양 모델 비교

지표	4.6	4.7	델타
Strict, 프롬프트 레벨	17/20 (85%)	18/20 (90%)	+5pp
Strict, 인스트럭션 레벨	25/29 (86%)	26/29 (90%)	+4pp
Loose, 프롬프트 레벨	18/20 (90%)	18/20 (90%)	0
Loose, 인스트럭션 레벨	26/29 (90%)	26/29 (90%)	0

• 방향성은 일관되게 개선이지만 작음
• 실제로 갈린 건 4개 제약 체인 프롬프트 하나 — 4.6은 1개를 놓쳤고 4.7은 4개 다 맞춤
• N=20이라 통계적으로 "차이 없음"부터 "진짜 +10pp"까지 구간 안에 다 들어감
• 토크나이저·가중치·사후학습이 한꺼번에 바뀌어서 +5pp의 원인을 토크나이저로만 못 돌림

---

80턴 Claude Code 세션 비용 실측

• 세팅: 고정 프리픽스 6K(CLAUDE.md 2K + 툴 정의 4K), 히스토리는 턴당 2K씩 증가 → 80턴째 160K, 캐시 히트율 95%

4.6 기준

항목	계산	비용
1턴 캐시 쓰기	8K × $6.25/MTok	$0.05
2~80턴 캐시 읽기	79 × 86K × $0.50/MTok	$3.40
신규 유저 입력	79 × 500 × $5/MTok	$0.20
출력	80 × 1,500 × $25/MTok	$3.00
합계		~$6.65

4.7 기준 (토큰 팽창 반영)

• CLAUDE.md 1.445배 → 2K가 2.9K
• 툴 정의 1.12배 → 4K가 4.5K
• 히스토리(영어+코드) 1.325배 → 160K가 212K, 평균 캐시 프리픽스 86K → 115K
• 출력은 비슷하지만 Claude Code의 새 xhigh 기본값이 생각 토큰을 더 뿜으면 최대 30%↑

항목	계산	비용
1턴 캐시 쓰기	10K × $6.25/MTok	$0.06
2~80턴 캐시 읽기	79 × 115K × $0.50/MTok	$4.54
신규 유저 입력	79 × 660 × $5/MTok	$0.26
출력	80 × 1,500~1,950 × $25/MTok	$3.00~$3.90
합계		$7.86$8.76

• 즉 세션당 2030% 더 비쌈
• Max 플랜 유저는 달러 대신 5시간 레이트 리밋 윈도우가 그만큼 빨리 닫힘 — 4.6에서 꽉 채우던 세션이 4.7에선 중간에 끊길 가능성

캐시 관련 함정

• Anthropic 프롬프트 캐시는 모델별로 파티셔닝 → 4.6 → 4.7 전환 시 모든 프리픽스 무효화 (Opus ↔ Sonnet 전환과 동일)
  • 게다가 새로 쓰는 프리픽스는 4.6 대비 1.3~1.45배 커진 상태라 콜드 스타트 비용 더 올라감
• CLAUDE.md 수정, 툴 리스트 변경, 컴팩션 이벤트 때마다 캐시 재작성 → 이런 엣지 케이스에선 토큰 팽창 비율을 그대로 맞음
• 빌링/옵저버빌리티를 과거 토큰 카운트 기준으로 잡아놨다면 모델 ID 바꾸는 날 계단식 점프 발생

반론 검토

• "입력 대부분이 캐시 읽기라 토큰당 비용 미미함" — 맞음. TTL 안쪽 세션이면 입력의 96%가 $0.50/MTok. 1.325배 팽창의 달러 임팩트는 신선 입력보단 작음
  • 하지만 Max는 모든 토큰을 레이트 리밋에 카운트. TTL 만료 직후, 캐시 무효화 이벤트, 컴팩션 때는 캐시 쓰기에 비율이 온전히 먹힘
• "1.0~1.35배는 범위지 상한 아님" — 동의. 다만 실측 가중 1.325배는 범위 꼭대기에 앉아있고 CLAUDE.md(1.445)·기술문서(1.473)는 이미 돌파. 평균이 아닌 상한 기준으로 계획 짜야 함

---

기술 맥락

Claude 4.7이 토큰을 더 많이 쓰게 된 이유를 이해하려면 BPE(Byte-Pair Encoding) 토크나이저가 어떻게 동작하는지 알아야 해요. BPE는 자주 붙어 나오는 문자 쌍을 하나의 토큰으로 "머지"해서 어휘에 넣는 방식이거든요. 예를 들어 function이라는 단어가 학습 데이터에 엄청 자주 나오면 한 토큰으로 통째로 들어가요. 4.7은 이런 긴 머지를 짧게 쪼갠 것으로 추정돼요. 왜냐면 토큰이 더 작을수록 모델이 단어 내부 문자에 어텐션을 줄 수 있어서 "정확히 N단어로", "모두 대문자로" 같은 문자 단위 지시를 더 잘 따르거든요.

프롬프트 캐시가 모델별로 분리되는 이유는 모델마다 어텐션 가중치와 내부 표현이 다르기 때문이에요. 같은 텍스트라도 4.6과 4.7이 만드는 내부 KV 캐시는 완전히 다른 숫자들이라, 섞어 쓸 수가 없어요. 그래서 모델을 바꾸면 캐시 히트율이 100%에서 0%로 떨어지고, 첫 턴에 풀 프리픽스를 다시 써야 해요. 캐시 쓰기는 읽기보다 12.5배(6.25 vs 0.50 $/MTok) 비싸니까 이 순간의 임팩트가 큰 거예요.

Max 플랜 사용자가 특히 타격 받는 이유는 Max가 달러가 아니라 토큰 기준 레이트 리밋이어서예요. 캐시 읽기 할인이 아무리 커도 레이트 리밋 계산엔 원래 토큰 수가 그대로 들어가니, 1.325배 팽창이 5시간 윈도우를 1.325배 빨리 소진시키는 거죠. 달러 민감한 API 사용자와 윈도우 민감한 Max 사용자의 경험이 갈리는 지점이에요.

IFEval은 모델 응답을 사람 평가자 없이 파이썬 함수로 자동 채점할 수 있게 설계된 벤치마크예요. 그래서 재현성이 높고 측정 비용이 낮지만, 이번 실험처럼 N=20에선 신뢰구간이 넓어져서 "방향성"만 볼 수 있지 "크기"는 못 잡아요. 실무에서 모델 업그레이드 검증할 때도 같은 함정이 있으니, 본인 워크로드에서 직접 A/B 테스트 하는 게 가장 정확해요.

count_tokens API는 추론 없이 토큰 수만 세주는 무료 엔드포인트예요. 이걸 쓰면 어떤 프롬프트가 자기 앱에서 얼마나 팽창하는지 배포 전에 미리 계산할 수 있어요. 프로덕션 붙이기 전에 주요 프롬프트 템플릿 몇 개로 4.6↔4.7 비율을 뽑아보고 비용/레이트리밋 예산 다시 짜는 걸 추천해요.