피드로 돌아가기
Dev.toBackend
원문 읽기
Stripe의 Machine Payments Protocol(MPP)로 에이전트가 자율적으로 결제 가능해지면서, 예산 초과 시 승인 요청을 처리할 인프라 계층의 필요성이 대두됨
When your agent needs to spend more than you told it to
AI 요약
Context
에이전트에 정적 예산 설정($100)을 하면 작업 범위 변화(5개 시장 → 40개 시장)에 대응할 수 없다. 예산 상한선을 고정하면 에이전트가 중간에 중단되어 부분 결과만 반환되고, 제한이 없으면 통보 없이 과다 비용이 발생한다. 두 경우 모두 에이전트가 예산 초과 전에 승인을 요청할 수 있는 메커니즘이 없다는 근본 문제를 드러낸다.
Technical Solution
- MPP 도입으로 에이전트-서비스 간 결제 흐름 구현: 에이전트가 리소스 요청 → 서비스가 결제 요청 반환 → 에이전트가 승인 → 리소스 전달(3줄 코드로 Stripe 결제 수락 가능)
- 정적 환경 변수 기반 예산 모델(AGENT_BUDGET=500)에서 단계적 정책 계층으로 전환: $X 이하 자동 진행, $X~$Y 사이에서 승인 요청, $Y 초과 명시적 승인, 반복 거래 인간 검토 플래그 처리
- 일방향 웹훅(webhook)과 데이터베이스 폴링 루프 대신 양방향 지속 채널 구축: 에이전트가 메시지 전송 후 대기하면 플랫폼이 보유했다가 인간의 응답을 에이전트에 재전달(태스크 재시작 불필요)
- 다중 에이전트 환경 라우팅 계층 추가: 어떤 에이전트의 질문이 어느 담당자에게 갈지, 응답 상태(대기중/손실)를 추적하는 기능
- 감사 추적(audit trail)에 거래와 승인 결정 연결: 어느 비용이 인간 승인/정책 규칙 사전 승인/에이전트 자율 결정 중 어디서 나왔는지 기록
Key Takeaway
MPP가 결제 채널을 개방하면서 정적 설정 모델의 한계가 명확해졌다. 가변 범위를 다루는 에이전트는 예산 정책 엔진, 양방향 통신 채널, 라우팅 및 감사 시스템을 함께 갖춰야 하며, 현재 이 인프라 계층을 팀 각각이 중복으로 구축하고 있다.
실천 포인트
에이전트 기반 서비스를 구축하는 팀이 변동 비용 구조(API 호출, 브라우저 세션, 실물 배송 등)를 다룰 때, 정적 환경 변수 대신 다단계 승인 정책(자동/문의/명시 승인/감시)과 양방향 채널을 설계하면 예산 초과 시 인간의 실시간 개입이 가능해진다.