Smithery의 MCP 서버를 에이전트에 연결한다는 것은 단순히 목록에서 URL 하나를 가져오는 일이 아닙니다. 클라이언트와 서버 사이에 있는 플랫폼에 탐색, 실행, 인증을 넘기는 일입니다. 그 호스팅 계층이 실제로 하는 일은 다음과 같습니다.
링크 목록만으로는 얻을 수 없는 Smithery 호스팅 계층의 역할
Smithery는 엄선된 GitHub 목록이 아니라 Model Context Protocol(MCP) 서버를 위한 3계층 제어 평면입니다. 어떤 서버가 있는지 찾을 수 있는 검색형 카탈로그인 디스커버리 레지스트리, 자체 인프라에서 해당 서버를 원격 엔드포인트로 실행하는 관리형 실행 계층, 그리고 범위가 지정된 토큰을 발급하고 자격 증명을 갱신해 주는 OAuth/자격 증명 릴레이를 하나로 묶습니다. 이는 Smithery 문서에 설명되어 있습니다. 이 카탈로그는 출시 당시 약 10개 서버에서 6,000~7,000개 이상의 MCP 서버가 보고된 규모까지 커졌습니다.
링크 목록이 따라 할 수 없는 핵심은 Smithery의 메타 MCP인 Toolbox입니다. 하나의 연결만으로 에이전트가 런타임에 레지스트리의 어떤 서버든 동적으로 연결할 수 있어, 클라이언트마다 서버별 설정을 반복하지 않아도 됩니다. 그 위에는 장기 연결을 만들고, 도구를 호출하고, https://mcp.smithery.run/{namespace}의 네임스페이스 단위 엔드포인트를 호출할 수 있는 REST 표면이 있습니다. Smithery가 프로토콜 준수를 처리하므로 호출자는 원시 MCP를 직접 구현할 필요가 없습니다(source).
Smithery는 Jenni.ai의 기술 공동창업자였던 Henry Mao가 2024년 12월에 설립했습니다. 이 레지스트리+호스팅+라우터 묶음이 Glama, PulseMCP, mcp.so 같은 카탈로그 중심 경쟁자들과 Smithery를 가르는 지점입니다. 특히 mcp.so는 19,700개 이상의 목록이 보고되어, 큐레이션보다 폭넓은 수집에 무게를 둡니다.
smithery.yaml: typescript, container, URL 등록
Smithery를 통해 배포하는 모든 서버는 저장소 루트의 smithery.yaml로 설명되며, 이 파일에서 세 가지 배포 모델 중 하나를 선택합니다 . 이 선택은 런타임을 누가 소유하는지, 어떤 언어를 쓸 수 있는지, 아래쪽 머신 패치는 누가 맡는지를 결정합니다. 코드를 커밋하기 전에 꼭 읽어볼 만합니다.
옵션 A — runtime: "typescript". 권장 경로입니다. CLI가 @smithery/cli build를 실행하고 Smithery 자체 인프라에 Streamable HTTP 엔드포인트를 배포합니다. TypeScript만 사용할 수 있지만, 대신 배포용 접착 코드를 거의 쓰지 않아도 됩니다. Smithery가 서버를 빌드하고, 호스팅하고, 라우팅합니다 .
옵션 B — runtime: "container". Smithery가 사용자의 Dockerfile에서 Docker 이미지를 빌드하므로 어떤 언어든 사용할 수 있습니다. 런타임에는 앱을 시작하고, PORT 환경 변수를 주입하고, MCP 트래픽을 /mcp 엔드포인트로 라우팅하며, 세션별 설정을 쿼리 매개변수로 전달합니다. 이 모드에서는 플랫폼이 세션 설정을 검증할 수 있도록 type: "http"인 startCommand와 JSON Schema configSchema가 필요합니다 .
옵션 C — URL 등록. 자체 VM을 계속 운영하면서, 이미 실행 중인 Streamable HTTP 엔드포인트를 Smithery에 연결합니다. 제어권은 온전히 갖지만 가동 시간과 패치는 직접 책임져야 합니다. 중간 선택지인 Uplink는 로컬 프로세스에서 지속적인 WebSocket 터널을 유지하지만, Smithery 문서는 이를 프로덕션 호스팅이 아니라고 명시합니다. 가용성이 개발자 머신에 달려 있기 때문입니다 .
Smithery가 모든 것을 Streamable HTTP 쪽으로 밀어붙이는 논리는 처리량입니다. Smithery는 이 전송 방식이 stdio보다 "최대 20배 높은 동시성과 더 낮은 지연 시간"을 제공하며, 로드 밸런싱과 자동 확장도 가능하다고 주장합니다 . 프로덕션에서 실제로 문제가 되는 항목을 기준으로 세 가지 모드를 비교하면 다음과 같습니다.
| 항목 | A: typescript | B: container | C: URL 등록 |
|---|---|---|---|
| 언어 지원 | TypeScript만 가능 | 모든 언어(Docker) | 모든 언어 |
| VM 소유권 | Smithery | Smithery | 사용자 |
| SLA 상태 | 공개된 내용 없음 | 공개된 내용 없음 | 직접 정의 |
| 자격 증명 처리 | Smithery 관리 OAuth | Smithery 관리 OAuth | 사용자 책임 |
| OS 패치 주체 | Smithery | Smithery | 사용자 |
콜드 스타트 지연: Fly.io 머신이 실제로 의미하는 것
콜드 스타트 지연은 Smithery 호스팅 이야기에서 문서화가 가장 부족한 부분입니다. 현재 빌드 문서에는 공개된 p50/p95/p99 표, SLA, 리전 목록, scale-to-zero 토글, 프리워밍 설정이 없습니다 . 추론할 수 있는 것은 아래쪽 런타임입니다. 2025년 10월 GitGuardian 공개 내용은 호스팅 서버가 Docker 레지스트리 뒤의 Fly.io 머신에서 실행된다는 점을 간접적으로 확인했습니다 . Fly.io 머신은 유휴 상태일 때 자동 중지되고 다음 요청에서 자동 시작될 수 있습니다. 한동안 조용했던 호스팅 MCP 서버에서 콜드 스타트를 만들어내는 바로 그 메커니즘입니다 .
그 정지가 얼마나 오래 이어지는지는 Smithery가 밝히지 않습니다. 더 넓은 서버리스 문헌의 참고점으로는, 약 850억 건의 요청과 1,190만 건의 콜드 스타트를 분석한 Huawei 추적 연구에서 한 리전의 콜드 스타트가 최대 7초까지 측정되었습니다. 이는 외부 맥락일 뿐 Smithery 자체 수치는 아니며, Smithery의 수치는 공개되지 않았습니다. Smithery가 공개한 아키텍처상의 근거는 Streamable HTTP가 stdio보다 "최대 20배 높은 동시성과 더 낮은 지연 시간"을 제공하고 로드 밸런싱과 자동 확장을 가능하게 한다는 점입니다 . 하지만 동시성 여유와 유휴 후 첫 요청 지연 시간은 서로 다른 지표입니다.
실무에서 치르는 비용은 제어권입니다. 호스팅 경로에서는 다음을 직접 설정할 수 없습니다.
- VM 크기와 메모리 할당
- 리전 고정 또는 멀티 리전 배치
- scale-to-zero를 막기 위한 keepalive 간격
- 자동 확장 임계값
- 의존성 캐싱 전략
이 모든 것은 자체 관리 VM, Kubernetes pod, 또는 데이터와 같은 위치에 둔 stdio 프로세스에서는 직접 조정할 수 있는 것들입니다. 결정적인 지연 시간이 중요하다면, 따져봐야 할 트레이드오프는 원시 속도가 아니라 이런 빠진 조절 장치들입니다.
2025년 6월 경로 탐색 취약점: 하나의 결함, 영향 범위 3,243개 앱
런타임 배치를 플랫폼에 맡긴다는 것은 그 플랫폼의 빌드 파이프라인 공격 표면까지 함께 떠안는다는 뜻이기도 합니다. Smithery의 호스팅 모델이 치른 비용을 가장 분명하게 보여주는 문서화된 사례는 GitGuardian이 2025년 10월 15일 공개한 경로 탐색 취약점입니다. 제출된 smithery.yaml의 dockerBuildPath 파라미터가 검증되지 않았고, 이를 ".."로 설정하면 악성 Dockerfile이 빌드 컨텍스트 밖으로 올라가 빌드 사용자 홈 디렉터리의 ~/.docker/config.json을 읽을 수 있었습니다 .
피해 범위는 그 파일 안에 무엇이 들어 있었는지에서 비롯됐습니다. 지나치게 많은 권한을 가진 Fly.io API 토큰이 있었고, 이 토큰은 정확히 3,243개 앱으로 구성된 Fly.io 조직 전체의 machines API 권한을 부여했습니다. 이는 3,000개가 넘는 호스팅 MCP 서버에 해당하며, 루트 접근과 Brave 키 같은 downstream API 키가 담긴 인바운드 트래픽을 스니핑할 수 있는 능력이 확인됐습니다 . 다시 말해, 잘못 설정된 빌드 파라미터 하나가 공유 인프라의 모든 테넌트를 노출한 셈입니다.
수정은 빠르게 진행됐습니다. GitGuardian은 6월 10일 취약점을 발견했고, 6월 13일 이를 보고했으며, Smithery는 2025년 6월 15일까지 패치와 자격 증명 교체를 완료했습니다. 악용 흔적은 발견되지 않았습니다 . 공개는 그로부터 4개월 뒤에 이루어졌습니다.
"서버가 한곳에 집중되면... 가치 있는 표적이 생긴다," — 중앙화된 MCP 호스팅의 구조적 위험에 대한 GitGuardian의 설명 (source: GitGuardian).
따져봐야 할 트레이드오프가 바로 이것입니다. Smithery를 편리하게 만드는 바로 그 집약성이 동시에 단일 고가치 표적으로 만듭니다. 게다가 목록에 올라갔다고 검증된 것은 아닙니다. 별도 스캔에서는 표본으로 확인한 Smithery 서버 100개 중 22개에서 보안 관련 발견 사항이 반환됐습니다 . 레지스트리에 포함됐다는 사실은 서버가 존재한다는 뜻일 뿐, 그 코드를 여러분의 자격 증명과 함께 실행해도 안전하다는 뜻은 아닙니다.
호스팅과 셀프 호스팅, 현실적인 선택 기준
배포 도달 범위, 관리형 OAuth 수명 주기, 폭넓은 클라이언트 호환성, 운영 부담 없는 온보딩이 지연 시간의 예측 가능성보다 중요하다면 호스팅을 선택하세요. 에이전트가 인증을 직접 연결하지 않고도 서버를 발견하고 접속하게 만들고 싶은 팀에게는 Smithery의 쓰기 전용 암호화 자격 증명 저장 방식, 즉 사용할 수는 있지만 읽을 수는 없는 구조가 시크릿을 평문 env 파일에 남겨두는 많은 DIY 구성보다 낫습니다 .
p99 지연 시간 보장, 데이터 레지던시, 감사 로그 소유권, 규제 경계, 언어 선택의 완전한 자유가 양보할 수 없는 조건이라면 셀프 호스팅을 선택하세요. warm VM이나 private VPC에 고정된 서버는 관리형 실행이 추상화해 버리는 배치, keepalive, 로깅 제어권을 제공합니다. 대신 인프라 운영과 패치는 직접 책임져야 합니다.
중간 경로는 URL 등록입니다. 호스팅은 직접 유지하고 Streamable HTTP 엔드포인트를 공개하면, 런타임 배치를 넘기지 않으면서도 Smithery의 발견성을 얻을 수 있습니다. 운영상 주의할 점이 하나 있습니다. WAF와 봇 보호가 Cloudflare Workers에서 들어오는 SmitheryBot/1.0 요청을 차단할 수 있으므로, 게이트웨이가 접근할 수 있도록 명시적 허용 규칙이나 정적 서버 카드가 필요할 수 있습니다 .
무엇을 선택하든 남는 공백은 같습니다. 검토한 문서 전반에서 Smithery의 콜드 스타트 특성, 호스팅 런타임 격리 모델, 시크릿 관리 내부 구조, 명시적인 SLA는 공개되어 있지 않습니다 . 결론은 단순합니다. 배포냐 예측 가능성이냐, 가장 강한 제약 조건에 배포 모델을 맞추세요. 그리고 문서화되지 않은 콜드 스타트 구간은 현재 측정 가능한 리스크가 아니라 받아들이기로 한 리스크로 취급해야 합니다.
자주 묻는 질문
Smithery는 호스팅 MCP 서버의 지연 시간 SLA를 공개하나요?
아니요. 검토한 Smithery 문서에는 p50/p95/p99 지연 시간 표, 리전 목록, scale-to-zero 설정, 공개된 콜드 스타트 설명이 없습니다 . 호스팅 서버는 Fly.io 머신에서 실행되며, 유휴 상태일 때 자동 중지되고 다음 요청에서 자동 시작될 수 있습니다. 이것이 콜드 스타트를 만드는 메커니즘입니다 . 자체 서버를 독립적으로 측정하지 않는 한, 콜드 스타트 시간은 단순히 짧다고 볼 수 있는 값이 아니라 알 수 없는 값입니다.
Smithery 호스팅 서버에서는 어떤 언어를 사용할 수 있나요?
배포 모델에 따라 다릅니다. runtime: "typescript"는 CLI가 @smithery/cli build를 실행하는 권장 호스팅 경로이며, TypeScript만 지원합니다 . runtime: "container"는 사용자가 만든 Dockerfile에서 Docker 이미지를 빌드하므로 어떤 언어든 사용할 수 있습니다 . URL 등록은 언어와 완전히 무관합니다. 자체 호스팅을 유지하면서 Smithery가 라우팅할 Streamable HTTP 엔드포인트만 노출하면 됩니다 .
2025년 6월 Smithery 경로 순회 사고에서는 정확히 무슨 일이 있었나요?
제출된 smithery.yaml의 검증되지 않은 dockerBuildPath 매개변수 때문에 조작된 빌드가 호스트의 ~/.docker/config.json을 읽을 수 있었고, 그 파일에는 정확히 3,243개 앱(호스팅 MCP 서버 3,000개 이상)이 속한 Fly.io 조직 전체에 machines-API 접근 권한을 가진 과도한 권한의 Fly.io API 토큰이 들어 있었습니다 . GitGuardian은 6월 10일 이를 발견해 6월 13일 보고했고, Smithery는 2025년 6월 15일까지 패치와 토큰 교체를 완료했으며 악용 증거는 없었습니다 .
Smithery의 Uplink 터널은 프로덕션에서 사용할 수 있나요?
아니요. Smithery의 설명 자체가 그렇습니다. Uplink는 지속적인 WebSocket 터널을 유지하는 CLI를 실행해 JSON-RPC를 로컬 프로세스와 연결하고 이를 일반 연결처럼 노출하지만, 문서에는 프로덕션 호스팅 용도가 아니며 가용성이 개발자 머신 상태를 따른다고 명시되어 있습니다 . 로컬 개발과 테스트에는 적합하지만, 안정적인 엔드포인트가 필요하다면 호스팅 런타임을 사용하거나 자체 상시 실행 배포를 가리키는 URL 등록을 사용하세요.
Smithery는 OAuth 자격 증명을 어떻게 저장하며, 누가 보관하나요?
Smithery 문서는 쓰기 전용 암호화 저장 방식을 설명합니다. 자격 증명은 실행 중인 서버에서 사용할 수 있지만, Smithery 직원을 포함해 다시 읽을 수는 없습니다 . 이는 많은 DIY 구성보다 낫지만, 그 대가로 보관 주체 문제가 생깁니다. 통합 시크릿이 자체 vault, KMS, 감사 스택이 아니라 Smithery 플랫폼 안에 있게 됩니다 . 2025년 6월 사고는 이런 집중의 위험을 보여줬습니다. 단일 과다 권한 토큰 하나가 교체되기 전까지 호스팅 앱 3,000개 이상에 도달할 수 있었습니다 .
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.
