예상치 못한 토큰별 LLM 비용 청구 방지하기: 정액제 기반의 자동 라우팅 API 접근 방식

LLM API를 기반으로 무언가를 출시해 보았다면, 아마 이런 순간을 경험했을 것입니다. 월말에 대시보드를 확인했는데 청구 금액이 예상 모델링보다 3배나 높게 나온 상황 말이죠. 시스템이 고장 난 것도 아니었습니다. 그저 사용량이... 흘러갔을 뿐입니다. 몇몇 프롬프트가 더 수다스러워졌고, 특정 모델이 더 많이 "생각(thinking)"하기 시작하면서, 당신의 토큰당 계산법이 조용히 무너져 버린 것입니다.

저는 그 굴레 속에서 살아왔기에, 왜 토큰당 가격 책정(per-token pricing)을 예측하기 어려운지, 그리고 이론적인 절감액을 일부 포기하는 대신 실제로 예측 가능한 숫자를 제공하는 다른 형태의 과금 방식에 대해 설명하고자 합니다.

토큰당 지출을 모델링하기 어려운 이유

토큰당 과금은 단순해 보입니다. 가격 × 토큰 수 방식이죠. 하지만 실제로는 세 가지 요소 때문에 예측이 까다롭습니다.

1. 출력 길이(Output length)는 당신이 통제할 수 없습니다. max_tokens는 물리적인 상한선이지만, 모델이 그 상한선 중 실제로 얼마만큼을 사용할지는 모델이 결정합니다. 동일한 프롬프트를 받은 두 모델이 매우 다른 출력 길이를 생성할 수 있으며, 말이 많은(verbose) 모델은 동일한 작업에 대해 더 많은 비용을 발생시킵니다.

2. "추론(Reasoning)" 토큰은 청구될 때까지 보이지 않습니다. 일부 최신 모델(예: OpenAI의 o-series)은 내부적인 추론 토큰을 생성하며, 이에 대해 비용이 청구되지만 기본 응답에서는 볼 수 없습니다. 로그에는 200토큰의 답변이 찍히지만, 인보이스에는 그 답변에 도달하기 위해 사용된 1,500토큰이 계산됩니다.

3. 입력(Input)이 조용히 증가합니다. RAG 컨텍스트, 더 길어지는 채팅 히스토리, 시간이 지나며 축적되는 시스템 프롬프트 등 — 입력 토큰 수는 릴리스가 거듭될수록 서서히 증가하며, 능동적인 모니터링 없이는 청구서를 받기 전까지 아무도 이를 알아차리지 못합니다.

이 요소들은 개별적으로는 괜찮습니다. 하지만 이들이 결합되면 요청당 비용(cost-per-request)에 두터운 꼬리(fat tail)가 생기게 되며, 이 두터운 꼬리야말로 가격 페이지나 단위 경제(unit-economics) 스프레드시트에 담을 수 없는 바로 그 요소입니다.

대안: 호출당 정액제 과금

아이디어는 간단합니다. 발생한 토큰 양에 관계없이, 당신이 선택한 품질 티어(quality tier) 내에서 **요청당 정액(flat rate per request)**을 부과하는 것입니다. 청구 금액은 호출 횟수 × 티어 가격으로 확정됩니다. 출력 길이, 추론 토큰, 어떤 특정 모델이 답변했는지 여부 — 그 어떤 것도 당신이 지불해야 할 금액을 바꾸지 않습니다.

여기서 당신은 실질적인 무언가를 포기하게 되지만(이에 대해서는 아래에서 더 자세히 다룹니다), 토큰당 과금 방식이 제공할 수 없는 단 한 가지, 즉 배포 전 예측 가능한 비용을 얻게 됩니다. 정액제 기반의 SaaS 기능, 예산이 정해진 내부 도구, 고객에게 특정 금액을 견적 내야 하는 모든 서비스와 같이 많은 제품군에서, 이러한 예측 가능성은 이론적인 최적값에서 몇 퍼센트를 절감하는 것보다 더 큰 가치를 지닙니다.

구체적으로 살펴보겠습니다. 예를 들어 요청 하나가 평균 1,000 토큰(tokens)이고 저렴한 모델이 1K 토큰당 $0.0005를 청구한다면, 이는 호출당 약 $0.0005입니다. 만약 호출당 $0.002의 고정 요금제를 사용한다면, 동일한 작업 부하(workload) 하에서는 비용이 더 많이 듭니다. 하지만 요청의 규모가 달라지는 순간 — 어떤 것은 200 토큰, 어떤 것은 8,000 토큰, 어떤 것은 프런티어 모델(frontier model)로 라우팅되는 경우 — 토큰당 평균 비용은 상승하고 변동성(variance)은 폭발적으로 증가하지만, 고정 가격은 그대로 유지됩니다. 고정 가격제는 평균이 아닌 편차(spread) 측면에서 승리합니다.

자동 라우팅(auto-routing)과의 결합

모델을 직접 선택하는 것을 중단할 때, 호출당 고정 가격제는 더욱 흥미로워집니다. 어떤 모델이 응답하든 모든 요청의 비용이 동일하다면, 라우터(router)가 각 요청의 난이도를 분류하고 이를 실제로 처리할 수 있는 가장 저렴한 모델로 보내도록 할 수 있습니다. 예를 들어 "이것을 요약해줘"에는 소형 모델을, "이 레이스 컨디션(race condition)을 디버깅해줘"에는 프런티어 모델을 할당하는 식입니다. 이 과정에서 당신이 직접 로직을 연결하거나, 어려운 요청이 비싼 모델에 할당되어 예상치 못한 비용이 발생하는 상황을 겪을 필요가 없습니다.

개발자 대상 인터페이스(contract)는 의도적으로 지루할 정도로 단순하게 유지됩니다:

curl https://your-gateway/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer $KEY" \
...

이는 OpenAI 호환 /chat/completions 본문(body) 형식이므로, 기존 SDK의 base_url과 키(key)만 변경하면 바로 작동합니다. 모델 이름으로 auto를 보내기만 하면 라우팅과 고정 요금제가 나머지를 처리합니다. 마이그레이션이 전혀 필요 없다는 점이 핵심 셀링 포인트입니다. 코드를 새로 작성해야 한다면 아무도 전환하지 않을 것이기 때문입니다.

고정 가격제가 유리하지 않은 경우 (솔직한 부분)

이것은 공짜 점심이 아니며, 그렇지 않은 척하는 것은 정직하지 못한 일입니다:

대량의 짧고 예측 가능한 호출 (High-volume, short, predictable calls). 만약 요청이 매우 작고 균일하다면 (예: 대규모로 수행되는 한 줄 입력의 분류 작업), 저렴한 모델을 사용하는 토큰당 과금 방식이 정액제 기반의 호출당 요금보다 거의 확실히 유리할 것입니다. 정액제의 가치는 *변동성 감소 (variance reduction)*에 있는데, 당신에게는 변동성이 없기 때문입니다.
이미 FinOps 작업을 완료한 경우. 만약 엄격한 토큰 예산, 프롬프트 길이 제한 (prompt-length guards), 그리고 우수한 관찰성 (observability)을 갖추고 있다면, 이미 스스로 예측 가능성을 만들어낸 상태이므로 정액제 계층이 주는 이점이 적습니다.
정액제 계층이 제한하는 기능이 필요한 경우. 비전 입력 (Vision inputs), 도구/함수 호출 (tool/function-calling), 방대한 출력값 등은 (게이트웨이에 따라 다르지만) 가격의 정직성을 유지하기 위해 정액제 호출당 요금제에서 제한되는 경우가 많습니다. 이러한 기능들이 필요하다면 사용량 기반 (metered) 모델이 더 적합합니다.
엄격한 지연 시간 SLA (latency SLAs)가 있는 경우. 비용 중심의 라우팅은 저렴하지만 느린 모델을 선택할 수 있습니다. 만약 엄격한 지연 시간 예산 내에서 작동해야 한다면, 라우터에 지연 시간 필터도 필요합니다. 이는 단순함이라는 이점을 일부 상쇄하는 추가적인 복잡성을 초래합니다.

경험 법칙(Rule of thumb): 정액제는 변동성에 대한 보험입니다. 요청당 비용이 요동칠수록 — 작업 난이도의 혼합, 장황하거나 추론 중심적인 모델 사용, 증가하는 컨텍스트 등 — 이 보험의 가치는 더욱 높아집니다. 이미 워크로드의 변동성이 낮다면, 보험의 필요성도 낮아집니다.

요약 (Takeaway)

토큰당 과금 방식이 틀린 것은 아니지만, 이는 당신이 제어하려는 지표(예측 가능한 청구서)가 아닌 다른 지표(토큰)를 최적화합니다. 고객에게 고정 가격을 제시하거나, 단순히 LLM 비용 항목이 예상치 못한 금액으로 나타나는 것을 방지하고 싶다면, (이상적으로는 하단에 자동 라우팅이 포함된) 호출당 정액 요금제를 검토해 볼 가치가 있습니다.

저는 이러한 접근 방식을 Modelis라는 작은 OpenAI 호환 게이트웨이에 구축해 왔습니다 (GPT/Claude/Gemini를 위한 하나의 키, auto 라우팅, 플랜별 정액 요금제, 체험을 위한 무료 티어 제공). 직접 테스트해 보고 싶다면 modelishub.com을 방문하세요. 하지만 비용 청구에 관한 논거 자체만으로도 충분한 가치가 있습니다. 여러분의 워크로드에서 정액제와 사용량 기반 방식 중 어느 지점에서 차이가 발생하는지 댓글로 진심 어린 의견을 듣고 싶습니다.