AI 에이전트가 무언가를 구매했는데 결제가 잘못되는 경우, 당사자들은 보통 같은 문제점을 발견합니다. 바로 실제로 무엇에 대해 약정했는지에 대한 구조화된 기록이 없다는 것입니다.
승인은 유효했습니다. 자격 증명도 진짜였습니다. 판매자는 합법적인 주문을 이행했습니다. 하지만 구매자가 본 것은 자신이 의도한 바가 아닌 무언가에 대한 청구 금액입니다. 카드 네트워크는 두 당사자 간의 분쟁을 위해 구축되었습니다. 스테이블코인 레일은 즉각적이고 되돌릴 수 없는 정산을 위해 구축되었습니다. 어느 쪽도 여기서 중요한 질문, 즉 에이전트가 실제로 무엇에 약정했는지, 그리고 판매자가 그것을 이행했는지를 답하도록 설계되지 않았습니다.
저는 이 문제를 해결하기 위한 프로토콜 계층을 구축해 왔습니다. 이것은 SAAX Protocol—Solvent Applied Autonomous Exchange Protocol입니다. 자율 상거래를 위한 공급자 중립적인 약정 수명 주기(commitment lifecycle)입니다.
스택의 격차
대부분의 에이전트 상거래 인프라는 두 가지 계층을 처리합니다:
- 승인 (Authorization) — 특정 가치 이전을 승인한 유효한 자격 증명을 가진 당사자가 존재함을 증명합니다. 이는 AP2, ACP 및 카드 네트워크가 처리하는 부분입니다.
- 정산 (Settlement) — 지정된 레일 위에서 가치를 이동시킵니다. 이는 x402, MPP 및 결제 프로세서가 처리하는 부분입니다.
이 둘 사이에는 누락된 계층, 즉 **약정(commitment)**이 있습니다. 에이전트가 실제로 동의한 것, 무엇이 이행으로 간주되는지, 그것을 증명하는 것이 무엇인지, 그리고 실패할 경우 무슨 일이 발생하는지에 대한 것입니다.
약정 계층 없이는 결제 계층이 애초에 조건(terms)을 받지 못한 작업을 수행하려고 합니다. 이는 승인해서는 안 될 거래를 승인하고 평가할 수 없는 분쟁을 제기합니다.
SAAX 약정이 기록하는 것
약정은 실행이 시작되기 전에 다섯 가지 요소를 묶습니다:
- 권한 (Authority) — 누가 에이전트에게 행동하도록 승인했는지, 어떤 범위 내에서, 어떤 한계로
- 조건 (Terms) — 무엇에 동의했는지: 가격, 제공물(deliverable), 마감일, 조건
- 수락 기준 (Acceptance criteria) — 객관적으로 이행으로 간주되는 것
- 증거 요구 사항 (Evidence requirements) — 어떤 증명이 제출되어야 하는지
- 복구 정책 (Recovery policy) — 이행이 실패할 경우 무슨 일이 발생하는지
지급(commitment)은 결제 이전에 발행됩니다. 증거는 참조 자료로 첨부됩니다. 결과(outcome)와 최종성(finality) 상태는 동일한 지급에 기록됩니다.
진행 중인 상태 (in-flight state)
가장 어려운 경우는 에이전트의 첫 시도가 시스템을 벗어나 응답을 절대 반환하지 않는 경우입니다. 이때 지급 ID(commitment ID)는 네트워크상에 존재합니다. 정산(settlement)은 이미 진행 중일 수 있습니다. 동일한 ID로 무작정 재시도하는 것은 가맹점의 승인 경로를 방해할 수 있습니다.
프로토콜 규칙: 알 수 없는 결과(unknown outcome)는 상태 확인이며, 또 다른 POST 요청이 아닙니다.
에이전트는 재시도하기 전에 지급 상태를 조회합니다. not_found는 재시도가 안전함을 의미하고, in_flight는 기다려야 함을 의미하며, fulfilled는 중단해야 함을 의미하고, failed는 새로운 지급 ID로 다시 시도해야 함을 의미합니다.
가맹점 측의 규칙 역시 마찬가지로 명확합니다. 요청을 처리하기 전에 반드시 in_flight 상태를 영구 저장소(durable storage)에 기록해야 합니다. 이 기록이 잠금(lock) 역할을 합니다. 동일한 지급 ID로 두 번째 요청이 오면, 이는 다시 처리되지 않고 in_flight가 반환됩니다.
양쪽 모두 이 규칙들이 필요합니다. 어느 한쪽만으로는 간극을 메울 수 없습니다.
현재 상태 (What's live)
이 프로토콜은 작동하는 참조 구현(reference implementation)을 가지고 있습니다:
사양(Spec): saax-protocol.com/spec
준수 테스트 스위트(Conformance suite): saax-protocol.com/conformance — 61/61 벡터 통과
문서(Docs): saax-protocol.com/docs
MCP 엔드포인트: https://www.saax-protocol.com/mcp — 10가지 도구, 무료 테스트 가능, 가입 불필요
레지스트리 목록(Registry listing): io.github.bryantrudy24/saax-protocol 버전 1.0.3
이 프로토콜은 특정 공급업체에 종속되지 않으며 의견 제시가 열려 있습니다. 라우터(Router)는 이 프로토콜의 한 구현체일 뿐입니다 — 정산 계층은 x402와 MPP를 사용하지만, 프로토콜 자체는 특정 레일을 요구하지 않습니다.
제가 이것을 공유하는 이유 (Why I'm sharing this)
저는 토큰이나 제품을 홍보하는 것이 아닙니다. 이 지급(commitment) 간극이 실제로 존재하기 때문에 제가 이것을 만들었습니다. 에이전트 상거래(agent commerce)를 중심으로 구축되고 있는 인프라(AP2, x402, MPP, UCP, ACP)에는 이 부분이 포함되어 있지 않습니다. 만약 거래하는 에이전트를 구축하고 계시다면, 공유 지급 계층(shared commitment layer)이 귀하의 스택에 유용한지 — 그리고 사양 중 어느 부분이 부족하거나 불분명한지 알고 싶습니다.
MCP 엔드포인트가 공개되었습니다. 컨포먼스 스위트도 공개입니다. 사양(spec)은 오픈되어 있습니다. 이것이 여러분의 문제를 해결한다면, 어떻게 도움이 되었는지 듣고 싶습니다. 만약 그렇지 않다면, 그것에 대해서도 듣고 싶습니다.