AI 에이전트 비용은 런타임 시그널이다 | Focused Labs

AI 에이전트 비용 관리는 비용을 월간 청구서로 취급할 때가 아니라, 런타임 시그널 (runtime signal)로 취급할 때 실패합니다.

코딩 에이전트 (coding agent)는 청구서와는 다르게 돈을 사용합니다. 에이전트는 특정 작업을 위해 모델을 선택하거나, 과거 작업에서 끌어온 컨텍스트 (context)를 사용하거나, 과거 작업의 도구 (tools)를 호출하거나, 작업을 완료하기 위해 전달받은 다른 서브 에이전트 (subagents)를 호출함으로써 비용을 지출할 수 있습니다. 그리고 이러한 지출은 하네스 (harness)나 개발자가 에이전트의 실행을 중단할 때까지 재시도 (retry), 재평가 (re-evaluation), 작업 전달의 루프 속에서 발생합니다.

먼저, LangChain은 코딩 에이전트의 지출을 예측 가능하게 만드는 것에 관한 6월 15일 게시물에서 코딩 에이전트 지출의 문제를 간결하게 설명했습니다: 헤비 유저는 누군가 알아차리기 전에 주당 수천 달러를 쓸 수 있습니다. Anthropic의 2026 코딩 에이전트 보고서는 동일한 압박의 다른 측면을 보여줍니다. 개발자들은 이미 업무의 약 60%에 AI를 사용하고 있지만, 작업의 완전한 위임은 0~20%에 불과합니다. 따라서 에이전트의 동작을 예측 가능하게 만들어 제어할 수 있다고 하더라도, 에이전트들은 이미 토큰 (tokens)을 소비하고, 도구 (tools) 비용을 지불하며, 리뷰어의 시간을 소모할 만큼 충분히 활발하게 활동하고 있습니다.

청구서는 동작이 일어난 후에 도착한다

지출은 재무 정보로 취급되며, 재무 부서는 시스템이 이미 동작을 수행한 후에 지출을 확인합니다. 엔지니어링 (Engineering) 부서는 코딩 에이전트의 동작을 담당합니다.

일반적인 클라우드 청구서(cloud bill)는 단순한 형태를 가집니다. 비용을 서비스, 환경, 팀 또는 클러스터(cluster)에 할당할 수 있습니다. 코딩 에이전트(coding agents)의 지출은 다른 형태를 띱니다. 비용이 많이 드는 코딩 에이전트는 단순한 지출 동작을 보일 수 있는데, 예를 들어 재시도 정책(retry policy), 작업 수명 주기 동안 확장되는 컨텍스트 윈도우(context window), 또는 저렴한 모델 호출을 비용이 많이 드는 추론 모델(reasoning model)로 격상시키는 폴백 정책(fallback policy) 등이 있습니다. 코딩 에이전트의 비용은 에이전트가 실행하는 도구 루프(tool loops), 특히 신뢰 임계값(confidence threshold)에 도달할 때까지 멈추지 않는 검색(search)에 의해 크게 좌우됩니다.

Orq는 적절한 단위를 지목하는 AI 에이전트 FinOps 프레임워크를 정의했습니다. 에이전트 비용은 런타임 동작(runtime behavior)에 의해 결정됩니다. 재무(finance)와 에이전트가 결합될 때, 유용한 지표는 토큰당 비용(cost per token)이 아니라 결과당 비용(cost per outcome)입니다. 지원 사례에 대해 올바른 수정 사항을 생성한 5달러짜리 워크플로(workflow)는, 사람이 해결해야 할 쓰레기 같은 작업의 트레이스(trace)를 계속해서 생성하는 50센트짜리 워크플로보다 비용 효율적일 수 있습니다.

월간 인보이스(invoice)는 이 차이를 말해주지 못합니다.

이것이 바로 비용에 관한 논의가 트레이스(traces), 평가(evals), 소유자 필드(owner fields), 그리고 정책 변경(policy changes)과 함께 이루어져야 하는 이유입니다. 우리는 몇 달 동안 다른 표현을 빌려 이 점을 강조해 왔습니다. 즉, 트레이스는 단순한 배기가스(exhaust)가 아니라 운영 증거(operational evidence)가 되어야 한다는 것입니다. 비용은 그 증거의 또 다른 필드입니다.

[

]

비용, 트레이스, 결과, 그리고 하네스 정책(harness policy)이 하나의 루프 안에 있을 때 비용 제어가 작동합니다.

트레이스 없는 상한선(Caps)은 조잡하다

이와 동일한 접근 방식은 LangChain이 코딩 에이전트(coding agent) 사용에 대해 내부적으로 도입한 비용 제어 방식에서도 나타나는데, 이는 조직, 워크스페이스, 사용자 및 API 키별로 범위가 지정된 LangSmith LLM 게이트웨이 예산을 사용합니다. 해당 시스템에는 월간, 주간, 일간 및 시간당 예산이 포함되어 있으며, 특별한 상황에서 사용자와 프로젝트가 기본 설정된 기간보다 더 많이 지출할 수 있도록 허용하는 예외 조항도 있습니다. 이를 계정 코드(account codes)가 아닌 프로덕션 제어(production controls)로 취급하십시오.

동일한 단순 월간 예산이라도 하나의 값비싼 작업으로 인해 모두 소진될 수 있으며, 그 외 나머지 한 달은 괜찮아 보일 수 있습니다. 값비싼 작업을 즉시 중단시키는 동일한 시간당 제한이, 가치를 창출하고 있는 실행 시간이 긴 저렴한 작업까지 끊어버릴 수도 있습니다. 상한선(Cap)은 팀이 비용의 런타임 경로(runtime path)를 잘 파악하고 있을 때에만 도움이 됩니다.

여기서 던져야 할 질문은 평범하지만 실행하기 어려운 것입니다. 어떤 트레이스(trace)가 예산을 초과했는가; 어떤 모델 경로(model route)를 사용했는가; 누가 또는 어떤 워크플로(workflow)가 이를 트리거했는가; 어떤 도구 호출(tool calls)이 관여했는가; 어떤 재시도(retry) 또는 평가(eval) 루프가 비용을 상승시켰는가; 그리고 그 결과가 소모된 비용만큼의 가치가 있었는가? 하는 점들입니다.

마찬가지로, 단일 실행에 대해 하네스(harness)나 에이전트를 추적하는 것은 단일 프롬프트가 아닌 파이프라인을 디버깅(debug a pipeline rather than a single prompt)하는 데 필요한 정보와 동일합니다. 프롬프트 트레이스만으로는 실행을 진단할 수 있는 충분한 정보를 드러내지 못합니다. 하네스의 트레이스는 에이전트가 어려운 작업을 수행했기 때문에 비용이 더 많이 들었는지, 실패 및 재시도 루프(failure-and-retry loop)에 갇혔는지, 아니면 컨텍스트 백팩(context backpack)에 쓰레기 데이터를 담고 있었는지를 보여줍니다.

예산 범위(Budget windows)는 루프를 드러내야 합니다

에이전트 비용 제어가 단순히 '예' 또는 '아니오'로만 작동할 때 실패합니다.

비용을 단순히 승인하거나 거부하는 대신, 예산 범위는 실질적인 역할을 수행해야 합니다. 조기에 경고를 보내고, 돈을 낭비하고 있는 트레이스의 원인을 규명하며, 끝이 없는 값비싼 루프를 조절(throttle)하고, 명명된 예외를 허용하며, 하네스가 동일한 형태를 다시 마주했을 때를 대비해 충분한 세부 정보를 보존해야 합니다.

예산 범위(budget window)는 인보이스(invoice)가 나오기 전에 루프(loop)를 드러내야 합니다.

코딩 에이전트 워크플로 (coding-agent workflow)에는 저장소에서 코드를 검색하고, 테스트를 작성 및 실행하며, 패키지를 설정하고, 브라우저를 열고, 실패에 대해 더 강력한 모델에 추가적인 추론 (reasoning)을 요청하는 과정이 포함될 수 있습니다. 에이전트와 모델이 개발자 업무에 통합되면, 해당 에이전트를 실행하는 비용은 개발자의 시간과 더불어 중요해지기 시작합니다.

Finout의 2026년 지출 분석에 따르면 개별 추론 (inference) 호출에서 변동성이 나타납니다. 단일 호출은 모델 선택, 컨텍스트 길이, 그리고 에이전트 워크플로의 형태에 따라 달라질 수 있습니다. 라우팅 (routing)이나 컨텍스트 (context)의 작은 변화가 구축 중인 기능에는 거의 변화를 주지 않으면서도 비용에는 큰 변화를 일으킬 수 있습니다. 총 지출액은 실제 경로를 숨깁니다.

경로가 곧 제품입니다.

하네스 (harness)가 예산을 소유한다

지출에 대한 소유권은 하네스 (harness)에 귀속됩니다.

하네스는 에이전트에 사용할 모델 경로 (model route)를 결정합니다. 하네스는 에이전트의 재시도 (retries)를 결정합니다. 하네스는 저장소에서 검색된 컨텍스트를 축소 (trim)할지, 요약 (summarize)할지, 전체를 검색할지, 아니면 향후 검색을 위해 그대로 둘지를 결정합니다. 하네스는 하위 작업 (subtasks)을 수행하기 위해 하위 에이전트 (subagents)를 생성할지 여부를 결정합니다. 하네스는 에이전트가 작업을 완료하기 위해 어떤 도구 (tools)를 사용할 수 있는지 결정합니다. 하네스는 실패한 평가 (eval)에 대해 재시도할지, 에스컬레이션 (escalate)할지, 티켓을 생성할지, 아니면 중단할지를 결정합니다.

이것이 바로 비용 정책이 모델 주변의 하네스에 속해야 하는 이유입니다. 단독으로 존재하는 프록시 (proxy)는 너무 얇습니다. 그것은 오직 '예' 또는 '아니오'라고만 말할 수 있을 뿐입니다.

저렴한 모델과 비싼 모델 사이에는 큰 차이가 있습니다. 저렴한 모델은 작업을 완료하기 위해 사용되는 방식, 즉 동일한 작업에 대해 루핑 (looping)을 반복하는 방식 때문에 결과적으로 훨씬 더 비싸질 수 있습니다. 반대로, 비싼 모델은 작업을 빠르게 완료하고 다시 호출될 필요가 없기 때문에 결과적으로 비용 효율적 (cost effective)일 수 있습니다. 검색 (Retrieval) 단계도 마찬가지입니다. 컨텍스트 (context)를 줄임으로써 돈을 아낄 수도 있지만, 무관한 정보를 포함함으로써 돈을 낭비할 수도 있습니다. 도구 (Tools)는 토큰 소모 (token churn)를 제거할 수도 있지만, 도구의 API 규약 (API contract)이 모호할 경우 재시도 폭풍 (retry storms)을 일으킬 수도 있습니다.

비용 정책은 비용의 구조를 이해해야 합니다. 고객에게 인시던트 (incident) 작업 비용이 더 많이 들게 하십시오. 시간 단위 윈도우 (window)가 임계값을 넘어서면 비용이 너무 많이 드는 리팩토링 (refactoring) 작업을 중단하십시오. 더 저렴한 모델이 특정 방식으로 실패한 후에만 더 강력한 모델을 사용하십시오. 재시도가 설정되어 있더라도, 동일한 트레이스 (trace)에서 동일한 오류가 세 번 발생하면 재시도를 중단하십시오. 동일한 워크플로 (workflow)가 시간이 지남에 따라 갑자기 반복적으로 더 많은 비용을 발생시킨다면 이슈 (issue)를 제기하십시오.

이것은 스프레드시트 (spreadsheet)에 들어갈 내용이 아닙니다. 하네스 (harness)에 넣으십시오. 하네스는 이미 에이전트 워크플로 (agent workflow)를 위한 모델 선택과 사용량을 제어하고 있습니다.

결과당 비용이 유일하게 유효한 지표다

토큰 수 (Token counts)는 그것이 가치의 대리 지표 (proxy)가 되기 전까지만 유용합니다.

토큰을 줄이는 것은 저렴한 답변이 여전히 나쁜 답변인 상황이 오기 전까지만 좋은 일입니다. 프롬프트 캐싱 (Caching prompts), 컨텍스트 트리밍 (trimming context), 다른 모델 선택, 또는 평가 (evals) 축소는 모두 토큰 수를 감소시키지만, 작업은 여전히 성공적으로 실행되어야 합니다.

그리고 결과당 비용 (Cost per outcome)에 대해서 말하자면: 고객이 원하는 각 결과에 대해, 시스템이 그것을 생성하기 위해 얼마나 많은 비용을 지출해야 했습니까? 병합된 PR당 비용, 해결된 티켓당 비용, 검증된 마이그레이션당 비용, 성공적인 워크플로당 비용, 방지된 인간 에스컬레이션 (human escalation)당 비용. 이것들은 토큰 수의 더미보다 예산 논의에서 다루기가 더 쉽습니다. 토큰 수가 낮아졌다는 것은 팀이 토큰을 줄였다는 것을 의미합니다. 좋습니다. 하지만 답변은 여전히 제대로 작동해야 합니다.

Honeycomb의 AI를 위한 OpenTelemetry에 대한 입장은 실제 시장의 긴장 상태를 강조한다는 점에서 타당합니다. AI 및 에이전트 시스템(agentic systems)이 어떻게 작동하는지 이해하려면 더 풍부한 관찰 차원(dimensions of observation)이 필요합니다: 추론(inference), 프롬프트(prompts), 토큰(tokens), RAG 컨텍스트(RAG context), 그리고 요청 동작(request behavior). 플랫폼 비용에 대한 논의는 이 모든 것을 단 하나의 숫자로 축소하려고 합니다. 지출 목표 수치를 맞추기 위해 잘못된 필드를 삭제하는 팀은, 가치를 창출하는 방식으로 돈을 쓰기 위해 필요한 증거를 스스로 제거하는 셈입니다.

트레이스 라우팅(trace routing)에 관한 LangSmith의 문서는 이 지점에서 좋은 입장을 취하고 있습니다. 런타임 트레이스 목적지 제어(runtime trace destination controls)를 통해 LangSmith, OpenTelemetry, 또는 두 곳 모두로 트레이스를 라우팅할 수 있습니다. 트레이스와 그 지출 데이터는 신뢰성, 검토, 보안 및 재무를 위해 시스템을 거치는 작업과 함께 이동해야 합니다.

비용은 작업(work)의 속성입니다.

비용이 많이 드는 트레이스는 관리되는 작업이 되어야 합니다

담당자(owner)는 예산 범위를 초과한 작업을 살펴보고 이를 끝까지 추적합니다. 알림(alert)에는 트레이스, 사용자, 팀, 워크플로우(workflow), 모델 경로(model route), 툴링(tooling), 재시도(retries), 평가(evals), 결과(outcome), 그리고 비용이 포함되어 있었습니다. 담당자는 해당 작업이 가치가 있었는지 결정할 수 있으며, 향후 유사한 작업에 대해 비용 정책을 완화할 수 있습니다. 만약 그것이 낭비였다면, 이를 방지하기 위해 하네스(harness)를 수정해야 합니다.

이 작업은 반복되는 에이전트 실패를 관리되는 이슈로 전환하는 것과 동일합니다. 비용이 많이 드는 트레이스는 달러 기호($)가 붙은 버그 리포트를 품고 있는 것과 같습니다.

Evaluation steers the harness는 비용, 동작, 그리고 결과를 연결함으로써 수행됩니다. 반복적인 저신뢰도 도구 사용 (low-confidence tool use)을 감지하는 평가는 비용 제어 (cost control) 역할을 할 수 있습니다. 더 저렴한 모델이 여전히 작업을 완수함을 증명하는 회귀 테스트 세트 (regression suite)는 이미 비용 제어입니다. 고객 워크플로우가 지출의 상당 부분을 차지함을 보여주는 트레이스 쿼리 (trace query)는 이미 제품 시그널 (product signal)입니다.

최상의 비용 관리 작업은 의심스러울 정도로 신뢰성 (reliability) 작업과 닮아 있습니다. 동일한 담당자. 동일한 트레이스 (traces). 동일한 릴리스 규율 (release discipline). 누군가가 그래프가 왜 그렇게 움직였는지 설명해야 하는 동일한 지루한 회의들.

좋습니다.

인보이스를 사후 분석 아티팩트 (postmortem artifact)로 취급하라

인보이스 (invoice)는 유용하지만, 늦습니다.

에이전트 지출은 런타임 결정 (runtime decisions) 과정에서 발생합니다: 작업이 어디로 흐르는지, 컨텍스트 (context)가 어떻게 집계되는지, 어떤 재시도 (retries)가 시도되는지, 어떤 도구 (tools)나 모델 (models)이 호출되는지, 어떤 모델로 에스컬레이션 (escalated)되는지 등입니다. 재무 부서가 지출된 돈을 확인하는 시점에는, 관련 엔지니어링 질문은 이미 런타임에 의해 질문되고 답변된 상태입니다.