@maru

Python MCP 서버의 한계 — FastMCP와 TypeScript의 실운영 격차
모델 컨텍스트 프로토콜(MCP) 생태계가 2,200% 이상 급성장하며 AI 에이전트와 도구를 연결하는 새로운 표준으로 부상했습니다. 하지만 실제 시장 통계를 살펴보면, 공개된 MCP 서버의 86%는 여전히 개발자의 로컬 환경에만 머물러 있습니다.
로컬 환경에서 설정 없이 간편하게 작동하던 단순함이 실제 운영 및 멀티테넌트 환경으로 전환될 때는 오히려 심각한 보안 공격 표면과 설계적 장벽으로 돌변하기 때문입니다. 이러한 모순적 현상을 'MCP 역설'이라고 부릅니다. 이 글에서는 가장 널리 쓰이는 파이썬 기반 FastMCP의 설계적 한계를 짚어보고, 왜 실제 상용 프로덕션 환경에서는 타입스크립트 기반 아키텍처나 전용 자가 호스팅 플랫폼이 대안으로 부각되는지 자세히 살펴보겠습니다.
Python 생태계의 급부상: FastMCP와 fastapi-mcp
앤트로픽이 출시한 FastMCP는 파이썬 개발자가 MCP 서버를 구축할 때 겪는 번거로운 보일러플레이트 코드를 완벽하게 제거해 줍니다. 복잡한 프로토콜 명세를 직접 다룰 필요 없이, 마치 FastAPI 환경에서 개발하듯 데코레이터 패턴 몇 줄만으로 로컬 스크립트나 함수를 AI 에이전트에 쉽게 연동할 수 있습니다.
여기에 더해 커뮤니티 라이브러리인 fastapi-mcp는 기존에 운영 중인 FastAPI 엔드포인트를 Pydantic 유효성 검사와 함께 MCP 도구로 자동 변환하여 노출하는 영리한 접근 방식을 취합니다. 이러한 도구들의 등장 덕분에 개발자들은 복잡한 인프라 설정에 시간을 낭비하지 않고 핵심 기능 개발에만 집중할 수 있게 되었습니다.
두 생태계의 대표적인 도구 등록 방식을 코드로 비교해 보면 지향하는 설계적 차이가 더 명확하게 드러납니다.
# Python (FastMCP)
from fastmcp import FastMCP
mcp = FastMCP("My MCP Server")
@mcp.tool
def greet(name: str) -> str:
"""Greets a user by name."""
return f"Hello, {name}!"// TypeScript (SDK v1.0.0+ Modern API)
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({
name: "my-mcp-server",
version: "1.0.0"
});
server.registerTool(
"greet",
{
description: "Greets a user by name.",
inputSchema: {
name: z.string()
}
},
async ({ name }) => ({
content: [{ type: "text", text: `Hello, ${name}!` }]
})
);파이썬의 FastMCP는 함수 자체의 파이썬 타입 힌트와 독스트링을 자동으로 해석하여 스키마를 구성하는 압도적인 편의성을 자랑합니다. 반면 타입스크립트는 현대적인 McpServer 클래스 하에서 Zod 스키마를 명시적으로 결합하는 구조를 취합니다. 이 구조적 차이는 프로토타이핑을 넘어 대규모 프로덕션 환경으로 나아갈 때 코드의 안정성과 세밀한 제어력 관점에서 결정적인 차이를 만들기 시작합니다.
코드 품질과 '스크립트 래핑'의 함정
쉽고 빠른 도구 연동이라는 장점 이면에는 실운영 환경에서 해결해야 할 코드 품질과 안정성 격차가 숨어 있습니다. 학계의 에이전트 상호운용성 프로토콜 조사 보고서에 따르면, 자바스크립트나 타입스크립트로 작성된 MCP 서버의 코드 스멜 중앙값이 2개 수준인 데 비해 파이썬 구현체는 4개 수준으로 두 배나 높게 나타났습니다.
이러한 격차는 많은 파이썬 개발자들이 기존에 개인용으로 쓰던 레거시 스크립트를 FastMCP 데코레이터로 급하게 감싸서 도구로 배포하는 이른바 '스크립트 래핑' 관행 때문입니다. 이 과정에서 엄격한 타입 유효성 검사나 체계적인 에러 핸들링이 생략되는 경우가 많아, 사소한 예외 상황에서도 AI 에이전트가 통제 불능 상태에 빠지거나 오작동할 위험이 커집니다.
느슨한 동적 실행 환경에서 비롯되는 공급망 보안 위협도 무시할 수 없습니다. 대표적인 예로 postgres 오타를 악용한 mcp-server-postgress 타이포스쿼팅 패키지 배포 사례처럼, 검증되지 않은 외부 라이브러리를 동적으로 불러와 실행하는 파이썬 MCP 환경은 심각한 보안 사고의 표적이 되기 쉽습니다. 로컬 프로토타입 단계를 넘어 실제 서비스 시스템에 MCP를 결합할 때 개발자가 가장 먼저 걷어내야 할 장벽입니다.
결정적 아키텍처 장벽: 세션 상태와 OAuth 분리
로컬 작동을 넘어 멀티테넌트나 기업용 시스템으로 MCP를 확장할 때 가장 큰 걸림돌은 세션 상태와 인증 정보의 동기화입니다. Portal One 엔지니어링 블로그 분석에 따르면, 표준 입출력(stdio) 기반의 독립 프로세스로 실행되는 파이썬 MCP 서버는 메인 웹 애플리케이션의 기본 사용자 세션이나 워크스페이스 권한에 직접 접근하기 어렵습니다. 도구 호출 시 매번 인증 토큰을 인자로 넘겨주는 임시방편을 쓰지 않는 한, 분산 환경에서 정교한 권한 제어를 보장하기 힘든 구조입니다.
반면 타입스크립트 MCP SDK는 이러한 분산 보안 환경을 처리할 수 있는 구조적 프리미티브를 기본 제공합니다. 도구 실행 컨텍스트에 내장된 authInfo 필드로 호출한 사용자의 인증 컨텍스트를 즉시 참조할 수 있으며, 전용 ProxyOAuthServer 클래스를 통해 외부 OAuth 흐름을 안전하게 중재합니다. 비동기 루프 안에서 이러한 복잡한 세션 통제 프레임워크를 직접 밑바닥부터 구현해야 하는 파이썬과 달리, 타입스크립트는 대규모 프로덕션 배포에 필요한 준비를 미리 마친 셈입니다.
자가 호스팅 플랫폼의 대안: Openship의 네이티브 MCP
실운영 환경에서 직접 MCP 서버를 구축하고 인증과 권한을 제어하는 작업이 부담스럽다면, 플랫폼 수준에서 MCP를 네이티브하게 통합한 대안을 고려해 볼 수 있습니다. 자가 호스팅 플랫폼인 오픈쉽(Openship)은 기존의 쿨리파이(Coolify)나 도쿠(Dokku) 같은 도구들과 달리, 플랫폼 자체에 MCP 서버를 내장하는 독특한 아키텍처를 선택했습니다. 개발자가 보안 위험을 무릅쓰고 인프라 제어용 MCP 서버를 직접 배포하는 대신, 플랫폼이 제공하는 검증된 인터페이스를 통해 안전하게 시스템을 제어하도록 우회한 것입니다.
오픈쉽은 Bun 기반의 CLI와 오픈레스티(OpenResty)를 활용하며, 대상 서버에 별도의 에이전트를 두지 않는 가벼운 아키텍처를 지향합니다. 빌드 파이프라인에서 생성된 불변 도커 컨테이너를 대상 서버로 SSH 스트리밍하는 방식을 사용해 타깃 인프라를 단순하게 유지합니다.
오픈쉽의 Bun 기반 CLI는 Node.js 없이도 단 한 줄의 명령어로 설치하고 실행할 수 있습니다.
# 오픈쉽 CLI 설치 및 개발 환경 실행
curl -fsSL https://get.openship.io | sh
openship up서비스를 시작하면 로컬 API 서버와 대시보드가 활성화되며, 내장된 MCP 서버는 클로드 코드나 커서 같은 AI 도구가 로컬 API 토큰 인증을 거쳐 프로젝트 배포, 클러스터 검사, 환경 변수 변경, 이전 배포로의 롤백까지 직접 수행할 수 있도록 안전하게 중재합니다.
참고로 오픈쉽은 최근 소스코드가 공개된 AGPL-3.0 및 커먼즈 클로즈(Commons Clause) 라이선스로 전환되어, 상용 서비스형 소프트웨어(SaaS) 형태의 무단 재판매는 불가능하지만 기업 내부의 자가 호스팅 인프라에서는 자유롭게 활용할 수 있습니다. 수동으로 복잡한 세션 보안이나 OAuth 분리 장벽을 넘기 위해 씨름하는 대신, 이처럼 플랫폼 레벨에서 보안 게이트웨이 역할을 대신하는 네이티브 MCP 플랫폼을 도입하는 것도 실운영 보안 관성을 지키는 효율적인 절충안입니다.
개발자를 위한 실전 제언
로컬 환경에서의 간결함이 실운영 환경의 보안 위협으로 돌변하는 'MCP 역설'은 아키텍처 선택에 중요한 기준을 제시합니다. 로컬 중심의 빠른 프로토타이핑이나 기존 스크립트의 빠른 전환에는 파이썬의 FastMCP가 훌륭한 출발점입니다. 하지만 세션 격리, 다중 사용자 인증, 엄격한 타사 권한 관리가 필수적인 상용 서비스 구축 단계라면 타입스크립트 기반 SDK를 도입하거나 인프라 레벨에서 검증된 게이트웨이를 설계하는 구조가 안정적인 선택이 될 수 있습니다.
참고 링크