토큰 수는 왜 글자 수가 아니라 모델별 운영 계약일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 모델을 바꿀 때 왜 같은 프롬프트라도 비용·컨텍스트 한도·캐시 히트가 함께 흔들릴까?
• 핵심 출처:
  • Introducing Claude Sonnet 5 - 2026-06-30 게시, 2026-07-08 확인
  • Pricing - Claude Platform Docs - 게시일 미표기, 2026-07-08 확인
  • Token counting - Claude Platform Docs - 게시일 미표기, 2026-07-08 확인
  • Counting tokens - OpenAI API - 게시일 미표기, 2026-07-08 확인
  • Understand and count tokens - Gemini API - 게시일 미표기, 2026-07-08 확인

1. 왜 지금 봐야 하나

최근 모델 릴리스를 볼 때 개발자가 놓치기 쉬운 문장이 있다. “더 싸졌다”, “더 긴 컨텍스트를 지원한다”, “더 agentic하다” 같은 headline보다 실제 운영비와 안정성을 흔드는 것은 토큰화 방식이다.

Anthropic은 Claude Sonnet 5를 2026년 6월 30일 공개하면서 더 강한 agentic 성능과 낮은 가격대를 강조했다. 그런데 Claude Platform 가격 문서에는 중요한 단서가 붙어 있다. Claude Sonnet 5와 일부 최신 Claude 모델은 새로운 tokenizer를 사용하며, 같은 텍스트가 이전 모델 대비 대략 30% 더 많은 토큰으로 계산될 수 있다고 안내한다. 즉 “입력 100만 토큰당 가격”만 보고 모델을 바꾸면 실제 청구액과 context window 사용량을 잘못 예상할 수 있다.

OpenAI와 Google 문서도 같은 방향을 보여준다. OpenAI의 token counting 문서는 로컬 tokenizer가 plain text에는 유용하지만 이미지, 파일, tool schema, response 구조 토큰, 모델별 동작은 정확히 세기 어렵다고 설명한다. Gemini 문서는 text뿐 아니라 이미지, 비디오, 오디오, tool use, thinking, cached content까지 usage에 토큰으로 잡힌다고 설명한다.

오늘의 핵심은 단순하다. 토큰은 문자열 길이가 아니라, 특정 모델이 특정 요청 구조를 어떻게 처리하는지에 대한 운영 계약이다.

2. 핵심 개념

토큰화(tokenization)는 입력을 모델 vocabulary의 작은 단위로 쪼개는 과정이다. 영어 단어 하나가 한 토큰일 수도 있고, 긴 단어 일부가 여러 토큰일 수도 있고, 한국어·코드·공백·이모지·JSON 기호는 모델과 tokenizer에 따라 예상과 다르게 쪼개질 수 있다.

하지만 LLM 앱에서 토큰을 “텍스트 조각”으로만 이해하면 부족하다. 실제 요청의 토큰 수에는 보통 다음이 함께 들어간다.

1. 사용자가 보낸 본문
2. system/developer instruction
3. 이전 대화 기록
4. tool/function schema
5. structured output schema
6. 이미지·PDF·오디오 같은 비텍스트 입력
7. provider가 메시지 구조를 표현하기 위해 넣는 formatting token
8. reasoning/thinking, tool use, cached token처럼 usage에 따로 잡히는 항목

그래서 글자 수 ÷ 4 같은 규칙은 초안 추정에는 쓸 수 있어도, 배포 판단에는 위험하다. 특히 에이전트 앱은 도구 설명과 JSON schema가 길고, RAG 앱은 검색 문서가 길며, 멀티모달 앱은 이미지나 오디오가 token budget을 크게 먹는다. 사용자가 입력한 문장은 짧아도 “실제 모델이 보는 요청”은 매우 클 수 있다.

3. 최신 이슈와 연결

Claude Sonnet 5 사례는 좋은 경고다. 공식 발표만 보면 Sonnet 5는 agentic 작업에 더 강하고, API identifier는 claude-sonnet-5이며, 2026년 8월 31일까지 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러의 introductory pricing을 제공한다. 이후 표준 가격은 입력 3달러, 출력 15달러로 안내되어 있다.

그런데 가격 문서와 token counting 문서는 최신 tokenizer가 같은 텍스트를 약 30% 더 많은 토큰으로 만들 수 있다고 말한다. 이 말은 “모델 가격표”와 “실제 workload token count”를 분리해서 봐야 한다는 뜻이다.

예를 들어 이전 모델에서 한 요청이 평균 20,000 input token이었다고 하자. 새 tokenizer에서 같은 요청이 26,000 token으로 늘면 context window 여유, rate limit, prompt cache 임계점, 월 비용이 모두 바뀐다. 가격이 비슷해 보이더라도 실제 요청당 비용은 달라질 수 있다. 반대로 새 모델의 성공률이 높아져 재시도와 human review가 줄면 총비용은 내려갈 수도 있다. 그래서 모델 교체 판단은 “토큰당 가격”이 아니라 완료된 작업당 비용으로 봐야 한다.

OpenAI의 token counting 문서도 이 관점을 강화한다. 같은 Responses API payload를 counting endpoint에 보내 정확한 input token 수를 미리 확인하라고 한다. 특히 tool과 schema는 로컬 tokenizer로 세기 어렵고, output token count에는 눈에 보이지 않는 구조 토큰이 포함될 수 있으므로 max output limit에 여유를 두라고 설명한다. Gemini 문서도 count_tokens와 실제 response의 usage를 함께 보라고 한다. usage에는 input/output 외에 thought, cached, tool use token이 따로 나타난다.

4. 개발자 관점 해석

토큰은 세 가지 결정을 동시에 건드린다.

첫째, context fit이다. 모델의 context window는 “입력만”이 아니라 보통 입력과 출력 예산의 합으로 이해해야 한다. 긴 RAG 문서를 꽉 채워 넣으면 답변할 공간이 부족해지고, tool schema와 structured output schema가 커지면 사용자가 넣을 수 있는 실제 여유가 줄어든다. Gemini 문서처럼 input token limit과 output token limit을 모델 정보로 조회하거나, provider의 count endpoint로 사전에 검사하는 흐름이 필요하다.

둘째, 비용과 rate limit이다. 최신 모델 가격표의 단위는 대개 million tokens다. 하지만 tokenizer가 바뀌면 같은 workload의 million token 환산량도 바뀐다. Claude 문서의 30% 증가 주의처럼, 모델 migration에서는 “가격표 비교”보다 “우리 실제 payload 50~100개를 새 모델 기준으로 recount”가 먼저다.

셋째, latency와 caching이다. 긴 prefix는 prefill 지연과 비용을 만든다. Prompt caching은 반복 prefix를 재사용해 비용과 TTFT를 낮출 수 있지만, cache hit도 결국 tokenized prefix가 안정적으로 반복될 때 가능하다. system prompt 앞부분에 매번 timestamp를 넣거나 tool schema 순서가 요청마다 바뀌면 캐시가 깨진다. 토큰 수 관리는 비용 관리이면서 캐시 설계이기도 하다.

여기서 흔한 실패 모드는 네 가지다.

• 문자 수 기준 validation: “5만 자 이하”로 검사했지만 특정 언어·코드·JSON에서 token limit을 넘는다.
• 로컬 tokenizer 과신: plain text만 세고 tool schema, 이미지, PDF, message wrapper 토큰을 빠뜨린다.
• 모델 교체 후 무검증 배포: tokenizer 변경 때문에 context truncation, rate limit 초과, cache miss가 늘어난다.
• visible output만 보고 max token 설정: 실제 output usage에는 reasoning이나 구조 토큰이 포함될 수 있어 원하는 만큼의 답변이 잘린다.

5. 내 프로젝트에 적용할 체크포인트

AI 기능을 운영 중이라면 token budget을 코드의 상수처럼 다루지 말고, 관측 가능한 지표로 만들어야 한다.

• 요청 전: provider의 token counting API로 실제 payload 기준 input token을 센다.
• 요청 중: max output token에는 visible answer 외 구조·reasoning 여유를 둔다.
• 요청 후: usage에서 input, output, cached, reasoning/thinking, tool use token을 분리 저장한다.
• 모델 교체 전: 대표 payload 50~100개를 새 모델 기준으로 recount한다.
• RAG: 검색 chunk 개수보다 “남은 answer budget”을 먼저 계산한다.
• Agent: tool schema와 system prompt가 전체 prompt에서 차지하는 비율을 기록한다.
• Cache: stable prefix와 variable suffix를 분리하고, cache hit token을 지표로 본다.

작은 팀이라면 처음부터 복잡한 비용 예측 시스템을 만들 필요는 없다. 대신 로그에 아래 필드를 남기는 것만으로도 충분히 시작할 수 있다.

{
  "model": "...",
  "feature": "support_rag_answer",
  "input_tokens": 0,
  "output_tokens": 0,
  "cached_tokens": 0,
  "reasoning_or_thought_tokens": 0,
  "tool_use_tokens": 0,
  "visible_output_chars": 0,
  "latency_ms": 0,
  "success": true
}

이 로그가 있으면 “프롬프트를 줄였는데 왜 비용이 그대로지?”, “모델을 바꿨더니 왜 rate limit이 터지지?”, “캐시를 켰는데 왜 TTFT가 그대로지?” 같은 질문에 답할 수 있다.

6. 오늘 10분 액션

10분만 써서 아래 표를 하나 만든다.

실제 API key가 없다면 오늘은 코드 구조만 잡아도 된다.

1. 프로덕션에서 자주 쓰는 요청 payload 3개를 고른다.
2. provider의 token counting endpoint에 보낼 수 있는 형태로 저장한다.
3. 현재 모델과 후보 모델 이름을 바꿔가며 count를 비교하도록 함수를 만든다.
4. 결과가 20% 이상 달라지는 요청을 표시한다.
5. 그 요청에서 줄일 수 있는 항목이 user content인지, RAG chunk인지, tool schema인지, system prompt인지 분리한다.

목표는 “토큰을 아껴라”가 아니다. 목표는 모델 교체와 프롬프트 변경이 비용·지연·context 안정성에 주는 영향을 배포 전에 보는 것이다.

7. 더 볼 자료

• Anthropic의 Claude Sonnet 5 발표: 새 모델의 agentic 성능, 가격, availability를 확인할 수 있다.
• Claude pricing 문서: 최신 모델 tokenizer와 cache pricing 주의사항을 확인할 수 있다.
• Claude token counting 문서: Messages API payload 기준으로 token count를 확인하는 방법을 제공한다.
• OpenAI token counting 문서: Responses API payload와 동일한 구조로 input token을 세는 흐름을 설명한다.
• Gemini token 문서: text, image, audio, video, thinking, cached, tool use token을 어떻게 usage에서 보는지 정리한다.

중복 회피 메모

최근 ai_dev 글은 도구 호출 왕복 프로토콜, 서브에이전트의 컨텍스트 격리, 백그라운드 에이전트 작업 큐, 장기 실행 memory/checkpoint, 실시간 세션 상태 머신, LLM 라우터와 prompt caching, structured outputs, reasoning effort를 다뤘다. 이번 글은 특정 agent architecture나 cache 기법을 반복하지 않고, 최신 Claude Sonnet 5의 tokenizer 변경 주의와 OpenAI/Gemini/Claude token counting 문서를 바탕으로 모델별 token counting을 비용·context·latency의 운영 계약으로 관리하는 법에 집중한다.