Molayo

© 2026 Molayo

Qiita헤드라인2026. 06. 23. 19:54

AI 에이전트가 "스스로 결제"하는 메커니즘: Stripe MPP의 정체는 HTTP 402

요약

Stripe가 AI 에이전트를 위한 새로운 결제 프로토콜인 MPP(Machine Payments Protocol)를 발표했습니다. HTTP 402 상태 코드를 활용하여 에이전트가 API 요청 과정에서 직접 극소액 결제를 수행할 수 있도록 설계되었습니다.

핵심 포인트

  • HTTP 402(Payment Required) 코드를 결제 신호로 활용
  • 에이전트의 특성에 맞춘 극소액·고빈도 결제 최적화
  • 암호화폐(Tempo)와 카드(SPT) 결제 경로를 통합 제공
  • 시한부 토큰(SPT)을 통한 에이전트 결제 권한 및 범위 제한

「현재의 금융 시스템은 인간을 위해 만들어졌다. 그래서 AI 에이전트에게는 사용할 수 없다. 그렇다면 다시 만들겠다」 —— 결제 대기업인 Stripe가 단언하며 내놓은 것이, AI 에이전트용 결제 프로토콜인 **Stripe MPP(Machine Payments Protocol, 기계 결제 프로토콜)**다. 블록체인 기업인 Tempo와 공동으로 책정하여, 2026년 3월 18일에 출시했다.

새로운 점은, 「인간이 화면을 조작하여 결제한다」는 전제였던 결제를, 「프로그램이 HTTP 주고받기만으로 결제한다」는 전제로 재편했다는 점에 있다. 결제 전문 분야가 아니더라도, API를 외부에 공개하고 있다면 언젠가 그 과금 대상에 AI 에이전트가 포함될 것이다.

온라인 쇼핑은 계정 생성, 카드 입력, 확인 버튼 클릭 등 인간의 조작을 전제로 한다. 자율적으로 움직이는 에이전트에게는 매 단계마다 인력이 필요한 장벽이 된다.

또 다른 문제는 돈의 장벽이다. 기존의 카드 결제는 대략 결제 금액의 2.9%에 건당 0.30달러를 더한 수수료가 발생한다. 에이전트는 「API 1회당 수 센트」 수준의 극소액 결제를 대량으로 처리하기 때문에, 1달러 미만에서는 수수료가 대금을 상회하게 된다. MPP는 이 「인간 전제」와 「극소액·고빈도」라는 두 가지 괴리를 HTTP 레벨에서 해결하려고 한다.

MPP의 핵심은 오랫동안 「예약됨·미사용」 상태로 잠들어 있던 HTTP 상태 코드(Status Code) **402 Payment Required(결제 필요)**를 실제 결제의 신호로 다시 사용하는 데 있다. 페이지를 찾을 수 없을 때 404가 반환되는 것과 같은 메커니즘으로, 결제가 필요하다면 402가 반환된다는 발상이다.

상호작용은 요청(Request)마다 완결된다.

  • 에이전트가 유료 데이터나 API를 결제 없이 요청한다.
  • 서버가 402를 반환하며, 「얼마를 어떤 방법으로 지불해야 하는지」를 전달한다.
  • 에이전트가 결제를 승인하고, 인증 정보를 첨부하여 동일한 요청을 재전송한다.
  • 서버가 영수증(Receipt)을 포함하여 데이터 본체를 반환한다.

계정 생성도 구독 계약도 필요 없다. 또한 「세션 단위로 묶는다」는 해설도 보이지만, 공식적으로 정해진 것은 요청 단위의 과금이며 거래를 묶는 메커니즘은 없다.

비슷한 이름이 이어지므로, 여기서 주인공인 4가지 용어를 정리해 둔다. MPP = 결제의 약속(프로토콜, 주인공), Tempo = 암호자산(스테이블코인)으로 결제하는 경로(Rail), SPT = 카드로 결제하는 경로(Rail), mppx = 구현에 사용하는 라이브러리.

MPP는 성격이 다른 두 가지 경로를 통합하여, 에이전트가 대응할 수 있는 쪽을 선택한다.

경로적합한 결제메커니즘
Tempo(암호)저단가·고빈도스테이블코인을 통한 블록체인 상의 결제
SPT(카드)폭넓은 결제 수단 대응Stripe의 기존 카드 결제 경로

카드 측의 **SPT(Shared Payment Tokens)**는 안전성의 핵심이다. 생(Raw) 카드 번호를 전달하는 대신, 「이 상대에게, 언제까지, 얼마만큼」과 같이 범위를 제한한 시한부 토큰을 발행한다. 사람이 상한선과 상대를 미리 승인해 두면, 에이전트는 그 범위 내에서만 결제할 수 있다. 권한을 제한하는 OAuth 스코프(Scope)의 결제 버전이라고 생각하면 된다. 암호 결제에 특화된 경쟁사 x402(Coinbase)가 암호 자산 하나에 집중하는 것에 반해, MPP는 암호와 카드의 두 경로를 통합할 수 있다는 점이 특징이다.

두 경로를 통합하는 흐름을 먼저 개념 코드로 살펴본다. 아래는 메커니즘을 파악하기 위한 스케치이며, 실제 동작하는 정확한 API 명칭이나 인수는 공식 구현 예시(docs.stripe.com/payments/machine/mpp)를 참조하기 바란다.

import * as mppx from 'mppx/server';
const PRICE_USDC = "0.01"; // 암호 경로의 결제 금액(반올림 오차를 피하기 위해 문자열로 전달)
const PRICE_CARD = "0.50"; // 카드 경로의 결제 금액
...

요점은 compose에 두 경로를 나열하는 것만으로, 「미결제 시 402, 결제 완료 시 영수증과 함께 배포」까지를 하나의 함수가 담당한다는 점이다. 길어 보이는 코드도 실제로 하는 일은 이 몇 줄로 요약된다.

실제로 402 상호작용을 직접 실행해 보려면, mppx의 CLI가 testnet(테스트용 네트워크)만으로 완결된다.

npx mppx account create # 테스트용 계정 생성
npx mppx account fund # testnet 자금 충전
npx mppx http://localhost:4242/paid # 402를 수신하여 결제 및 리소스 획득

카드 측에서 "이 상대에게 얼마까지 한도를 부여할지"를 미리 승인하는 SPT(Shared Payment Token) 발행은 또 다른 CLI를 통해 수행한다.

npx @stripe/link-cli spend-request create --amount 100 --request-approval # 한도와 상대를 사전 승인

이미 실서비스에서 운영 중인 대표적인 사례는 Parallel Web Systems(미국)다. 에이전트(Agent)를 위해 Web 액세스 API를 제공하는 회사로, 창업자는 전 Twitter CEO인 Parag Agrawal이다. 에이전트는 API를 호출할 때마다 자율적으로 결제한다. "1회 호출 = 1단위의 가치"로 과금하는, MPP(Machine Payments Protocol)다운 방식이다.

Stripe의 공식 블로그는 그 외에도 브라우저 조작 기반인 Browserbase, 물리적 우편 발송 서비스인 PostalForm, 뉴욕의 정육점인 Prospect Butcher Co.를 실제 사례로 꼽는다. 카드 네트워크 측에서도 Visa가 카드 버전의 MPP 사양과 SDK를 공개했다.

다만 주의할 점도 있다. 출시 당시 100개 이상의 기업이 협력 파트너로 이름을 올렸으나, 그중 상당수는 의향 표명(Letter of Intent) 단계로 실제 운영까지는 거리가 있다. 1차 정보(Primary source)를 통해 실제 이용을 확인할 수 있는 곳은 Stripe가 직접 명시한 몇몇 기업에 국한된다.

Stripe MPP는 인간을 위해 만들어진 결제 방식을, 이미 검증된 HTTP 402 위에서 에이전트용으로 재구성한 프로토콜이다. 결제는 요청(Request) 단위로 완결되며, 암호(Tempo)와 카드(SPT)를 구분하여 사용하고, 서버 측에서는 단 몇 줄의 코드와 CLI만으로 테스트할 수 있다.

자사 API를 공개하고 있거나 수탁(Contract) 형태로 API를 납품하는 사람이라면, 그 과금 대상에 에이전트가 포함될 날이 머지않았을지도 모른다. 에이전트가 물건이나 서비스를 사고파는 경제(Agentic Commerce)는 이제 막 시작되었다. 우선 손안의 testnet에서 402 상호작용을 한 번 실행해 본다면, "기계가 돈을 지불한다"는 감각을 직접 체감할 수 있을 것이다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0