AI 에이전트가 프로바이더 호출 전 런타임 예산(Runtime Budgets)을 가져야 하는 이유

문제점

대부분의 AI 비용 제어는 너무 늦게 이루어집니다.

프로바이더(Provider) 대시보드는 API 호출이 이미 실행된 후에 무슨 일이 일어났는지 알려줄 수 있습니다.

그것은 유용합니다.

하지만 실행 중인 잘못된 에이전트 실행을 중단시키지는 못합니다.

기본적인 LLM 사용의 경우, 이는 용인될 수 있습니다. 프롬프트(Prompt)를 하나 보내고, 응답을 하나 받고, 나중에 비용을 확인하면 됩니다.

에이전트는 다릅니다.

AI 에이전트는 단 한 번의 호출이 아닙니다.

그것은 루프(Loop)입니다.

그 루프에는 다음이 포함될 수 있습니다:

모델 호출 (model calls)
도구 호출 (tool calls)
재시도 (retries)
폴백 모델 (fallback models)
확장되는 컨텍스트 (growing context)
계획 단계 (planning steps)
검증 단계 (validation steps)
더 많은 재시도

각 단계는 그 자체로는 합리적으로 보일 수 있습니다.

실패는 전체 실행 과정에 걸쳐 나타납니다.

비싼 실패는 대개 지루합니다

많은 AI 비용 실패는 극적이지 않습니다.

그것들은 단순한 런타임(Runtime) 실패입니다:

에이전트가 너무 많이 재시도함
프롬프트가 약간 변하지만 의미 있게 변하지 않음
에이전트가 진전 없이 계속 도구를 호출함
실행이 안전한 단계 수를 초과함
모델 가격을 알 수 없음
워크플로(Workflow)가 예산 한도를 초과함

이 중 어느 것도 복잡한 이론을 필요로 하지 않습니다.

그것들은 지루한 런타임 제어를 필요로 합니다.

그것이 핵심입니다.

프로덕션(Production) 소프트웨어는 이미 모든 곳에 제한 사항을 가지고 있습니다.

타임아웃 (Timeouts).

메모리 제한 (Memory limits).

속도 제한 (Rate limits).

재시도 제한 (Retry limits).

서킷 브레이커 (Circuit breakers).

AI 에이전트 런타임도 동일한 종류의 사고방식이 필요합니다.

대시보드는 가드레일(Guardrail)이 아닙니다

대시보드는 다음 질문에 답합니다:

“무슨 일이 일어났는가?”

런타임 가드(Runtime guard)는 다음 질문에 답합니다:

“이 다음 호출이 일어나야 하는가?”

이것들은 서로 다른 질문입니다.

두 번째 질문이 실행 중에는 더 중요합니다.

프로바이더 호출이 이루어지면, 비용은 이미 현실이 됩니다.

그렇기 때문에 AI 에이전트 비용 제어는 청구서가 나온 후에만 이루어져서는 안 됩니다.

프로바이더 API 호출이 실행되기 전에 이루어져야 합니다.

간단한 TypeScript 지향적 사고

프로바이더 호출 전의 에이전트 단계를 상상해 보십시오.

요청을 보내기 전에, 런타임은 몇 가지 사항을 확인할 수 있습니다:

const decision = guard.beforeCall({
  runId,
  model,
  prompt,
  step,
  estimatedCost,
});

if (!decision.allowed) {
  throw decision.error;
}

const result = await provider.call({
  model,
  prompt,
});

중요한 아이디어는 정확한 API가 아닙니다.

중요한 아이디어는 체크(check)가 수행되는 위치입니다.

이는 프로바이더(provider) 호출 전에 발생합니다.

즉, 런타임(runtime)이 비용이 지출되기 전에 위험한 동작을 차단할 수 있음을 의미합니다.

호출 전 유용한 체크 사항들

실질적인 가드 레이어(guard layer)는 다음과 같은 질문을 던질 수 있습니다:

이 모델의 가격을 알고 있는가?

알 수 없다면, 실패 처리(fail closed) 하십시오.

이 실행이 예산(budget)을 초과했는가?

그렇다면, 중단하십시오.

이 에이전트(agent)가 최대 단계(max steps)를 초과했는가?

그렇다면, 중단하십시오.

이 프롬프트(prompt)가 이전의 실패한 시도와 너무 유사한가?

그렇다면, 루프(loop)를 차단하십시오.

에이전트가 진전을 보이지 못하고 있는가?

그렇다면, 구조화된 에러(structured error)를 반환하십시오.

이러한 체크들이 모델을 더 똑똑하게 만들지는 않습니다.

하지만 런타임을 더 안전하게 만듭니다.

그것이 중요합니다.

알 수 없는 모델 가격은 실패 처리(fail closed)되어야 합니다

알 수 없는 가격은 과소평가하기 쉽습니다.

모델 이름의 오타 하나가 가정을 깨뜨릴 수 있습니다.

프로바이더 별칭(provider alias)이 변경될 수 있습니다.

폴백(fallback)이 더 비싼 모델로 경로를 지정할 수 있습니다.

대시보드는 나중에야 이를 보여줄 수도 있습니다.

런타임 가드(runtime guard)는 호출 전에 이를 차단할 수 있습니다.

프로덕션 에이전트 워크플로(production agent workflows)에서 알 수 없는 가격은 리스크로 취급되어야 합니다.

추측하는 것보다 실패 처리(fail closed)하는 것이 더 안전합니다.

최대 단계 제한은 프로덕션 안전성입니다

최대 단계(max-step) 제한은 기초적인 것처럼 들립니다.

기초적입니다.

그렇기 때문에 이것이 런타임에 포함되어야 하는 것입니다.

합리적인 단계 내에 완료하지 못하는 에이전트는 혼란에 빠졌을 수 있습니다.

에이전트가 영원히 계속하게 두는 것은 거의 유용하지 않습니다.

단계 제한은 시스템에 명확한 중단 지점을 제공합니다.

또한 개발자에게 검사할 수 있는 구조화된 실패(structured failure)를 제공합니다.

이는 소리 없이 비용이 지출되는 것보다 낫습니다.

AI CostGuard가 위치하는 곳

이것이 제가 AI CostGuard로 구축하고 있는 레이어입니다.

AI CostGuard는 AI 에이전트를 위한 로컬 퍼스트(local-first) TypeScript / Node.js 런타임 안전 레이어입니다.

이는 프로바이더 API 호출이 실행되기 전에 비용 및 루프 실패를 포착하도록 설계되었습니다.

현재 체크 사항은 다음과 같습니다:

• 재시도 폭풍(retry storm) 탐지
• 유사 프롬프트 루프 탐지
• 알 수 없는 모델 가격 차단
• 최대 단계(max-step) 보호
• 예산 가드(budget guards)
• 미들웨어 및 래퍼(wrapper) 지원
• 구조화된 에러(structured errors)

이것은 과금 원장(billing ledger)이 아닙니다.

이것은 엄격한 보안 경계(security boundary)가 아닙니다.

이것은 엔터프라이즈 방화벽(enterprise firewall)도 아닙니다.

이것은 AI 에이전트의 비용 및 루프 실패(loop failures)를 방지하기 위한 호출 전 런타임 킬 스위치(runtime kill switch)입니다.

핵심 요약 (The takeaway)

더 저렴한 토큰(tokens)은 일반적인 실행(normal runs)에 도움이 됩니다.

캐싱(Caching)은 일반적인 실행에 도움이 됩니다.

라우팅(Routing)은 일반적인 실행에 도움이 됩니다.

하지만 비정상적인 에이전트 동작에는 런타임 제한(runtime limits)이 필요합니다.

핵심 질문은 단지 다음과 같은 것이 아닙니다:

“이 모델의 비용이 얼마나 들었는가?”

더 나은 질문은 다음과 같습니다:

“다음 프로바이더(provider) 호출을 허용해야 하는가?”

AI 에이전트에게 있어, 그 질문은 실행(execution) 전에 이루어져야 합니다.