FastMCP와 Apify Standby 기반 MCP 서버 7종 2주 내 배포 완료

I shipped 7 production MCP server Actors in two weeks — here's what the docs don't tell you

Noel Himer2026년 6월 2일11분intermediate

AI 요약

Context

기존 MCP 서버 구축 시 문서화되지 않은 Silent Failure로 인한 디버깅 비용 발생. 특히 Apify Standby 모드의 라우팅 설정과 FastMCP의 인스턴스 관리 방식에 따른 런타임 오류가 주요 병목 지점으로 작용.

webServerMcpPath 설정을 통한 Apify Standby 프로세스와 FastMCP 서버 간의 경로 일치화로 404 라우팅 오류 해결
HTTP 406 Not Acceptable 응답을 정상 상태로 정의하는 MCP 프로토콜 특성을 활용한 Health Check 체계 구축
get_server() 함수 내부에서 @server.tool 데코레이터를 정의하는 Scope 제한 설계를 통해 서버 인스턴스 간 도구 등록 불일치 방지
Pay-per-event(PPE) 과금 모델 도입으로 분 단위 과금 방식에서 Tool Call 기반 과금 구조로 전환하여 비용 최적화
SHA-256 기반 Dockerfile Clobber Guard와 3단계 Smoke Test(Unit → Python -m → curl)를 통한 배포 안정성 확보

실천 포인트

1. Apify Standby 사용 시 actor.json의 webServerMcpPath와 FastMCP 마운트 경로 일치 여부 확인

2. MCP 서버 Health Check 시 406 응답은 정상, 404는 라우팅 오류, 503은 프로세스 미구동으로 판별

3. 모든 Tool 등록은 반드시 get_server() 반환 인스턴스 내부 Scope에서 수행

4. PPE 모델 적용 시 Actor.charge() 배치 위치와 무료 크레딧 버퍼를 고려한 과금 설계 검토

태그