Railway에서 FastAPI + Stripe + x402 + MCP를 하나의 스택으로 구축하여 다중 제품 AI API 비즈니스를 만든 방법

몇 달 전, 저는 제가 직접 만든 AI 도구들 — 수동적 소득 분석기(passive income analyzer), AI 전략 컨설턴트(AI strategy consultant), 자율 커머스 레이어(autonomous commerce layer) — 의 접근 권한을 판매하고 싶었습니다. 일반적인 접근 방식은 SaaS 플랫폼을 선택하고, 그들의 수수료를 지불하며, 그들의 제한 사항을 받아들이는 것입니다.

대신 저는 모든 것을 스스로 처리하는 AI 커머스 엔진인 ACE를 구축했습니다. ACE는 몇 달 동안 Railway에서 실행되며 라이선스 키를 전달하고, Stripe 웹훅(webhook)을 처리하며, x402 마이크로 결제(micropayments)를 수락해 왔습니다. 아키텍처는 다음과 같습니다.

ACE가 하는 일

ACE는 결제 이벤트와 AI 도구 전달 사이에 위치하는 라이선스 서버입니다. 누군가 결제하면 다음과 같은 과정이 진행됩니다:

Stripe가 웹훅(webhook)을 발송합니다.
ACE가 이 이벤트를 검증합니다.
ACE가 구매한 제품에 한정된 Fernet 암호화 라이선스 키를 생성합니다.
Resend가 이메일을 통해 키를 전달합니다.
고객은 해당 키를 사용하여 API를 호출합니다.

현재 세 가지 제품을 처리하고 있습니다:

YIELD INTELLIGENCE — 수동적 소득 기회 스캐너 (국채 금리, 배당금 스크리닝, AI 분석 통과)
COUNSELOR — AI 인프라 전략 및 아키텍처 컨설팅
ACE Autonomous Commerce — 지출 한도 강제가 적용된 에이전트 간(agent-to-agent) 구매 실행

세 제품 모두 MCP 네이티브(MCP-native, Streamable HTTP, spec 2025-11-25)이며, 에이전트 카드(agent cards)를 통해 A2A(agent-to-agent) 탐색이 가능합니다.

스택 (The stack)

FastAPI (Python)
├── Stripe 웹훅 핸들러 (결제 → 라이선스)
├── 라이선스 생성 (Fernet 암호화)
...

Railway에 배포되었습니다. 현재 규모에서의 비용: $0/월 (트래픽이 증가하기 전까지는 Railway의 무료 티어(free tier)로 충당 가능합니다).

결제 레이어: Stripe + x402

ACE의 고객은 인간과 에이전트 모두이기 때문에 두 가지 결제 모드를 지원합니다.

Stripe는 인간의 구독 결제(subscription billing)를 처리합니다. Stripe 웹훅(webhook)을 사용하는 월간 티어(monthly tiers)가 라이선스 키 생성을 트리거합니다. 웹훅 핸들러는 멱등성(idempotent)을 유지합니다. 즉, 재전송된 이벤트는 두 번째 키가 발급되기 전에 SQLite 중복 제거(deduplication) 과정을 통해 포착됩니다.

x402는 에이전트 간 마이크로 결제 (agent-to-agent micropayments)를 처리합니다. AI 에이전트가 결제 없이 보호된 엔드포인트 (protected endpoint)를 호출하면, ACE는 USDC 결제 챌린지 (payment challenge)와 함께 HTTP 402를 반환합니다. 에이전트는 Base 메인넷 (Base mainnet)에서 결제한 후, X-PAYMENT 헤더를 포함하여 재시도하며, ACE는 응답을 제공하기 전에 온체인 정산 (on-chain settlement)을 검증합니다.

라이선스 키 아키텍처 (License key architecture)

from cryptography.fernet import Fernet

# 키 생성 (웹훅 발생 시)
...

키 자체가 페이로드 (payload)입니다. 검증을 위한 별도의 조회 테이블 (lookup table)은 존재하지 않으며, 복호화 (decryption) 자체가 곧 검증입니다. Fernet 복호화에 성공하고 만료 시간이 지나지 않았다면, 해당 키는 유효한 것입니다.

SQLite WAL은 멱등성 (idempotency)을 처리합니다:

# 키를 발급하기 전
cursor.execute(
    "SELECT license_key FROM licenses WHERE stripe_payment_intent = ?",
...

MCP 래퍼 (The MCP wrapper)

각 제품은 MCP 도구 (MCP tool)로서 자신을 노출합니다. 래퍼 (wrapper)는 매우 최소한으로 구성됩니다:

@app.post("/mcp")
async def mcp_endpoint(request: MCPRequest, api_key: str = Depends(validate_key)):
    if request.method == "tools/list":
...

A2A 에이전트 카드 (A2A agent card)는 /.well-known/agent.json에 위치하며, 가격 매니페스트 (pricing manifest), 지원 프로토콜 (supported protocols), 그리고 기능 설명 (capability descriptions)을 포함합니다. 다른 에이전트는 결제가 발생하기 전에 ACE를 발견하고, 가격을 조회하며, 호출 여부를 결정할 수 있습니다.

BYOK 모델 (The BYOK model)

ACE의 AI 제품들은 추론 레이어 (reasoning layer)로 Claude를 사용하지만, 비용 구조는 고객에게 그대로 전달됩니다. BYOK (Bring Your Own Key): 고객이 자신의 Anthropic API 키를 가져오면, ACE는 이를 분석 호출 (analysis call)에 적용하고 결과를 반환합니다.

이는 ACE의 AI 호출에 대한 한계 비용 (marginal cost)이 제로임을 의미합니다. 라이선스 수수료는 인프라와 IP (프롬프트, 데이터 파이프라인, AI 호출 관련 비즈니스 로직)를 커버하며, 컴퓨팅 비용 (compute)을 커버하는 것이 아닙니다.

# 고객의 키는 해당 요청 컨텍스트 (request context)로 범위가 제한됨
async def analyze_yield_opportunities(args: dict, customer_key: str):
    client = AsyncAnthropic(api_key=customer_key)
...

Railway 배포 (Deployment on Railway)

Railway의 Dockerfile 배포:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
...

Railway의 환경 변수 (STRIPE_$SECRET_$KEY, FERNET_$KEY, RESEND_$API_$KEY 등) — 레포지토리(repo)에는 비밀 정보(secrets)를 전혀 남기지 않습니다.

Push 시 Railway의 자동 배포(auto-deploy) 기능 덕분에 CI/CD 프로세스는 다음과 같습니다: main 브랜치에 push하면 Railway가 약 2분 내에 재배포를 완료합니다. 이 정도 규모에서는 GitHub Actions 설정이 별도로 필요하지 않습니다.

내가 다르게 했을 부분 (What I'd do differently)

SQLite는 한계가 올 때까지는 괜찮습니다. WAL(Write-Ahead Logging) 모드는 동시 읽기(concurrent reads)를 잘 처리하지만, 갑작스러운 트래픽 급증은 쓰기 경합(write contention)을 일으킬 수 있습니다. 마이그레이션 경로는 Postgres로 전환하는 것이며, Railway에서는 환경 변수 하나만 바꾸면 됩니다. 하지만 실제 부하가 발생할 때까지는 이 작업을 미루고 있습니다.

x402 미들웨어는 더 나은 에러 메시지가 필요합니다. 현재는 잘못된 결제 헤더(malformed payment header)가 들어오면 일반적인 402 에러를 반환합니다. 구조화된 에러 본문(어떤 필드가 실패했는지, 올바른 형식은 무엇인지)을 추가한다면, API를 호출하는 에이전트 개발자들의 디버깅 시간을 줄여줄 수 있을 것입니다.

모니터링이 빈약합니다. 현재는 헬스 체크(health checks)와 Railway의 내장 메트릭(built-in metrics)을 사용하고 있습니다. 제대로 된 관측성 계층(observability layer, 구조화된 로그 → 쿼리 가능한 형태)을 갖춘다면 운영 환경의 문제를 더 빠르게 디버깅할 수 있을 것입니다. 현재는 railway logs와 grep을 사용하고 있습니다.

현재 상태 (Current status)

ACE는 라이브 상태입니다. 라이선스 전달은 자동화되었습니다. 엔드포인트(endpoint)는 MCP 네이티브이며 A2A(Agent-to-Agent)로 발견 가능합니다. 수익은 아직 적지만(초기 단계), 아키텍처는 저의 개입 없이도 작동합니다.

다음 마일스톤은 트래픽입니다. 이러한 도구가 필요한 에이전트 개발자들이 그들이 찾는 곳(MCP 레지스트리, 모델 마켓플레이스, 이와 같은 dev.to 기사 등)에서 ACE를 발견하게 만드는 것입니다.

만약 여러분이 에이전트 스택에서 수동적 소득 분석(passive income analysis), AI 아키텍처 전략, 또는 자율 커머스 계층(autonomous commerce layer)이 필요한 무언가를 구축하고 있다면 — ACE는 ace-license-server-production.up.railway.app에서 확인하실 수 있습니다.

Built by ~K¹ (William Kyle Million) · IntuiTek¹