Claude Opus 4.7은 이 문제가 실제로 어떻게 나타나는지 보여주는 사례입니다. Anthropic 문서는 Opus 4.7의 새 토크나이저가 텍스트를 처리할 때 이전 모델 대비 대략 1x~1.35x의 토큰을 사용할 수 있다고 설명합니다. 즉 최대 약 35% 더 많아질 수 있지만, 증가 폭은 콘텐츠에 따라 달라집니다. 또 같은 입력을 /v1/messages/count_tokens로 비교하면 Claude Opus 4.7과 Opus 4.6의 토큰 수가 다르게 나온다고 명시되어 있습니다.
가장 정확한 표현은 이렇습니다. 새 토크나이저 때문에 같은 프롬프트의 입력 토큰 수가 늘어날 수 있고, 입력 토큰 단가가 그대로라면 입력 비용도 올라갈 수 있습니다. 다만 Anthropic이 제시한 범위는 약 1x~1.35x이며, 콘텐츠에 따라 달라진다고 밝히고 있습니다. 따라서 모든 프롬프트가 일괄적으로 35% 더 많은 토큰을 쓴다고 해석하면 안 됩니다.
또 토큰 증가율을 곧바로 전체 청구액 증가율로 보는 것도 위험합니다. Anthropic의 가격 문서는 Base Input Tokens, Cache Writes, Cache Hits, Output Tokens를 나눠 제시합니다. OpenAI와 Gemini도 각각 별도의 API pricing 문서를 제공합니다. 즉 입력 토큰이 늘면 입력 비용에는 영향을 줄 수 있지만, 실제 총비용은 출력 토큰 수, 캐시 적중·쓰기, 모델별 가격, 요청 구조까지 함께 계산해야 합니다.
토큰은 글자 수나 단어 수와 다릅니다. OpenAI의 tiktoken 안내는 특정 encoding을 사용해야 텍스트가 몇 개의 토큰으로 나뉘는지 계산할 수 있음을 보여줍니다. Gemini 문서도 Gemini API의 입력과 출력이 모두 토큰화되며, 텍스트뿐 아니라 이미지 같은 입력도 토큰화 대상이라고 설명합니다.
그래서 글자 수, 단어 수, 대략적인 비율만으로 비용을 추정하는 방식은 어디까지나 rough estimate에 가깝습니다. 실제 비용 판단에는 대상 모델이 반환하는 token count가 더 중요합니다. Claude Opus 4.7과 Opus 4.6이 count_tokens에서 서로 다른 값을 반환할 수 있다는 Anthropic의 설명은, 토크나이저 변경만으로도 같은 콘텐츠의 계산 결과가 달라질 수 있음을 보여줍니다.
| 흔한 해석 | 더 정확한 해석 |
|---|---|
| Opus 4.7로 바꾸면 모든 프롬프트가 35% 비싸진다 | 과도한 단순화다. 공식 설명은 약 1x~1.35x 토큰이며, 콘텐츠에 따라 달라진다. |
| 같은 텍스트가 더 많은 토큰으로 계산될 수 있다 | 맞다. Anthropic은 Opus 4.7의 새 토크나이저가 더 많은 토큰을 사용할 수 있고, Opus 4.6과 token count가 달라진다고 설명한다. |
| 토크나이저 변경은 context limit에만 관련 있고 비용과는 무관하다 | 불완전한 설명이다. API pricing은 input, output, cache 등 토큰 사용량 항목을 기준으로 나뉘므로 token count 변화는 비용 계산에 영향을 줄 수 있다. |
| 공식 counter로 직접 재는 것이 가장 안전하다 | 맞다. OpenAI는 input token counting 및 tiktoken 안내를 제공하고, Gemini는 count_tokens 문서를 제공하며, Anthropic도 Opus 4.7 문서에서 /v1/messages/count_tokens를 언급한다. |
입력 토큰만 따지고, 입력 토큰 단가가 바뀌지 않았다고 가정하면 단순 계산식은 다음과 같습니다.
추가 입력 비용 ≈ (새 토크나이저의 입력 토큰 수 − 기존 토크나이저의 입력 토큰 수) × 입력 토큰 단가
하지만 이 식은 입력 비용만 보는 계산입니다. 실제 청구액에는 출력 토큰, 캐시 쓰기, 캐시 히트 또는 기타 제품별 과금 항목이 들어갈 수 있습니다. Anthropic의 pricing 문서는 이런 항목을 구분해 제시하고 있으며, OpenAI와 Gemini도 각각 공식 pricing 문서를 제공합니다.
실제 서비스가 모델에 보내는 내용은 단순한 사용자 질문 하나가 아닐 수 있습니다. system 지시문, 긴 context, 도구 호출용 데이터, 파일, 이미지 등 여러 입력이 함께 들어갈 수 있습니다. Gemini 문서는 모든 input과 output이 토큰화된다고 설명하며, OpenAI의 token counting guide도 텍스트와 이미지를 포함한 input token counting 예시를 제공합니다.
OpenAI는 responses.input_tokens.count 문서와 tiktoken 계산 안내를 제공하고, Gemini는 count_tokens 문서를 제공합니다. Anthropic은 Opus 4.7 문서에서 /v1/messages/count_tokens를 언급하며, Opus 4.7과 Opus 4.6의 토큰 수가 다르게 반환될 수 있다고 설명합니다.
짧은 테스트 프롬프트 하나만 재면 실제 비용 변화를 놓치기 쉽습니다. Anthropic은 Opus 4.7의 토큰 증가 폭이 콘텐츠에 따라 달라진다고 설명합니다. 따라서 트래픽이 많은 요청, 긴 context를 포함한 요청, 비용이 큰 요청, 가장 흔한 payload 유형을 나눠 비교하는 편이 좋습니다.
먼저 새 모델과 기존 모델의 입력 토큰 수 차이를 계산합니다. 그다음 해당 모델의 공식 pricing으로 입력 비용 차이를 구하고, 이후 출력 토큰과 cache 관련 항목을 전체 비용 모델에 다시 더해야 합니다. Anthropic, OpenAI, Gemini 모두 공식 pricing 문서를 제공합니다.
token delta가 작다면 예산과 모니터링 기준만 업데이트해도 충분할 수 있습니다. 반대로 고트래픽 payload에서 입력 토큰이 크게 늘어난다면 프롬프트 압축, context 축소, cache 전략 개선, 요청당 비용 재산정이 필요할 수 있습니다. 핵심은 “35%”라는 숫자만 보고 놀라는 것이 아니라, 공식 counter와 공식 pricing으로 실제 영향을 수치화하는 것입니다.
새 토크나이저는 같은 프롬프트가 더 많은 토큰으로 계산되게 만들 수 있습니다. Claude Opus 4.7의 공식 문서는 텍스트 처리 시 이전 모델 대비 약 1x~1.35x 토큰을 사용할 수 있으며, 최대 약 35% 증가할 수 있지만 콘텐츠에 따라 달라진다고 설명합니다.
따라서 중요한 질문은 “정말 35%인가?”가 아니라 “우리의 실제 payload가 새 모델에서 입력 토큰을 얼마나 더 쓰는가?”입니다. 여기에 출력 토큰 변화, cache 과금 항목, 공급사의 pricing 구조까지 함께 봐야 합니다. 모델을 바꾸기 전 공식 token counter로 먼저 재고, 그 결과를 공식 pricing에 대입하는 것이 프롬프트 비용 증가 여부를 판단하는 가장 현실적인 방법입니다.