AI 에이전트(AI agents)는 웹을 검색하고, API를 호출하며, 문서를 분석하고, 보고서를 생성하며, 다단계 워크플로(workflows)를 조정할 수 있습니다. 하지만 많은 에이전트 워크플로가 유료 리소스에 도달하면 중단됩니다.

전통적인 결제 시스템은 인간을 위해 설계되었습니다. 이러한 시스템은 종종 사용자가 계정을 생성하고, 플랜을 선택하고, 결제 정보를 입력하고, 인증을 완료하며, 리다이렉트(redirects)를 거치도록 요구합니다.

자율 에이전트(autonomous agent)에게는 기계가 읽을 수 있는(machine-readable) 대안이 필요합니다.

에이전트는 다음과 같은 작업을 수행할 수 있어야 합니다:

• 리소스에 결제가 필요함을 발견
• 가격 및 지원되는 결제 수단을 이해
• 구매 허용 여부를 결정
• 결제를 승인
• 결제 완료를 증명
• 요청한 리소스에 접근

머신 결제 프로토콜(Machine Payments Protocol), 즉 MPP는 일반적인 HTTP 요청을 통해 이 프로세스를 처리하는 표준화된 방법을 도입합니다.

MPP는 2026년 3월 Stripe와 Tempo가 공동 작성한 개방형 표준으로 출시되었습니다. 이는 에이전트와 온라인 서비스가 API, 콘텐츠, 도구 및 기타 HTTP 주소 지정이 가능한 리소스에 대해 프로그래밍 방식으로 결제를 조정할 수 있도록 합니다. ([Stripe][1])

그 핵심 흐름은 세 가지 객체를 중심으로 구축됩니다:

Challenge → Credential → Receipt

이 흐름이 결제 자격 증명(payment credentials)을 인증하고 유료 리소스에 대한 접근 권한을 부여하기 위해 HTTP 402 Payment Required를 어떻게 사용하는지 살펴보겠습니다.

전통적인 API 과금 방식이 충분하지 않은 이유

대부분의 유료 API는 다음 모델 중 하나를 사용합니다:

• 계정을 생성하고 구독(subscription) 구매
• 요청을 보내기 전에 카드 추가
• 크레딧(credits) 선불 충전
• 엔터프라이즈 계약 협상
• 과금 계정에 연결된 API 키 수령

이러한 접근 방식은 인간이 제어하는 반복적인 사용에는 잘 작동합니다. 하지만 에이전트가 이전에 사용해 본 적 없는 서비스로부터 하나의 작은 리소스를 구매해야 할 때는 적합하지 않습니다.

단 하나의 프리미엄 시장 보고서가 필요한 AI 연구 에이전트를 가정해 봅시다.

이 에이전트에게는 다음과 같은 것들이 필요하지 않을 수 있습니다:

• 월간 구독
• 영구적인 계정
• 긴 온보딩(onboarding) 과정
• 수동으로 생성된 API 키

단지 보고서의 가격을 확인하고, 결제하며, 그 결과를 받기만 하면 됩니다.

Stripe는 MPP를 에이전트(agent)의 리소스 요청의 일부로서 서비스가 결제를 요청할 수 있는 인터넷 네이티브 프로토콜 (internet-native protocol)로 설명합니다. 이는 마이크로 트랜잭션 (microtransactions) 및 반복 결제 (recurring payments)와 같은 머신 지향적 비즈니스 모델을 지원할 수 있습니다. ([Stripe][1])

Stripe MPP란 무엇인가?

MPP는 머신 간 (machine-to-machine) 인터넷 결제를 위한 프로토콜입니다.

클라이언트가 유료 리소스를 요청하면, 서버는 결제 요구 사항을 포함하는 HTTP 402 응답을 반환합니다. 클라이언트는 결제를 승인하고, 결제 자격 증명 (payment credential)과 함께 요청을 재시도하며, 검증이 성공하면 영수증과 함께 보호된 리소스를 받습니다.

전체 흐름은 다음과 같습니다:

에이전트가 보호된 리소스를 요청함
             ↓
서버가 402 Payment Required를 반환함
...

MPP는 모든 제공업체가 하나의 특정 결제 망 (payment rail)을 사용할 것을 요구하지 않습니다. 이 프로토콜은 클라이언트와 서버가 결제 요구 사항을 전달하는 방식을 표준화하는 반면, 실제 자금의 이동은 결제 수단 (payment methods)이 처리합니다.

Stripe의 현재 MPP 통합은 온체인 (on-chain) 입금 주소를 통한 암호화폐 결제와 공유 결제 토큰 (Shared Payment Tokens)을 통한 법정 화폐 (fiat) 결제 수단을 지원합니다.

1단계: 에이전트가 유료 리소스를 요청함

제공업체가 다음과 같은 엔드포인트 (endpoint)를 노출한다고 가정해 보겠습니다:

GET /api/reports/market-analysis

에이전트는 일반적인 요청을 보냅니다:

GET /api/reports/market-analysis HTTP/1.1
Host: reports.example.com
Accept: application/json

서버는 요청에 유효한 결제 자격 증명이 포함되어 있는지 확인합니다.

이것이 첫 번째 요청이기 때문에 사용 가능한 자격 증명이 없습니다. 서버는 보고서를 반환하는 대신 402 Payment Required로 응답합니다.

2단계: 서버가 HTTP 402 챌린지를 반환함

응답은 개념적으로 다음과 같이 보일 수 있습니다:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment challenge="..."
Cache-Control: no-store
...

{
  "status": 402,
  "title": "Payment Required",
...

WWW-Authenticate 헤더는 MPP **Challenge (챌린지)**를 전달합니다.

Challenge는 보호된 리소스(protected resource)를 얻기 위해 무엇을 수행해야 하는지 클라이언트에게 알려줍니다. 여기에는 다음과 같은 정보가 포함될 수 있습니다:

• 결제 금액 (Payment amount)
• 통화 (Currency)
• 결제 수단 (Payment method)
• 결제 의도 (Payment intent)
• 리소스 범위 (Resource scope)
• 만료 세부 정보 (Expiration details)
• Challenge 식별자 (Challenge identifier)

MPP는 이러한 Challenge–Credential–Receipt 모델을 통해 HTTP 402를 표준화합니다. ([MPP — Machine Payments Protocol][2])

서버가 하나 이상의 결제 수단을 허용하는 경우, 여러 개의 결제 챌린지를 반환할 수도 있습니다. Stripe의 퀵스타트(quickstart)는 암호화폐(crypto)와 법정 화폐(fiat) 결제 옵션을 모두 제공하는 엔드포인트를 시연하며, 클라이언트가 지원되는 방식을 선택할 수 있도록 합니다.

핵심적인 개선 사항은 이제 가격을 머신이 읽을 수 있는(machine-readable) 형태로 제공한다는 점입니다. 에이전트(agent)가 가격 페이지를 스크래핑하거나 체크아웃 인터페이스를 이해할 필요가 없습니다.

Step 3: 에이전트가 Challenge를 평가함

402 응답을 받는 것이 에이전트가 자동으로 결제해야 함을 의미해서는 안 됩니다.

결제를 승인하기 전에, 에이전트는 자신의 지출 정책(spending policy)을 평가해야 합니다:

이 제공업체는 신뢰할 수 있는가?
요청된 금액이 예산 범위 내에 있는가?
이 구매가 현재 작업을 지원하는가?
...

기본적인 정책은 다음과 같을 수 있습니다:

type PaymentChallenge = {
  amount: number;
  currency: string;
...

가치가 높거나 민감한 거래의 경우, 에이전트는 진행하기 전에 사람(human)에게 승인을 요청할 수 있습니다.

MPP는 결제 통신을 조정합니다. 에이전트를 제어하는 애플리케이션은 지출 한도, 가맹점 제한 및 승인 정책에 대한 책임을 계속 유지합니다.

Step 4: 에이전트가 Payment Credential을 생성함

결제를 승인한 후, 클라이언트는 사용 가능한 결제 수단 중 하나를 사용하여 Challenge를 충족합니다.

그 후 MPP **Credential (자격 증명)**을 생성하고 원래의 요청을 재시도합니다:

GET /api/reports/market-analysis HTTP/1.1
Host: reports.example.com
Accept: application/json
...

자격 증명 (Credential)은 챌린지 (Challenge)에 대한 클라이언트의 응답입니다. 이는 필요한 결제가 완료되었거나 적절하게 승인되었음을 증명합니다. MPP 자격 증명 (MPP Credentials)은 HTTP Authorization 헤더를 사용하여 전송됩니다. ([MPP — Machine Payments Protocol][3])

자격 증명 (Credential)은 다음과 같은 세부 정보를 포함하여 원래의 결제 조건과 일치해야 합니다:

• 챌린지 (Challenge)
• 금액 (Amount)
• 통화 (Currency)
• 대상 리소스 (Intended resource)
• 결제 수단 (Payment method)
• 요청 범위 (Request scope)

자격 증명 (Credential)을 챌린지 (Challenge)에 바인딩 (Binding)하면, 특정 리소스를 위해 의도된 결제가 관련 없는 다른 리소스에 대한 승인으로 처리되는 것을 방지할 수 있습니다.

단계 5: 서버가 자격 증명을 인증함

서버가 두 번째 요청을 받으면, 결제 자격 증명 (Payment Credential)을 검증합니다.

이것이 MPP 흐름의 인증 (Authentication) 부분입니다.

서버는 실질적으로 다음과 같이 질문합니다:

이것이 이 요청을 위해 발행된 챌린지 (Challenge)를 충족하는 유효한 결제 자격 증명 (Payment Credential)인가?

개념적으로 검증은 다음과 같이 보일 수 있습니다:

type VerificationInput = {
  credential: string;
  expectedAmount: string;
...

MPP의 서버 API는 요청 파라미터 (Request parameters), 메타데이터 (Metadata), 리소스 범위 (Resource scope)를 포함하여 원래의 챌린지 (Challenge)로부터 기대되는 값들과 자격 증명 (Credential)을 비교합니다. ([MPP — Machine Payments Protocol][4])

서버는 다음 사항들을 검증할 수 있습니다:

• 자격 증명 (Credential)의 형식이 올바른지
• 예상된 챌린지 (Challenge)를 위해 생성되었는지
• 결제 금액이 정확한지
• 통화 (Currency)가 일치하는지
• 자격 증명 (Credential)이 요청된 리소스에 적용되는지
• 결제가 성공했는지
• 자격 증명이 여전히 유효한지
• 부적절하게 재사용되지 않았는지

MPP 명세 (Specification)는 자격 증명 (Credentials)이 특정 요청에 대해 유효한 것으로 기술하며, 이를 통해 결제 승인 (Payment authorization)의 범위를 좁게 유지할 수 있도록 돕습니다. ([MPP — Machine Payments Protocol][3])

단계 6: 결제 검증이 리소스 접근을 승인함

서버가 자격 증명 (Credential)을 검증하면, 결제된 리소스에 대한 접근을 승인할 수 있습니다:

유효한 결제 자격 증명 (Credential)
↓
결제 조건 충족 (Payment condition satisfied)
...

자격 증명 (Credential)이 누락되었거나 유효하지 않은 경우:

누락되었거나 유효하지 않은 자격 증명 (Credential)
↓
결제 조건 미충족 (Payment condition not satisfied)
...

Stripe의 퀵스타트 (quickstart)는 이 패턴을 따릅니다. 엔드포인트는 유효한 자격 증명 (Credential)이 없을 때 402 응답을 반환하며, 들어오는 결제 정보가 성공적으로 검증된 후에만 접근을 허용합니다.

단순화된 엔드포인트는 다음과 같은 모습일 수 있습니다:

export async function getPremiumReport(
  request: Request
): Promise<Response> {
...

이는 예시용 의사코드 (pseudocode)이지만, 서버의 주요 책임을 나타냅니다:

1. 챌린지 (Challenge) 발행
2. 자격 증명 (Credential) 수신
3. 결제 검증
4. 접근 권한 부여
5. 영수증 (Receipt) 반환

7단계: 서버가 결제 영수증을 반환함

검증이 성공하면, 서버는 리소스와 MPP **영수증 (Receipt)**을 반환합니다:

HTTP/1.1 200 OK
Content-Type: application/json
Payment-Receipt: ...

{
  "report": {
    "industry": "AI infrastructure",
...

영수증 (Receipt)은 결제의 결과를 기록하고 챌린지-자격 증명-영수증 (Challenge–Credential–Receipt) 흐름을 완료합니다. ([
MPP — Machine Payments Protocol
][2])

이는 클라이언트에게 다음과 같은 도움을 줄 수 있습니다:

• 구매 기록
• 지출을 에이전트 작업과 연결
• 트랜잭션 대조 (Reconcile)
• 에이전트 활동 감사 (Audit)
• 결제 실패 문제 해결
• 실수로 인한 중복 구매 방지

최종적인 교환 과정은 다음과 같습니다:

GET 보호된 리소스 (protected resource)
        ↓
402 + 챌린지 (Challenge)
...

MPP에서 "인증 (Authentication)"의 의미

전통적인 애플리케이션 보안에서 인증 (authentication)은 보통 다음 질문에 답합니다:

이 요청을 수행하는 주체는 누구인가?

예시로는 다음과 같은 것들이 있습니다:

• 비밀번호 및 패스키 (passkeys)
• API 키 (API keys)
• OAuth 액세스 토큰 (access tokens)
• 서명된 신원 토큰 (Signed identity tokens)
• 엔터프라이즈 싱글 사인온 (Enterprise single sign-on)

MPP 인증 (authentication)은 더 좁은 범위의 질문에 답합니다:

이 결제 자격 증명 (Credential)이 이 결제 챌린지 (Challenge)에 대해 유효한가?

유효한 MPP 자격 증명 (Credential)이 반드시 증명하는 것은 아닙:

• 에이전트 운영자의 법적 신원 (Legal identity)
• 어떤 직원이 요청을 시작했는지
• 어떤 조직이 에이전트를 소유하고 있는지
• 에이전트가 고객 계정에 접근할 수 있는지 여부
• 사람이 트랜잭션을 승인했는지 여부

MPP는 결제 증명 (Payment proof)을 인증하는 것이지, 에이전트 뒤에 있는 완전한 현실 세계의 신원을 인증하는 것이 아닙니다.

MPP에서 “권한 부여 (Authorization)”의 의미

MPP는 검증된 결제를 권한 부여 조건 (Authorization condition)으로 사용합니다.

서비스는 다음과 같이 말하는 것입니다:

필요한 결제가 검증되었을 때 이 리소스에 대한 접근 권한이 부여됩니다.

하지만 결제가 유일한 권한 부여 요구 사항이 되는 경우는 드물어야 합니다.

프로덕션 서비스는 다음과 같은 사항을 평가해야 할 수도 있습니다:

const canAccessResource =
  identityIsValid &&
  tenantMatches &&
...

예를 들어, 재무 보고서에 대한 비용을 지불한다고 해서 에이전트가 다른 회사의 비공개 재무 데이터를 자동으로 볼 수 있게 해서는 안 됩니다.

서비스에는 여전히 다음과 같은 사항이 필요할 수 있습니다:

• 인증 (Authentication)
• 테넌트 격리 (Tenant isolation)
• 역할 기반 액세스 제어 (RBAC)
• 데이터 권한 (Data permissions)
• 지역 제한 (Regional restrictions)
• 사용량 제한 (Usage limits)
• 컴플라이언스 체크 (Compliance checks)

MPP는 결제 기반의 권한 부여를 제공합니다. 이는 애플리케이션의 더 넓은 보안 모델을 대체하는 것이 아닙니다.

MPP vs OAuth, API Keys, 및 RBAC

이러한 메커니즘들은 서로 다른 질문에 답합니다:

유료 API는 여러 계층을 함께 사용할 수 있습니다:

OAuth
  → 에이전트와 그 권한을 식별함

...

성공적인 머신 결제가 신원 또는 권한 확인을 우회해서는 안 됩니다.

Stripe MPP가 해결하는 문제

MPP는 다음과 같은 항목에 대해 머신에 직접 비용을 청구하고자 하는 서비스에 특히 유용합니다:

• API 호출 (API calls)
• MCP 도구 호출 (MCP tool calls)
• 프리미엄 콘텐츠 (Premium content)
• 데이터 검색 (Data retrieval)
• 문서 생성 (Document generation)
• AI 추론 (AI inference)
• 브라우저 자동화 (Browser automation)
• 컴퓨팅 리소스 (Compute resources)
• 사용량 기반 서비스 (Usage-based services)

Stripe의 출시 사례에는 에이전트가 프로그래밍 방식의 결제 흐름 (Programmatic payment flows)을 통해 브라우저 세션, API 기반 웹 접속, 물리적 우편 및 기타 서비스에 대해 비용을 지불하는 예시가 포함되었습니다. ([Stripe][1])

MPP는 모든 머신 고객(machine customer)이 사전에 결제 관계(billing relationship)를 설정하도록 요구하는 대신, API 상호작용의 일부로 결제를 수행할 수 있게 합니다.

MPP가 해결하지 못하는 것

MPP를 완전한 에이전트 보안 프레임워크(agent-security framework)로 취급해서는 안 됩니다.

MPP는 다음 사항들을 자동으로 제공하지 않습니다:

에이전트 신원 (Agent identity)

유효한 결제 자격 증명(Credential)이 반드시 에이전트를 제어하는 주체가 누구인지를 식별하는 것은 아닙니다.

애플리케이션 권한 (Application permissions)

결제가 해당 에이전트가 특정 계정, 사용자, 조직 또는 레코드에 접근할 권한이 있음을 증명하지는 않습니다.

지출 거버넌스 (Spending governance)

에이전트 운영자는 여전히 거래 한도, 승인된 가맹점, 예산 규칙 및 인간의 승인 임계값(human-approval thresholds)을 강제해야 합니다.

비즈니스 규칙 검증 (Business-rule validation)

결제가 제품 가용성, 계약상 제한 사항, 컴플라이언스(compliance) 규칙 또는 계정 상태를 우회해서는 안 됩니다.