에이전트가 일을 하다 뭔가를 사야 하는 순간이 옵니다. 모델 추론 한 번, API 응답 한 번, 웹 콘텐츠 한 조각. 건당 몇 센트의 몇 분의 1 수준이고, 사람은 중간에 없습니다.

AWS가 10월 8일 운영 사례로 공개한 AgentCore payments와 x402의 조합은 그 순간을 위한 인프라입니다. Incarna라는 에이전트가 BlockRun의 추론 API를 호출할 때마다 직접 결제하고, 1,000건 넘는 소액 결제를 실제로 처리했다는 보고입니다. 기능 자체는 5월 프리뷰, 8월 정식 출시됐고, 이번 소식은 실전 사례라는 점을 먼저 밝혀둡니다.

왜 카드 결제로는 안 되나

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

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

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

Incarna × BlockRun 구조 한 장으로 보기

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

에이전트 → BlockRun 추론 요청
  → BlockRun: HTTP 402 (Payment Required) + 이번 호출 가격 제시
  → AgentCore payments: 결제 세션 열고 ProcessPayment 호출
     · 세션 한도와 견적을 대조
     · 에이전트 지갑 주소로 서명 (Coinbase CDP, 고객 소유·사용 위임 구조)
  → 판매자(BlockRun): 서명 검증
  → 추론 제공 + 과금 기록 (건당 소액, USDC·Base 네트워크에서 정산)

포인트가 몇 개 있습니다. 지갑은 고객이 소유하고 Incarna에 위임하는 구조라 플랫폼 공용 키로 찍히지 않습니다. 온체인 결제자는 에이전트 자신의 ID입니다. 한도는 모델 밖 인프라에서 강제돼서, 프롬프트가 조작돼도 뚫리지 않습니다. 결제는 스테이블코인(USDC)으로 정산되고 전부 온체인에서 검증 가능합니다.

가격 방식도 두 가지입니다. 가격이 upfront에 정해지면 exact, 사용량에 따라 동적으로 정해지면 upto(상한을 걸고 실제 사용분만 정산)입니다. 추론처럼 토큰량에 따라 달라지는 과금에 upto가 맞습니다.

지출 통제의 핵심: 결제 세션

에이전트에게 실돈을 쥐여줘도 되는 이유는 결제 세션 때문입니다. 세션마다 상한과 만료 시간을 걸고, Incarna는 하루 예산 크기로 잡았습니다. 에이전트 로직이 꼬여도 고객이 정한 한도를 넘길 수 없습니다.

세션 = [지출 상한 + 만료 시간]
  → AgentCore payments가 인프라 계층에서 강제
  → 에이전트 코드·프롬프트로 변경 불가
  → 코드 수정 없이 세션 예산 도입 가능

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

붙이는 과정도 공개됐습니다. Agent Toolkit의 payments 스킬(Claude Code·Kiro·Codex 대화형 가이드)이나 AgentCore CLI·SDK로, Coinbase CDP나 Stripe Privy 자격을 Secrets Manager에 넣고 Payment Manager·커넥터·결제 수단(내장 지갑)을 만든 뒤 사용자가 펀딩·서명 위임을 승인하는 흐름입니다. Incarna 팀은 전체 통합을 3일에 끝냈다고 합니다. 1일은 구축, 2일은 테스트, 애플리케이션 코드는 200줄 수준. 원래는 2~3개월로 잡았던 일입니다. 베타에서 처리한 결제는 건당 0.001~0.05달러, 1,000건 이상이 각각 온체인에서 정산됐습니다.

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

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

① 요청별 가격 확인: paid 엔드포인트의 402 응답과 견적을 로그로
② 승인 한도: 세션 상한·만료 시간을 업무량에 맞게 (작게 시작)
③ 중복 방지: 재시도·타임아웃 때 같은 호출이 두 번 결제되지 않는지
④ 귀속 확인: 결제자가 공용 키가 아니라 에이전트 ID인지
⑤ 감사: 온체인 기록과 관측 대시보드가 맞는지

에이전트 보안 가이드의 승인 층(되돌리기 어려우면 멈춘다)을 돈에 적용한 겁니다. 요금 발생 작업은 사람 확인 목록의 단골이니까요. 비용 관점의 자세한 잣대는 성공 1건당 비용 글과 함께 보세요.

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

한 줄로 정리합니다.

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

AgentCore payments와 x402 사례가 보여주는 건 거창한 미래가 아니라 당장 쓸 수 있는 분리입니다. 사는 결정은 에이전트가, 쓰는 한도는 인프라가, 남는 기록은 체인이 맡습니다. 에이전트에 결제 기능을 붙이기 전에 가상 예산으로 위의 다섯 가지를 먼저 돌려보세요. 그게 자율 구매 시대의 최소 안전장치입니다.

함께 읽으면 좋은 글

참고 자료

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

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