지난 몇 달 동안 사이드 프로젝트로 MCP 서버들을 구축해 왔는데, 어느 시점에 그중 하나에 제대로 된 인증 (Auth)과 결제 (Billing) 기능을 추가하기로 결정했습니다. 큰 실수였습니다. 아니, 정확히 말하면 제가 완전히 과소평가했습니다. 시작한 지 4시간 만에 저는 RFC 9728을 읽고 있었습니다. 농담이 아닙니다. 인증 코드는 단 한 줄도 서버를 더 똑똑하거나, 빠르거나, 유용하게 만들지 못했습니다. 그것은 그저 배관 작업 (Plumbing)일 뿐이었습니다. 게다가 그 위에 결제 기능까지 더해지니 — 사용량 기반 미터링 (Usage-based metering)은 재시도 (Retries), 스트리밍 (Streaming), 그리고 클라이언트가 호출 중간에 연결을 끊었을 때 어떤 일이 발생하는지를 실제로 고민해 보기 전까지는 단순하게 들립니다. 결국 저는 이 모든 것을 보류하고 정적 API 키 (Static API key)를 사용하여 배포했습니다. 전형적인 실수였죠. 결국 저는 Claude Code를 기본적으로 시니어 개발자 페어 (Senior dev pair)로 활용하여 이를 제대로 구축하기로 결정했습니다. 진정으로 흥미로운 경험이었습니다. 제가 사양 (Spec)을 작성하면 Claude Code가 구현하고, 저는 다음 모듈로 넘어가기 전에 엄격한 아키텍처 문서 (Architecture doc)를 기준으로 모든 것을 검토했습니다. 7개의 모듈, 300개의 테스트 통과. 몇 주가 걸렸지만, 결제 예외 케이스 (Billing edge cases)만으로도 미래의 저(그리고 이것을 구매하는 모든 사람)의 시간을 꼬박 3~5일은 아껴주었을 것입니다. 결국 가장 어려웠던 부분은 OAuth가 아니라 미터링 (Metering)이었습니다. 구체적으로는 다음과 같습니다: 클라이언트가 실패한 요청을 재시도하면 어떻게 되는가? (멱등성 키 (Idempotency keys) — 각 이벤트는 하나를 가지며, 중복은 폐기되어 이중 결제가 발생하지 않음) 사용자가 스트리밍 응답을 중단하면 어떻게 되는가? (이벤트 상태는 partial로 유지되며, 이를 과금할지는 사용자가 결정함) 완료된 호출과 실패한 호출을 구분하는 기준은 무엇인가? (명시적인 completed | partial | failed 상태를 정의하였으며, README에 코드 예제와 함께 문서화함) 이러한 결정 사항들은 그 어떤 Stripe 튜토리얼에도 나와 있지 않습니다. 스스로 결정해야 하며, 그 결정에 책임을 져야 합니다. 저는 모든 것을 문서화했습니다.

보일러플레이트(Boilerplate)에 포함된 내용:

• OAuth 2.1 + PKCE (래퍼(Wrapper)가 아닌 전체 플로우)
• API 키 관리 (접두사가 붙은 형식, SHA-256 해시, 다운타임 없는 로테이션)
• Stripe 사용량 기반 결제 (Billing Meters 활용)
• Redis 속도 제한 (Rate limiting, 슬라이딩 윈도우, 플랜별 적용)
• 300개의 테스트
  자체 호스팅 가능, 수익 배분 없음, 플랫폼 수수료 없음. 당신의 결제 계층, 당신의 인프라입니다.

데모 영상 (67초):

만약 MCP 서버를 구축 중이며 인증(auth) 및 결제(billing) 부분을 두려워하고 있다면: https://mcp-billing.com /u/OpeningSir9287 님이 제출함 [link] [comments]