LLM 토큰 사용량：4 토큰짜리 답변에 217 토큰이 청구되는 이유

GPT-5.6 에 한 줄짜리 수학 문제를 던지면 출력 청구액의 88% 는 눈에 보이지도 않는 reasoning 이다. 눈에 보이는 토큰은 10 개, 청구되는 건 81 개다. 그나마 GPT-5.6 은 양반이다. 같은 문제를 GLM 5.2 에 던지면 4 토큰짜리 답에 completion 토큰 217 개가 청구되고, 똑같은 답이 Qwen3.7-max 에서는 1,104 개가 청구된다. 이건 이상 현상이 아니라 reasoning 모델이 원래 그렇게 청구하도록 설계된 것이다. 그리고 이건 대부분의 비용 대시보드가 따로 구분해 주지 않는 여러 토큰 종류 중 첫 번째일 뿐이다. 이 글에서는 실제 usage 객체를 종류별로 뜯어보고 측정한 수치를 함께 살펴본다。

TL;DR

• GPT-5.6 의 기본 설정은 10 토큰짜리 답에 81 토큰을 청구했고, 그중 88% 가 reasoning 이었다. GLM 5.2 는 98%, Qwen3.7-max 는 99.3% 였다。
• Claude Sonnet 5 는 thinking 파라미터를 보내지 않았는데도 5 토큰짜리 답에 thinking 토큰 114 개를 청구했다。
• 다섯 개 모델 계열은 thinking 없이 틀린 답을 냈다（399, 400, 427, 466, 467）。thinking 없이 정답을 맞힌 건 GPT-5.6 뿐이었고, reasoning 을 켠 모든 실행은 401 을 답했다。
• 1,181 토큰짜리 Claude 캐시 쓰기와 읽기는 각각 $0.01246, $0.00566 이 들었고, 이는 정가와 정확히 일치했다。

테스트에 사용한 것

이 글의 모든 측정값은 동일한 단일 턴 프롬프트를 사용했다. 별도 표시가 없으면 각 모델의 기본 설정으로 보냈다：

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

정답은 401 이다（3 의 배수 333 개에 5 의 배수 200 개를 더하고, 두 번 센 66 개를 빼면 467 이 나온다. 여기서 15 의 배수 66 개를 빼면 401 이 남는다）。이 문제를 고른 데는 이유가 있다. 눈에 보이는 답이 아주 짧아서 어떤 토크나이저에서도 3~4 토큰으로 고정되고, 정답이 하나뿐이라 “thinking 이 값을 했는지”를 검증할 수 있다. 게다가 모델이 생각을 하고 싶어질 만큼 딱 적당히 어려운데, 바로 이 동작이 우리가 들여다보려는 대상이다。

청구서에 찍히는 다섯 가지 토큰 종류

요즘 completion 하나는 최대 다섯 가지 토큰 종류를, 네 가지 요금으로 청구한다. “사용한 토큰” 이라는 단일 수치는 이걸 전부 가려버린다.

위 필드명은 OpenAI 호환 형태다. Claude 도 똑같은 다섯 종류를 자기 이름으로 갖고 있다. input_tokens 와 output_tokens 가 있고, thinking 은 output_tokens_details.thinking_tokens 에 담겨 output 으로 청구된다. cache write 는 cache_creation 객체 안에서 TTL 별로 다시 나뉜다（ephemeral_5m_input_tokens 는 1.25x, ephemeral_1h_input_tokens 는 2x）. 구조는 같고 이름만 다르다. 이 파싱 문제는 뒤 섹션에서 다시 나온다.

다섯 종류와 각각의 가격 배수를, OpenAI 호환 필드명과 Anthropic 필드명으로 표시했다. 88% 수치는 위 예시에서 측정한 GPT-5.6 의 reasoning 비중이다.

헤드라인 수치 뒤에 있는 실제 객체는 다음과 같다. 기본 설정의 GPT-5.6 이 테스트 질문에 답한 결과다.

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

여기에 청구 계산의 핵심이 들어 있고, 한 번은 명시적으로 짚어볼 만하다. 받은 답변은 completion_tokens 에서 reasoning_tokens 를 뺀 값이다. 81 − 71 = 10 토큰, 즉 “401” 이라는 단어와 그 서식이다. 나머지 71 토큰은 full output 요금으로 청구되는 chain-of-thought 로, output 청구의 88% 를 차지한다. 게다가 GPT-5.6 에서는 그중 한 글자도 읽을 수 없다. 이 글에 나오는 “노출되는 답변” 수치는 전부 같은 방식으로 계산했다. 다른 데서는 비율이 더 극단적으로 벌어진다. GLM 5.2 는 같은 질문에 completion 토큰 217 개를 쓰고 답변은 4 토큰이었다. 그러니 completion_tokens 를 “모델이 말한 내용” 으로 읽는 비용 모델은 여기서는 8x, 저기서는 54x 씩 틀린다.

추론은 예산이고, 조종할 수 있다

한 줄짜리 동일한 질문을, 조종 가능한 세 계열이 받아들이는 모든 thinking 설정에 대해 하나의 게이트웨이로 돌렸다 (2026-07-13/14, 각 계열 안에서 추론이 적은 것부터 많은 것 순으로 정렬. 나머지 계열의 플래그십 기본값은 다음 절에 있다):

이 표에서 솔직하게 읽어낼 만한 네 가지:

• 레버가 먹히는 곳에서는 효과가 크다. reasoning_effort: none은 $0.000062에 정답을 냈는데, 이는 luna 기본값의 1/8.5 수준이다. 더 어려운 작업에서는 GLM 5.2에서 20배 차이를 측정한 적도 있다. 티어 선택도 같은 레버의 일부다. GPT-5.6 플래그십은 이 질문을 기본값에서 추론 없이 답했으니 (다음 절), 생각할 필요가 없는 큰 모델이 생각해야 하는 작은 모델보다 더 저렴할 수 있다.
• 그리고 안 먹히는 곳에서는 거의 무의미하다. 다이얼이 얼마나 돌아가는지는 계열의 특성이다. Sonnet 5는 단조 증가하며 비용이 5배 차이 났고 (84에서 249), GPT-5.6은 폭이 작고 순서도 없었으며, Qwen3.7-max는 거의 무의미했고 (low도 추론 token을 974개 썼는데 기본값은 1,096개였다), DeepSeek V4 Pro에서는 죽어 있었다 (267 대 269).
• 레이블은 단조롭지 않고 기본값은 결정적이지 않다. GPT-5.6의 high는 여기서 medium보다 token을 적게 썼고, GLM의 low는 앞선 글에서 high보다 더 썼다. Sonnet 5는 thinking 파라미터를 전혀 보내지 않은 요청에서 114개 token만큼 생각했다. 동일한 GLM 기본값 요청이 한 번은 추론 token을 213개, 다른 번은 1,312개 써서 6배 차이가 났다. 다이얼의 실제 효과는 레이블을 보지 말고 자기 워크로드에서 직접 측정하라.
• 싸구려 오답이 반복되는 실패 유형이다. 여기서 생각 없이 답한 두 계열은 모두 오답을 냈다 (GLM 399, Sonnet 5 467). 다섯 계열 전체 결과는 다음 절에 있다. 추론은 정확도 예산이고, 그것을 깎는 게 이득인지 여부는 모델이 아니라 작업에 달려 있다.

실무 규칙: reasoning_tokens를 일급 항목으로 다뤄라. 출력 요율로 과금되고, 눈에 보이는 답변을 압도하는 경우가 흔하며, 실제 효과를 직접 측정해야 하는 파라미터에 반응한다. GPT-5.6에서는 가격 규칙도 바뀌었다. GPT-5.6 비용 가이드에서 write 프리미엄과 cache-key 요건을 다룬다.

돈 낸 만큼 실제로 읽어볼 수 있나?

“답변과 분리되어 있다”는 게 항상 “숨겨져 있다”는 뜻은 아니다. 이 차이는 정확히 짚어둘 만하다. 우리는 usage뿐 아니라 응답 본문까지 확인했다:

• GLM 5.2, DeepSeek, Qwen3.7-max, MiniMax 는 전체 reasoning 텍스트를 반환한다. 답변 옆의 reasoning_content 필드에 담기며, 여기서는 각각 3,987, 1,604, 2,509, 581 자였다. 개발자는 청구된 토큰을 하나도 빠짐없이 읽을 수 있다. 최종 사용자는 애플리케이션이 이걸 렌더링할 때만 보게 되는데, 대부분은 그렇게 하지 않는다.
• GPT-5.6 은 원본 chain of thought 를 내주지 않는다. 받을 수 있는 건 요약이 최대다. 응답에 모델이 작성한 reasoning.summary(여기서는 359 자)가 담길 수 있지만, 청구된 91 토큰은 요약이 아니라 숨겨진 원본 텍스트다. 그 텍스트에 가장 가까운 건 reasoning.encrypted_content로, 멀티턴 연속성을 위해 다시 넘겨줄 수는 있지만 복호화는 못 하는 암호화된 blob 이다. 돈을 낸 토큰이 자기 응답 본문 안에 들어 있는데도 읽을 수 없는 상태다.
• Claude 는 어떻게 요청하느냐에 달렸다. adaptive-thinking 으로 호출한 Sonnet 5 는 thinking 블록을 반환했지만 텍스트는 비어 있었고, thinking_tokens 는 114 로 청구됐다. 생각은 했다는 증거만 있고 읽을 건 없다. Fable 5 도 always-on 기본값에서 똑같이 동작했다(59 청구, 빈 블록). 반면 같은 Sonnet 5 를 명시적 reasoning budget 으로 호출하니 실제 thinking 텍스트가 돌아왔다(73 토큰 청구, 텍스트 있음). 어떻게 요청하는지가 무엇을 볼 수 있는지를 결정한다.

즉 청구서는 어디서나 똑같지만 가시성은 다르다. 모든 계열이 reasoning 에 output 요금을 매기고, 정작 돈 주고 산 텍스트를 감사할 수 있는지는 “전부 다”에서 “요약만”, “서명된 빈 블록”까지 제각각이다.

텍스트가 돌아오면 기계적으로 채점할 수 있다. 우리 질문에는 고정된 중간 결과가 다섯 개 있고(333, 200, 66, 467, 401), 반환된 reasoning 텍스트에는 이 다섯이 전부 들어 있었다. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code, MiniMax M3 모두 완전한 도출 과정을 담아 보냈고, low-effort 변형은 각각 한 단계씩 빠뜨렸다. 답만 필요한 게 아니라 과정이 필요한 사람에게 갈림길은 여기다. reasoning_content 가 있으면 돈 낸 걸 검증할 수 있고, 요약이나 빈 블록이면 믿는 수밖에 없다. Invisible Tokens, Visible Bills 는 이 책임성 격차를 정식화하고, PALACE 는 숨겨진 reasoning 을 외부에서 추정한다.

계열별 최상위 모델에 던진 동일한 질문

앞서 나온 steering 표는 각 노브를 보여주려고 특정 티어를 사용했다. 여기서는 각 계열의 최신 플래그십에 같은 질문을 던지고, 설정은 모두 기본값으로 두었다.

동일한 질문에 대한 플래그십별 청구된 출력 토큰(빗금친 주황색 = 추론 비중; 초록색 = 표시되는 답변). MiniMax의 별표: 사용량에 추론 카운트가 포함되지 않으므로, 비중은 뺄셈으로 재구성되었으며, 반환하는 추론 텍스트와 대조하여 검증되었습니다. GPT-5.6 sol의 체크 표시는 유일하게 올바른 제로 추론 실행을 나타내며, Gemini 3.5 Flash의 X 표시는 유일하게 틀린 플래그십 답변(466)을 나타냅니다.

모든 보고 방식을 한 차트에 담았다.

• 여덟 개 플래그십 중 일곱 개가 정답을 냈지만, 같은 401을 두고 가격 차이가 엄청났다. Qwen3.7-max는 reasoning 토큰 1,096개, 22초, $0.0084를 썼고, GPT-5.6의 플래그십은 reasoning 토큰 0개에 $0.00031을 썼다. 똑같은 정답을 두고 비용은 27배, 지연은 7배 차이가 났다. reasoning 예산이 눈에 보이는 형태로 드러난 것이다.
• MiniMax는 reasoning 텍스트는 반환하지만 개수는 주지 않는다. 노출된 답은 3 토큰인데 completion 토큰은 260개다. 응답의 reasoning_content에는 전체 유도 과정이 담겨 있지만, completion_tokens_details에는 reasoning 항목이 없다. 개수가 없으면 빼기로 복원하면 된다. completion에서 노출 토큰을 빼면 숨겨진 출력 개수가 나온다.
• Gemini 3.5 Flash는 유별났다. 유일하게 오답(466)을 낸 플래그십이고, completion 토큰은 3개인데 reasoning 개수는 어디에도 없다. 형제 모델인 2.5 Flash는 401을 담은 3 토큰짜리 답을 내는 데 12.5초를 썼으면서 그 이유를 청구서 어디에도 남기지 않았고, 같은 질문을 다시 돌리자 427을 답했다.
• 오답은 하위 티어와 thinking을 끈 경우에 몰려 있다. GLM은 thinking을 끄자 399라고 했고, Sonnet 5는 끈 상태에서 467이라고 했다. 구형 qwen3-max는 아예 사고하지 않고(3 토큰) 400이라고 했다. reasoning 채널이 없는 Kimi K2.5는 청구된 노출 토큰 144개에 걸쳐 소리 내어 추론하며 본문 안에서 401을 유도해놓고는 400이라고 결론지었다. 다섯 계열이 각기 다른 다섯 개의 오답을 냈다: 399, 400, 427, 466, 467. reasoning 없이 정답을 낸 건 GPT-5.6 하나뿐이었다.

캐시 토큰： 두 방향, 12배 차이

prompt caching은 입력을 두 종류로 더 쪼개는데, 이렇게 나누는 이유는 둘 사이의 가격 차이다. Claude에서 write는 입력 요율의 1.25배로 청구되고（1시간 TTL은 2배）, read는 0.1배다. 1,181 token짜리 캐시된 system prompt로 Opus 4.8을 두 번 호출해 측정한 결과, write는 $0.01246, read는 $0.00566이었다. 둘 다 소수점 여섯 자리까지 정가와 맞아떨어졌고, 입력 쪽 요금은 호출 간 약 11배 떨어졌다. 이 글에서 중요한 건 회계 처리다. cache_creation_input_tokens와 cache_read_input_tokens를 “입력 토큰”으로 뭉뚱그리면 할인이 제대로 적용됐는지 검증할 수도 없고, 그 할인이 소리 없이 멈춰도 알아챌 수 없다. 그리고 이런 일은 문서가 시사하는 것보다 자주 일어난다. 우리 캐싱 측정에서는 실효 임계값이 문서에 적힌 최솟값보다 1.4배에서 2.4배 높게 나왔다. 프로바이더별 동작 원리는 prompt caching 가이드에서 자세히 다룬다.

로컬 추정치가 청구서와 절대 안 맞는 이유

흔한 패턴은 tokenizer 라이브러리로 클라이언트 쪽에서 비용을 추정하고 나중에 대조하는 것이다. 숫자가 안 맞는 이유는 세 가지다.

• tokenizer는 벤더마다 다르다. Claude로 보낼 텍스트를 OpenAI tokenizer로 세는 건 잘못된 자로 재는 셈이다. 같은 문자열이라도 모델 계열마다 다르게 토큰화된다.
• 메시지보다 더 많은 걸 청구받는다. system prompt와 tool schema는 그것들이 실린 모든 요청에서 입력 토큰으로 잡히는데, 로컬 추정에서 빠뜨리기 쉽다.
• reasoning은 응답이 오기 전까지 예측 불가다. 모델이 thinking token을 얼마나 쓸지는 어떤 클라이언트 쪽 계산으로도 예측할 수 없다. 반환된 usage를 봐야 알 수 있다.

반환된 usage 객체는 업스트림이 직접 만든 청구 기록이므로, 가장 저렴하고 정확한 카운터는 추정을 그만두고 이걸 읽는 것이다. 문제는 프로바이더마다 형태가 다르다는 점이다. 캐시된 토큰 하나만 봐도 계열에 따라 cached_tokens, prompt_cache_hit_tokens, total_cached_tokens, cache_read_input_tokens 중 하나로 나타난다.

세부 객체 역시 고정된 스키마가 아니다. OpenAI 레퍼런스는 completion 쪽 필드 네 개를 문서화한다． reasoning_tokens, audio_tokens, 그리고 Predicted Outputs 쌍인 accepted_prediction_tokens / rejected_prediction_tokens다. rejected prediction token은 출력에 아예 나타나지 않지만 그래도 completion token으로 청구된다. prompt 쪽에서는 같은 형태에 cached_tokens 옆으로 text_tokens, audio_tokens, image_tokens가 붙는다. GPT-5.6은 cache_write_tokens를 추가하고, 실환경에서 video_tokens를 본 적도 있다. 벤더들은 이걸 마음대로 확장한다. Kimi K2.7은 문서에 없는 completion_tokens_details.text_tokens를 반환했고, Gemini는 thinking token과 tool-use token을 각자의 이름으로 따로 센다. 방어적으로 파싱해라． 모르는 세부 필드가 나오는 걸 당연하게 받아들이고, 필드가 없다고 해서 0이라고 넘겨짚지 마라.

여기서 게이트웨이의 진가가 드러난다． Synthorai는 이 모든 걸 하나의 객체로 정규화한다. reasoning_tokens와 두 캐시 방향이 OpenAI, Anthropic, Gemini, open-weight 계열 전반에서 채워지므로, 파서 하나로 라우팅하는 모든 모델을 커버할 수 있다.

보는 것에서 막는 것으로

원장을 읽는 것은 일의 절반일 뿐이다. 나머지 절반은 초과 지출을 눈에 보이게만 하는 게 아니라 아예 불가능하게 만드는 것이다. 월말 대시보드는 이미 돈이 다 나간 뒤에야 놀라운 사실을 알려주고, 재시도 루프에 갇힌 에이전트는 대시보드를 읽지 않는다. 게이트웨이에서는 모든 키가 quota를 갖고, used_quota로 사용량을 추적하며 RPM 상한을 요청 시점에 강제한다. 예산을 다 쓴 키는 다음 요청에서 명확한 에러를 받는다. 3주 뒤에 더 큰 청구서를 받는 게 아니다. 요청별 귀속 정보(어느 키, 어느 모델, BYOK 인지 플랫폼 과금인지)는 같은 응답 봉투에 담겨 돌아온다. 그래서 기능별 비용은 group-by 한 번으로 나오지, 따로 복원해야 하는 작업이 아니다.

측정값에서 따라 나오는 작업 순서는 이렇다. 무언가를 최적화하기 전에 먼저 reasoning_tokens와 cache 필드를 읽고, 태스크별로 reasoning 다이얼을 설정하며, 실패 모드가 루프인 모든 키에는 하드 quota 를 건다. 특정 모델 조합과 token 클래스가 당신의 트래픽 규모에서 얼마나 드는지 보려면, cost optimizer가 위에서 쓴 것과 동일한 token 단가로 가격을 계산해 준다.

← 블로그로 돌아가기