AI API 비용 제어는 가격 스프레드시트의 문제가 아니라 라우팅(Routing) 문제입니다

대부분의 팀은 AI 비용 제어를 스프레드시트로 시작합니다. 모델 A는 이만큼 비용이 들고, 모델 B는 저만큼 드니, 더 저렴한 것을 사용하자는 식입니다.

이는 일주일 정도는 도움이 됩니다. 하지만 실제 운영 트래픽(production traffic)이 들어오기 시작하면 상황이 달라집니다.

진정한 비용 문제는 모델의 가격이 아닙니다. 사용자 요청과 과금되는 제공업체(provider) 호출 사이의 경로(path)를 놓치는 것이 문제입니다.

제품에 여러 기능, API 키, 환경(environments), 재시도(retries), 그리고 폴백 경로(fallback routes)가 포함되면, 청구서는 창업자들이 실제로 궁금해하는 질문에 답을 주지 못하게 됩니다.

어떤 제품 경로가 이 지출을 발생시켰으며, 더 나은 방식으로 라우팅할 수 있었는가?

실패 모드 (The failure mode)

전형적인 초기 설정은 다음과 같습니다:

환경 변수에 하나의 OpenAI 키 설정
더 높은 품질의 작업을 위한 하나의 Claude 키
더 저렴한 워크로드(workloads)를 위한 Gemini 또는 프록시(proxy)
애플리케이션 오류는 보여주지만 토큰 경제(token economics)는 보여주지 않는 로그
너무 늦게 도착하는 월간 제공업체 청구서

이는 개발자 한 명이 실험하는 동안에는 괜찮습니다.

하지만 여러 워크플로우(workflows)가 동일한 제공업체 계정을 공유하게 되면 문제가 발생합니다. 단 하나의 재시도 루프(retry loop), 백그라운드 요약기(background summarizer), 또는 테스트 환경이 조용히 당신의 AI 예산에서 가장 큰 고객이 될 수 있습니다.

나쁜 점은 단순히 돈이 쓰였다는 것만이 아닙니다. 진짜 나쁜 점은 그 경로(route)를 재구성할 수 없다는 것입니다.

모든 AI 요청을 과금 가능한 이벤트(billable event)로 취급하세요

더 깔끔한 패턴은 요청이 시스템을 떠나기 전에 회계 데이터를 부착하는 것입니다.

최소한, 모든 호출은 다음 정보를 포함해야 합니다:

사용자 또는 API 키 소유자
프로젝트 또는 워크스페이스(workspace)
요청된 모델
실제 업스트림(upstream) 모델
직접(direct), 백업(backup), 또는 더 저렴한 풀(pool)과 같은 라우트 유형(route type)
입력 및 출력 토큰
크레딧(credits), 지갑 잔액(wallet balance), 또는 내부 비용 센터(internal cost center)와 같은 정산 버킷(settlement bucket)
디버깅을 위한 요청 ID(request id)

이렇게 하면 제공업체의 청구서가 아닌, 게이트웨이(gateway)가 신뢰할 수 있는 단일 원천(source of truth)이 됩니다.

만약 요청이 gpt-5.5로 시작되었으나 백업 경로(backup route)를 통해 처리되었다면, 그 결정 사항은 가시적이어야 합니다. 더 저렴한 모델 풀(model pool)이 비핵심 워크플로우(non-critical workflow)를 처리한다면, 이 또한 가시적이어야 합니다. 프리미엄 직접 경로(premium direct route)가 사용된다면, 즉시 적절한 잔액(balance) 및 소유자(owner)에 할당되어야 합니다.

평균 가격보다 라우팅 정책(Route policy)이 더 중요합니다

평균값은 당신이 조정해야 할 핵심 요소를 숨깁니다.

예를 들어, 한 팀이 호출의 80%는 더 저렴한 경로를 감수할 수 있는 저위험 변환(low-risk transformations) 작업이고, 나머지 20%는 공식적인 직접 모델 경로(official direct model path)가 필요하다는 사실을 발견할 수 있습니다. 만약 이 두 가지가 하나의 월간 지출 항목으로 합쳐진다면, 아무도 올바른 라우팅 결정을 내릴 수 없습니다.

실질적인 설정은 다음과 같이 분리합니다:

예측 가능성(predictability)이 중요한 워크로드(workload)를 위한 공식/직접 모델(official/direct models)
낮은 비용의 처리량(throughput)을 위한 일반 또는 풀링된 경로(ordinary or pooled routes)
제공업체 불안정성에 대비한 폴백 채널(fallback channels)
경로별 사용량 및 에러 로그(per-route usage and error logs)
각 정산 경로(settlement path)에 대한 명확한 잔액 또는 예산

이것이 바로 제품 가격(product pricing)과 제공업체 가격(provider pricing)을 혼동하지 않도록 방지하는 방법이기도 합니다. 제품은 내부적으로 여러 제공업체에 걸쳐 라우팅을 수행하면서도 사용량 기반 크레딧(usage-based credits)을 판매할 수 있습니다. 고객은 안정적인 API 인터페이스(API surface)를 보아야 하며, 운영자는 라우팅 경제성(routing economics)을 보아야 합니다.

알림(Alerts)은 총액이 아닌 속도(velocity)에 따라 트리거되어야 합니다

일일 지출 알림은 통제 불능의 루프(runaway loops)를 막기에는 너무 느립니다.

토큰 속도(Token velocity)는 문제를 더 일찍 포착합니다. 평소 시간당 2만 토큰을 소모하던 워크플로우가 갑자기 10분 만에 200만 토큰을 소모한다면, 그것이 바로 당신이 주목해야 할 이벤트입니다. 피해가 시작되는 시점에는 절대적인 일일 총액이 여전히 수용 가능한 수준으로 보일 수 있습니다.

유용한 알림 신호에는 다음이 포함됩니다:

API 키별 분당 토큰 수(tokens per minute)
업스트림 채널(upstream channel)별 에러율(error rate)
폴백 경로 빈도(fallback route frequency)
모델 경로별 지출(spend by model route)
갑작스러운 제공업체/모델 구성 변화
토큰을 소모했으나 실패한 요청(failed requests)

이 지점이 바로 게이트웨이 수준의 로그(gateway-level logs)가 제공업체 대시보드(provider dashboards)를 압도하는 부분입니다. 제공업체 대시보드도 유용하지만, 당신의 기능 경계(feature boundaries)는 알지 못합니다.

우리가 만들고 있는 것

저는 이 아이디어를 중심으로 Tokens Forge를 구축하고 있습니다: 하나의 OpenAI 호환 API 인터페이스를 제공하되, 모델 라우팅 (model routing), 공식/직접 및 저비용 경로, 사용 로그 (usage logs), 잔액 분리 (balance separation), 그리고 AI 연구자 워크플로우 (AI Researcher workflows)를 한곳에 모으는 것입니다.

목표는 블랙박스 프록시 (black-box proxy)로 복잡성을 숨기는 것이 아닙니다. 목표는 라우팅 및 과금 경로를 창업자가 다음과 같은 질문에 답할 수 있을 만큼 충분히 조사 가능하게 만드는 것입니다:

어떤 사용자나 키가 비용을 지출하고 있는가
어떤 모델이 실제로 요청을 처리하고 있는가
어떤 경로가 비용은 높지만 필수적인가
어떤 경로를 더 저렴한 경로로 옮길 수 있는가
어떤 실패 사례가 운영상의 주의를 필요로 하는가

만약 당신이 AI 기능을 구축하고 있다면, 저는 게이트웨이 계측 (gateway instrumentation)을 단순한 과금 관리 (billing admin)가 아닌 제품 인프라 (product infrastructure)로 취급할 것입니다.

요청이 당신의 앱을 떠나고 나면, 유용한 비즈니스 컨텍스트 (business context)를 결합할 기회는 이미 대부분 사라지기 때문입니다.

Tokens Forge: https://tokens-forge.com/