Claude 4.7 토크나이저 비용 측정 결과
(claudecodecamp.com)- Claude 4.7은 이전 버전보다 평균 1.3~1.45배 더 많은 토큰을 생성, 동일한 가격 체계에서 세션당 20~30% 비용 증가 발생
- 영어 및 코드 콘텐츠에서 토큰 증가가 두드러지며, CJK(중국어·일본어·한국어) 콘텐츠는 거의 변화 없음
- 더 세분화된 토큰화로 인해 명령어 준수도(Instruction Following) 가 약 5%p 향상, 특히 형식 오류가 감소
- 캐시 프리픽스와 대화 이력의 토큰 수가 늘어나 캐시 비용과 레이트 리밋 소모 속도가 함께 상승
- 결과적으로 Claude 4.7은 정확도와 세밀한 명령 수행 향상을 얻는 대신 추가 토큰 비용을 감수해야 하는 구조로 평가됨
Claude 4.7 토크나이저 측정 결과
- Anthropic의 Claude Opus 4.7은 이전 버전인 4.6보다 1.0~1.35배 더 많은 토큰을 사용한다고 명시되어 있으나, 실제 측정에서는 1.45~1.47배 수준으로 확인됨
- 동일한 가격과 쿼터 조건에서 토큰 수가 늘어나 맥스 윈도우 소모 속도 증가, 캐시 프리픽스 비용 상승, 레이트 리밋 조기 도달 등의 영향 발생
- 실험은 비용 측정과 명령어 준수도 측정의 두 부분으로 구성됨
비용 측정 방법
- Anthropic API의
POST /v1/messages/count_tokens엔드포인트를 사용해 동일한 콘텐츠를 4.6과 4.7 모델에 각각 입력, 순수 토크나이저 차이만 비교 - 두 가지 샘플 세트를 사용
- 실제 Claude Code 사용자가 전송한 7개 실사용 샘플
- 영어, 코드, 구조화 데이터, CJK, 이모지, 수학 기호 등 12개 인공 샘플
-
실제 Claude Code 콘텐츠 결과
- 7개 실사용 샘플의 가중 평균 비율 1.325배 (8,254 → 10,937 토큰)
- 주요 예시
- CLAUDE.md 파일: 1.445배
- 사용자 프롬프트: 1.373배
- 블로그 포스트: 1.368배
- 코드 diff: 1.212배
-
콘텐츠 유형별 결과 (12개 인공 샘플)
- 영어 및 코드 콘텐츠 평균: 1.345배
- CJK(중국어·일본어·한국어) 콘텐츠 평균: 1.01배
- 세부 예시
- 기술 문서: 1.47배
- Shell script: 1.39배
- TypeScript 코드: 1.36배
- 영어 산문: 1.20배
- JSON: 1.13배
- 일본어·중국어 산문: 1.01배
토크나이저의 변화 패턴
- CJK, 이모지, 기호 콘텐츠는 1.005~1.07배 수준으로 거의 변화 없음
- 비라틴어 어휘는 크게 변경되지 않은 것으로 보임
- 영어 및 코드 콘텐츠는 1.20~1.47배 증가, 코드가 산문보다 더 큰 영향을 받음
- 코드의 반복 문자열(키워드, import, 식별자 등)이 세분화되어 더 많은 토큰으로 분할됨
- 영어의 문자당 토큰 비율은 4.33→3.60, TypeScript는 3.66→2.69로 감소
- 동일한 텍스트가 더 작은 단위로 분리되어 표현됨
더 많은 토큰을 사용하는 이유
- Anthropic은 4.7에서 “명령어를 더 문자 그대로 따르는 경향” 을 강조
- 더 작은 토큰 단위는 단어 수준 주의(attention) 를 강화해 정확한 명령 수행, 문자 단위 작업, 도구 호출 정밀도 향상에 기여
- Notion, Warp, Factory 등 파트너들은 도구 실행 오류 감소를 보고
- 다만, 토큰화 외에도 모델 가중치와 사후 학습(post-training) 이 함께 변경되어 원인 분리는 불가능
명령어 준수도 테스트
- IFEval 벤치마크(2023, Google) 사용: “정확히 N단어로 답하라”, “쉼표 없이 작성하라” 등 541개 프롬프트 중 20개 샘플 테스트
- 결과
- 엄격 모드 프롬프트 단위: 4.6 → 85%, 4.7 → 90% (+5pp)
- 엄격 모드 명령 단위: 86% → 90% (+4pp)
- 느슨한 모드에서는 차이 없음
- 개선은 주로 형식(formatting) 관련 오류 감소에서 발생
- 단일 프롬프트(
change_case:english_capital)에서만 명확한 차이 확인 - 표본 수가 적어(+5pp는 통계적으로 불확실), 작지만 일관된 개선으로 평가됨
Claude Code 세션 단위 비용 계산
- 80회 왕복 대화 세션 가정
- 정적 프리픽스: 6K 토큰 (CLAUDE.md 2K + 도구 정의 4K)
- 대화 이력: 턴당 2K씩 증가, 80턴 시 160K 도달
- 입력/출력: 턴당 500 / 1,500 토큰
- 캐시 적중률: 95%
-
4.6 기준 세션 비용
- | 항목 | 계산 | 비용 |
- | --- | --- | --- |
- | 첫 캐시 쓰기 | 8K × $6.25/MTok | $0.05 |
- | 캐시 읽기 (79회) | 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
- 사용자 입력: 1.325배 → 500 → 660
- 평균 캐시 프리픽스: 약 115K 토큰
- | 항목 | 계산 | 비용 |
- | --- | --- | --- |
- | 첫 캐시 쓰기 | 10K × $6.25/MTok | $0.06 |
- | 캐시 읽기 (79회) | 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 |
- 세션당 20~30% 비용 증가, 토큰 단가 변화 없이 발생
- Max 요금제 사용자는 동일 시간 창 내에서 세션 종료 시점이 더 빨라짐
프롬프트 캐시 영향
- 모델별 캐시 분리로 인해 4.7 전환 시 기존 4.6 캐시 무효화
- 첫 세션은 캐시 미적용 상태로 시작, 더 큰 프리픽스 비용 발생
- 캐시 볼륨 자체가 1.3~1.45배 증가, 읽기·쓰기 모두 동일 비율로 상승
- 동일 대화 로그라도 토큰 수가 달라짐, 과거 대비 청구량·모니터링 수치에 단절 발생
반론 및 해석
-
“입력 대부분이 캐시 읽기라 영향 미미하다”
- 캐시 적중률이 높을 경우 비용 영향은 작지만, TTL 만료, 캐시 무효화, 모델 전환 시에는 전체 비율로 비용 증가
-
“1.35배는 상한이 아니라 범위다”
- 실제 측정값은 상한 근처(1.325배)에 집중, 일부 파일은 이를 초과
- 실제 사용 시 상한 기준으로 계획하는 것이 안전
결론
- 영어 및 코드 중심 작업에서 토큰 사용량 1.3~1.45배 증가
- 명령어 준수도는 약 +5pp 개선, 소폭이지만 실질적 향상
- 세션당 비용은 20~30% 상승, 토큰 단가 동일
- 결과적으로 더 높은 정확도와 세밀한 명령 수행을 위해 추가 비용을 지불하는 구조로 평가됨
Hacker News 의견들
-
LLM의 성능/비용 곡선이 로그 형태로 존재함을 전제로, Opus 4.5+가 이 곡선 위의 새로운 지점인지, 아니면 단순히 더 높은 성능을 위해 비용이 급증하는 구간에 위치한 것인지 불분명함
Anthropic이 가격을 빠르게 인상하는 것은 운영비 급등을 반영하는 신호일 수 있음
모델 평가 그래프에서 x축을 비용 로그로 표시하는 관행이 이런 현실을 가리고 있다고 생각함- Toby Ord의 AI 에이전트 시간당 비용 분석을 참고했음. 그의 성능/비용 프런티어 개념이 더 주목받아야 함
- 이제는 개발자들이 작업에 맞는 모델 크기와 노력 수준을 적정화(right-sizing) 해야 할 시점이라 생각함
무조건 최고 모델을 쓰는 시대는 끝났음. 작업에 따라 여러 지점을 선택할 수 있는 옵션이 필요함
복잡한 작업에는 더 큰 모델을 써서 한 번에 5시간 토큰을 다 써도 괜찮다고 생각함
다만 이런 선택의 복잡성을 싫어하는 사람도 많을 것이고, 앞으로는 스마트 라우팅 시도가 늘어날 것이라 예상함 - Anthropic이 IPO를 앞두고 있어 사용자당 수익 증대 압박이 큼. 결국 실제 모델 운영비를 반영한 가격 구조로 가는 중임
- 모델이 실리콘에 직접 구현되면 비용은 내려가고 속도는 빨라질 것임. Taalas 같은 시도를 참고할 만함
- 만약 고객이 더 높은 비용을 감수할 의향이 있다면, 훨씬 강력한 모델도 제공할 수 있을 것이라 생각함
예를 들어 Apple처럼 초고가 옵션을 원하는 고객층이 존재하듯, 초고성능 LLM 시장도 가능성이 있음
-
많은 사람들이 AI 모델의 비용에 집중하지만, 실제로는 인간이 AI 코딩 에이전트를 조정하고 검토하는 데 드는 시간이 훨씬 비쌈
$200/월은 취미로는 비싸지만, 비즈니스 관점에서는 미미한 수준임
중요한 건 모델이 일을 얼마나 잘하느냐이며, 현재 가격대에서는 시간 대비 효율이 핵심임- 우리 팀은 올해 Claude로 세 가지 제품을 출시했음. 특히 9명 6개월 예상 프로젝트를 2명 2개월로 끝냈음
Claude 구독의 경제적 가치는 1만~4만 유로 수준이라 생각함.
가격이 100배 올라가도 살 것임. 단, 2만 유로/월이 되면 대안을 검토하겠지만, 현재는 생산성 향상이 압도적임 - $200은 기업 입장에서는 부담이 거의 없지만, 개인 취미로는 정당화하기 어려움
- 내 Openclaw 인스턴스는 Opus 사용으로 하루 $200이 청구됐음. 라우팅 최적화가 더 큰 문제임. $1/시간일 땐 좋았지만 $15/시간이면 경쟁력이 떨어짐
- 우리 팀은 올해 Claude로 세 가지 제품을 출시했음. 특히 9명 6개월 예상 프로젝트를 2명 2개월로 끝냈음
-
모델 품질 향상은 결국 수익 체감 구간에 도달할 것이라 생각함
8K vs 16K 디스플레이처럼 대부분의 사용자는 차이를 체감하지 못함
20~30%의 비용 상승이 있다면, 그만큼의 가시적 가치 상승이 있어야 함- 그래서 대부분의 연구가 코딩 분야에 집중된다고 봄. 난이도가 계속 높아지고 경제적 가치도 유지되기 때문임
반면 일반 대화형 질의는 이미 포화 상태라 모델 간 차별화가 어려움 - 99% 정확해 보여도 하루 10만 번의 의사결정을 내릴 때는 작은 오차가 누적되어 큰 문제가 됨
- 로컬에서 실행 가능한 4K 모델이 나오면 대형 연구소들은 곤란해질 것임. 그래도 Google은 광고 수익이 있으니 버틸 듯함
- 작업 종류에 따라 다름. 예를 들어 신약 설계에서 95% 완성과 100% 완성의 차이는 가치의 수십 배 차이를 만듦
- 웹 검색이나 요약용으로는 이미 한계에 도달했지만, 코딩 복잡성은 무한히 확장 가능함
- 그래서 대부분의 연구가 코딩 분야에 집중된다고 봄. 난이도가 계속 높아지고 경제적 가치도 유지되기 때문임
-
GitHub Copilot의 모델 배수(multiplier) 가 3에서 7.5로 증가했음
Microsoft가 손실을 줄이려는 시도로 보임
공식 문서 참고- 그래서 우리 조직에는 “Opus 4.7은 절대 켜지 말라”고 권고했음. 4.6(3x)과 4.5(3x)는 괜찮지만 4.7(7.5x)은 가성비가 전혀 없음
- 최근 Opus 4.6이 추론 품질 저하를 보임. 결론을 서두르고, 논리를 생략함. 큰 돌파구가 없으면 급격한 품질 저하(en**)** 가 올 것 같음
-
기사 제목이 오해를 불러일으킴. 토큰 수는 늘었지만 작업당 비용은 다를 수 있음
Opus 4.7이 Opus 4.6보다 동일한 추론 경로를 쓰지 않는다고 가정함
Artificial Analysis의 Intelligence Index 결과를 기다려야 함- 내부 벤치마크에서 Opus 4.7이 50% 저렴하고 성능 점수는 80%(vs 60%)였음
- 기사 제목을 “Claude Opus 4.7 costs 20–30% more per session”에서 중립적으로 수정했음
- 28개 작업 비교 실험 결과, 4.7은 구버전 4.6과 비슷한 비용이며 신버전 4.6보다 약 20% 비쌈
- 개인 데이터 기준으로는 4.7이 4.6보다 비용이 더 높고, 성능 향상은 불분명했음
- 공식 발표 그래프에서도 “strictly better” 주장 근거를 확인함
-
어제 Opus를 쓸 때는 놀라울 정도로 좋았는데, 오늘은 단순한 작업도 계속 실수함
세 번째로 같은 문제를 지적해야 했고, 세션이 자주 끊기며 컴팩션(compaction) 이 과도하게 발생함
결국 Sonnet으로 돌아가기로 함- 이건 버그가 아니라 연산량 절감 정책임. 앞으로 더 심해질 것임
- LLM은 인격이 아님. 확률 분포에서 샘플링하다 보면 나쁜 세션이 나올 확률이 100%임. 컨텍스트를 초기화하고 다시 시도해야 함
- 나도 최근 Opus 4.7을 쓰며 엉망인 결과를 자주 봄. 모델이 스스로 잘못을 인정하고 다시 시도하는 모습이 씁쓸했음
-
요즘 자주 드는 생각은 “정말 더 강력한 모델이 필요한가?”임
업계가 성능 경쟁에만 몰두하고 효율성과 지속 가능성을 놓치고 있음
앞으로는 0.5B~1B 파라미터 모델을 특정 작업에 맞게 최적화하는 방향이 중요하다고 봄- 나도 Sonnet 4.6을 로컬에서 돌릴 수 있다면 충분히 만족할 것임
CPUs Aren’t Dead 글처럼, Google의 Gemma 4 E2B 모델은 휴대폰에서도 돌아가며 GPT-3.5-turbo를 능가함
Artificial Analysis의 Intelligence Index에 따르면 최신 2B 모델이 3~4년 전 175B 모델과 비슷한 성능을 냄
Gemma 4 E4B는 GPT-4o를 능가하기도 함
이런 추세라면 곧 노트북에서도 최고 수준 모델을 돌릴 수 있을 것임 - 많은 이들이 Sonnet 4.6이 Opus 4.5급 성능을 기대했지만, 현실은 그렇지 않았음
- 효율성은 돈이 안 됨. 대형 LLM 기업은 추론 비용을 비싸게 유지하는 게 이익임
“새 모델이 미쳤다”는 식의 홍보는 결국 FOMO 마케팅임 - 모든 사람이 고급 계산기를 필요로 하진 않음. 필요한 수준의 도구를 고르는 게 중요함
- 하지만 “게으르고 부정확한 모델”에 만족할 수는 없음. 이 문제를 해결하는 연구소가 결정적 우위를 차지할 것임
- 나도 Sonnet 4.6을 로컬에서 돌릴 수 있다면 충분히 만족할 것임
-
인도 콜카타의 과자 상인들이 원자재 가격 상승에도 가격을 못 올리자, 크기를 줄여 대응했음
사람들의 심리적 적응이 이런 식으로 작동함- 전 세계적으로 비슷함. 과자 포장은 그대로인데 내용물이 줄었음. 프링글스 통조차 얇아지고 짧아짐
- 이런 현상은 Shrinkflation으로 불림
-
Anthropic이 4.7에서 xhigh 모드를 새로 도입함
max 모드는 토큰 사용량이 많고 과도한 추론을 유발할 수 있어, 대부분의 경우 xhigh를 권장함
공식 문서 참고- xhigh 단계를 추가하고 max를 멀리 밀어낸 건 마치 “이건 11까지 올라간다”는 느낌임
-
실제 코드 기준으로 Opus 4.7은 약 30% 토큰 증가를 보였음
중요한 건 “4.7이 4.6보다 어떤 새로운 능력을 주는가”임
아직 판단하기 이르며, 가치가 있다면 비용 상승을 감수할 수 있음- 회의 중 흥미로운 점은, 많은 이들이 새 모델을 쫓지만 Sonnet 4.6만으로도 충분히 효율적이라는 것임
작업 범위를 좁히면 리뷰와 관리가 쉬워지고, 작은 diff로 빠르게 수정 가능함
Copilot 토큰 소비가 7배 늘어난다면 오히려 워크플로우 단절이 생길 것 같음 - 최근 4.6이 성능 저하됐다는 불만이 많음
- 4.6이 얼마나 오래 유지될지 모르겠음. 기업용은 좀 더 가겠지만, 개인 구독자는 곧 선택권이 사라질 듯함
- 회의 중 흥미로운 점은, 많은 이들이 새 모델을 쫓지만 Sonnet 4.6만으로도 충분히 효율적이라는 것임