하나의 402, 두 개의 프로토콜: x402와 MPP

Key Takeaways

• MPP는 x402의 402 흐름을 계승하되, 세션과 정산을 재설계한 별도의 프로토콜이다. x402가 요청 단위의 온체인 결제라면, MPP는 예치→스트리밍→일괄정산이라는 세션 단위의 결제다.

• MPP는 레일 중립성을 통해 '카드 vs 크립토'라는 프레임을 해체한다. 에이전트는 하나의 태스크 안에서 스테이블코인과 카드를 동시에 넘나들며, MPP는 이 전환을 프로토콜 수준에서 추상화한다.

• MPP와 x402의 차이는 기능의 유무가 아니라 추상화의 깊이에 있다. x402의 부품들을 하나의 레이어로 엮은 것이 MPP이며, 이는 동시에 스트라이프가 에이전트 결제의 가치를 자사 생태계 안에서 포착하려는 플랫폼 전략이기도 하다.

• x402와 MPP는 경쟁이 아닌 분업의 관계다. 바텀업과 탑다운이라는 방향성의 차이 위에서, 한쪽의 혁신을 다른 한쪽이 흡수하는 플라이휠이 돌아가느냐가 402 기반 에이전트 결제의 미래를 가른다.

Source: mpp.dev

3월 18일, 스트라이프(Stripe)는 템포 메인넷 런칭과 함께 MPP(Machine Payments Protocol)를 발표했다. 템포(Tempo)와 공동으로 설계한 이 머신 결제 오픈 표준은, 결제 생태계의 두 강자가 손잡고 내놓은 에이전트 결제 프로토콜이라는 점에서도 의미가 크다. 하지만 무엇보다 시선을 끄는 특별한 대목이 하나 있었다.

Source : Stripe Docs

그것은 바로 템포가 기존의 x402 표준을 확장하는 대신, 아예 별도의 프로토콜을 새로 구축했다는 점이다. x402와 MPP 모두 동일한 HTTP 402 프리미티브를 사용하므로 상호 호환은 가능하다. 그럼에도 불구하고 스트라이프 공식 문서에서조차 이 둘을 명확히 다른 프로토콜로 선 긋고 있다.

1. 402 기반 결제 프로토콜, MPP

먼저 MPP와 x402의 공통점부터 짚어보자면, 프로토콜의 뼈대 자체는 사실상 동일하다. 클라이언트가 리소스를 요청하면 서버가 '402 Payment Required' 응답과 함께 결제 조건을 제시한다. 이후 클라이언트가 결제를 수행한 뒤 그 증명을 붙여 재요청하면, 서버가 이를 검증하고 리소스를 반환한다. 즉, ‘요청 → 402 응답 → 결제 → 증명 첨부 및 재요청’으로 이어지는 흐름은 두 프로토콜이 완전히 일치한다.

진짜 차이는 이 결제 흐름 위에 '어떤 요소를 결합했느냐'에서 발생한다. 구체적으로 다음 두 가지 지점에서 두 프로토콜의 방향성이 명확하게 갈린다.

첫째, 결제 빈도와 정산 방식(Session)이다. x402는 기본적으로 매 요청마다 온체인 트랜잭션이 발생하는 구조다. 반면 MPP는 자금을 사전 예치한 뒤 결제를 스트리밍하고, 수천 건의 소액 결제를 하나의 정산으로 집계한다.

둘째, 결제 레일의 중립성이다. x402가 온체인 결제에 집중하는 반면, MPP는 스테이블코인, 카드, 지갑, BNPL(Buy Now, Pay Later)까지 SPT(Shared Payment Tokens)라는 단일 토큰 규격을 통해 하나의 프로토콜 안에서 추상화한다. SPT는 결제 수단의 종류와 무관하게 에이전트가 동일한 방식으로 결제 증명을 제출할 수 있도록 하는 장치다.

2. 세션 기반 결제 : x402와 MPP의 차이

2.1 x402의 세션: 이미 결제한 리소스를 기억하는 프로토콜

Source: x402.org

x402 재단은 2025년 12월 11일 V2를 발표하면서 재사용 가능한 접근을 위한 기반 구조(Foundation for Reusable Access)의 도입을 이야기했다. 이는 지갑 기반 인증을 통해 이미 결제한 리소스에 재접근할 때 온체인 트랜잭션을 생략할 수 있는 구조다. 재단은 해당 구조가 LLM 추론, 멀티콜 에이전트 같은 고빈도 워크로드에서 지연을 줄이고 반복 호출 비용을 낮출 수 있다고 설명한다.

이를 통해 세션 기반의 접근이 가능해졌지만, 정확히 이야기하자면 ‘이전에 결제한 적 있음’을 증명해서 같은 리소스에 대한 반복 결제를 건너뛰는 구조다. 즉, 에이전트가 아직 접근한 적 없는 새로운 리소스를 호출할 때는 여전히 개별 온체인 트랜잭션이 필요하다.

현재 구현된 결제 방식도 exact(건당 정확한 금액의 온체인 결제)뿐이다. upto라는 방식이 제안되어 있지만, 이것은 한 요청 안에서 소비량에 따라 과금하는 모델(예: LLM 한 번 호출에서 생성된 토큰 수에 따라 과금)이지, 여러 요청을 하나의 세션으로 묶는 개념이 아니다.

2.2 MPP의 세션: 예치금 위에서 작동하는 페이먼트 스트리밍

MPP의 세션은 프로토콜 레벨에서 근본적으로 다른 의미를 갖는다. 에이전트가 특정 서비스에 대해 세션을 열면, 해당 서비스와의 결제 채널에 자금을 사전 예치한다. 이후 같은 서비스에 API 호출, 모델 추론, 데이터 쿼리 등 새로운 요청을 보낼 때마다 별도의 온체인 트랜잭션 없이 오프체인 바우처로 결제가 처리된다. 바우처는 블록체인 처리량에 병목이 걸리지 않고, 순수하게 서명 검증만으로 동작한다. 수천 건의 소액 결제가 누적되다가, 채널을 닫을 때 한 번의 온체인 트랜잭션으로 최종 정산된다.

Source : tempo.xyz

템포 블로그는 이를 "OAuth for money"로 표현한다. OAuth가 인증의 단위를 "요청"에서 "세션"으로 바꿔 웹 API 생태계를 열었듯이, MPP는 결제의 단위를 "거래"에서 "세션"으로 바꾼다.

에이전트가 클로드 코드에서 처음 한 번 OAuth 인증을 거치면 이후에는 매번 로그인하지 않고 API를 자유롭게 호출하는 것처럼, MPP 세션도 한 번 자금을 예치하면 예치 한도 내에서 결제가 연속 실행된다. 인증 토큰 대신 결제 바우처가, 인증 한도 대신 예치 한도(maxDeposit)가 그 역할을 한다.

2.3 x402는 거래마다, MPP는 세션마다 : 에이전트 결제의 분기점

정리하자면, x402의 세션이 '이미 구매한 리소스에 대한 중복 결제 방지'에 초점을 맞춘다면, MPP의 세션은 '사전 예치금을 바탕으로 한 오프체인 결제 스트리밍'에 방점이 찍혀 있다. 즉, x402가 세션을 결제의 '생략'에 활용할 때, MPP는 결제의 '연속(스트리밍)'에 활용하는 구조다.

이러한 설계의 차이는 결국 주체의 소비 방식에서 비롯된다. 사람은 가끔씩 큰 금액을 지불하지만, 에이전트는 정반대다. 압도적으로 많은 횟수로 아주 작은 금액을 지불하는 마이크로페이먼트(소액 결제)가 이들의 기본 패턴이다. 에이전트 생태계에서 결제의 단위는 더 이상 단순한 재화의 '구매'가 아니다. 그들에게 결제는 곧 '연산' 그 자체다.

구체적인 예를 들어보자. 에이전트가 LLM API를 사용해 리서치 보고서를 작성한다고 하자. 프롬프트 A로 초안을 생성하고, 프롬프트 B로 팩트체크를 요청하고, 프롬프트 C로 요약을 만든다. 각각은 이전에 접근한 적 없는 새로운 요청이다.

• x402 V2: 프롬프트 A, B, C 각각에 온체인 결제가 발생한다. 같은 프롬프트를 다시 보내면 반복 결제를 생략할 수 있지만, 새 프롬프트마다 개별 온체인 트랜잭션이 필요하다.

• MPP: 온체인 트랜잭션으로 세션을 열면, 예치 한도 내에서 A, B, C 모두 오프체인 바우처로 접근할 수 있으며, 세션을 닫을 때 온체인 정산이 이루어진다. 프롬프트를 몇 백 번 호출하든 예치 한도 안에서 온체인은 단 2회다.

에이전트가 하나의 태스크를 수행하는 데 수백 건의 API 호출이 필요하고, 호출마다 온체인 트랜잭션이 발생한다면, 블록체인의 처리량과 수수료가 곧 에이전트의 행동 속도와 비용의 상한선이 된다. MPP의 세션은 온체인 횟수를 요청 수가 아닌 세션 수로 고정함으로써, 이 병목을 프로토콜 레벨에서 제거한다.

3. 레일 중립성: 402 기반 결제 프로토콜은 카드의 경쟁상대가 아니다

3.1 카드 대체론의 오류 : 카드는 결제 수단이 아니라 금융 상품이다

x402를 둘러싼 가장 흔한 내러티브 중 하나는 "스테이블코인이 신용카드를 대체한다"는 것이었다. 이 내러티브를 근거로 x402를 긍정하는 쪽도, 반대로 카드 대체 자체가 비현실적이라며 x402를 통째로 과소평가하는 쪽도 있었다. a16z crypto의 노아 르바인(@nlevine19)은 최근 아티클에서 이를 정면으로 반박했다.

Source: X(@nlevine19)

그의 핵심 논점은 카드가 단순 결제 수단이 아니라는 것이다. 카드는 무담보 신용, 사기 보호, 차지백이 결합된 금융 상품이며, 소비자가 이 보호 장치를 포기할 유인이 낮다. 동시에 카드 네트워크는 소액 결제에도 이미 적응해왔다. 에이전트가 카드를 못 쓴다는 주장도 반박한다. Visa Intelligent Commerce, Mastercard Agent Pay가 이미 토큰 방식으로 에이전트에 카드를 적용하고 있으며, 비자는 이러한 주장에 호응하듯 3월 18일 에이전트용 CLI인 Visa CLI까지 발표했다.

Source: x402.org

또한 x402 프로토콜 자체가 카드 네트워크를 경쟁 상대로 상정한 적도 없다. x402 V2 스펙에 명시되어 있듯, 프로토콜은 카드 네트워크를 퍼실리테이터 형태로 수용하도록 설계됐다. 기술적으로 카드 결제도 가능하다. "카드 대체"는 프로토콜의 설계 의도가 아니라 커뮤니티 일부의 과잉 해석이다.

그렇다면 x402를 포함한 402 기반 결제 프로토콜은 어디서 가치를 포착해야 하는가. 르바인의 답은 '아직 존재하지 않는 가맹점'이다. 웹사이트도, 법인도, 이용약관도 없는 서비스는 기존 프로세서의 심사를 통과할 수 없다. 여기서 스테이블코인은 카드보다 나은 선택이 아니라 유일한 선택이다.

3.2 현실은 멀티레일이다. 그리고 추상화가 필요한 이유

그러나 에이전트가 접근하는 서비스가 전부 '아직 존재하지 않는 가맹점'인 것은 아니다. 에이전트는 카드가 필요한 영역과 스테이블코인이 필요한 영역을 하나의 태스크 안에서 동시에 넘나든다. 그렇다면 에이전트는 어떠한 방식으로 준비해야 하는가? 하나의 예시를 들어보자, 사용자가 "다음 주 출장 준비해줘"라고 말하면, 에이전트는 다음과 같은 절차를 밟을 것이다.

첫째, 항공권이나 호텔 가격 비교를 위해 데이터 API를 수십 번 호출한다($0.001, USDC).

둘째, 최적 조합을 찾으면 항공권을 예약한다($500, 신용카드).

셋째, 확인서를 정리하려고 문서 변환 API를 다시 호출한다($0.01, USDC).

왜 이렇게 나뉘는지 생각해보자. 결제 레일 선택의 기준은 단순히 금액이 아니라 거래의 되돌림 가능성에 대한 요구 수준이다. 항공권 예약은 일정 변경, 결항, 서비스 불만 등 분쟁 가능성이 높고, 차지백이라는 소비자 보호 메커니즘이 경제적 가치를 갖는다. 반면 API 호출은 요청 즉시 리소스가 소비되는 원자적 거래이며, 되돌릴 사유 자체가 구조적으로 존재하지 않는다. $500짜리 API 호출이라도 즉시 소비되는 원자적 거래라면 스테이블코인이 합리적이고, $0.50짜리 구독이라도 환불 분쟁이 예상된다면 카드가 합리적이다.

물론 현실의 레일 선택에는 되돌림 가능성 외에도 규제 관할권, 환율 리스크, 기업의 회계, 세무 처리 같은 변수가 개입한다. 여기서 중요한 것은 개별 기준의 목록이 아니라, 이 복잡한 판단을 에이전트 개발자가 직접 구현해야 한다는 구조적 문제다.

핵심은, 이 멀티레일 전환이 프로토콜 수준에서 추상화되어야 한다는 것이다. 에이전트가 태스크마다 레일을 직접 골라야 한다면, 결제는 에이전트의 행동을 돕는 인프라가 아니라 행동을 가로막는 병목이 된다. 402 기반 결제 프로토콜이 카드를 경쟁 상대로만 바라보는 한, 이 추상화는 실현될 수 없다. MPP는 정확히 이 문제의식 위에 설계됐다.

3.3 레일 중립성을 구현한 MPP의 설계

MPP는 이 402 기반의 결제 흐름 위에서 두 가지 결제 방식을 제공한다. x402가 V2에서 '카드 퍼실리테이터를 수용하겠다'고 선언만 한 부분을, SPT를 기반으로 실제 구현으로 옮긴 것이다.

• tempo.charge() (Rail A): 소액 결제, 온체인 정산

• stripe.charge() (Rail B) : SPT 기반으로 카드, 지갑 등 기존 결제 수단, 스트라이프 레일을 통한 정산

초기화 패턴은 다르지만, 402를 반환하고 결제 요구서를 제시한 뒤, 결제 증명서를 검증하여 리소스를 개방하는 프로토콜 흐름은 완전히 동일하다.

앞선 출장 시나리오로 돌아가 보자. 첫 번째와 세 번째 작업(API 호출)은 스테이블코인 레일(Rail A)을, 두 번째 작업(항공권 예약)은 신용카드 레일(Rail B)을 탄다. 하지만 결제를 수행하는 에이전트가 마주하는 흐름은 셋 다 완벽히 동일하다. '결제 레일의 선택이 프로토콜 수준에서 추상화된다'는 말의 진정한 의미가 바로 여기에 있다.

이러한 MPP의 방향성에서 우리는 템포(Tempo)의 뚜렷한 설계 원칙 하나를 읽을 수 있다. 바로 '크립토가 기존 신용카드를 대체해야 한다'는 웹3 업계의 오랜 강박에서 벗어나는 것이다. x402가 스펙상으로 카드 수용을 선언하고, MPP가 이를 스트라이프 레일로 실제 구현해 냈다는 사실은, 에이전트 결제 생태계가 '카드 vs 스테이블코인'이라는 무의미한 경쟁을 넘어 각자의 특성을 살린 공존의 단계로 진화하고 있음을 보여준다.

이러한 MPP의 방향성에서 우리는 템포의 뚜렷한 설계 원칙 하나를 읽을 수 있다. 바로 '크립토가 기존 신용카드를 대체해야 한다'는 웹3 업계의 오랜 강박에서 벗어나는 것이다. x402가 스펙상으로 카드 수용을 선언하고, MPP가 이를 스트라이프 레일로 실제 구현해 냈다는 사실은, 에이전트 결제 생태계가 '카드 vs 스테이블코인'이라는 프레임 자체를 넘어서고 있음을 보여준다.

그렇다면 각 레일은 어디서 자신의 역할을 갖는가. 수천 개의 독립 에이전트 제공자가 난립하는 롱테일 생태계에서, 카드 결제를 위해 모든 서비스 조합에 대해 가맹점 계약과 배치 정산 파이프라인을 구축하는 것은 비현실적이다. 건당 수수료를 배치 청구로 완화하거나, 플랫폼이 가맹점 역할을 대행해 심사 장벽을 낮출 수는 있지만, 이 해법은 동일 플랫폼 내부에서만 유효하다. 그 경계 바깥, 사전 계약 관계 없는 에이전트 간 즉시 정산이 필요한 지점에서 스테이블코인은 유일한 결제 레일이 된다. 스마트 컨트랙트를 통한 조건부 결제, 즉 결과를 검증한 뒤 지불하는 구조 역시 이 위에서만 자연스럽게 성립한다. 반면, 차지백과 소비자 보호가 필수적인 영역에서는 카드가 여전히 우위를 가진다.

이 두 방향을 하나의 프로토콜 안으로 추상화하는 것. 템포는 MPP를 통해, 레일 중립성을 설계 원칙으로 채택한 결제 인프라의 가능성을 보여주고 있다.

4. x402와 MPP, 경쟁이 아닌 상호보완적 관계로

MPP와 x402를 비교했을 때, 기능만 놓고 보면 극적인 차이를 느끼기 어렵다. 오히려 스트라이프와 템포라는 인프라의 규모와 상징성에 먼저 눈이 갈 것이다. 실제로 MPP의 기능 상당수는 x402 위에서 이미 구현되어 있거나, 제안 단계에서 구현을 앞두고 있다. 멀티레일은 V2의 퍼실리테이터 구조로 수용 가능하고, MPP가 프로토콜 레벨에 내장한 페이먼트 디스커버리(Payments Directory)는 x402에서 디스커버리 레이어의 x402 Bazaar가 이미 같은 역할을 제안하고 있다. MPP가 하는 것 중 x402 생태계 위에서 구현이 불가능한 것은 거의 없다.

차이는 기능의 유무가 아니라, 누구를 위해 어디까지 추상화했느냐에 있다. 스트라이프가 "7줄의 코드로 결제를 붙인다"는 비전으로 인터넷 커머스의 결제 장벽을 허문 것처럼, MPP는 에이전트 개발자가 세션, 멀티레일, 디스커버리를 각각 골라 조립하는 대신 하나의 프로토콜로 바로 쓸 수 있게 만든 것이다. 부품은 이미 x402에 있었다. MPP가 한 일은 그 부품들을 하나의 레이어로 엮어, 개발자가 결제를 신경 쓰지 않아도 되는 세계를 프로토콜 수준에서 실현한 것이다.

가치 포착의 관점에서도 짚어볼 필요가 있다. 스트라이프는 x402도 함께 지원하면서 MPP를 별도 프로토콜로 만들었다. x402가 코인베이스 주도인 이상, 스트라이프가 자체 프로토콜을 갖는 것은 에이전트 결제 트래픽의 가치가 자사 생태계 안에서 포착되도록 하려는 플랫폼 전략이기도 하다. x402 위에서 베이스(Base), 솔라나(Solana) 등 L1들이 자신의 네트워크를 정산 레이어로 온보딩하며 트랜잭션 활성화를 꾀한 것과 같은 논리다. 스트라이프는 카드, 지갑 등 기존 결제 수단을 SPT로 묶어 자사 결제망 위에서 처리하게 함으로써, 에이전트 경제의 정산 허브를 목표로 하고 있다. 실제로 스트라이프 레일을 경유하는 모든 에이전트 결제에는 스트라이프의 표준 수수료가 그대로 적용된다. MPP의 추상화가 기술적으로 유효하다는 것과, 그 추상화가 만들어내는 가치를 누가 쥐느냐는 별개의 문제다.

그렇다면 이 가치를 둘러싼 구도에서 두 프로토콜은 각각 어디를 향하는가. x402는 오픈소스 커뮤니티에서 개발자들이 자유롭게 확장을 제안하고 쌓아 올리는 바텀업 구조다. MPP는 스트라이프와 템포가 기업이 현장에서 부딪히는 페인포인트—세션 정산, 멀티레일 전환, 서비스 디스커버리—를 프로토콜 레벨에서 미리 해결해 내려주는 탑다운 구조다. 같은 402 위에 서 있지만, x402는 개발자 커뮤니티를 향하고 MPP는 기업의 결제 인프라를 향한다. 이 방향성의 차이는 경쟁이 아니라 사실상 분업에 가깝다. 그리고 이 분업이 작동한다면, 에이전트 개발자가 마주하는 최종 경험은 단순해진다. 프로토콜이 레일을 선택하고, 세션이 서비스별 정산을 묶는다. 에이전트는 그저 API를 호출하고 결과를 받을 뿐이다.

그러나 분업만으로는 충분하지 않다. 에이전트 경제가 실험을 넘어 실질적 어답션에 도달하려면, 둘 중 하나가 혁신적 구조를 내놓으면 다른 하나가 이를 흡수하고 발전시키는 플라이휠이 필요하다. MPP가 x402의 402 흐름을 계승한 것이 첫 번째 사례라면, 다음은 x402가 MPP의 세션 모델이나 멀티레일 구조를 흡수하는 것일 수 있다. 이처럼 한쪽이 더 효율적인 구조를 제시할 때마다 다른 한쪽이 이를 수용하고 진화하는 흐름이 반복될 수 있고, 더 나아가 제3의 402 기반 프로토콜이 등장해 양쪽의 발전을 함께 견인하는 시나리오도 충분히 가능하다. 이 플라이휠이 실제로 돌아가느냐가 402 기반 에이전트 결제의 미래를 가른다고 생각한다.