에이전트 결제 프로토콜 전쟁: X402 vs UCP vs ACP vs AP2, 그리고 승자를 선택하는 것이 정답이 아닌 이유

X402 vs UCP vs ACP vs AP2, 그리고 왜 정답이 승자를 선택하는 것이 아닌가

저는 지난 1년 동안 모든 주요 에이전트 결제 프로토콜 (Agentic Payment Protocol)을 단일 SDK에 통합하는 데 시간을 보냈습니다. 외부에서 단순히 공부하는 것이 아니라, 실제로 어댑터 (Adapter) 코드를 작성하고, 예외 상황 (Edge cases)을 처리하며, 상호 운용성 (Interop) 실패를 디버깅했습니다. 내부에서 바라본 실제 지형은 어떠한지, 그리고 왜 파편화 (Fragmentation) 문제가 대부분의 사람들이 인식하는 것보다 더 심각한지 말씀드리겠습니다.

프로토콜들

X402: Coinbase (HTTP 402 Micropayments)

무엇을 하는가: HTTP 402 상태 코드를 부활시킵니다. 서버는 결제 헤더 (Payment header)와 함께 402 Payment Required를 반환합니다. 클라이언트는 스테이블코인 (Stablecoin, Base 상의 USDC)을 통해 결제합니다. 서버는 결제를 확인하고 콘텐츠를 제공합니다.

작동 방식:
에이전트가 리소스를 요청함 → 서버가 402 + 결제 요구 사항을 반환함
에이전트가 스테이블코인 트랜잭션 (Transaction)을 구성함
에이전트가 재시도 요청 (Retry request) 시 결제 증빙을 제출함
서버가 온체인 (On-chain)에서 확인 후 리소스를 제공함

강점: 우아합니다. 단순합니다. HTTP에 네이티브 (Native)합니다. 모든 웹 리소스와 함께 작동합니다.
약점: Base 상의 스테이블코인만 지원합니다 (확장 중이지만 제한적임). 마이크로페이먼트 (Micropayment)에 집중되어 있어 복잡한 커머스 흐름 (Commerce flows)을 위해 설계되지 않았습니다. 협상 단계가 없으며, 가격은 정해진 대로입니다.

우리의 통합 방식: ProtocolDetector가 402 응답을 식별하고 결제 트랜잭션을 자동으로 구성합니다. 즉시 사용 가능합니다.

UCP: Google/Shopify (Universal Commerce Protocol)

무엇을 하는가: 커머스 오케스트레이션 (Commerce orchestration). 상대방이 자신이 무엇을 할 수 있는지 설명하면 ("저는 API 호출, 컴퓨팅 시간, 데이터 피드를 판매합니다"), 에이전트가 조건을 협상합니다.

작동 방식:
에이전트가 UCP가 활성화된 서비스를 발견함 → 서비스가 기능 (Capabilities)을 게시함
에이전트와 서비스가 협상함 (수량, 가격, 조건)
합의에 도달함 → 결제 실행됨
서비스가 인도함

강점: 유연합니다. 발견, 협상, 그리고 복잡한 다중 항목 트랜잭션을 지원합니다. 에이전트가 서비스를 비교하고 쇼핑할 수 있습니다.
약점: 복잡합니다. 협상 단계가 지연 시간 (Latency)을 추가합니다. 양측 모두 전체 UCP 사양 (Spec)을 구현해야 하며, 기존 API에 바로 적용할 수 있는 방식이 아닙니다.

우리의 통합 방식: ProtocolDetector가 UCP 기능 엔드포인트(Capability endpoints)를 식별합니다. AgentWallet이 협상 루프(Negotiation loop)를 처리합니다. 각 단계에서 정책 검사(Policy checks)가 적용됩니다.

ACP: OpenAI/Stripe (Agent Commerce Protocol)
기능: 구조화된 트랜잭션 형식(Structured transaction format). 서비스가 장바구니를 제시하면 ("구매할 항목은 이것이고, 가격은 이렇습니다"), 에이전트가 이를 확인하고 결제합니다.
작동 방식: 서비스가 장바구니 내용이 담긴 SharedPaymentToken을 제시합니다. 에이전트가 정책에 따라 장바구니를 검증합니다. 에이전트가 결제를 승인합니다. 서비스가 주문을 이행합니다.
강점: 친숙함 (기본적으로 에이전트를 위한 Stripe Checkout과 같습니다). 이미 ChatGPT에서 라이브로 운영 중입니다. OpenAI와 Stripe의 강력한 지원을 받습니다.
약점: 경직됨. 협상이 불가능하며, 장바구니를 수락하거나 거절할 뿐입니다. 실제로는 OpenAI/Stripe 생태계에 종속(Vendor-locked)됩니다. SharedPaymentToken 형식이 ACP에 특화되어 있습니다.
우리의 통합 방식: ProtocolDetector가 ACP 토큰 형식을 식별합니다. 승인(Authorization) 전 단계에서 정책 평가가 수행됩니다. 증거 번들(Evidence bundle)에는 장바구니 내용과 승인 증명(Authorization proof)이 포함됩니다.

AP2: Google (Agent Payment Protocol v2)
기능: 암호학적으로 서명된 위임 명령(Cryptographically signed delegation mandates). 본인(인간/기업)이 에이전트가 카테고리 Y에서 최대 $X까지 지출할 수 있도록 허용하는 W3C 검증 가능한 자격 증명(Verifiable Credential, VC)을 생성합니다.
작동 방식: 본인이 서명된 위임 명령(VC 형식)을 생성합니다. 에이전트가 서비스에 명령을 제시합니다. 서비스가 서명 체인(Signature chain)을 검증합니다. 트랜잭션이 위임 명령의 범위 내에서 실행됩니다.
강점: 가장 강력한 권한 부여(Authorization) 모델입니다. 명령은 단순한 세션 토큰이 아니라 위임에 대한 암호학적 증명입니다. 중첩된 위임(Nested delegation, 에이전트 A가 더 엄격한 범위 내에서 에이전트 B에게 위임하는 것)을 지원합니다.
약점: 복잡한 자격 증명 관리. VC 인프라가 필요합니다. 아직 널리 채택되지 않았습니다. 사양(Specification)이 여전히 진화 중입니다.
우리의 통합 방식: ProtocolDetector가 AP2 명령 제시를 식별합니다. 상호 운용성(Interop)을 위해 세션 키 범위(Session key bounds)를 명령 제약 조건(Mandate constraints)에 매핑합니다.

MPP: 세션 기반 예산 할당 (Session-Based Budget Allocation)
기능: 에이전트가 정의된 범위 내에서 인출할 수 있는 사전 할당된 예산 풀(Budget pools).

작동 방식: 원금(Principal)이 예산 풀을 할당합니다 (예: 이번 세션을 위해 1000 USDC 할당). 에이전트는 풀의 범위 내에서 작동합니다. 각 트랜잭션(Transaction)은 풀에서 금액을 차감합니다. 세션이 종료되면 → 남은 자금이 반환됩니다.

강점: 제한된 지출을 위한 가장 단순한 모델입니다. 풀이 설정되면 트랜잭션마다 별도의 승인이 필요하지 않습니다.
약점: 프로토콜 협상(Protocol negotiation) 기능이 없으며, 결제 방식이 이미 합의되었다고 가정합니다. 제어 단위가 거칠게(Coarse-grained) 이루어집니다.

우리의 통합 방식: MPP는 Veridex의 네이티브 기능이며, 이는 본질적으로 우리의 세션 키(Session key) 시스템이 프로토콜 수준에서 수행하는 작업과 동일합니다.

파편화 문제 (The Fragmentation Problem)
2026년 4월의 현실은 다음과 같습니다:

• Coinbase 생태계 서비스는 x402를 사용합니다.
• Google 생태계 서비스는 UCP 또는 AP2를 사용합니다.
• OpenAI 생태계 서비스는 ACP를 사용합니다.
• 크립토 네이티브(Crypto-native) 서비스는 MPP 또는 로우 트랜잭션(Raw transactions)을 사용합니다.
• 대부분의 서비스는 아직 이 중 어느 것도 사용하지 않습니다.

단 하나의 프로토콜만 구사할 수 있는 AI 에이전트는 해당 생태계 내의 서비스와만 거래할 수 있습니다. 다섯 가지 프로토콜을 모두 구사할 수 있는 에이전트는 누구와도 거래할 수 있습니다. 하지만 어떤 개발자도 다섯 개의 프로토콜을 통합하고 싶어 하지 않습니다. 프로토콜별 코드는 복잡하며, 각 프로토콜은 서로 다른 탐색 메커니즘(Discovery mechanisms), 서로 다른 협상 흐름(Negotiation flows), 서로 다른 결제 형식(Payment formats), 서로 다른 검증 방법(Verification methods)을 가지고 있기 때문입니다.

우리가 ProtocolDetector를 구축한 이유
@veridex/agentic-payments의 ProtocolDetector는 이 문제를 해결합니다:

const wallet = await createAgentWallet ({
...
}); // 개발자는 이 단 하나의 통합 코드를 작성합니다:

const result = await wallet.pay ({
recipient: 'https://api.example.com/resource',
amount: '5.00',
currency: 'USDC',
});

// ProtocolDetector가 다음을 처리합니다:
// 1. 엔드포인트(Endpoint) 조사 → 지원하는 프로토콜 탐지
// 2. 비용, 속도 및 에이전트 정책을 기반으로 최적의 프로토콜 선택
// 3. 프로토콜별 흐름 실행
// 4. 사용된 프로토콜에 관계없이 통합된 증거 번들(Evidence bundle) 생성

하나의 API. 그 이면에는 다섯 개의 프로토콜이 있습니다. 개발자는 프로토콜별 코드를 작성할 필요가 전혀 없습니다.

나의 견해 (My Take)
프로토콜 전쟁에서 단 한 명의 승자가 나오지는 않을 것입니다. 2026년에도, 아마 영원히 없을 것입니다.

x402는 마이크로페이먼트 (micropayments)와 API 수익화 (API monetization)를 지배할 것입니다 (그것을 하지 않기에는 너무나 우아하기 때문입니다). ACP는 OpenAI 생태계를 지배할 것입니다 (그들은 배포망을 확보하고 있습니다). UCP는 복잡한 커머스 (complex commerce)를 지배할 것입니다 (Google + Shopify는 강력한 조합입니다). AP2는 기업용 위임 (enterprise delegation)을 지배할 것입니다 (암호학적 권한 부여 (cryptographic mandates)는 컴플라이언스 (compliance)가 필요로 하는 것입니다). MPP는 세션 기반 예산 (session-based budgets)의 기본값으로 남을 것입니다. 정답은 승자를 선택하는 것이 아닙니다. 그 모든 프로토콜과 통신할 수 있는 추상화 계층 (abstraction layer)을 구축하는 것입니다. 그것이 바로 @veridex/agentic-payments가 하는 일입니다. 257개의 테스트. 5개의 프로토콜. 1개의 API. 이 분석은 AXTP, VIC, MAP 및 신뢰/신원 전제 조건 (ERC-8004, Visa TAP)을 포함한 전체 프로토콜 지형을 매핑한 우리의 Agentic Payments Protocol Map 연구 논문을 기반으로 합니다. 논문 전문은 요청 시 제공 가능합니다. 프로토콜 생태계를 가로질러 거래해야 하는 에이전트 (agents)를 구축하고 있다면, SDK는 공개되어 있습니다: npm install @veridex/agentic-payments