에이전트를 위한 일괄 결제 (BPA) 1.0: AI 에이전트가 여러 수취인에게 동시에 결제하는 방식에 대한 개방형 표준

이제 에이전트(Agents)는 _행동_할 수 있습니다. 예약하고, 구매하고, 도구(tools)를 호출하며, 지출합니다. 하지만 간단한 질문을 던져보겠습니다. 자율 에이전트(autonomous agent)가 어떻게 500명에게 한 번에 결제할 수 있을까요? 이에 대한 깔끔한 답은 없습니다. 일회성 통합(one-off integrations)의 더미와 모호한 설명들만 존재할 뿐입니다.

그래서 우리는 명세(spec)를 작성했습니다. Batch Payments for Agents (BPA) 1.0은 에이전트가 단일하고, 관리되며, 검증 가능한 일괄 처리(batch)를 통해 여러 수취인에게 자금을 분배하는 방식에 대한 프레임워크 중립적인(framework-neutral) 개방형 표준입니다. 여기에서 확인하고 인용할 수 있습니다:

👉 docs.spraay.app/bpa/1.0 · 소스: github.com/plagtech/bpa-spec

이 포스트는 그 이유(why)와 내용(what)에 대해 다룹니다.

에이전트에게 실제로 필요한 결제는 기존의 결제망(rails)이 제약을 가하는 방식입니다

카드 및 은행 네트워크는 사람이 한 번 결제 버튼을 클릭하는 것에 최적화되어 있습니다. 에이전트의 지급(payouts)은 그 반대 형태이며, 다음과 같은 세 가지 구체적인 방식으로 비용 모델을 무너뜨립니다:

소액 (Micro-amounts). 데이터 라벨러(data labelers) 무리에게 작업당 0.50달러를 지급하는 방식은 고정 수수료 때문에 불가능합니다.
기계 주도 (Machine-initiated). 결제 시 사람이 없으며, 카드 실물 제시 흐름(card-present flow)도 없고, 차지백(chargeback) 절차도 없습니다.
일대다, 글로벌 (One-to-many, global). 500명의 기여자에게 동시에 지급하며, 이들 중 다수는 국경을 넘나들거나 은행 계좌가 없을 수 있고, 결제는 몇 초 내에 정산되어야 합니다.

빠른 체인(fast chains) 위의 스테이블코인(Stablecoins)은 결제망(rail) 문제를 해결합니다. 부족한 것은 _계약(contract)_입니다. 즉, "에이전트가 여러 수취인에게 동시에 안전하게 결제한다"는 합의된 형태가 필요합니다. 이것이 없다면, 모든 팀은 동일하고 취약한 로직을 다시 구축해야 합니다: 어떻게 일괄 처리를 멱등적(idempotent)으로 만들 것인가? 500개 항목 중 347번째 항목이 실패하면 어떻게 되는가? 정산되었음을 어떻게 증명하는가? 오작동하는 에이전트가 자금고(treasury)를 탕진하는 것을 어떻게 막는가?

BPA는 이러한 질문들에 대해 단 한 번의 답을 제시함으로써, 아무도 다시 답할 필요가 없게 만듭니다.

BPA 1.0이 실제로 정의하는 것

이 명세는 좋은 인프라가 그러하듯 의도적으로 지루합니다. 다음과 같은 사항들을 확정합니다:

요청 형식 (A request format) — 검증 가능한 JSON Schema를 포함하는 단일 Disbursement Request 객체.
멱등성 (Idempotency) — 일괄 지급 (batch disbursement)은 되돌릴 수 없으므로, 구조적으로 재전송에 안전함 (replay-safe).
부분 실패 의미론 (Partial-failure semantics) — 기본적으로 원자적 (atomic)임; 만약 특정 레일 (rail)이 원자적일 수 없는 경우, 수취인별 결과와 실패한 항목에만 국한된 재시도 토큰 (retry token)을 제공함.
결제 확인 (Settlement confirmation) — 체인별 최종성 (finality) 규칙에 따라 온체인 (on-chain)에서 검증 가능하며, "보냈으니 믿으라"는 식의 방식은 허용하지 않음.
거버넌스 모델 (A governance model) — 지출 한도, 수취인 화이트리스트 (allowlists), 승인 게이팅 (approval gating), 변조 방지 감사 (tamper-evident audit)를 모두 포함하며, 이 모든 사항은 결제 (settlement) 전에 평가되어 실패 시 차단 (failing closed)됨.
투명한 수수료, 전송 바인딩 (transport bindings, x402 / MPP), 그리고 MCP 도구 형태.

에이전트가 생성하는 핵심 객체는 다음과 같습니다:

{
  "bpa_version": "1.0",
  "idempotency_key": "payout-2026-06-02-001",
...

금액은 정수 기반 단위 (integer base units)로 처리됩니다 (부동 소수점 오차 방지). 전송하기 전에 공개된 JSON Schema를 통해 검증하십시오.

강조할 만한 세 가지 설계 선택 사항

엔드 투 엔드 비수탁형 (Non-custodial end to end). 퍼실리테이터 (facilitator)는 트랜잭션을 '구축'할 뿐이며, 에이전트 자신의 서명이 지출을 승인합니다. 게이트웨이는 자금을 보유하지 않습니다. 이 단일한 특성만으로도 보안 우려의 한 범주를 완전히 제거합니다. 위조된 요청은 그저 아무도 제출할 수 없는 서명되지 않은 트랜잭션을 생성할 뿐입니다.

실행 후가 아닌, 실행 전 거버넌스 적용. BPA는 모든 지급을 고위험 작업으로 취급합니다. 목표는 에이전트에게 올바르게 행동하라고 '요청'하는 것이 아니라, 정책을 벗어난 지급이 구조적으로 불가능하게 만드는 것입니다. 한도, 화이트리스트, 승인은 단 하나의 토큰이 이동하기 전에 요청이 통과해야 하는 결정론적 검사 (deterministic checks)입니다. 정책을 평가할 수 없다면, 결과는 "거부 (denied)"입니다.

의도적인 세 개의 체인. BPA 1.0은 에이전트의 결제 활동이 실제로 집중되어 있고 기관의 도달 범위가 넓은 Base, Ethereum, 그리고 Solana를 기준으로 규범적으로 정의되었습니다. 저희는 더 많은 체인에서 레퍼런스 컨트랙트 (reference contract)를 실행하지만, 사양 (spec)의 신뢰성은 가장 취약한 주장(weakest claim)이 될 수 있습니다. 규범 본문의 모든 내용은 메인넷 (mainnet) 기반이며 소스 검증을 마쳤습니다 (결제 컨트랙트는 BaseScan 및 Etherscan에서 정확히 일치하도록 검증되었습니다). 지지력이 없는 광범위함은 의구심을 자아내는 표면적 영역일 뿐입니다.

직접 시도해 보세요

Spraay는 레퍼런스 구현체 (reference implementation)입니다 (솔직히 말씀드리면, 저희의 프로젝트이며, 사양을 작성하면서 이를 완벽하게 만들 수밖에 없었습니다). 두 가지 방식으로 접근할 수 있습니다:

HTTP / x402: POST https://gateway.spraay.app/api/v1/batch/execute — 에이전트가 서명할 수 있도록 서명되지 않은 트랜잭션 (unsigned transaction)을 반환합니다.
MCP: Smithery에 @plagtech/spraay-x402-mcp로 게시된 spraay_batch_execute 도구로, 의도 (intent)에 따라 설명되어 있어 에이전트가 런타임 (runtime)에 이를 매칭할 수 있습니다.

온체인 (on-chain) 프로토콜 수수료는 0.30%이며, 호출당 수취인 제한은 200명입니다 (더 큰 배치 (batch)는 하나의 멱등성 키 (idempotency key) 아래에서 청크 (chunk)로 나누어 처리하십시오).

이것은 개방형 표준입니다 — 이를 기반으로 구축하세요

BPA는 CC-BY-4.0 라이선스로 게시되었습니다. 구현에는 제한이 없으며 허가가 필요하지 않습니다. 준수 여부를 확인할 수 있는 체크리스트 (§14)와, 저희뿐만 아니라 모든 조력자 (facilitator)가 준수함을 주장할 수 있는 자기 인증 (self-attestation) 형식이 마련되어 있습니다. 만약 에이전트 인프라를 구축 중이고 지급 (payouts) 기능을 다룬다면, 이것은 귀하의 툴링 (tooling)이 참조해야 할 기준이 되도록 설계되었습니다.

작업 승인 기반 결제 (task-gated payments, pay-on-approval)를 위한 인증 모델에 대해 강력한 의견이 있다면, 이는 1.1 버전에서 명시적으로 다룰 예정인 부분입니다 — 이슈 (issue)를 생성해 주세요.

사양 (Spec): docs.spraay.app/bpa/1.0
리포지토리 (Repo): github.com/plagtech/bpa-spec
레퍼런스 게이트웨이 (Reference gateway): gateway.spraay.app

에이전트들은 많은 사람에게 소액의 돈을 아주 많이 움직이게 될 것입니다. 적어도 그 방식에 대해서는 합의를 해둡시다.