Pay-per-inference for AI agents: How BlockRun and Incarna use Amazon Bedrock AgentCore payments

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Incarna는 Amazon Bedrock AgentCore payments를 통해 BlockRun의 추론을 호출별로 결제하며, 모델 외부의 인프라가 지출 한도를 강제하는 흐름을 운영 환경에 구현했다.

📌 핵심 요약

• AI 에이전트의 추론 결제는 한 세션에서 수백 번 발생할 수 있는 소액 거래다. Amazon Bedrock AgentCore payments는 지갑 연결, 결제 프로토콜 처리, 거래 서명과 지출 한도 집행을 관리형 서비스로 제공한다.
• BlockRun은 x402를 통해 15곳이 넘는 공급자의 90개가 넘는 모델을 제공하는 사용량 기반 추론 라우터다. 공급자 선택과 결과 전달을 처리하며, 공급자별 구독 없이 각 호출을 독립적으로 견적·결제·정산한다.
• AgentCore payments는 결제 세션의 지출 상한과 만료 시간을 인프라에서 적용하며, 에이전트 코드나 프롬프트는 상한을 변경할 수 없다. Incarna는 하루 예산에 맞춰 세션을 설정하고, 고객 소유 지갑으로 Base 네트워크에서 USDC를 정산한다.
• Incarna는 당초 2~3개월로 예상한 통합을 개발 1일과 테스트 2일, 총 3일에 완료했으며 애플리케이션 코드는 약 200줄이었다. 베타 기간에는 호출당 $0.001~$0.05의 결제를 1,000건 넘게 처리했고, 각 거래를 온체인에서 개별 정산했다.
• AgentCore payments는 가격이 사전에 정해진 exact와 상한 내 실제 사용량으로 정산하는 upto 방식을 지원한다. SpreadX가 개발한 Incarna는 세션·모델·런타임이 바뀌어도 유지되는 에이전트 신원을 제공하며, 결제는 공유 플랫폼 키가 아닌 해당 신원의 지갑에 귀속된다.

🧩 주요 포인트

1. 결제 기능의 관리형 통합 → 지갑·서명·x402 처리를 직접 구축하는 부담을 줄이고 호출별 추론 결제 도입을 단축한다.
2. 인프라가 강제하는 세션 상한과 만료 시간 → 에이전트 로직 오류나 프롬프트 조작이 있어도 고객이 설정한 지출 한도를 유지한다.
3. BlockRun의 공급자 통합과 exact·upto, Incarna의 지속적 신원 → 여러 모델의 가격 방식에 대응하면서 개별 에이전트에 거래를 귀속한다.

🧠 상세 정리

1. 에이전트 실행 중 발생하는 소액 결제의 과제

AI 에이전트는 작업을 완료하기 위해 모델 추론, API 응답, 웹 콘텐츠 접근 또는 다른 에이전트 호출을 구매해야 할 수 있다. 이러한 구매는 에이전트 실행 루프 안에서 빈번하게 발생하고, 거래당 금액이 1센트의 일부에 불과하며 사람이 매번 승인하기 어려운 형태다. 한 세션에서 수백 건의 소액 구매가 발생할 수 있지만, 원문은 카드 결제망이 이런 1센트 미만 거래를 위해 설계되지 않았다고 설명한다. 결제 체계를 직접 구축하려면 자금 보관 위치와 거래 서명 방식뿐 아니라 x402 같은 새로운 프로토콜 지원도 해결해야 한다. 여기에 자율적으로 움직이는 에이전트가 과도하게 지출하지 못하도록 통제하는 문제까지 더해진다. AgentCore payments는 이러한 부담을 관리형 서비스로 처리하고, 지출 제한을 모델의 판단이 아닌 인프라에서 집행하는 방식으로 접근한다.

2. 관리형 결제 기능과 전체 구조

Amazon Bedrock AgentCore는 프레임워크나 모델에 관계없이 에이전트를 구축·연결·최적화하는 플랫폼이며, AgentCore payments는 여기에 결제 기능을 추가하는 관리형 역량이다. 이 서비스는 결제 프로토콜을 처리하고 지갑을 연결하며 거래에 서명하고 지출 한도를 집행하므로, 개발자는 각 구성 요소를 직접 조립하는 대신 하나의 서비스와 통합한다. Incarna는 Coinbase CDP 커넥터로 에이전트별 지갑을 마련하고, 고객이 지갑을 소유한 상태에서 사용 권한을 위임받는다. 유료 엔드포인트가 HTTP 402를 반환하면 AgentCore payments가 설정된 지갑으로 x402 결제에 서명하고 판매자에게 제시할 암호학적 증명을 반환한다. 전체 구조에서는 AgentCore가 에이전트를 실행하고 BlockRun이 사용량 기반 추론을 제공하며, AgentCore payments가 고객 지갑 연결과 한도 집행, 에이전트의 Incarna 신원을 대신한 결제 서명을 담당한다. Incarna는 Base 네트워크의 USDC로 정산하며, 각 거래는 온체인에서 검증할 수 있다.

3. 자격 증명과 지갑을 준비하는 절차

원문은 다른 팀도 Incarna와 같은 경로를 사용할 수 있으며, AgentCore payments가 필요한 구성 요소의 준비를 지원한다고 설명한다. Agent Toolkit for AWS의 AgentCore payments 스킬을 이용하면 Claude Code, Kiro 또는 Codex에서 안내 대화로 설정할 수 있고, AgentCore CLI·AgentCore SDK·AWS SDK로 각각 생성하는 방법도 제공된다. 먼저 Coinbase CDP 또는 Stripe Privy 자격 증명을 결제 자격 증명 공급자로 저장해 비밀 정보를 코드 대신 AWS Secrets Manager에 보관한다. 이어서 해당 자격 증명을 사용하는 결제를 조정할 Payment Manager와 커넥터를 생성하고 기본 지출 한도를 설정한다. 그다음 에이전트가 결제에 사용할 내장 지갑인 결제 수단을 생성하며, 최종 사용자는 리디렉션 URL을 통해 지갑에 자금을 넣고 서명 권한을 부여한다. 테스트 네트워크에서는 testnet USDC로 자금을 공급할 수 있어, 실제 결제 흐름을 연결하기 위한 준비 단계가 함께 제시된다.

4. BlockRun에서 추론 한 건을 구매하는 흐름

이 통합에서 판매자는 BlockRun이며, 실시간 모델 카탈로그의 추론을 호출마다 개별적으로 견적·결제·정산한다. 에이전트가 모델 호출을 필요로 하면 BlockRun과 연결하고, BlockRun은 공급자 선택과 결과 전달을 처리하므로 공급자별 구독이 필요하지 않다. BlockRun은 해당 호출의 가격을 포함한 PaymentRequired 챌린지를 반환하고, 에이전트는 결제 세션을 열어 ProcessPayment를 호출한다. AgentCore payments는 견적이 세션에 설정된 지출 한도 안에 있는지 확인한 뒤 에이전트 자신의 지갑 주소에서 결제 승인을 서명한다. 판매자가 결제 서명을 검증하면 BlockRun이 추론을 제공하고 소액의 호출별 요금을 기록한다. 요청마다 정산하므로 에이전트는 실제 이용한 호출에 대해서만 지불하며, 실행하지 않기로 선택한 호출에는 비용이 발생하지 않는다.

5. 고정 가격과 가변 가격에 대응하는 결제 방식

AgentCore payments는 x402의 exact와 upto라는 두 결제 방식을 지원하며, 원문은 가격이 결정되는 시점에 따라 두 방식의 용도를 구분한다. exact는 가격을 사전에 알 수 있을 때 일반적으로 사용하는 방식으로, 호출에 대해 제시된 금액을 기준으로 결제를 진행한다. upto는 가격이 동적으로 달라지는 자원에 적합하며, 에이전트가 먼저 결제 가능한 최대 금액을 승인한다. 추론 공급자는 처리가 끝난 뒤 실제 사용량에 해당하는 금액을 정산하되, 승인된 상한을 넘을 수 없다. 이는 호출별 결제라는 동일한 구조 안에서 사전에 가격이 확정되는 경우와 최종 사용량에 따라 금액이 달라지는 경우를 모두 다루는 방법이다. 서비스는 BlockRun뿐 아니라 Amazon Bedrock 추론 엔드포인트를 포함한 x402 호환 엔드포인트와도 작동한다고 설명된다.

6. 모델 외부에서 지출 상한을 강제하는 세션

원문은 에이전트가 실제 자금을 움직이도록 허용할 때 핵심 통제 장치가 결제 세션이라고 설명한다. 세션은 에이전트가 지출할 수 있는 최대 금액을 정하고, AgentCore payments는 이 상한을 인프라 계층에서 집행한다. 에이전트 자신의 코드와 프롬프트는 한도를 변경할 수 없으므로, 프롬프트가 조작되거나 에이전트 로직에 문제가 생겨도 고객이 설정한 금액을 초과할 수 없다. 각 세션에는 만료 시간도 있으며, Incarna는 하루 예산에 맞춰 세션 규모를 설정한다. 원문은 현재 세션 단위 예산을 사용하지 않는 통합도 코드 변경 없이 이를 도입할 수 있다고 설명한다. 이러한 구조에서 자율 결제의 허용 범위는 모델이 스스로 준수해야 할 지침에만 의존하지 않고, 서비스가 집행하는 금액과 시간의 제약으로 정해진다.

7. 운영 적용 결과와 창업자들의 평가

Incarna는 Base에서 호출별 추론 결제 흐름을 운영 환경에 배포했으며, BlockRun이 판매 측을 담당하고 AgentCore payments가 모든 거래를 통제했다. 팀은 당초 2~3개월로 예상했던 전체 통합을 개발 1일과 테스트 2일, 총 3일에 완료했고, 애플리케이션 코드는 약 200줄이었다. 베타 기간에는 호출당 $0.001~$0.05인 결제를 1,000건 넘게 처리했으며, 거래마다 온체인에서 개별 정산했다. BlockRun 창업자 Vicky Fu는 오픈 소스 라우터가 개발자에게 모델 구성의 통제권을 주고, 벤치마크 기반 라우팅 개선을 통해 더 낮은 토큰 비용과 더 높은 작업 성공률을 제공한다고 평가했다. 이는 창업자의 주장으로 제시되며, 본문에는 해당 성능과 비용 개선의 구체적인 비교 수치가 없다. Incarna 창업자 Justin Zhou는 고객 소유 지갑, 자금 공급과 권한 철회 흐름, 플랫폼이 집행하는 지출 한도, x402 두 버전을 처리하는 서명을 서비스가 제공해 직접 구현하지 않았다고 밝혔다.

8. 호출별 과금과 지속적 에이전트 신원의 결합

BlockRun은 하나의 사용량 기반 엔드포인트로 15곳이 넘는 공급자의 90개가 넘는 모델을 제공하며, 공급자 선택과 전달을 맡아 개별 구독이나 청구 관계 없이 여러 모델에 접근하게 한다. 각 호출은 독립적으로 견적·승인·결제·정산되며, Base의 USDC를 이용한다. SpreadX가 개발한 Incarna는 세션·모델·런타임이 바뀌어도 유지되는 에이전트 신원을 제공하고, 각 신원에 지갑·이메일 주소·소셜 계정·행동 이력을 연결한다. 따라서 서비스 이용료를 낼 때 온체인 지급자는 공유 플랫폼 키가 아니라 에이전트 자신의 신원이 되며, 거래를 하나의 지속적인 개체에 귀속할 수 있다. Incarna는 Base 메인넷에서 실제 정산을 수행 중이고, 원문은 이 사례를 추론을 구매하는 에이전트, 사용량을 측정하고 정산하는 공급자, 거래를 소유하는 신원의 결합으로 정리한다. 도입 절차는 지갑 연결과 지출 정책을 갖춘 Payment Manager 설정, 작업 예산에 맞춘 결제 세션 개설, HTTP 402 응답에 대한 ProcessPayment 호출로 제시된다.

🧾 핵심 주장 / 시사점

• 이 사례의 개발 기간 단축은 추론 호출 자체보다 지갑·프로토콜·서명·지출 통제를 관리형 서비스가 맡는 데서 설명된다. 다만 3일이라는 결과는 Incarna의 통합 사례에 해당한다.
• 호출별 과금과 세션별 지출 상한은 서로 다른 역할을 한다. 전자는 이용한 추론에만 비용을 부과하고, 후자는 에이전트가 자율적으로 실행할 수 있는 지출 범위를 제한한다.
• Incarna의 지속적 신원과 에이전트별 지갑은 온체인 거래를 특정 에이전트에 귀속시키며, 개별 정산 기록의 검증 가능성과 결합한다.

✅ 액션 아이템

• AgentCore payments와 BlockRun의 x402 연동을 통한 호출별 추론 결제 적용 검토.
• Incarna의 하루 예산 운영 사례를 참고해 결제 세션의 지출 상한과 만료 시간 설정.
• 추론 가격이 사전에 확정되는지 실제 사용량에 따라 달라지는지에 따라 exact 또는 upto 적용 방식 결정.

❓ 열린 질문

• BlockRun의 90개가 넘는 모델과 15곳이 넘는 공급자 중 실제 에이전트 작업에 적합한 조합은 무엇인가?
• Incarna의 하루 예산 사례를 참고할 때 작업별 결제 세션의 지출 상한과 만료 시간은 어떻게 정할 것인가?
• 대상 추론 호출의 가격은 사전에 확정되어 exact가 적합한가, 실제 사용량에 따라 달라져 upto가 적합한가?