# External Distribution Review — File Time Search MCP
작성일: 2025-12-15
## 1. 배포 시나리오 정의(중요)
MCP 서버의 “배포”는 보통 아래 2가지 형태로 갈립니다.
1) **로컬 STDIO 서버 배포**
- Host(IDE/Agent/Claude Desktop/CLI)가 프로세스를 실행하고 stdin/stdout으로 MCP를 연결
- 사용자 PC에 설치되는 형태(로컬 도구)
2) **원격/사내 서비스(HTTP) 배포**
- Streamable HTTP로 서버를 띄우고 여러 클라이언트가 접속
- 운영/관찰성/스케일링/인증이 중요
본 문서의 결론은 (1) 로컬 배포를 우선 기준으로 하되, (2)도 함께 고려합니다.
## 2. 외부 배포에서 평가 기준
- **설치 마찰**: 런타임(JRE/Node/Python/.NET) 요구 여부, 설치 크기, 권한
- **단일 실행물**: exe/바이너리 1개로 배포 가능 여부
- **크로스플랫폼**: Windows/macOS/Linux 제공 용이성
- **업데이트/패치**: 취약점 패치 전달 용이성, 의존성 업데이트 전략
- **운영 안전성**: stdout 오염 방지(stdio), 로깅/관찰성
- **SDK 성숙도**: MCP 스펙 추종, 예제/문서/릴리즈
## 3. 언어별 배포 적합성(요약)
### A. Go (추천: 외부 배포 최상급)
강점
- **단일 바이너리 배포**가 쉬움(특히 로컬 STDIO 서버에 유리)
- 런타임 설치 의존성이 사실상 없음
- 성능/메모리 사용량 예측이 비교적 쉬움
- 공식 Go SDK가 stdio 기반 예제를 제공
약점
- Windows에서 "created time"(생성 시간) 의미는 언어가 아니라 OS/FS에 좌우 → 테스트는 필수
- 빠르게 UI/웹 프레임워크 결합이 필요하면 TS/Python 대비 개발 속도 차이가 날 수 있음
근거
- Go SDK: https://github.com/modelcontextprotocol/go-sdk
### B. .NET / C# (Windows-first 외부 배포 최상급)
강점
- **self-contained single-file 배포** 옵션(조직 표준에 따라)으로 런타임 설치 부담을 줄일 수 있음
- Windows 친화적(파일 시스템/권한 모델)
- 공식 C# SDK가 서버/클라이언트 모두 제공
약점
- 크로스플랫폼 배포는 가능하지만, 테스트/패키징을 플랫폼별로 관리해야 함
- README 기준 “preview” 표기가 있어 버전 관리 정책이 필요
근거
- C# SDK: https://github.com/modelcontextprotocol/csharp-sdk
### C. Java (운영/기업 배포 강점, 로컬 배포는 전략 필요)
강점
- 엔터프라이즈 환경에서 운영/관찰성/배포 프로세스 성숙
- BOM 제공으로 의존성 관리가 쉬움
- HTTP 서버 배포(서비스형)로 가면 강력
약점
- 로컬 배포에서 JRE 요구가 있을 수 있음(대안: jlink로 커스텀 런타임 번들링, 또는 native-image 등)
- 단일 exe처럼 “그냥 실행” UX를 만들려면 추가 작업이 필요
근거
- Java SDK: https://github.com/modelcontextprotocol/java-sdk
- Java SDK Overview: https://modelcontextprotocol.io/sdk/java/mcp-overview
### D. Rust (외부 배포 최상급 후보)
강점
- 단일 바이너리, 성능/배포 관점에서 매우 강함
약점
- 팀 숙련도/개발 속도/생태계 결합 비용이 조직마다 차이가 큼
- (본 리포트에서는 Rust SDK의 세부 문서/예제까지는 심층 검증하지 않음)
근거
- Rust SDK: https://github.com/modelcontextprotocol/rust-sdk
### E. TypeScript/Node (개발/확장성 강점, “외부 설치” UX는 상대적으로 불리)
강점
- 예제/문서가 매우 풍부
- stdio/Streamable HTTP 모두 지원
- 웹 생태계 결합이 빠름
약점
- 최종 사용자 환경에 Node 런타임이 필요하거나, 별도 번들링이 필요
- 로컬 배포에서 “단일 실행물”을 만들기 어렵거나 제약이 생길 수 있음
근거
- TypeScript SDK: https://github.com/modelcontextprotocol/typescript-sdk
### F. Python (PoC/개발자 배포 강점, 일반 사용자 배포는 전략 필요)
강점
- FastMCP로 구현 속도가 매우 빠름
- structured output을 타입 기반으로 자동 생성/검증해 도구 품질을 올리기 쉬움
약점
- 일반 사용자 배포에서 Python 런타임/의존성 패키징 이슈가 생기기 쉬움
- 단일 실행물로 만들려면 PyInstaller 등 별도 패키징 전략이 필요
근거
- Python SDK: https://github.com/modelcontextprotocol/python-sdk
## 4. 권장 결론(외부 배포 목적별)
### 4.1 “사용자 PC에 설치되는 로컬 MCP(StdIO) 서버”를 외부 배포
- **1순위: Go**
- 설치 마찰이 가장 낮고(단일 바이너리), 크로스플랫폼 제공이 단순
- **2순위: C#**
- Windows 고객/조직이면 매우 좋은 선택(단일 파일/self-contained 가능)
- **3순위: Rust**
- 팀이 Rust에 강하면 Go와 비슷하거나 더 강력한 배포 UX
### 4.2 “사내/외부 서비스로 HTTP(Streamable HTTP) 배포”
- **1순위: Java 또는 Go**
- Java: 엔터프라이즈 운영/관찰성/보안 표준과 결합이 쉬움
- Go: 단순한 배포/리소스 효율, 빠른 스타트업
- **2순위: TypeScript**
- 기존 Node 인프라(Observability/Deploy)가 갖춰진 조직이라면 현실적인 선택
### 4.3 “개발자 대상 오픈소스/예제 배포(설치가 가능한 사용자)”
- **1순위: Python 또는 TypeScript**
- 문서/예제 중심의 DX가 좋아서 커뮤니티가 쉽게 사용
- 단, 일반 사용자 배포(노드/파이썬 미설치)까지 목표면 별도 패키징 필요
## 5. PRD와 직접 연결되는 배포 체크리스트
- stdout 로깅 금지(stdio): 로그는 stderr 또는 파일
- created time 정책 명시: 미지원 파일시스템에서 `createdAt=null` 처리 규칙
- 경로 루트 경계/심볼릭 링크 정책: 외부 배포에서 보안 이슈가 가장 먼저 터짐
- 스캔 제한/타임아웃: 외부 배포 시 “응답 안 옴”이 가장 큰 불만
## 6. 추천 조합(현실적인 실행안)
- **외부 배포용 정식 빌드: Go**
- **사내/개발 생산성용: Python(FastMCP)로 PoC → 스펙/테스트 고정 후 Go로 포팅**
이 조합은 PRD의 핵심(스키마/정책/테스트)을 먼저 잠그고,
최종 배포 UX(단일 바이너리, 낮은 설치 마찰)를 확보하기에 유리합니다.
