나도 페이퍼콜 MCP 서버를 만들었는데, 거의 모든 걸 망가뜨릴 뻔한 부분을 공개합니다.

출처: Dev.to

저도 호출당 결제 방식 MCP 서버를 만들었습니다 — 거의 모든 것을 망가뜨릴 뻔한 부분

kirothebot이 에이전트 결제 스택이 실제로 어떻게 구성되는지 상세히 공개했을 때 큰 반향을 일으켰습니다. 이는 거의 아무도 정리해 놓지 않은 문제이기 때문이죠. MCP 위에 호출당 결제를 구현하는 것은 겉보기보다 훨씬 복잡하고, 대부분의 복잡성은 정산 시점에 집중됩니다.

명백한 접근 방식은 다음과 같습니다: 도구를 실행하고, 결제가 완료됐는지 확인한 뒤 결과를 반환한다. 하지만 이것은 역순입니다. 이유는 다음과 같습니다.

통화를 마친 뒤에 정산하면 이미 연산 비용을 사용한 셈이 됩니다. 결제를 하지 않는 에이전트가 자원을 고갈시킬 수 있으며, 이미 값을 반환했기 때문에 복구할 방법이 없습니다. 사후에 속도 제한을 적용할 수는 있지만, 그때는 이미 무료로 작업을 수행한 뒤이기 때문이죠.

올바른 순서는 가격 확인 → 인가 → 도구 실행 → 결과 전달 입니다. 인가 단계가 Stripe 호출이 붙은 일반 웹훅과 차별화되는 핵심 포인트입니다.

이 맥락에서 인가란 호출하는 에이전트 혹은 그 오케스트레이터가 다음을 확인했음을 의미합니다:
(a) 해당 호출 유형에 대한 크레딧이 존재한다,
(b) 실행 전에 크레딧이 예약된다,
(c) 도구는 반환 흐름의 일부분으로 정산 확인을 받는다.

기본 HTTP 요청은 이런 흐름을 자동으로 제공하지 않습니다. MCP 프로토콜과 도구 핸들러 사이에 위치하는 레이어가 필요합니다.

여러 동시 에이전트가 있을 때 드러나는 복잡성은 경합 상황에서의 크레딧 예약 입니다.

예를 들어, 10명의 에이전트가 각각 5개의 크레딧을 남겨두고 동시에 MCP 서버에 요청을 보낸다면, 순진한 구현은 모두에게 요청을 허용합니다—각 요청이 도착했을 때마다 해당 에이전트는 크레딧이 있는 것으로 보이기 때문이죠. 결과적으로 10번 실행되고 결제는 5번만 이루어집니다.

이는 도구 로직이 아니라 인가 레이어에서 발생하는 레이스 컨디션이며, 해결책은 크레딧 상태에 대한 낙관적 잠금을 적용하는 것입니다. 이는 표준 데이터베이스 동시성 제어 방식이지만 결제 미들웨어에 명시적으로 구현해야 합니다.

저는 바로 이 스택—인가, 호출당 정산, 그리고 적절한 동시성 처리를 갖춘 크레딧 예약—을 해결하기 위해 MnemoPay를 만들었습니다. 이 통합은 MCP 도구 핸들러를 래핑하고, 실행 전에 인가 검사를 수행하며, 결과와 함께 정산 확인을 반환합니다.

• v1.0.0‑beta.1 기준 672개의 테스트 통과
• npm‑native 패키지
• 이미 Smithery와 ClawHub에 등재됨

SDK는 에이전트 FICO 점수(300‑850) 를 제공하여 호출 측이 자신의 신용 상태를 확인하고, 예산이 제한된 경우 비용이 높은 도구를 우회하도록 할 수 있습니다.

kirothebot이 수작업으로 만든 결제 스택이 바로 우리가 드롭인 형태로 패키징한 부분입니다. 더 많은 MCP 서버를 구축하면서 매번 결제 시스템을 처음부터 만들고 싶지 않다면, 아래를 확인해 보세요: https://mnemopay.com