Claude Opus 4.7 새 토크나이저와 ‘토큰 35% 증가’의 실제 의미

왜 같은 문장인데 토큰 수가 달라질까?

토큰은 글자 수나 단어 수와 다릅니다. OpenAI의 tiktoken 안내는 특정 encoding을 사용해야 텍스트가 몇 개의 토큰으로 나뉘는지 계산할 수 있음을 보여줍니다. Gemini 문서도 Gemini API의 입력과 출력이 모두 토큰화되며, 텍스트뿐 아니라 이미지 같은 입력도 토큰화 대상이라고 설명합니다.

그래서 글자 수, 단어 수, 대략적인 비율만으로 비용을 추정하는 방식은 어디까지나 rough estimate에 가깝습니다. 실제 비용 판단에는 대상 모델이 반환하는 token count가 더 중요합니다. Claude Opus 4.7과 Opus 4.6이 count_tokens에서 서로 다른 값을 반환할 수 있다는 Anthropic의 설명은, 토크나이저 변경만으로도 같은 콘텐츠의 계산 결과가 달라질 수 있음을 보여줍니다.

‘35% 증가’는 어떻게 읽어야 하나

비용은 어떻게 계산하면 좋을까?

입력 토큰만 따지고, 입력 토큰 단가가 바뀌지 않았다고 가정하면 단순 계산식은 다음과 같습니다.

하지만 이 식은 입력 비용만 보는 계산입니다. 실제 청구액에는 출력 토큰, 캐시 쓰기, 캐시 히트 또는 기타 제품별 과금 항목이 들어갈 수 있습니다. Anthropic의 pricing 문서는 이런 항목을 구분해 제시하고 있으며, OpenAI와 Gemini도 각각 공식 pricing 문서를 제공합니다.

모델 업그레이드 전 점검 절차

1. user message만 보지 말고 전체 payload를 뽑기

실제 서비스가 모델에 보내는 내용은 단순한 사용자 질문 하나가 아닐 수 있습니다. system 지시문, 긴 context, 도구 호출용 데이터, 파일, 이미지 등 여러 입력이 함께 들어갈 수 있습니다. Gemini 문서는 모든 input과 output이 토큰화된다고 설명하며, OpenAI의 token counting guide도 텍스트와 이미지를 포함한 input token counting 예시를 제공합니다.

2. 목표 모델의 공식 token counter 사용하기

OpenAI는 responses.input_tokens.count 문서와 tiktoken 계산 안내를 제공하고, Gemini는 count_tokens 문서를 제공합니다. Anthropic은 Opus 4.7 문서에서 /v1/messages/count_tokens를 언급하며, Opus 4.7과 Opus 4.6의 토큰 수가 다르게 반환될 수 있다고 설명합니다.

3. 콘텐츠 유형별로 샘플링하기

짧은 테스트 프롬프트 하나만 재면 실제 비용 변화를 놓치기 쉽습니다. Anthropic은 Opus 4.7의 토큰 증가 폭이 콘텐츠에 따라 달라진다고 설명합니다. 따라서 트래픽이 많은 요청, 긴 context를 포함한 요청, 비용이 큰 요청, 가장 흔한 payload 유형을 나눠 비교하는 편이 좋습니다.

4. token delta를 공식 pricing에 대입하기

먼저 새 모델과 기존 모델의 입력 토큰 수 차이를 계산합니다. 그다음 해당 모델의 공식 pricing으로 입력 비용 차이를 구하고, 이후 출력 토큰과 cache 관련 항목을 전체 비용 모델에 다시 더해야 합니다. Anthropic, OpenAI, Gemini 모두 공식 pricing 문서를 제공합니다.

5. 결과에 따라 최적화 여부 결정하기

token delta가 작다면 예산과 모니터링 기준만 업데이트해도 충분할 수 있습니다. 반대로 고트래픽 payload에서 입력 토큰이 크게 늘어난다면 프롬프트 압축, context 축소, cache 전략 개선, 요청당 비용 재산정이 필요할 수 있습니다. 핵심은 “35%”라는 숫자만 보고 놀라는 것이 아니라, 공식 counter와 공식 pricing으로 실제 영향을 수치화하는 것입니다.

핵심 정리

새 토크나이저는 같은 프롬프트가 더 많은 토큰으로 계산되게 만들 수 있습니다. Claude Opus 4.7의 공식 문서는 텍스트 처리 시 이전 모델 대비 약 1x~1.35x 토큰을 사용할 수 있으며, 최대 약 35% 증가할 수 있지만 콘텐츠에 따라 달라진다고 설명합니다.

따라서 중요한 질문은 “정말 35%인가?”가 아니라 “우리의 실제 payload가 새 모델에서 입력 토큰을 얼마나 더 쓰는가?”입니다. 여기에 출력 토큰 변화, cache 과금 항목, 공급사의 pricing 구조까지 함께 봐야 합니다. 모델을 바꾸기 전 공식 token counter로 먼저 재고, 그 결과를 공식 pricing에 대입하는 것이 프롬프트 비용 증가 여부를 판단하는 가장 현실적인 방법입니다.