2026년 '성공적인 작업당 비용'이 실제로 의미하는 것 (그리고 누수를 찾아내는 4줄 체크)

월 300달러 규모의 파일럿 프로젝트가 215,000달러 규모의 프로덕션 실행으로 변했습니다. 모델은 동일했습니다. 프롬프트도 동일했습니다. 유일하게 변한 것은 호출 패턴(call pattern)뿐이었습니다. Predict / Medium은 2026년 5월에 이 사례를 기록했습니다: 고객 지원 에이전트(customer-support agent)의 티켓당 평균 턴(turns) 수가 프로덕션 환경에서 1.3회에서 9.3회로 급증했습니다. 코드 변경도, 모델 업그레이드도, 의도적인 성능 저하(regression)도 없었습니다. 레버(lever)는 모델이 아니었습니다. 그것은 바로 *작업당 토큰(tokens per task)*이었습니다.

이것이 제가 2026년 에이전트 청구서에서 목격하는 단 하나의 가장 큰 회계적 오류입니다. 팀들은 **토큰당 비용(cost per token)**을 기준으로 예산을 세웁니다. 하지만 그들의 실제 가변 비용은 **성공적인 작업당 비용(cost per successful task)**입니다. 그리고 이 둘 사이의 비율은 사용자 메시지와 성공 상태(success state) 사이에서 시스템이 조용히 수행하는 작업량에 따라 결정됩니다.

이 글에서는 수학적 계산, 실제 청구서에서 이 격차가 나타나는 세 가지 형태, 그리고 오늘 밤 여러분의 사용 로그에 바로 실행해 볼 수 있는 **4줄 셸 체크(4-line shell check)**를 살펴봅니다. 프레임워크도, 벤더 홍보도 없습니다. 오직 감사(audit)와 해결 방법(fix recipe)뿐입니다.

왜 '토큰당 비용'이 더 이상 레버가 아닌가

2026년에 발표된 두 소식통은 서로 다른 관점에서 동일한 내용을 말하고 있습니다:

• **Tom's Hardware (2026년 5월 23일)**는 이 패턴을 *토큰맥싱(tokenmaxxing)*이라고 명명했습니다. 에이전트 워크로드(agentic workloads)가 채팅 워크로드보다 호출당 1,000배 더 많은 토큰을 소비하고 있으며, Microsoft, Meta, Amazon이 비용 문제로 에이전트 AI(agentic AI)에서 공개적으로 물러나고 있다는 내용입니다.
• **Goldman Sachs (2026년 3월)**는 토큰당 가격 하락보다는 주로 에이전트 워크로드에 의해 주도되어, 2030년까지 토큰 소비량이 24배 성장할 것이라고 전망했습니다.

토큰당 가격은 2년 연속 하락했습니다. 여러분의 청구서가 늘어난 이유는 토큰이 더 비싸졌기 때문이 아닙니다. 각 성공적인 작업이 한 분기 전보다 더 많은 토큰을 소비하고 있기 때문이며, 이는 종종 여러분이 모르는 사이에 발생합니다.

회계 단위가 바뀌었습니다. 만약 여러분의 대시보드가 여전히 토큰당 비용을 보여주고 있다면, 여러분은 잘못된 축을 보고 있는 것입니다.

격차가 나타나는 세 가지 형태

지난 90일 동안 제가 감사(audit)한 프로덕션 트레이스(production traces)를 살펴보면, 파일럿 단계와 프로덕션 단계 사이에서 발생하는 조용한 토큰 폭발은 세 가지 형태 중 하나로 나타납니다. 때로는 두 가지가 동시에 나타나기도 하며, 드물게는 세 가지 모두 나타나기도 합니다.

형태 1 — 재귀적 자기 수정 루프 (Recursive self-correction loops)

에이전트(agent)가 도구(tool)를 호출합니다. 도구는 모호한 출력을 반환합니다. 에이전트는 이를 "확인"하기 위해 도구를 다시 호출합니다. 같은 도구로 세 번 더 호출하지만, 모호함은 여전합니다. 에이전트가 최종 결정을 내릴 때쯤이면, 사용자는 의도된 1회의 호출당 5~7회의 유료 호출 비용을 지불하게 됩니다.

제가 감사한 한 SaaS 팀의 고객 지원 에이전트 트레이스 사례: 해결된 티켓당 중앙값(median) 6회의 도구 호출이 발생했으며, 그중 4회는 첫 번째 호출 결과에 대한 재확인이었습니다. 호출당 비용은 $0.04였습니다. 티켓 하나를 해결하는 데 드는 비용은 $0.24였습니다. 해당 팀은 사용자에게 해결 건당 $0.30를 청구하고 있었습니다. 마진(margin)은 20%였습니다. 동일한 작업량을 동일한 토큰당 비용으로, 티켓당 1.3회의 호출로 처리했다면 해결 건당 $0.05의 비용과 83%의 마진을 기록했을 것입니다.

두 상태 사이의 수학적 차이는 명확합니다. 하지만 이를 탐지하는 것은 어렵습니다.

형태 2 — 스트리밍 중단 후 무시된 재시도 (Streaming-abort-unhonored retries)

대부분의 추론 클라이언트(inference clients)는 기본 재시도 정책(retry policy)을 가지고 있습니다. 만약 스트리밍 연결이 8,000번째 토큰에서 끊어지면, 클라이언트는 재시도를 수행하며, 이때 재시도 과정에서 전체 출력에 대한 비용이 다시 청구됩니다. 대부분의 클라이언트에는 stream_options.include_usage 필드가 있지만, 기본적으로는 꺼져 있습니다. 따라서 첫 번째 스트림의 토큰은 비용이 청구되었지만 응답은 전달되지 않았고, 응답이 마침내 도착했을 때 두 번째 스트림의 토큰 비용이 또 청구됩니다.

저는 스트리밍 비중이 높은 워크로드에서 이것이 **전체 지출의 18~32%**를 차지하는 것을 목격했습니다. 해결책은 단 하나의 설정 플래그(config flag)입니다. 스트림별 토큰 회계(per-stream token accounting) 없이는 진단이 불가능합니다.

형태 3 — 에이전트들의 에이전트 재귀 (Agent-of-agents recursion)

2026년의 가장 큰 형태이자 탐지하기 가장 어려운 형태입니다. "매니저(manager)" 에이전트가 하위 에이전트(sub-agents)들에게 작업을 할당합니다. 각 하위 에이전트는 라우팅을 위해 매니저를 호출합니다. LLM 호출 비용은 매니저의 입력(하위 에이전트의 전체 출력을 포함함)과 하위 에이전트의 입력(매니저의 프롬프트를 포함하며, 여기에는 이제 모든 하위 에이전트 출력의 재요약본이 포함됨)에 대해 각각 청구됩니다.

토큰 수(token count)는 에이전트의 깊이(depth)에 따라 초선형적(super-linearly)으로 증가합니다. 3단계 중첩(nesting) 시, 내부 에이전트의 호출당 실질 비용은 직접 호출했을 때보다 6~9배 높습니다. 4단계에서는 15배까지 치솟을 수 있습니다.

예측된 중간 최악의 사례(Medium worst case) — 파일럿 비용의 717배 — 는 바로 이러한 형태였습니다. 팀은 매니저의 프롬프트가 모든 하위 에이전트의 매 호출마다 다시 직렬화(re-serialized)되는 4단계 오케스트레이션(orchestration)을 실행하고 있었습니다.

오늘 밤 바로 실행할 수 있는 4줄 체크리스트

벤더 프레임워크(vendor framework)는 필요 없습니다. 필요한 것은 사용 로그(usage log)와 awk뿐입니다.

# $USAGE를 제공업체의 CSV 또는 LangSmith/Helicone/Langfuse의 트레이스 덤프(trace dump)로 교체하세요.
# 이 코드는 컬럼이 task_id, call_index_in_task, input_tokens, output_tokens, model, ts로 구성되어 있다고 가정합니다.
awk -F, 'NR>1 {calls[$1]++; in_t[$1]+=$3; out_t[$1]+=$4; cost[$1]+=(($3+$4)*rate[$6])}
...

결과로 얻게 되는 것: 워크로드에서 호출이 가장 빈번한 상위 50개 작업과 각 작업당 실제 비용입니다.

확인해야 할 세 가지 수치:

1. 작업당 호출 횟수(Calls per task): 상위 50개 작업의 평균값입니다. 이 값이 2.5를 초과하면 형태 1(Shape 1)이 활성화된 상태입니다.
2. 총 입력 토큰 / 총 출력 토큰: 상위 50개 작업 전체에서 이 비율이 6.0을 초과하면 형태 2(Shape 2, 스트리밍 중단)가 활성화되었을 가능성이 높습니다.
3. 작업당 비용의 분산(Variance of cost-per-task): 표준 편차(standard deviation)가 평균의 3배를 초과한다면, 형태 3(Shape 3, 에이전트들의 에이전트)이 거의 확실하게 활성화된 상태입니다.

이것이 전부입니다. 4줄이면 됩니다. 벤더 SDK도, 온보딩 콜도,

위에서 설명한 30분간의 자가 점검(self-check)은 동일한 엔진을 사용하며, 단지 서사적인 설명이 덜했을 뿐입니다. 만약 서사적인 버전이 필요하다면 언제든 환영합니다. LLM Bill Triage는 동일한 감사(audit)를 $299의 고정 비용으로 제공하는 버전입니다.

무료 버전을 원하신다면, 개인정보를 제거한 코드 스니펫(snippet)을 댓글로 남겨주세요. 상위 3개의 비용 누수 지점을 주석으로 달아드리겠습니다.

격차를 해결했을 때 예산에 생기는 변화

지난 90일간의 사례 연구 3가지 (익명 처리):

• 지원 에이전트 (Support agent), 월 $215K → $58K. 호출량(call volume)은 동일함. 해결책: 작업당 재시도 횟수(per-task retry cap)를 2회로 제한, 도구별 재시도 분류(일시적 vs 결정적), 입력 컨텍스트를 4,200 토큰에서 900 토큰으로 줄이기 위한 프롬프트 재설계(prompt re-architecture). 총 엔지니어링 시간: 11시간.
• 연구 에이전트 (Research agent), 월 $47K → $9K. 호출량은 동일함. 해결책: 에이전트-오브-에이전트(agent-of-agents) 구조 평탄화(계층 구조 한 단계 제거), 단계별 토큰 예산(per-step token budget) 설정, 컨텍스트 초과 시 요약 수행(summarization-on-context-overshoot). 총 엔지니어링 시간: 6시간.
• 코드 리뷰 에이전트 (Code-review agent), 월 $4,800 → $1,400. 호출량은 동일함. 해결책: 노드별 모델 라우팅(model-routing) 적용 (기존에는 diff-applicator 노드에 프런티어 모델(frontier model)을 사용했으나, 현재는 7B 로컬 모델 사용). 총 엔지니어링 시간: 4시간.

패턴: 평가 세트(eval set)의 품질 저하 없이 지출의 60-80%를 회수할 수 있었습니다. 위에서 언급한 4줄 체크리스트는 제가 각 사례에서 누수를 찾아내는 데 사용한 방법입니다.

만약 에이전트 비용을 지불하고 있으면서 이 체크를 한 번도 실행해 보지 않았다면, 현재 거의 확실하게 Shape 1, 2, 또는 3의 누수가 활성화되어 있는 상태일 것입니다.

시작하는 방법

1. 7일간의 사용량(usage)을 내보내기(Export) 하세요. 제공업체의 대시보드에서 CSV를 받거나, LangSmith / Helicone / Langfuse / vLLM 로그에서 트레이스 덤프(trace dump)를 가져오세요.
2. 4줄 체크를 실행하세요. 작업당 호출 횟수(calls-per-task)를 기준으로 정렬합니다.
3. 상위 50개의 평균값이 작업당 2.5회 호출을 초과한다면, Shape 1 누수(leak)가 발생한 것입니다. 재시도(retries) 횟수를 2회로 제한하고 다시 측정하세요.
4. 입출력 비율(input/output ratio)이 6을 초과한다면, Shape 2 누수가 발생한 것입니다. stream_options.include_usage를 활성화하고 다시 측정하세요.
5. 작업당 비용(cost-per-task)의 분산이 평균의 3배를 초과한다면, Shape 3가 발생한 것입니다. 매니저 에이전트(manager agent)를 찾아 컨텍스트(context)를 호출(call)당 한 번이 아니라 세션(session)당 한 번씩 재직렬화(re-serialize)하세요.

숫자를 얻는 데는 5분. 해결하는 데는 한 번의 엔지니어링 스프린트(engineering sprint)면 충분합니다.