MCP 서버 배포는 코드 배포보다 넓은 문제입니다. 실행 환경, 인증, 네트워크 경계, 롤백, 버전 호환성이 같이 들어오기 때문입니다. local로 충분한지, remote로 분리해야 하는지, gateway를 둘지 먼저 결정해야 합니다.
이 글은 MCP 서버를 배포하는 대표 패턴을 local, remote, gateway로 나눠 설명합니다. FastMCP, OpenAI Remote MCP, Cloudflare MCPAgent, Remote MCP Architecture를 함께 보면 선택이 훨씬 쉬워집니다.
이런 분께 추천합니다 #
- MCP 서버를 컨테이너나 원격 서비스로 배포하려는 팀
- 인증과 네트워크 경계를 함께 설계해야 하는 개발자
MCP deployment,remote MCP,gateway,FastMCP deployment를 찾는 분
개요 #
배포에서 먼저 봐야 할 것은 성능이 아니라 경계입니다.
- 어디에서 실행할지
- 누가 호출할 수 있는지
- 실패 시 어디까지 되돌릴지
이 세 가지를 먼저 정하면 배포 방식이 거의 결정됩니다.
왜 중요한가 #
MCP 서버는 단순 API 서버처럼 보이지만 실제로는 도구 실행 권한이 걸린 시스템입니다. 그래서 배포 시점에 아래 문제가 자주 생깁니다.
- local 전용으로 설계했는데 원격 호출이 들어옵니다.
- 환경 변수와 secret 관리가 느슨해서 인증이 새어 나갑니다.
- 버전이 바뀌어도 클라이언트가 이전 스키마를 계속 사용합니다.
- gateway 없이 서버를 직접 노출해서 통제가 어렵습니다.
배포는 기능 전달보다 운영 안정성 전달에 더 가깝습니다.
운영 방식 #
선택 기준은 단순합니다.
- 단일 사용자와 내부 실험이면 local 배포가 충분합니다.
- 여러 사용자와 팀 공유가 필요하면 remote 배포가 적합합니다.
- 도구 통제와 감사가 중요하면 gateway를 둡니다.
- Cloudflare 같은 엣지 환경을 쓰면 edge와 상태 계층을 분리합니다.
FastMCP는 서버 패키징과 배포 진입점을 빠르게 만들기에 좋고, Cloudflare MCPAgent는 remote MCP와 edge execution을 묶는 데 유리합니다. OpenAI Remote MCP를 같이 보면 승인과 허용 도구 설계도 이해하기 쉽습니다.
아키텍처 도식 #
workflow는 local에서 remote까지 배포 선택 흐름을 보여줍니다.
choice-flow는 어떤 조건에서 배포 방식을 바꿔야 하는지 보여줍니다.
architecture는 실행 계층, 인증 계층, 관측 계층을 분리하는 구조를 보여줍니다.
체크리스트 #
- 실행 위치가 명확한가
- 인증과 secret이 분리되어 있는가
- 스키마 버전 호환성이 문서화되어 있는가
- 롤백 경로가 준비되어 있는가
- gateway를 둘 이유가 있는가
- 배포 후 헬스체크가 자동화되어 있는가
- 감사 로그가 배포 단위로 남는가
결론 #
MCP 서버 배포는 “어디에 올릴까"보다 “어떻게 통제할까"가 본질입니다. local, remote, gateway 중 하나를 고르는 순간 끝이 아니라, 그 선택에 맞는 인증과 롤백, 로그를 같이 붙여야 운영이 됩니다.