Claude Code, Aider, 그리고 몇 가지 자체 개발한 다단계 워크플로우(multi-step workflows)와 같은 코딩 에이전트(coding agents)를 프로덕션 환경에서 운영한 지 몇 달이 지났을 때, 재무팀에서 제가 답할 수 없는 질문을 던졌습니다. "왜 이번 달 비용이 지난달보다 40%나 더 나왔나요? 우리가 더 많이 배포했나요?"

그렇지 않았습니다. 트래픽은 일정했습니다. 에이전트들은 대략 동일한 양의 작업을 수행하고 있었습니다. 하지만 비용은 우리가 지목할 수 있는 변화가 없음에도 불구하고 약 $1,100에서 $1,500 이상으로 급등했습니다. 저를 괴롭혔던 부분은 바로 이것이었습니다. 비용이 비싸다는 것이 아니라, **예측 불가능하다(unpredictable)**는 점이었습니다. "비싼 것"에 대해서는 예산을 세울 수 있습니다. 하지만 "매달 주사위를 던지는 것"에 대해서는 예산을 세울 수 없습니다.

그래서 우리는 청구서를 한 줄씩 뜯어보았습니다. 비용의 변동은 우리가 전혀 주시하지 않았던 세 가지 숨겨진 변수에서 발생했습니다. 각 변수와 우리가 이에 대해 취한 조치를 소개합니다.

변수 1: 모든 것에 비례하여 증가하는 플랫폼 수수료

우리는 여러 모델에 걸쳐 하나의 엔드포인트(endpoint)를 사용할 수 있는 편리함을 위해 대부분의 호출을 애그리게이터(aggregator)를 통해 라우팅하고 있었습니다. 합리적인 선택이었습니다. 하지만 애그리게이터의 가격 정책은 종량제(pay-as-you-go) 티어에서 모델 비용 외에 5.5%의 플랫폼 수수료를 추가로 부과하며, 이는 볼륨 할인 없이 고정되어 있습니다.

이 수수료는 백분율 측면에서는 예측 가능하지만, 다른 모든 요소와 함께 규모가 커집니다:

따라서 다른 변수들이 우리의 지출을 높였을 때, 이 수수료는 변동을 완화하는 대신 오히려 증폭시켰습니다. 지출이 $1,500인 달에는 단 하나의 토큰(token)이 생성되기도 전에 $82.50가 증발했습니다. 가장 큰 항목은 아니지만, 이미 움직이고 있는 수치 위에 올라타 있는 순수한 오버헤드(overhead)입니다.

깨달은 점: 수수료 자체가 악당은 아닙니다. 문제는 우리가 아직 통제하지 못한 변동성(volatility)에 대한 승수(multiplier) 역할을 한다는 점입니다.

변수 2: 예상치 못한 상위 단계(Upstream)의 가격 변동

실제로 저희를 놀라게 했던 것은 바로 이것입니다. "패스스루 가격 책정 (pass-through pricing)"을 광고하는 애그리게이터(Aggregators)들은 가격 변동(price changes) 또한 그대로 전달합니다. 상위 제공업체(upstream provider)가 리스트 가격을 조정하거나, 모델 에일리어스(model alias)가 가리키는 기본 버전을 조용히 변경하면 토큰당 비용이 움직이게 되며, 이는 인보이스(invoice)를 받고 나서야 알게 됩니다.

저희는 특정 버전이 아닌 일반적인 모델 에일리어스에 워크플로(workflow)를 고정해 두었습니다. 어느 시점에 그 에일리어스가 더 비싼 최신 스냅샷(snapshot)을 가리키기 시작했습니다. 코드는 동일하고, 프롬프트(prompts)도 동일하며, 저희 쪽에서의 배포(deploy)도 없었지만 토큰당 비용은 높아졌습니다. 이것만으로도 비용 변동의 상당 부분을 차지했습니다.

이 문제에 대한 해결책은 지루하지만 효과적입니다: 비용이 중요한 모든 곳에서 유동적인 에일리어스(floating aliases)가 아닌 명시적인 모델 버전(explicit model versions)에 고정하십시오. 유동적인 에일리어스는 편리하지만, 소리 없는 가격 변동의 원인이 될 수 있습니다. 만약 사용 중인 제공업체나 애그리게이터가 요율(rate)이나 버전을 고정할 수 있게 해준다면, 트래픽이 많은 경로(high-volume paths)에는 반드시 그렇게 하십시오.

변수 3: 가장 큰 주범은 바로 저희의 코드였습니다

솔직히 말씀드리면, 가장 큰 단일 요인은 수수료나 상위 가격 책정이 아니었습니다. 바로 저희였습니다. 저희의 에이전트(agents)는 스스로 초래한 두 가지 패턴 때문에 토큰을 낭비하고 있었으며, 이 부분은 어떤 제공업체를 사용하든 반드시 적용해 볼 만한 가치가 있습니다.

재시도 폭풍 (Retry storms). 저희 에이전트 단계 중 몇몇은 단순한 재시도 로직(retry logic)을 가지고 있었습니다. 타임아웃(timeout)이 발생하거나 형식이 잘못된 응답(malformed response)이 오면 다시 전송하는 방식입니다. 개별적으로는 괜찮지만, 일부 "실패"는 사실 절반 정도 완료된 상태였고, 운이 나쁜 날에는 몇몇 단계가 3~4번씩 재시도될 수 있었습니다. 모든 재시도는 새롭고 완전히 비용이 청구되는 호출(call)입니다. 저희는 동일한 논리적 단계를 여러 번 수행하면서 그것을 회복탄력성(resilience)이라고 부르며 비용을 지불하고 있었습니다.

영향력이 큰 순서대로 도움이 되었던 조치들은 다음과 같습니다:

1. 논리적 단계당 재시도 횟수 제한 (Cap retries per logical step) (저희는 2회로 결정했습니다) 및 지수 백오프 (exponential backoff)를 추가하여, 일시적인 오류(transient blip)가 비용이 발생하는 대규모 재시도 폭주(billed stampede)로 이어지지 않도록 했습니다.
2. 가능한 경우 재시도 비용을 원래 비용보다 저렴하게 만들기 — 먼저 더 작고 저렴한 모델로 재시도하고, 실패할 경우에만 상위 모델로 에스컬레이션(escalate)합니다. 대부분의 일시적인 실패는 모델에 관계없이 두 번째 시도에서 성공합니다.
3. 재전송하는 컨텍스트(context) 다듬기. 저희 에이전트들은 매 단계마다 누적된 대화 전체를 다시 보내고 있었습니다. 이전 대화 내용을 요약하거나 윈도잉(windowing) 처리함으로써, 저희가 측정한 작업들에서 품질 저하 없이 입력 토큰(input tokens)을 상당히 절감할 수 있었습니다.

재시도 제한과 컨텍스트 다듬기를 병행한 결과, 토큰 사용량을 약 3분의 1 정도 줄일 수 있었습니다. 그리고 결정적으로, 이 조치들은 변동성(variance)을 줄여주었습니다. 비용이 가장 많이 발생했던 달은 재시도 폭풍(retry storms)이 인지되지 않은 채 쌓였던 달이었기 때문입니다.

이 포스트에서 단 한 가지만 얻어가야 한다면, 바로 이 섹션입니다. 이는 어떤 API를 호출하느냐와는 상관이 없습니다. 그저 여러분이 놓치고 있을 가능성이 높은, 가장 쉬운 30%의 개선 사항입니다.

실제로 청구 금액을 예측 가능하게 만든 것

종합해 보면, 예측 가능성은 다음 세 가지를 공략함으로써 얻어졌습니다:

• 변수 3 (우리의 코드): 재시도 제한 + 컨텍스트 다듬기 — 가장 크고 이식성이 높은 성과입니다.
• 변수 2 (업스트림 드리프트, upstream drift): 트래픽이 많은 경로에서 버전을 고정(pin versions)하거나 요율을 잠금(lock rates)하여, 토큰당 비용이 멋대로 움직이지 않게 합니다.
• 변수 1 (플랫폼 수수료): 여러분이 지불하고 있는 5.5%의 라우팅(routing) 기능을 실제로 사용하고 있는지 결정하십시오.

공지: FuturMix는 저희의 제품이므로, 다음 부분은 변수 1과 2를 어떻게 해결했는지에 대한 하나의 사례로 간주해 주시기 바랍니다. 중립적인 순위 매기기가 아닙니다.

변수 1에 대해서는, 메인스트림 모델 (mainstream-model) 트래픽을 수수료 모델에서 분리했습니다. 변수 2에 대해서는, 비용이 그대로 전가되어 변동되는 방식 (pass-through drift) 대신 고정되고 예측 가능한 요율을 원했습니다. FuturMix는 이 두 가지를 모두 수행하기 위해 우리가 구축한 릴레이 (relay)입니다. 추가 플랫폼 수수료가 없으며, 상위 제공업체의 정가(list price)에서 고정 할인을 제공합니다 (Claude는 Anthropic 대비 약 10% 할인, GPT는 OpenAI 대비 약 30% 할인, Gemini는 Google 대비 약 20% 할인). 따라서 상위 제공업체의 정가가 흔들릴 때 요율이 함께 요동치지 않습니다. OpenAI와 호환되므로, 전환 시에는 Base-URL만 변경하면 됩니다.

from openai import OpenAI

# Before
...

솔직한 트레이드오프 (tradeoff): 대형 애그리게이터 (aggregators)들이 제공하는 200개 이상의 모델과 비교하면, 이 서비스는 25개 이상의 모델만을 제공하며 커뮤니티 규모도 더 작습니다. 만약 오픈 소스 모델의 롱테일 (long tail)이나 200개 이상의 옵션이 필요하다면 여전히 광범위한 애그리게이터가 유리합니다. 하지만 이 서비스는 카탈로그의 크기보다 안정적이고 낮은 요율을 더 중요하게 생각하며 메인스트림 모델 (Claude, GPT, Gemini)을 주로 사용하는 팀을 위한 것입니다.

언제 무엇을 사용할 것인가

핵심은 "제공업체를 바꾸라"는 것이 아닙니다. 예측 불가능한 AI 청구서는 대개 하나의 트렌치코트를 입고 있는 세 가지 별개의 문제일 뿐이라는 점입니다. 자체적인 재시도 (retries) 로직을 수정하고, 고정할 수 있는 것은 고정한 뒤에야, 라우팅 수수료 (routing fee)를 지불하는 것이 가치가 있는지 결정하십시오.

공시: FuturMix는 우리의 제품입니다. 플랫폼 수수료 없이 25개 이상의 메인스트림 모델을 지원하며 제공업체 요율에서 고정 할인을 제공하는 OpenAI 호환 릴레이입니다. 이 포스트는 우리 자신의 청구서를 디버깅하며 얻은 실제 경험을 반영합니다. 변수 3에 대한 해결책은 귀하가 어떤 API를 사용하든 상관없이 적용됩니다.

여러분은 LLM 청구서의 변동을 어떻게 막고 계신가요? 가장 당황스러웠던 예상치 못한 인보이스(invoice) 경험은 무엇인가요? 댓글로 남겨주세요. 앞으로 며칠 동안 댓글에 답변해 드리겠습니다.