LLM 에이전트 API 비용 킬 스위치: 공급자 호출 전에 지출을 멈추는 법

LLM 에이전트 API 비용 킬 스위치는 유료 공급자 호출이 시스템 밖으로 나가기 전에 실행되어야 합니다. 월간 예산 알림, 사용량 대시보드, 결제 이메일은 운영에 도움을 주지만, 이미 루프를 돌고 있는 에이전트, 재시도 worker, sub-agent, 모델 호출을 숨긴 tool을 그 순간 멈춘다는 보장은 없습니다.

가장 작은 실무 설계는 다음과 같습니다. 요청이 만들 수 있는 최대 비용을 먼저 추정하고, 공유 원장에서 그 금액을 원자적으로 예약합니다. 예약이 성공한 경우에만 OpenAI, Anthropic, gateway, proxy 또는 다른 유료 모델 경로로 요청을 보냅니다. 응답 후에는 usage로 실제 금액을 정산하고 남은 예약을 해제합니다. 예산을 넘는다면 에이전트에는 retryable: false인 over_budget이 돌아와야 합니다.

중지 규칙은 코드와 runbook 양쪽에 있어야 합니다. over_budget 이후 planner는 새 유료 작업을 만들지 않고, sub-agent를 띄우지 않으며, 다른 paid key나 fallback route로 바꾸지 않고, tool 내부의 모델 호출도 멈춥니다. 사람이 cap이나 policy를 바꾸고 승인 이유를 기록하기 전까지 run은 끝난 상태입니다.

진짜 비용 킬 스위치란 무엇인가

진짜 킬 스위치는 사용량 그래프, billing dashboard, 이메일 알림, 일반 rate limit이 아닙니다. 다음 유료 요청을 보내기 전에 no라고 말할 수 있는 enforcement point입니다. 위치는 에이전트 runtime, 내부 OpenAI-compatible proxy, AI gateway, 공급자 wrapper, sidecar service 중 어디든 가능하지만, 반드시 에이전트가 실제로 쓰는 credential path를 통제해야 합니다.

흔한 장애는 예산을 모르는 것이 아니라 예산을 잘못된 층에 둔 것입니다. worker가 direct provider key를 이미 갖고 있는데 뒤쪽에 budget warning만 붙이면, 보호되는 것은 재무 메일함뿐입니다. planner loop, retry loop, tool loop, sub-agent queue는 모두 같은 budget scope를 통과해야 합니다.

운영 문서에서는 용어를 분리해야 합니다.

이 구분은 사고 대응을 바꿉니다. 폭주 중 첫 질문은 어느 dashboard에 budget 필드가 있느냐가 아니라 어느 component가 다음 유료 호출을 막을 수 있느냐입니다.

제어 계층 선택

프로덕션에서는 계층을 나누는 편이 안전합니다. 요청 경로의 예산 게이트가 주 제어이고, 공급자, 플랫폼, 토큰 cap, 알림은 후방 장치입니다.

OpenAI-compatible proxy를 이미 쓰고 있다면 거기에 budget check를 넣는 것이 가장 빠릅니다. 에이전트 runtime만 모든 모델 호출과 tool 호출을 본다면 runtime에 먼저 넣고 모든 sub-agent가 같은 budget scope를 상속하도록 해야 합니다. 여러 공급자를 쓰는 경우에는 worker마다 복사하는 것보다 내부 gateway나 proxy를 두는 편이 감사와 유지보수가 쉽습니다.

잘못된 설계는 일부만 막는 gate입니다. planner는 gate를 거치지만 evaluator, retrieval tool, image generator, emergency fallback key가 직통이면 사고 때 비용은 그 옆길로 빠져나갑니다.

예약, 호출, 정산 구현

응답 전에는 정확한 비용을 알 수 없습니다. 그래서 gate는 보수적으로 최대 합리 비용을 예약하고, 응답 후 usage로 실제 비용을 정산합니다.

최소 원장 필드는 다음과 같습니다.

호출 전 흐름은 짧게 유지할 수 있습니다.

ts
async function guardedModelCall(request) {
  const estimate = estimateWorstCaseCost(request);
  const reservation = await ledger.reserveAtomically({
    budgetId: request.budgetId,
    requestId: request.requestId,
    agentRunId: request.agentRunId,
    amount: estimate,
  });

  if (!reservation.allowed) {
    return { error: "over_budget", retryable: false };
  }

  const response = await provider.responses.create(request.payload);
  await ledger.reconcile({
    reservationId: reservation.id,
    actualAmount: costFromUsage(response.usage),
    usage: response.usage,
  });
  return response;
}

핵심은 원자적 예약입니다. 다섯 worker가 같은 남은 금액을 읽고 모두 공급자 호출을 보내면, usage 로그가 도착했을 때는 이미 늦습니다. 예약은 데이터베이스 transaction, Redis script, durable workflow step, gateway operation처럼 같은 budget_id에 대해 서로 끼어들 수 없는 단일 결정이어야 합니다.

streaming도 별도 규칙이 필요합니다. 처음 예약은 허용한 최대 출력 비용으로 잡습니다. usage가 stream 끝에만 나오면 close 후 정산합니다. client가 중간에 끊기고 usage가 불명확하면 전체 예약을 즉시 풀지 마세요. 보수적으로 보류하거나 unknown으로 표시하고 공급자 로그 기반 재정산 job을 돌리는 쪽이 안전합니다.

에이전트가 실제로 멈추게 만들기

예산 응답은 일반 예외가 아니라 에이전트 의미론입니다. timeout이나 일부 429는 재시도할 수 있지만, 같은 budget scope에서 over_budget은 끝입니다.

json
{
  "error": "over_budget",
  "retryable": false,
  "budget_id": "team-alpha-agent-run",
  "next_allowed_action": "human_budget_override"
}

세 가지 전파 규칙을 지키세요.

retry policy에는 stop list가 있어야 합니다. over_budget, policy_blocked, missing_budget_scope는 재시도하지 않습니다. 로그를 남기고 운영자에게 노출하며 run을 멈춥니다. 다른 공급자나 key로 바꾸는 것은 retry가 아니라 새로운 예산 결정입니다.

공급자와 gateway 경계 확인

공급자 제어는 유용하지만 같은 종류의 킬 스위치가 아닙니다. 내부 문서에 넣기 전에 현재 공식 문서를 다시 확인해야 합니다.

OpenAI rate limit 또는 quota exceeded 증상은 별도 사고 경로로 다루세요. rate limit은 처리량 문제이고, spend kill switch는 다음 유료 요청을 예산 정책으로 막는 문제입니다.

공급자 호출 없이 테스트하기

킬 스위치가 준비되었다는 증거는 blocked 로그가 아니라 cap 이후 provider counter가 0이라는 점입니다.

가격 메타데이터, 모델 라우팅, retry policy, gateway 설정, ledger 저장소를 바꾸면 이 테스트를 다시 실행하세요. cap 이후 fake provider가 요청을 받는다면 아직 킬 스위치가 아니라 비용 모니터링입니다.

운영 runbook

1. direct provider credential을 동결하고 worker가 gate를 우회할 수 없는지 확인합니다.
2. budget scope를 확인합니다. user, team, project, agent run, monthly account cap 중 무엇인지 구분합니다.
3. ledger에서 actual spend, reserved spend, in-flight calls, unknown reconciliation items를 확인합니다.
4. agent가 terminal over_budget을 받았는지 확인합니다.
5. retries, sub-agent scheduling, tool-triggered model calls를 중지합니다.
6. provider logs와 ledger records를 request_id로 대조합니다.
7. cap을 올릴지, task를 줄일지, run을 닫을지 결정합니다.
8. human override가 필요하면 승인자, 새 cap, 만료 시간, 이유를 기록합니다.

가장 위험한 override는 다른 route로 다시 시도하는 것입니다. 공급자, 모델, gateway, key를 바꾸는 것은 같은 실패의 재시도가 아니라 새 budget decision입니다.

자주 묻는 질문

OpenAI project budget만으로 충분한가요?

아닙니다. 이번 확인 기준으로 OpenAI Help Center는 project budgets를 soft threshold로 설명합니다. governance와 alert에는 유용하지만 runaway agent를 멈추는 주 장치는 request-path gate여야 합니다.

HTTP 402, 429, 또는 domain error 중 무엇을 써야 하나요?

클라이언트가 일관되게 처리할 수 있는 것을 쓰면 됩니다. 다만 payload에는 budget cap 초과와 retryable: false가 있어야 합니다. gateway는 429를 쓸 수 있고 내부 runtime은 over_budget이 더 명확할 수 있습니다.

응답 전 비용은 어떻게 추정하나요?

그 요청이 만들 수 있는 최대 input, output, tool, image, streaming cost를 사용합니다. 완료 후 usage로 정산하고 남은 예약을 해제합니다.

provider usage가 늦게 오면요?

정산이 끝날 때까지 예약을 유지하거나 unknown으로 보수적으로 잡습니다. interrupted stream 직후 전액을 해제하면 실제 사용량 확인 전 예산이 다시 열립니다.

sub-agent는 별도 예산을 가져도 되나요?

가능하지만 parent run의 cap을 반드시 상속해야 합니다. helper가 parent 중지 후 계속 소비하면 안 됩니다.

이미 gateway가 있다면 어디서 시작하나요?

모든 paid model path가 gateway를 통과하는지 먼저 확인하세요. 그다음 fake provider, low cap, parallel calls로 테스트합니다. 우회가 닫힌 경우에만 gateway budget을 주 킬 스위치로 볼 수 있습니다.