에이전트가 스스로 결제하는 그림이 실제 운영 사례로 나왔습니다. 10월 8일 AWS가 공개한 Incarna와 BlockRun 사례입니다. 에이전트가 추론 API를 호출할 때마다 직접 돈을 내고, 베타 기간에 1,000건이 넘는 결제가 각각 온체인에서 정산됐습니다. 건당 0.001달러에서 0.05달러 사이의 소액입니다.

기능 자체는 5월 프리뷰, 8월 정식 출시됐고 이번 소식은 실전 사례라는 점은 먼저 밝혀둡니다. 기본 구조는 앞선 정리 글에서 다뤘습니다. 이 글에서는 그 다음 단계, 즉 운영으로 옮기기 전에 뭘 정해야 하는지에 집중합니다.

에이전트와 BlockRun, AgentCore payments 사이의 결제 흐름과 세션 상한, 만료, 감사 구조

위 그림이 핵심입니다. 사는 결정은 에이전트가 하고, 쓰는 한도는 인프라가 강제하고, 남는 기록은 체인과 로그가 나눠 맡습니다.

왜 카드 결제로는 안 되나

0.001달러를 1,000번 카드로 결제한다고 상상해 보세요. 카드망은 이런 고빈도 초소액을 위해 만들어지지 않았습니다. 직접 만들려면 어려운 문제가 한꺼번에 옵니다.

- 돈은 어디에 두고 매번 결제는 어떻게 서명하나
- x402 같은 새 결제 프로토콜을 어떻게 지원하나
- 자율 에이전트가 과지출하지 않게 누가 막나
- 나중에 감사할 기록은 어디에 남나

AgentCore payments는 이걸 관리형 기능으로 풉니다. 결제 프로토콜 처리와 지갑 연결, 트랜잭션 서명, 지출 한도 강제까지 한 서비스에서 맡습니다. Coinbase CDP나 Stripe Privy 지갑을 붙이고, 몇 줄의 코드로 붙이는 구조입니다.

Incarna와 BlockRun: 한 호출씩 값을 매기고 따로 정산한다

등장인물은 셋입니다. 사는 쪽인 Incarna 에이전트, 파는 쪽인 BlockRun 추론 라우터, 중간에서 지갑과 한도, 서명을 맡는 AgentCore payments입니다. BlockRun은 15개 넘는 제공사의 90개 넘는 모델을 하나의 과금 엔드포인트로 묶어주고, 호출마다 가격을 매겨 따로 정산합니다.

에이전트 -> BlockRun 추론 요청
  -> BlockRun: HTTP 402 + 이번 호출 가격 제시
  -> AgentCore payments: 결제 세션 열고 ProcessPayment 호출
     · 세션 한도와 견적 대조
     · 에이전트 지갑 주소로 서명
  -> 판매자: 서명 검증
  -> 추론 제공 + 과금 기록 (USDC, Base 네트워크)

지갑은 고객이 소유하고 Incarna에 사용을 위임하는 구조라 플랫폼 공용 키로 찍히지 않습니다. 온체인 결제자는 에이전트 자신의 ID입니다. Incarna는 SpreadX가 만든 것으로, 세션과 모델, 실행 환경이 바뀌어도 이어지는 지속 ID에 지갑과 메일, 행동 기록이 붙습니다. 그래서 결제가 누구의 것인지 끝까지 따라갑니다.

가격 방식도 두 가지입니다. 가격이 미리 정해지면 exact, 토큰량처럼 사용량에 따라 달라지면 upto입니다. 상한을 걸고 실제 사용분만 정산하는 방식이라 추론 과금에 맞습니다. AgentCore payments는 x402 외에 Stripe와 Tempo가 함께 만든 Machine Payment Protocol도 지원합니다.

운영의 핵심: 결제 세션부터 정하라

에이전트에게 실돈을 쥐여줘도 되는 이유는 결제 세션 때문입니다. 세션마다 상한과 만료 시간을 걸고, Incarna는 하루 예산 크기로 잡았습니다. 에이전트 로직이 꼬여도 고객이 정한 한도를 넘길 수 없습니다. 프롬프트가 조작돼도 뚫리지 않는 이유는 한도가 모델 밖 인프라에서 강제되기 때문입니다.

자동 결제를 붙이기 전에 이 네 가지를 먼저 정하세요. 브리핑의 실무 액션을 풀어쓴 것입니다.

1. 서비스별 허용 목록: 어느 paid 엔드포인트에만 돈을 내게 할지
2. 세션 예산: 상한과 만료 시간, 작게 시작해서 업무량에 맞추기
3. 중복 방지: 재시도와 타임아웃 때 같은 호출이 두 번 결제되지 않는지
4. 감사 로그: 온체인 기록과 CloudWatch, 관측 대시보드가 맞는지

붙이는 순서는 공개돼 있습니다. Agent Toolkit의 payments 스킬이나 CLI와 SDK로 Payment Manager와 커넥터, 결제 수단인 내장 지갑을 만들고, 사용자가 펀딩과 서명 위임을 승인하는 흐름입니다. Incarna 팀은 전체 통합을 3일에 끝냈다고 합니다. 1일은 구축, 2일은 테스트, 애플리케이션 코드는 200줄 수준입니다. 원래는 2~3개월로 잡았던 일이라는군요. 이 수치는 AWS 발표 수치이니 그대로 믿기보다 내 환경에서 재는 게 맞습니다.

관측도 붙어 있습니다. CloudWatch 로그와 사전 구축 대시보드로 트랜잭션 성공률과 평균 금액을 에이전트와 세션, 기간별로 봅니다. 에이전트 KPI 글에서 말한 토큰에서 결과까지의 추적이 돈까지 확장된 셈입니다.

CodeBridge Mini Lab: 실결제 전에 가상 예산으로

돈이 오가는 에이전트는 테스트 순서가 생명입니다.

1. 요청별 가격 확인: paid 엔드포인트의 402 응답과 견적을 로그로
2. 승인 한도: 세션 상한과 만료 시간을 업무량에 맞게, 작게 시작
3. 중복 방지: 같은 호출이 두 번 결제되지 않는지 재시도 조건에서 확인
4. 귀속 확인: 결제자가 공용 키가 아니라 에이전트 ID인지
5. 감사: 온체인 기록과 관측 대시보드가 맞는지

에이전트 보안 가이드의 승인 층을 돈에 적용한 겁니다. 되돌리기 어려우면 멈추는 거죠. 비용 관점의 잣대는 성공 1건당 비용 글과 함께 보세요.

결론: 자율성이 구매까지 확장되면 통제도 인프라로

한 줄로 정리합니다.

에이전트가 스스로 살 수 있게 되면, 한도와 인증, 감사는 모델이 아니라 플랫폼이 맡아야 한다.

이번 사례가 보여주는 건 거창한 미래가 아니라 당장 쓸 수 있는 분리입니다. 사는 결정은 에이전트가, 쓰는 한도는 인프라가, 남는 기록은 체인이 맡습니다. 자동 결제를 구현하기 전에 허용 목록과 세션 예산, 만료 시간, 감사 로그부터 정하세요. 그게 자율 구매 시대의 최소 안전장치입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

실행과 검증이 반복되는 에이전트 루프에 예산과 승인, 감사 같은 통제 장치를 함께 설계해보고 싶다면, 에이전트가 일하는 구조를 직접 만드는 과정이 이 글의 결제 세션 이야기와 바로 이어집니다.