MCP는 에이전트에게 Stripe 접근 권한을 부여합니다. 스킬은 무엇을 망가뜨리지 말아야 할지 알려줍니다.

Stripe 연동은 AI 코딩 에이전트가 마법처럼 보이다가도 위험해지기 직전까지 가는 지점 중 하나입니다.

에이전트는 문서를 읽을 수 있습니다.

체크아웃 흐름 (checkout flow)을 생성할 수 있습니다.

웹훅 (webhook)을 연결할 수 있습니다.

연결된 계정 (connected account)을 생성하고, 플랫폼과 판매자 사이에서 돈을 이동시키며, 그럴싸해 보이는 코드를 남길 수 있습니다.

마지막 부분이 문제입니다.

결제 코드는 할 일 관리 (todo) 앱처럼 실패하지 않습니다.

할 일 관리 앱에 잘못된 엣지 케이스 (edge case)가 있다면, 누군가가 작업을 완료로 표시하지 못할 뿐입니다.

하지만 마켓플레이스 결제 흐름에 잘못된 엣지 케이스가 있다면, 잘못된 당사자가 수수료를 징수하거나, 판매자가 온보딩 (onboarding)을 완료하지 못하거나, 내부 상태에서 지급액 (payout)이 사라지거나, 웹훅 재시도 (webhook retry)가 조용히 정산 혼란을 야기할 수 있습니다.

이것이 제가 "그저 에이전트를 Stripe MCP에 연결하는 것"만으로는 충분하지 않다고 생각하는 이유입니다.

MCP는 에이전트에게 접근 권한을 부여합니다.

스킬 (skill)은 에이전트에게 플레이북 (playbook)을 제공합니다.

접근 계층: Stripe MCP

Stripe는 에이전트 워크플로우 (agentic workflows)를 위한 MCP 서버를 보유하고 있습니다.

이것이 중요한 이유는 에이전트가 기억에 의존하거나 웹에서 오래된 코드 조각을 복사하여 붙여넣는 대신, 구조화된 도구 인터페이스를 통해 Stripe와 작업할 수 있기 때문입니다.

Stripe의 자체 문서에서는 MCP 서버를 에이전트가 Stripe API와 상호작용하고 Stripe의 지식 베이스를 검색하는 데 사용할 수 있는 도구 세트로 설명합니다.

이는 LLM에게 다음과 같이 요청하는 것보다 실질적인 개선입니다:

"내 마켓플레이스를 위한 Stripe Connect를 구축해줘"

그리고 그것이 최신 API 형태를 기억하고 있기를 바라는 것 말입니다.

하지만 접근 권한이 판단력과 같은 것은 아닙니다.

에이전트가 Stripe 도구를 가지고 있더라도, 여전히 다음 사항들을 알아야 합니다:

어떤 Connect 결제 유형이 제품 모델에 적합한지
판매자에게 Express, 전체 대시보드 접근 권한, 또는 완전히 임베디드된 흐름 (embedded flow)이 필요한지
연결된 계정 ID (connected account id)를 어디에 저장할지
어떤 이벤트가 내부 주문 상태를 업데이트해야 하는지
직접 결제 (direct charges) vs 목적지 결제 (destination charges) vs 별도 결제 및 이체 (separate charges and transfers) 중 언제 무엇을 사용할지
환불 (refunds), 분쟁 (disputes), 온보딩 요구 사항, 그리고 지급 상태 (payout status)를 어떻게 처리할지

이것들은 단순한 API 호출이 아닙니다.

이것들은 제품 결정 (product decisions)입니다.

지시 계층: Stripe Connect 스킬

Terminal Skills에서 제가 살펴본 가장 최근의 Stripe 관련 스킬은 stripe-connect입니다.

이 스킬은 마켓플레이스(marketplace) 및 플랫폼 결제를 위해 구축되었습니다:

양면 마켓플레이스 (two-sided marketplaces)
판매자/제공자 온보딩 (seller/provider onboarding)
구매자와 판매자 간의 결제 분할 (splitting payments between buyers and sellers)
플랫폼 수수료 (platform fees)
지급 (payouts)
연결된 계정 관리 (connected account management)
Connect 웹훅 (Connect webhooks)

중요한 세부 사항은 이 스킬이 단순히 엔드포인트(endpoints)의 목록이 아니라는 점입니다.

이 스킬은 에이전트에게 흐름(flow)을 통해 추론하는 방법을 알려줍니다.

예를 들어, 이 스킬은 새로운 Connect 플랫폼을 위해 Stripe Accounts v2를 사용합니다. 기존의 평면적인 type: "express" 형태를 먼저 생각하는 대신, 연결된 계정을 다음과 같은 설정(configurations)을 중심으로 구성합니다:

결제를 수락하기 위한 merchant
송금 및 지급을 받기 위한 recipient
고객으로서 비용을 청구받기 위한 customer

이는 에이전트가 이전 예시들로부터 패턴 매칭 (pattern-matching)만 할 경우 쉽게 놓칠 수 있는 종류의 세부 사항입니다.

또한 이 스킬은 대시보드 접근 권한을 명시적으로 구분합니다:

Stripe 호스팅 온보딩 및 대시보드를 위한 express
전체 Stripe 대시보드 또는 OAuth 스타일의 흐름이 필요한 판매자를 위한 full
임베디드/커스텀 플랫폼 제어를 위한 none

이러한 구분은 중요합니다. 왜냐하면 온보딩은 단순한 기술적 단계가 아니기 때문입니다. 온보딩은 UX, 지원, 컴플라이언스(compliance) 범위, 그리고 판매자 제어권을 누가 소유하는지를 결정합니다.

이것이 단순한 프롬프트가 아닌 스킬에 포함되어야 하는 이유

에이전트에게 다음과 같이 말할 수 있습니다:

"Stripe의 베스트 프랙티스 (best practices)를 사용하세요."

명확하게 들립니다.

하지만 그렇지 않습니다.

무엇에 대한 베스트 프랙티스인가요?

단순한 SaaS 체크아웃인가요?

사용량 기반 구독 (usage-based subscription)인가요?

판매자가 있는 마켓플레이스인가요?

화이트 라벨 (white-label) 플랫폼인가요?

업무가 완료될 때까지 자금을 예치해야 하는 서비스 마켓플레이스인가요?

이것들은 서로 다른 시스템입니다.

좋은 스킬은 코드가 나타나기 전에 작업을 좁혀줍니다.

Stripe Connect의 경우, 저는 에이전트가 다음과 같은 질문을 던지고 인코딩(encode)하기를 바랍니다:

플랫폼이 기록상 판매자(Merchant of Record)인가요, 아니면 판매자가 판매자인가요?
판매자에게 대시보드 접근 권한이 필요한가요?
결제 시점에 플랫폼이 수수료를 징수해야 하나요?
이행(Fulfillment)이 즉시 이루어지나요, 지연되나요, 아니면 마일스톤(Milestone) 기반인가요?
온보딩(Onboarding)이 완료될 때 내부 상태는 어떻게 변경되나요?
어떤 웹훅(Webhook) 이벤트가 신뢰할 수 있는 원천 데이터(Source of truth)인가요?
환불, 분쟁(Dispute), 결제 실패 및 지급(Payout) 실패 시에는 어떤 일이 발생하나요?

그것이 바로 작업의 핵심입니다.

API 호출은 마지막 단계(Last mile)일 뿐입니다.

가장 유용한 부분: 결제 모델(Charge model) 선택

많은 마켓플레이스 결제 버그는 잘못된 결제 모델을 선택하는 것에서 시작됩니다.

stripe-connect 스킬은 주요 옵션들을 다음과 같이 구분합니다:

직접 결제 (Direct charges)

결제가 연결된 계정(Connected account)에서 발생합니다.

판매자가 결제 관계의 더 많은 부분을 소유해야 하고, 자신의 Stripe 계정에서 결제 내역을 직접 확인해야 하는 경우에 적합합니다.

목적지 결제 (Destination charges)

플랫폼이 결제를 생성하고 자금을 판매자에게 전달(Route)합니다.

플랫폼이 구매자 경험을 제어하고 애플리케이션 수수료(Application fee)를 징수하는 경우, 이는 종종 깔끔한 마켓플레이스 기본 설정이 됩니다.

별도 결제 및 이체 (Separate charges and transfers)

플랫폼이 먼저 구매자에게 결제한 후, 나중에 자금을 이체합니다.

배송, 리스크, 에스크로(Escrow)와 유사한 타이밍, 또는 다자간 라우팅(Multi-party routing)이 중요한 경우에 유연한 옵션이 됩니다.

에이전트는 PaymentIntent 코드를 작성하기 전에 이 결정을 내려야 합니다.

그렇지 않으면 테스트 카드의 해피 패스(Happy path)에서는 작동하지만, 실제 비즈니스 로직과는 일치하지 않는 코드를 생성할 수 있습니다.

웹훅(Webhooks)은 통합이 실질적으로 완성되는 지점입니다

Stripe 통합은 브라우저에서 결제가 성공했다고 해서 끝나는 것이 아닙니다.

백엔드 상태가 현실의 변수 속에서도 유지될 때 비로소 통합이 완료됩니다.

즉, 웹훅(Webhooks)이 필요하다는 뜻입니다.

Connect의 경우, 플랫폼은 다음 사항들을 모니터링해야 할 수도 있습니다:

온보딩(Onboarding) 업데이트
결제 성공 및 실패
이체(Transfers)
지급(Payouts)
분쟁(Disputes)
연결된 계정 이벤트(Connected-account events)

해당 스킬(skill)은 놓치기 쉬운 세부 사항을 지적합니다: Accounts v2는 이벤트 목적지(event destinations)를 통해 얇은 이벤트(thin events)를 방출하며, 온보딩(onboarding) 상태를 확인하려면 계정 요구 사항 업데이트(account requirements updates)를 리스닝(listening)해야 할 수도 있습니다.

이것이 바로 일반적인 프롬프트(prompt)가 건너뛸 수 있는 바로 그런 종류의 사항입니다.

프롬프트는 해피 패스(happy path)는 구축할 수 있지만, 운영 경로(operational path)는 미완성 상태로 남겨둘 수 있습니다.

Stripe MCP와 스킬이 결합되는 방식

제가 생각하는 방식은 다음과 같습니다:

MCP는 도구 소켓(tool socket)입니다.

스킬(skill)은 운영 절차(operating procedure)입니다.

Stripe MCP는 에이전트(agent)가 Stripe 지식을 쿼리(query)하고, 리소스(resources)를 검사하며, 구조화된 API 대응 인터페이스를 통해 작업할 수 있도록 합니다.

stripe-connect 스킬은 에이전트에게 마켓플레이스 결제 시스템이 어떻게 조립되어야 하는지를 알려줍니다:

판매자 계정 모델 정의
연결된 계정(connected account) 생성
온보딩(onboarding) 생성
계정 ID 저장
결제 유형(charge type) 선택
의도적으로 플랫폼 수수료(platform fees) 수집
웹훅(webhooks) 연결
환불(refunds), 분쟁(disputes), 지급(payouts) 처리
Stripe CLI 및 테스트 카드로 테스트

이것이 "에이전트가 Stripe를 호출할 수 있음"과 "에이전트가 올바른 Stripe 흐름(flow)을 구축할 수 있음"의 차이입니다.

모호한 자금 이동을 에이전트에게 전적으로 신뢰해서는 안 됩니다

이것이 저에게 주는 큰 교훈입니다.

AI 에이전트는 구현(implementation) 능력이 점점 좋아지고 있습니다.

하지만 자금 이동(money movement)은 단순한 구현이 아닙니다.

그것은 정책(policy), 제품 설계(product design), 컴플라이언스 경계(compliance boundary), 리스크 관리(risk handling), 그리고 상태 조정(state reconciliation)입니다.

따라서 워크플로(workflow)는 다음과 같은 모습이어야 합니다:

사람이 마켓플레이스 모델을 정의함
        |
        v
...

이것이 제가 거대한 프롬프트보다 더 신뢰하는 스택(stack)입니다.

"AI, 결제 시스템을 구축해줘"가 아니라,

"AI, 이 결제 아키텍처(architecture)를 따르고, 현재의 Stripe 도구들을 사용하며, 돈을 움직이기 전에 나에게 결정 사항을 보여줘"라고 해야 합니다.

이 지점에서 에이전트가 진지한 백엔드(backend) 작업을 위해 유용해지기 시작합니다.

Source:

Terminal Skills stripe-connect: [https://terminalskills.io/skills/stripe-connect]
Stripe MCP docs: [https://docs.stripe.com/mcp]
Stripe AI build docs: [https://docs.stripe.com/building-with-ai]