AI 사용료 청구서가 라우팅 버그가 된 이유

과거에는 AI가 생산성 치트 코드처럼 팔렸습니다. 모든 개발자에게 코딩 어시스턴트를 제공하고, 모든 팀이 챗봇을 연결하며, 증가하는 사용량 차트를 회사가 더 생산적이 되었다는 증거로 여겼죠.

그것은 재미있는 부분이었습니다. 청구서(bill)가 그 방을 조용하게 만드는 부분입니다.

[Reuters]에 따르면 이번 주에는 기업들이 AI 비용의 벽에 부딪히기 시작했다고 합니다. 직원들이 AI 코딩 도구를 급하게 사용하면서 Uber는 2026년 전체 AI 예산을 네 달 만에 소진한 것으로 알려졌습니다. BlueRock CEO Harold Byun은 라이선스 모델이 변경된 후 일부 고객들이 예산 대비 20~30% 초과 지출을 경험했다고 말했습니다. Gartner는 2028년까지 AI 코딩 비용이 평균 개발자 연봉을 넘어설 것으로 예상합니다.

마지막 문장은 에이전트(agents)를 구축하는 사람들에게 신경 쓰일 만한 문제입니다.

AI 코딩 도구가 쓸모없다는 것이 아니기 때문입니다. 그렇지 않습니다. 문제는 더 간단하고, 더 당황스러운 것입니다: 많은 팀들이 여전히 2024년처럼 작업을 라우팅합니다. 모든 요청은 구매할 수 있는 가장 큰 모델로, 담을 수 있는 가장 긴 컨텍스트를 거쳐, 완료된 작업당 측정하지 않는 에이전트 루프(agent loop)를 통과합니다.

그것은 AI 전략이 아닙니다. 그것은 더 멋진 대시보드를 가진 청구서상의 사고일 뿐입니다.

Tokenmaxxing은 원래 깨질 운명이었다

Reuters 기사는 좋은 비속어인

토큰 청구서는 워크플로우가 얼마나 마법처럼 느껴졌는지에는 관심이 없습니다. 청구서는 입력 크기(input size), 출력 크기(output size), 모델 선택(model choice), 캐시 히트(cache hits), 재시도(retries), 도구 호출(tool calls), 그리고 에이전트가 포기하기 전까지 몇 번이나 루프(loop)를 도는지에만 관심을 가집니다. BCG도 최근 토큰 비용에 관한 글에서 동일한 점을 지적했습니다. 즉, 청구 금액은 프롬프트 길이(prompt length), 검색된 컨텍스트(retrieved context), 추론 노력(reasoning effort), 도구(tools), 캐시 동작(cache behavior), 그리고 루프 횟수(loop count)에 따라 결정된다는 것입니다. 다시 말해, 비용이 많이 드는 부분은 종종 모델 호출(model call) 그 자체가 아니라, 모델 호출을 둘러싼 시스템의 형태입니다.

개발자들은 다른 모든 인프라 계층에서도 이러한 패턴을 알고 있습니다. 서비스가 느려진다고 해서 즉시 가장 큰 인스턴스를 구매하고 그것을 아키텍처라고 부르지는 않습니다. 프로파일링(profile)을 합니다. 핫 패스(hot path)를 찾아냅니다. 반복되는 것을 캐싱(cache)합니다. 불필요한 작업을 중단합니다.

출력이 영어로 나온다고 해서 AI가 예외를 적용받아서는 안 됩니다.

가장 저렴한 모델이 정답도 아니다

당연한 반응은 반대 방향으로 너무 치우치는 것입니다. 즉, 모든 곳에서 프런티어 모델(frontier models)을 더 작은 모델로 교체하고 승리를 선언한 뒤, 고객 지원(customer support)에서 품질 버그가 나타나기를 기다리는 것입니다.

그것 또한 게으른 방식입니다.

Reuters 보고서에서 흥미로운 수치는 단순히 중국 모델과 오픈 소스(open-source) 모델이 더 저렴하다는 점만이 아닙니다. Citi의 노트에 따르면, OpenRouter를 통해 처리된 오픈 소스 토큰의 비중이 1월 34%에서 6월 65%로 급증했다고 합니다. 이는 팀들이 단순히 더 저렴한 모델을 찾는 것뿐만 아니라, 모델 선택을 런타임 결정(runtime decision)으로 받아들이기 시작했음을 의미합니다.

그것은 올바른 방향입니다. 하지만 '저렴함 우선' 라우팅(cheap-first routing)은 표면적인 가격(sticker price)이 아니라 전체 태스크(full task)를 측정할 때만 유효합니다.

한 번의 호출로 답변하는 작은 모델이 더 저렴합니다. 하지만 실패하여 두 번 재시도하고, 더 큰 모델로 에스컬레이션(escalate)하며, 결국 인간의 사후 정리(human cleanup pass)까지 필요하게 되는 작은 모델은 처음부터 더 나은 모델을 사용하는 것보다 더 비쌀 수 있습니다. 지연 시간(latency)도 마찬가지입니다. 저렴하고 빠른 경로(fast path)는 폴백 경로(fallback path)가 일반적인 경로가 되기 전까지만 훌륭할 뿐입니다.

제가 주시할 지표는 100만 토큰당 비용이 아닙니다. 바로 수락된 결과당 비용 (cost per accepted result)입니다.

여기에는 재시도 (retries), 폴백 비율 (fallback rate), 지연 시간 (latency)이 포함됩니다. 또한, 스프레드시트의 계산을 망치기 때문에 아무도 계산하고 싶어 하지 않는 지루한 인간 검토 (human review) 단계도 포함됩니다.

모델 라우팅 (Model routing)은 일반적인 엔지니어링이 되고 있습니다

성숙한 패턴은 복잡하지 않습니다. 판단 능력을 갖춘 요청 게이트웨이 (request gateway)와 같은 형태를 띱니다.

단순한 추출 (extraction)은 작거나 특화된 모델로 보냅니다. 분류 (classification)는 언어 모델 (language model)이 전혀 필요하지 않을 수도 있습니다. 결정론적 정책 확인 (deterministic policy check)은 코드로 처리해야 합니다. 고객 지원 답변 초안은 저렴한 모델로 시작하여 신뢰도 (confidence)가 낮을 때만 에스컬레이션 (escalate)할 수 있습니다. 까다로운 리팩토링 (refactor)이나 장애 분석 (incident analysis)은 비싼 모델을 사용할 가치가 있는데, 이는 틀렸을 때의 비용이 토큰 비용보다 높기 때문입니다.

글로 써놓으면 당연하게 들립니다. 소프트웨어에서 발생하는 대부분의 낭비가 그렇습니다.

어려운 부분은 라우팅 정책을 가시화하는 것입니다. 모든 요청은 나중에 기본적인 질문에 답할 수 있을 만큼 충분한 메타데이터 (metadata)를 포함해야 합니다: 어떤 앱이 보냈는지, 어떤 팀이 소유하고 있는지, 어떤 모델이 처리했는지, 입력 및 출력 토큰이 얼마나 되었는지, 응답이 수락되었는지, 재시도했는지, 에스컬레이션되었는지, 그리고 최종 비용은 얼마였는지와 같은 정보들입니다. CIO는 이를 앱, 환경, 팀, 모델, 유스케이스 (use case)별로 집계된 요청 수준의 토큰 텔레메트리 (token telemetry)라고 불렀습니다. 이것이 바로 적절하게 지루한 수준입니다.

그러한 텔레메트리 (telemetry) 없이는, 가장 저렴한 모델에 대한 논쟁은 대부분 느낌 (vibes)에 의존하게 됩니다. 하지만 이것이 있다면, 조달 팀 (procurement team)이 아닌 엔지니어처럼 변화를 만들어낼 수 있습니다.

에이전트 세금 (agent tax)이 예산을 사라지게 만드는 곳입니다

이는 챗봇 (chatbot)보다 에이전트 (agent)에게 더 중요합니다.

A 일반적인 챗봇의 턴 (turn)은 하나의 프롬프트 (prompt)와 하나의 응답 (response), 그리고 아마도 검색 (retrieval)이 포함된 형태입니다. 하지만 에이전트의 턴은 계획 (planning), 도구 스키마 (tool schemas), 도구 결과 (tool results), 히스토리 (history), 재시도 (retries), 성찰 (reflection), 검증 (validation), 그리고 최종 답변을 포함할 수 있습니다. 만약 에이전트가 정체된다면, 몇 번의 루프 (loops) 동안 매우 정중하게 돈을 태워버릴 수 있습니다.

그렇기 때문에 에이전트 워크플로 (agent workflows)에는 예산 (budgets)이 재무적인 사후 고려 사항이 아니라, 설계 기본 요소 (design primitive)로서 반드시 포함되어야 합니다.

저는 모든 프로덕션 에이전트가 자신의 한계치를 알기를 바랍니다: 최대 토큰 (max tokens), 최대 도구 호출 (max tool calls), 최대 재시도 (max retries), 최대 실행 시간 (max wall time), 그리고 언제 멈춰서 도움을 요청해야 하는지에 대한 명확한 규칙 말입니다. 제약 사항이 에이전트를 약하게 만들기 때문이 아닙니다. 경계 없는 자율성 (unbounded autonomy)은 그저 신용카드를 결합한 while 루프일 뿐이기 때문입니다.

여기에는 유용한 구분법이 있습니다:

• 결정론적인 작업 (deterministic work)에는 소프트웨어를 사용하세요.
• 저렴하고 좁은 범위의 판단 (narrow judgment)에는 작은 모델 (small models)을 사용하세요.
• 난도가 높은 작업 (hard tail)에는 프런티어 모델 (frontier models)을 사용하세요.
• 오답의 비용이 기다리는 비용보다 높을 때는 인간을 사용하세요.

이것은 반(反) AI적인 태도가 아닙니다. 재무적 상황 악화로 인해 아침에 눈을 뜨는 일을 방지하려는 찬성 (pro)의 태도입니다.

토큰을 더 구매하기 전에 제가 구축할 것들

만약 제가 엉망이 된 AI 스택을 정리해야 한다면, 벤더 (vendors)를 교체하는 것부터 시작하지 않을 것입니다. 대신 다섯 가지의 지루한 통제 수단부터 시작할 것입니다.

첫째, 모든 모델 호출 (model call)을 작업 유형, 모델, 입력 토큰, 출력 토큰, 지연 시간 (latency), 재시도, 폴백 경로 (fallback path), 그리고 수락 또는 거부된 결과와 함께 기록하세요. 대시보드의 미사여구는 필요 없습니다. 오직 사실만이 중요합니다.

둘째, 기본적으로 출력 길이를 제한하세요. 긴 답변은 돈을 낭비하는 가장 쉬운 방법 중 하나입니다. 출력 토큰은 보통 입력 토큰보다 비용이 더 많이 들기 때문입니다.

셋째, 제공업체가 지원하는 경우 안정적인 컨텍스트 (stable context)를 캐싱 가능한 접두사 (cacheable prefixes)로 이동시키세요. 거대한 시스템 프롬프트 (system prompts)와 정책 덩어리 (policy blobs)를 매 요청마다 처음부터 다시 비용을 지불하며 처리해서는 안 됩니다.

넷째, 브랜드별 라우팅을 하기 전에 작업 클래스 (task class)별로 라우팅하세요. 추출 (extraction), 요약 (summarization), 코드 리뷰 (code review), 계획 (planning), 고객 지원 (customer support), 그리고 장애 분석 (incident analysis)은 서로 다른 작업입니다. 첫 번째 데모가 잘 나왔다는 이유만으로 이 작업들이 하나의 기본 모델을 공유해서는 안 됩니다.

다섯째, 수락된 결과당 비용 (cost per accepted result)을 측정하세요. 만약 더 저렴한 경로가 더 많은 재시도, 더 많은 에스컬레이션 (escalations), 또는 더 많은 인간의 사후 정리 작업을 만들어낸다면, 그것은 저렴한 것이 아닙니다. 단지 비용을 다른 곳에 숨기고 있을 뿐입니다.

AI 연구소들은 계속해서 토큰 가격을 낮출 것입니다. 오픈 소스 모델 (open-source models)은 계속해서 발전할 것입니다. 프런티어 모델은 특정 작업에 대해 계속해서 가치를 유지할 것입니다. 이 모든 사실은 동시에 성립할 수 있습니다.

승리하는 팀은 항상 가장 최신 모델을 선택하거나 항상 가장 저렴한 모델을 선택하는 팀이 아닐 것입니다. 그들은 모델 선택을 인프라(infrastructure)처럼 다루는 팀이 될 것입니다. 즉, 측정하고(measured), 라우팅하고(routed), 상한을 설정하며(capped), 캐싱하고(cached), 검토하는(reviewed) 팀입니다.

청구서는 미스터리가 아닙니다. 그것은 흔적(trace)입니다.

만약 토큰(tokens)이 어디로 갔는지 설명할 수 없다면, 당신은 아직 AI 문제를 겪고 있는 것이 아닙니다. 당신은 관측 가능성(observability) 문제를 겪고 있는 것입니다.

원문 게시처: komoai.live