9월 22일, 우리는 Kimi K3에게 max_tokens: 16이라는 짧은 요청을 보냈습니다. 눈에 보이는 답변은 23토큰 길이였습니다. 하지만 사용량 블록에는 150개의 완료(completion) 토큰이 기록되어 있었습니다. 이 중 127개는 아무도 본 적 없는 텍스트였습니다.
바로 그 차이가 이 글의 핵심입니다. 추론 모델(reasoning models)은 답변하기 전에 생각합니다. 그리고 그 사고 과정 자체가 출력 가격으로 청구되며, 대부분의 API에서는 사용자가 이를 볼 수 없습니다. 짧은 보이는 답변이라도 긴 답변만큼 비용이 많이 들 수 있습니다.
추론 토큰이란 무엇인가
**토큰(token)**은 대략 단어의 3/4 정도이며, 우리는 이 토큰 단위로 비용을 지불합니다. 출력 토큰(Output tokens)—즉 모델이 작성하는 내용—은 일반적으로 입력 토큰보다 4~8배 더 비쌉니다. 추론 모델(reasoning model) (o3, GPT-5.x, Gemini 2.5+, Kimi K3, Thinking 기능이 활성화된 Claude 등)은 먼저 자신을 위해 초안을 작성합니다. 즉, 작업을 분해하고, 가설을 확인하며, 이를 폐기하는 과정을 거칩니다. 이 초안 토큰들이 바로 **추론 토큰(reasoning tokens)**입니다.
제공업체는 이 추론 토큰들을 답변과 동일한 하드웨어에서 생성하기 때문에 출력으로 청구됩니다. 대부분의 API는 이 초안을 숨기거나 짧은 요약만 반환합니다. 어떤 경우든 사용자는 초안 전체에 대해 비용을 지불하게 됩니다.
따라서 호출(call)의 가격은 '답변이 얼마나 긴가'가 아닙니다. 답변과 사고 과정 모두를 포함하며, 이 사고 과정 부분은 모델이 질문을 얼마나 어렵다고 판단하느냐에 따라 달라지며, 사용자가 원하는 답변 길이와는 무관합니다.
우리가 실제로 측정한 것들
두 가지 실제 사례이며, 둘 다 저희 자체 게이트웨이 로그에서 가져온 것입니다. 수치는 제공업체의 사용량 필드에서 나온 것입니다:
| 케이스 | 출력 제한(Output cap) | 추론(Reasoning) | 보이는 답변(Visible answer) |
|---|
| Kimi K3, 요청 1건, 2026.09.22 | 16 (무시됨) | 127 | 23 |
| Gemini 2.5 Pro / 3.x, 상태 점검(health probe), 15회 실행 2026.10.01–10.15 | 32 | 28–30 | 0 |
Kimi 행의 경우: 공식 $15/백만 출력 토큰 기준으로, 150토큰은 $0.00225입니다. 사용자가 볼 수 있는 23토큰은 $0.00035에 불과합니다. 이는 텍스트가 시사하는 것보다 6.5배 더 비싼 비용입니다. 만약 매달 이런 호출이 백만 건 발생한다면, 예상치($345)와 달리 $2,250의 비용이 발생할 수 있습니다.
Gemini 행은 저희의 가용성 탐지기(availability probe)입니다. 이 행은 '다음과 같이 정확하게 답변하세요:'라는 지시와 함께 32토큰 제한을 요청합니다. 15회 실행 동안 모델은 생각할 필요가 없는 작업에 대해 28~30토큰을 사용했습니다. 이는 제한에 도달하여(finish_reason: "length") 아무 텍스트도 반환하지 않았습니다. 이는 약 5,000개의 Gemini 탐지기 중 15건에 불과하므로 드문 경우입니다. 하지만 가장 순수한 사례입니다. 전체 출력이 보이지 않았다는 것이죠.
응답에서 확인하는 방법
추측할 필요가 없습니다. OpenAI와 호환되는 API를 사용하면, 토큰 수는 usage.completion_tokens_details.reasoning_tokens에 포함되어 있으며, 이미 completion_tokens에 _포함_되어 있습니다. 이 둘을 나누면 출력 청구액 중 얼마나 많은 부분이 생각하는 과정(thinking)에 쓰였는지 알 수 있습니다:
from openai import OpenAI
client = OpenAI(base_url="https://api.openai.com/v1", api_key="...")
...
Anthropic은 다르게 처리합니다. 토큰 예산(token budget)을 사용하여 생각하는 과정을 활성화하며, 응답에는 text 블록 앞에 별도의 thinking 콘텐츠 블록이 포함됩니다. 이 생각하는 과정의 토큰은 usage.output_tokens 내에서 계산됩니다. 별도의 숫자가 없으므로 청구액을 분할하려면 총 지불 금액에서 얻은 텍스트 양을 빼야 합니다. 만약 API가 생각하는 과정에 대한 요약을 제공하더라도, 요약본이 아닌 전체 생각하는 과정에 대해 비용이 청구됩니다.
{
"model": "claude-...",
"max_tokens": 4000,
...
두 개의 노브(knobs)와 그 작동 방식
reasoning_effort (OpenAI 스타일: low / medium / high)는 모델에게 얼마나 생각할지 알려줍니다. 이것은 가장 저렴한 해결책입니다. 분류, 추출 및 '다음과 같이 답변하세요(reply with X)' 같은 작업에는 high가 필요하지 않습니다. 기본값도 신뢰하지 마세요. 모델과 제공업체마다 다르므로 명시적으로 설정해야 합니다.
budget_tokens (Anthropic, Gemini의 생각하는 과정 예산)은 초안에 대한 하드 상한선입니다. 이것을 너무 낮게 설정하면 모델이 중간에 생각이 끊기며, 이는 저희 Gemini 탐지기가 했던 것과 같습니다. 당신은 제한된 토큰만큼 생각하는 것에 대해 비용을 지불하지만 아무것도 돌려받지 못합니다.
여기서 우리가 빠진 함정이 있습니다. Kimi K3는 max_tokens를 무시하고 오직 max_completion_tokens만 따릅니다. 이 모델의 노력(effort) 스케일은 low / high / max이며, low / medium / high가 아닙니다. 만약 OpenAI의 medium을 보내면, 이를 인식하지 못하고 max로 생각합니다. 22.09에 이 값을 사용했을 때 비용은 high보다 2~3배 더 많이 들었습니다. 오류나 경고는 없었고, 단지 usage 값에 더 큰 숫자만 찍혔습니다. 알 수 없는 설정값은 크게 실패를 알리지 않고, 제공업체가 안전하다고 생각하는 임의의 값으로 폴백(fallback)하며, 이는 보통 비싼 쪽입니다.
독자가 제기할 만한 합리적인 반론이 있습니다: '사고 과정(thinking)을 줄이면 답변 품질이 떨어질 수 있다.' 때때로 그럴 수 있습니다. 그래서 측정해야 합니다. 실제 프롬프트를 두 가지 노력 수준에서 실행하여 품질과 reasoning_tokens를 비교하고, 여전히 통과하는 가장 낮은 수준을 유지하세요.
이것이 해결하지 못하는 것들
호출(call) 전에 추론 토큰을 예측할 수 없습니다. 동일한 프롬프트라도 어느 날은 30개의 토큰을 생각하고 다음 날은 300개를 생각할 수 있으므로, 요청당 예산은 계속 추정치로 남습니다. 노력 수준을 낮추는 것은 어려운 작업에 대한 정확도를 비용과 맞바꾸는 것이며, 오직 사용자의 테스트 세트만이 경계가 어디인지 알려줍니다. 게다가 일부 제공업체는 이 숫자를 제대로 보고하지 않거나 아예 보고하지 않습니다. 저희는 스트리밍 호출(streamed calls)에서 추론 토큰이 미보고되는 문제가 생겨서, 상위 두 곳에 명시적으로 stream_options.include_usage를 요청해야 했습니다.
저희 측의 경우: 운영하는 게이트웨이는 completion_tokens_details.reasoning_tokens를 전달하고 모델별 노력 수준을 매핑하여, Kimi의 medium 버그가 발견되고 수정될 수 있었습니다. 하지만 저희 자체 사용 기록은 여전히 총 완료 토큰(total completion tokens)만 저장합니다. 따라서 대시보드에서 추론 토큰 비중을 보여드릴 수는 없으며, 각 응답에서 직접 읽어내셔야 합니다. 그리고 토큰당 가격이 10~25% 낮아진다고 해서 비율이 바뀌지는 않습니다: 150개 중 숨겨진 127개의 토큰은 어떤 가격대에서도 여전히 85%를 차지합니다.
다음 백 번의 호출에서는 completion_tokens 옆에 reasoning_tokens를 기록하세요. 만약 단순한 작업에서 숨겨진 비중이 절반을 넘는다면, 더 저렴한 모델을 찾기 전에 노력 수준을 낮추세요.