AI 에이전트가 API 비용을 자동으로 결제하는 Stripe 기반 마켓플레이스를 구축했습니다

몇 주 전, Stripe는 AI 에이전트가 결제 수단을 보유하고 프로그래밍 방식으로 돈을 사용할 수 있는 방법인 Agent Toolkit을 출시했습니다. 저는 이 발표를 읽고 즉시 다음과 같은 생각을 했습니다. '에이전트가 실제로 이 돈을 쓸 수 있는 곳이 어디에도 없다.'

그래서 제가 직접 만들었습니다. 이것은 그 과정과 기술적 결정, 그리고 그 과정에서 마주했던 막다른 길들에 대한 이야기입니다.

문제점

AI 에이전트는 페이지 스크래핑, 전화번호 검증, PDF 생성 등 외부 서비스를 호출해야 할 필요성이 점점 커지고 있습니다. 오늘날 이를 연결하는 개발자에게는 다음 세 가지 중 하나를 선택해야 함을 의미합니다:

• 에이전트가 필요로 할 수 있는 모든 서비스에 대해 API 키를 하드코딩(Hardcode)하기
• 제공자별로 맞춤형 결제 통합(Billing integration) 구축하기
• 에이전트가 몇 번 호출하지 않는 서비스들을 위해 늘어나는 구독 목록을 관리하기

이 중 어느 것도 에이전트 네이티브(Agent-native) 방식이 아닙니다. 작업을 수행하는 도중에 특정 기능이 필요하다는 것을 발견한 에이전트가 제공자를 찾고 정확히 사용한 만큼만 결제할 수 있는 표준화된 방법이 없습니다.

**MCP (Model Context Protocol)**는 이 문제의 절반을 해결합니다. 즉, 에이전트가 도구를 발견하고 호출하는 방식을 표준화합니다. Stripe Agent Toolkit은 나머지 절반을 해결합니다. 에이전트가 실제로 무언가에 대해 결제할 수 있게 해줍니다. 하지만 아무도 이 두 가지를 실제 마켓플레이스로 연결하지 않았습니다. 그것이 바로 run.pay입니다.

작동 방식

두 개의 측면, 하나의 백엔드:

**판매자(Sellers)**는 호출당 가격이 책정된 서비스로서 모든 API를 게시합니다. 스크래퍼, 검증기, JSON을 반환하는 것이라면 무엇이든 가능합니다.

**에이전트(Agents)**는 MCP 엔드포인트를 통해 한 번만 연결하면 전체 카탈로그를 자동으로 발견합니다:

{
  "mcpServers": {
    "runpay": {
...

그다음부터는 서비스를 호출하고 결제하는 것이 하나의 요청으로 이루어집니다:

curl -X POST https://runpay-backend-visibility-production.up.railway.app/api/call/SERVICE_ID \ 
  -H "Content-Type: application/json" \ 
  -d '{"agent_id":"my-agent","payload":{"phone":"+33612345678"}}'

Stripe가 에이전트에 연결된 카드로 비용을 청구하면, 요청이 판매자의 엔드포인트(endpoint)로 전달되고 결과가 돌아옵니다. 판매자는 Stripe Connect를 통해 대금을 지급받습니다. 그 누구도 대시보드에 접속할 필요가 없습니다.

아키텍처 (The architecture)

의도적으로 매우 단순하게 구성했습니다. 단순함이 곧 신뢰성입니다:

• 백엔드 (Backend): Railway 기반의 Node.js + Express
• 데이터베이스 (Database): PostgreSQL (마찬가지로 Railway 사용)
• 결제 (Payments): 지급을 위한 Stripe Connect, 호출당 과금을 위한 Payment Intents API 기반의 커스텀 래퍼 (custom wrapper)
• 디스커버리 (Discovery): list_services와 call_service를 도구(tools)로 노출하는 표준 MCP 서버
• 이메일 (Email): 공급업체 온보딩 및 판매 알림을 위한 Resend

흥미로운 점은 개별 구성 요소가 아니라, 자율적인 (autonomous) 호출자를 위해 결제 흐름이 어떻게 작동해야 하는가 하는 점입니다.

무엇이 문제였고, 왜 그랬는가

Stripe의 최소 결제 금액

처음에는 Twilio나 AbstractAPI가 하는 방식처럼 호출당 1센트 미만의 아주 작은 금액으로 서비스를 책정하려 했습니다. 이는 최종 사용자에게 적합한 가격이지만, Stripe는 최소 결제 금액(통화에 따라 약 $0.50)을 강제하며, 그 외에도 거래당 고정 수수료를 부과합니다. 호출당 $0.01를 청구하면 Stripe 수수료만으로도 손해를 보게 됩니다.

v1을 위한 해결책은 실용적이었습니다. 서비스 가격을 $0.60 이상으로 책정하여, 단 한 번의 Stripe 결제로 최소 금액을 충족하고 수수료가 낮은 비율로 유지되도록 했습니다. 이것이 장기적인 정답은 아닙니다. 크레딧 기반 시스템(한 번의 거래로 $10의 크레딧을 구매하고, 호출당 1센트 미만의 금액을 차감하는 방식)이 진정한 해결책이며, 이는 로드맵의 다음 단계에 있습니다. 하지만 이를 구현했다면 출시가 몇 주간 지연되었을 것이고, 첫날부터 단위 경제성 (unit economics)을 완벽하게 맞추는 것보다 작동하는 호출당 결제 (pay-per-call) 루프를 사람들에게 선보이는 것이 더 중요했습니다.

실패한 호출에 대한 자동 환불

판매자의 엔드포인트(endpoint)가 타임아웃(timeout)되거나 500 에러를 반환하면, 에이전트(agent)는 이미 비용이 청구된 상태입니다. 실패한 원인이 에이전트의 잘못이 아님에도 "죄송합니다, 환불은 불가합니다"라는 상황은 결코 용납될 수 없습니다. 따라서 /api/call/:id는 판매자 요청을 try/catch로 감싸며, 에러가 에이전트에 도달하기도 전에 2xx가 아닌 응답이나 타임아웃이 발생할 경우 Stripe 자동 환불을 트리거합니다. 이를 통해 에이전트는 아무런 대가 없이 비용만 지불되는 상황 대신, refunded: true가 포함된 깔끔한 실패 상태를 확인하게 됩니다.

단일 도구가 아닌 마켓플레이스를 위한 MCP 인터페이스 설계

제가 살펴본 대부분의 MCP 서버는 고정된 도구 세트를 노출합니다. 즉, 하나의 서버가 하나의 기능만을 담당하는 구조입니다. 하지만 마켓플레이스는 다른 형태가 필요합니다. 동적인 서비스 ID를 받는 하나의 안정적인 도구(call_service)와, 현재 카탈로그에 포함된 내용을 반환하는 탐색 도구(list_services)가 필요합니다. 벤더(vendor)들이 합류함에 따라 카탈로그는 계속 변하지만, MCP 인터페이스 자체는 변경될 필요가 없어야 합니다. 이 차이를 정확히 구현하기까지 몇 번의 시행착오를 겪었습니다. 초기 버전에서는 서비스마다 새로운 MCP 도구를 생성하려고 시도했는데, 이는 서비스가 50개 정도가 되면 에이전트의 컨텍스트 윈도우(context window)가 호출할 일도 없는 도구 정의들로 가득 차버리는 문제로 이어졌습니다.

현재 진행 상황

현재 전화번호 유효성 검사, 웹 스크래핑(web scraping), PDF 생성, 스크린샷 캡처, 그리고 이 중 몇 가지의 배치(batch) 변형 버전을 포함하여 총 6개의 서비스가 운영 중입니다. 실제 Stripe 트랜잭션 하나가 전체 루프를 성공적으로 통과했습니다: 결제, 호출, 실패 시 환불 로직(실제 화가 날 만한 상황에서 테스트되지는 않았지만 다행인 부분), 그리고 2초 이내에 에이전트로 결과가 반환되었습니다.

이제 더 어려운 문제는 기술적인 것이 아니라, 모든 마켓플레이스가 겪는 전형적인 콜드 스타트 문제 (cold-start problem)입니다. 판매자는 자신을 호출하는 에이전트가 하나도 없는 곳에 서비스를 등록하지 않을 것이고, 에이전트는 서비스가 하나도 없는 마켓플레이스를 통합할 이유가 없습니다. 저는 지난 일주일 동안 화려하지는 않지만 꼭 필요한 작업들을 수행했습니다. 카탈로그를 채우기 위해 직접 서비스를 구축하고, 이미 수익화할 가치가 있는 것을 보유한 MCP 서버 유지 관리자들에게 수동으로 연락을 취하며, Smithery와 awesome-mcp-servers 리스트에 인덱싱되도록 노력했습니다.

유사한 것을 구축하려는 사람에게 해주고 싶은 말

Stripe의 경제 모델을 먼저 고려하고, 당신의 이상적인 경제 모델은 그다음으로 고려하세요. 저는 사전에 Stripe의 문서를 더 주의 깊게 읽는 대신, 운영 환경에서 최소 결제 금액 문제를 발견하느라 하루를 허비했습니다.

호출자의 잘못이 아닌 모든 것에 대해서는 자동 환불을 실시하세요. 자율 에이전트 (autonomous agent)는 결제에 대해 이의를 제기할 수 없습니다. 만약 시스템이 성공을 확인하기 전에 비용을 청구한다면, 해당 확인이 도착하지 않을 경우 자동으로 결제를 취소(un-charge)해야 합니다.

탐색 계층 (discovery layer)을 카탈로그와 독립적으로 확장 가능하도록 설계하세요. 누군가 서비스를 추가할 때마다 MCP 인터페이스를 변경해야 한다면, 그것은 마켓플레이스가 아니라 단일 테넌트 (single-tenant) 통합 시스템을 만든 것입니다.

run.pay는 getrunpay.com에서 확인할 수 있습니다. 문서 (docs)에는 모든 서비스에 대해 복사하여 붙여넣을 수 있는 curl 예제가 있으며, 실제 결제 없이 흐름을 테스트하고 싶다면 샌드박스 (sandbox) 모드도 제공됩니다. MCP 서버 소스와 Python SDK 모두 GitHub에서 확인할 수 있습니다.

수익화할 가치가 있는 무언가로 MCP 서버를 운영 중이거나, 외부 서비스를 호출해야 하는 에이전트를 구축하고 있다면, 어떤 점이 이러한 마켓플레이스를 당신에게 유용하게 만들지 진심으로 듣고 싶습니다.