자율형 AI 에이전트를 위한 지출 한도 설정 방법

자율형 AI 에이전트(Autonomous AI agents)는 실제 트랜잭션을 실행하고 있습니다. 여행 예약, 소프트웨어 라이선스 조달, 클라우드 인프라 구축, 계약자 비용 지불 등이 이에 해당합니다. 에이전트가 행동을 하면, 청구서는 나중에 도착합니다.

행동과 책임 사이의 그 간극에서 엔지니어링 팀들이 피해를 보고 있습니다.

만약 여러분이 에이전트 워크플로우(agentic workflows)를 구축하거나 내부적으로 배포하고 있다면, 지출 거버넌스(spend governance) 계층이 필요합니다. 사후 고려 사항이 아니라, 일급 요구 사항(first-class requirement)으로서 말입니다.

이에 대해 어떻게 생각해야 하는지 설명하겠습니다.

왜 에이전트에게는 인간과 다른 제어 방식이 필요한가

인간 직원이 구매를 할 때는 자연스러운 마찰 지점(friction points)이 존재합니다. 잠시 멈추고, 재고하고, 매니저에게 물어볼 수도 있습니다. 그 마찰은 번거롭지만, 동시에 하나의 제어 장치이기도 합니다.

에이전트는 멈추지 않습니다. 실행합니다. 프롬프트(prompt)의 버그, 오해된 지침, 또는 워크플로우의 예외 케이스(edge case)는 인간이 알아차리기도 전에 수백 번의 API 호출, 수십 개의 구독, 또는 통제 불능의 클라우드 지출 사태를 초래할 수 있습니다.

인간 직원에게 작동하는 제어 방식은 에이전트에게 그대로 적용되지 않습니다. 프롬프트가 아닌 결제 계층(payment layer)에서 강제되는, 기계가 읽을 수 있는(machine-readable) 한도가 필요합니다.

에이전트 지출 제어의 세 가지 계층

1. 트랜잭션당 상한선 (Per-Transaction Caps)

가장 세밀한 제어 방식입니다. 단일 트랜잭션이 승인할 수 있는 최대 달러 금액을 설정합니다.

에이전트의 업무가 이코노미 항공권을 예약하는 것이라면, 트랜잭션당 2,000달러의 상한선이 합리적입니다. 월간 구독 형태의 SaaS 도구를 구매하는 것이라면 500달러 정도가 적당할 수 있습니다. 이 숫자는 마법 같은 것이 아니라, 에이전트가 한 번의 행동에서 타당하게 지출할 수 있는 금액에 맞춰 조정(calibrated)되는 것입니다.

트랜잭션당 상한선은 폭주하는 단일 구매를 잡아냅니다. 하지만 에이전트가 연속해서 500번의 작은 구매를 수행하는 것은 잡아내지 못합니다.

구현 접근 방식:

• 각 에이전트에게 엄격한 트랜잭션당 한도가 설정된 카드를 발급합니다.
• 예상되는 현실적인 최대 트랜잭션보다 10-20% 높게 한도를 설정합니다.
• 상한선에 근접하지만 초과하지는 않는 트랜잭션에 대해 알림을 보냅니다. 이러한 패턴은 에이전트가 한도를 악용(gaming limits)하고 있음을 나타낼 수 있습니다.

2. 일간 및 월간 예산

Rolling budgets(롤링 예산)는 두 번째 계층입니다. 이는 거래당 한도(per-transaction caps)가 놓치는 부분인 볼륨 공격(volume attacks)을 잡아냅니다.

일일 예산이 $1,000라면, 에이전트가 각각 $4.99로 적절히 설정된 200건의 거래를 실행하더라도 200건에서 멈춥니다. 카드는 거절됩니다. 워크플로우(workflow)는 일시 중지됩니다. 사람이 검토합니다.

월간 예산은 더 느린 드리프트(drift)—즉, 에이전트가 예상보다 약간 더 많은 금액을 지속적으로 지출하여 몇 주에 걸쳐 의미 있는 초과 지출로 이어지는 경우를 처리합니다.

구현 접근 방식:

• 예상 일일 지출액 × 2배의 안전 마진(safety margin)을 기준으로 일일 예산 설정
• 분기별 계획 할당량을 기준으로 월간 예산 설정
• 예산의 100%에서만이 아니라, 50%, 80%, 95% 소진 시점에 알림(alerting) 구축
• 예산 재설정은 에이전트가 악용할 수 있는 자동 이월(automatic rollovers)이 아닌, 명시적인 이벤트여야 함

3. 가맹점 업종 제한 (MCCs)

이것은 가장 덜 사용되는 통제 수단이지만, 종종 가장 가치 있는 수단이기도 합니다.

모든 가맹점에는 카테고리 코드(category code)가 있습니다. 여행 에이전트는 소프트웨어 벤더와 다른 MCC를 가지며, 소프트웨어 벤더는 암호화폐 거래소와 다른 MCC를 가집니다. 여러분의 애플리케이션 계층(application layer)이 이해하지 못하더라도, 결제 레일(payment rails)은 이러한 카테고리를 이해합니다.

만약 여러분의 에이전트가 호텔을 예약해야 한다면, 호텔, 항공사, 렌터카로 코딩된 가맹점과만 거래할 수 있어야 합니다. 그것으로 끝입니다. 호텔을 예약하는 에이전트가 암호화폐 거래소나 송금 서비스에서 활동할 이유는 전혀 없습니다.

MCC 제한은 결제 계층에서 의도(intent)를 강제합니다. 이는 여러분의 애플리케이션 로직(application logic)이 아니라 카드 네트워크에 의해 강제되기 때문에 악용하기 어렵습니다.

구현 접근 방식:

• 에이전트의 의도된 사용 사례와 일치하는 MCC 허용 목록(allowlist) 정의
• 기본적으로 허용 목록 이외의 모든 항목은 차단
• 모든 거절된 거래를 로그(log)로 기록 — 예상치 못한 카테고리에서 거절이 반복되는 패턴은 에이전트가 자신의 범위를 벗어난 무언가를 시도하고 있다는 신호임

종합: 심층 방어 (Defense in Depth)

이러한 통제 수단 중 어느 것도 단독으로는 충분하지 않습니다. 올바른 아키텍처는 이 세 가지를 모두 계층화합니다:

통제 수단	탐지 가능한 항목	탐지하지 못하는 항목
거래당 한도 (Per-transaction cap)	단일 대액 결제	소액의 다량 결제
...

이러한 수단들은 함께 작동하여 중첩된 보호 범위를 형성합니다. 에이전트가 유의미한 피해를 입히려면 거래당 한도를 준수하면서, 동시에 전체 예산 범위 내에 있어야 하며, 허용된 가맹점(in-scope merchants) 내에서 활동해야 합니다. 즉, 실수로 이러한 제약 조건들을 모두 위반하기는 훨씬 더 어렵습니다.

카드 발급 패턴 (The Card Issuance Pattern)

이 모든 것을 실제로 구현하는 방법은 카드 발급입니다. 각 에이전트(또는 에이전트 클래스)에 생성 시점에 통제 기능이 내장된 전용 결제 카드를 발급하십시오.

이는 에이전트들에게 공유 법인 카드를 사용하는 것과는 다릅니다. 공유 카드를 사용하면 모든 에이전트가 동일한 한도, 동일한 카테고리, 동일한 예산을 갖게 됩니다. 이는 단 하나의 탈주 에이전트(rogue agent)가 전체 에이전트 군단의 통제 수단을 고갈시킬 수 있음을 의미합니다.

에이전트별 카드를 사용하면 다음과 같은 이점이 있습니다:

• 격리 (Isolation): 한 에이전트의 지출이 다른 에이전트의 한도에 영향을 줄 수 없음
• 귀속 (Attribution): 모든 거래가 특정 에이전트의 신원과 연결됨
• 회수 (Revocation): 다른 에이전트에게 영향을 주지 않고 특정 에이전트의 카드만 정지 가능

**Spur**와 같은 에이전트 네이티브 지출 관리 플랫폼은 정확히 이 패턴을 기반으로 구축되었습니다. 즉, 카드 레벨에서 거래당 한도, 유동적 예산(rolling budgets), MCC(가맹점 업종 코드) 제한을 설정할 수 있도록 에이전트별로 카드를 발급합니다.

구축할 것인가, 구매할 것인가 (What to Build vs. What to Buy)

초기 단계이고 에이전트의 지출 규모가 작으며 위험도가 낮다면, 다음과 같은 방법으로 이러한 통제 수단을 유사하게 구현할 수 있습니다:

• 수동 충전 방식의 선불 카드 (예산 한도 역할)
• 거래 영수증에 대한 수동 검토
• 특정 카테고리를 피하도록 하는 프롬프트 레벨 지침 (Prompt-level instructions)

하지만 이는 규모가 커지면 한계에 부딪힙니다. 프롬프트 레벨 지침은 강제력이 아니라 제안일 뿐입니다. 문맥을 잘못 해석하는 에이전트는 이를 무시할 것입니다. 또한 수동 충전 방식의 선불 카드는 에이전트 수가 증가함에 따라 운영 오버헤드(operational overhead)가 기하급수적으로 늘어납니다.

그 변곡점은 일반적으로 에이전트 수가 5~10개에 도달하거나, 에이전트가 주도하는 지출액이 월 $5,000에 달하는 시점입니다. 해당 임계값에 도달하면, 적절한 지출 관리 계층 (spend management layer)을 구축하는 비용이 그 시스템이 방지할 수 있는 첫 번째 사고의 비용보다 더 저렴해집니다.

체크리스트: 에이전트 지출 거버넌스 (Agent Spend Governance)

금융 거래를 실행할 수 있는 에이전트를 배포하기 전에 다음 사항을 확인하십시오:

• 거래당 한도 (Per-transaction cap) 설정 및 테스트 완료
• 50/80/95% 지점에서 알림이 설정된 일일 예산 구성 완료
• 계획된 할당량에 따른 월간 예산 설정 완료
• MCC (Merchant Category Code) 화이트리스트 정의 및 강제 적용 완료
• 에이전트별 카드 발급 완료 (공용 카드 사용 금지)
• 감사를 위한 거래 로그 접근 가능 여부 확인
• "에이전트가 예산을 초과하는" 시나리오에 대한 런북 (Runbook) 준비 완료
• 카드 취소 (Card revocation) 프로세스의 엔드 투 엔드 (end-to-end) 테스트 완료

에이전트들은 이미 실행 중입니다. 이제 지출 통제 시스템이 그 속도를 따라잡아야 합니다.

Spur는 내장된 지출 통제 기능이 포함된 에이전트 네이티브 (agent-native) 법인 카드를 구축합니다. 자세히 알아보기 →