Coinbase x402 대 Google A2A: 에이전트 간 결제를 위한 두 가지 상반된 결제 순서

연구 에이전트를 개발 중인 개발자가 작업을 검색, 요약, 번역 세 개의 다른 에이전트에 분산시키려면 1센트 미만의 기계 간 결제가 필요했습니다. Stripe는 0.001달러 호출에 최소 0.30달러로 300배의 오버헤드가 발생하고, 온체인 L1 가스도 비슷하며, 구독은 사전 협상이 필요합니다. 그는 x402를 발견했습니다. Coinbase가 HTTP 402 "Payment Required"를 구현한 것으로, EIP-3009 사전 서명 인증을 헤더로 전달하여 Base에서 1센트 미만 결제를 약 2초, 약 0.0001달러에 처리하는 상태 비저장 중개자입니다.

핵심 질문: 결제 순서

검증(빠름, 오프체인), 정산(느림, 온체인), 실제 작업(LLM 호출)이 있을 때 세 가지 순서가 가능합니다:

• A: 검증 → 실행 → 정산
• B: 검증 → 정산 → 실행
• C: 검증 → 예약 → 실행 → 캡처 (신용카드 홀드 패턴 — EIP-3009의 일회성 설계로 불가능)

Coinbase의 미들웨어는 A를 사용하고, Google의 A2A x402 확장은 B를 사용합니다. 차이는 작업 시간에 있습니다: Coinbase의 호출자는 빠른 API 엔드포인트(500ms 미만)이므로 검증-정산 간격이 미미합니다. 그러나 에이전트가 다른 에이전트를 호출할 때는 이 간격이 수초에서 수분으로 늘어나, 결제자가 검증 후 정산 전에 지갑을 비워 무료 컴퓨팅을 얻을 수 있습니다.

에이전트 작업에는 선정산이 유리

개발자는 B(검증 → 정산 → 실행)를 선택했습니다. 에이전트 작업은 실제 비용(호출당 0.30달러 이상)이 들고 느리기 때문입니다. 선정산 방식에서는 결제 실패 시 LLM이 실행되지 않습니다. 그는 네 가지 시나리오를 스트레스 테스트했습니다:

• 유효 서명, 정산 전 지갑 잔고 부족 → 정산 되돌려짐, 컴퓨팅 낭비 없음(0달러 손실).
• 같은 지갑에서 서로 다른 논스로 두 개의 병렬 요청, 동일 잔고 → 하나는 정산 성공, 다른 하나는 체인 경쟁에서 실패하여 모델에 도달하지 않음.
• 결제 헤더 재사용 → 검증 전 논스 확인에서 걸러져 402 반환.
• 중개자 10초 타임아웃, 체인 확인 25초 → 고아 결제(결제자 출금, 작업 실패). 이는 체인 부하 속성으로, 순서로 해결 불가.

선정산의 실패 모드: 결제는 성공했지만 작업 실패(500 오류, 버그). 제공자는 논스/인증 메타데이터를 유지하고 수동 환불 처리합니다.

전체 흐름은 오픈 소스이며, 네 가지 시나리오를 모두 랩탑에서 실행하는 e2e 테스트가 포함되어 있습니다. github.com/GetBindu/Bindu