11개의 공개 MCP 서버를 모니터링했습니다. 지연 시간은 215배(97ms에서 21초까지) 차이가 났습니다.

요약(TL;DR): 저는 MCP 프로토콜을 사용하는 아주 작은 도구를 만들어 11개의 공개 Model Context Protocol (MCP) 서버를 대상으로 실행해 보았습니다. 핸드셰이크(Handshake) 지연 시간은 97ms에서 거의 21초까지, 즉 215배의 차이를 보였습니다. 그리고 더 큰 문제는 다운타임(Downtime)이 전혀 아니었습니다. 하단에 무료 라이브 인덱스(Live index)와 오픈 소스 CLI를 제공합니다.

갈증 (The itch)

Model Context Protocol은 약 1년 만에 제안 단계에서 10,000개 이상의 공개 서버로 성장했습니다. 이제 에이전트(Agents)는 웹 앱이 API에 의존하는 것과 같은 방식으로 이 서버들에 의존합니다. 하지만 저는 이들을 기반으로 개발하는 동안 불안정한 실패를 계속 겪었고, 이것이 내 코드 때문인지, 아니면 서버 때문인지 알 수 없었습니다.

MCP를 위한 Pingdom(모니터링 서비스)은 없습니다. 그래서 제가 직접 만들었습니다. 그리고 가장 먼저 한 일은 잘 알려진 공개 서버 세트를 대상으로 지정하는 것이었습니다.

작동 방식 (API가 아닌, 오직 프로토콜만 사용)

핵심은 MCP가 단순한 프로토콜 — 즉, HTTP 기반의 JSON-RPC라는 점입니다. 따라서 어떤 제3자 API를 호출하는 대신, 이 도구는 에이전트인 척합니다. Claude나 다른 MCP 클라이언트가 하는 것과 똑같이 실제 핸드셰이크(초기화 후 도구 목록 조회)를 실행하고 왕복 시간(Round trip)을 측정합니다. 의존성 제로, 약 150줄의 코드입니다.

발견 1: 215배의 지연 시간 격차

서버	핸드셰이크 지연 시간	도구(Tools)
Hugging Face	97 ms	8
...

중앙값(Median)은 522ms였습니다. 만약 당신의 에이전트가 21초가 걸리는 서버의 도구를 호출한다면, 사용자는 21초 동안 로딩 스피너를 바라보거나 요청이 타임아웃(Timeout)될 것입니다. 여기서 지연 시간은 단순한 수치가 아닙니다. 에이전트가 제대로 작동하느냐, 아니면 멈춰버리느냐의 문제입니다.

발견 2: 진짜 사각지대 — 계약 드리프트 (Contract drift)

이 11개의 서버는 총 245개의 도구를 노출합니다. 모든 도구는 하나의 계약(Contract)입니다. 즉, 에이전트가 의존하는 이름과 필수 입력값 세트입니다.

여기에 아무도 감시하지 않는 문제가 있습니다. 일반적인 업타임 모니터(Uptime monitor)는 200 OK를 확인하고 '정상'이라고 판단합니다. 하지만 MCP 서버는 서버가 다운됨으로써 실패하는 경우가 드뭅니다. 대신 계약을 조용히 변경함으로써 실패합니다. 재배포 과정에서 도구의 이름이 바뀌거나, 선택적 파라미터(Optional param)가 필수(Required)가 되거나, 도구가 사라지는 식입니다. 서버는 여전히 200 OK를 반환하지만, 이를 호출하는 모든 에이전트는 조용히 고장 납니다.

업타임 (Uptime)은 서버가 응답했다는 사실을 알려줄 뿐입니다. 서버가 여전히 에이전트가 기대하는 대로 동작하고 있는지는 알려줄 수 없습니다.

이를 포착하려면 실제로 프로토콜 (Protocol)을 사용하여 통신하고, 시간에 따라 도구 스키마 (Tool schemas)를 비교 (Diffing)해야 합니다. 그것이 이 도구의 핵심 목적입니다.

사용해 보기

• 무료 라이브 인덱스 (지속적으로 업데이트됨): https://mcpwatch.app/reliability-index.html
• 전체 보고서: https://mcpwatch.app/report.html
• 오픈 소스 CLI (MIT): npx mcpwatch — https://github.com/ClaudefoustCEO/mcpwatch

만약 MCP 서버를 운영 중이시라면, 인덱스에 진심으로 추가해 드리고 싶습니다. 댓글에 URL을 남겨주세요. 그리고 제가 미처 생각하지 못한 것 중, 여러분이 모니터링되기를 원하는 것이 무엇인지도 궁금합니다.