모든 원격 MCP 서버의 약 절반이 작동하지 않는다는 이야기가 돌고 있습니다.

저 또한 제가 게시한 도구의 README에서 이 말을 반복한 적이 있습니다. 그 이야기가 어디서 시작되었는지 찾을 수 없어서, 제가 직접 측정해 보았습니다.

결과는 실제로 10개 중 약 하나가 고장 나 있다는 것이었습니다. "절반"이라는 수치는 API 키를 요구하는 서버를 작동하지 않는 것으로 간주하여 계산한 데서 비롯된 것으로 보입니다.

다음은 측정 방법과 전체 분석 내용입니다.

측정 대상

2026년 7월 29일, 저는 공식 MCP 레지스트리에서 모든 항목인 1,200개의 서버를 가져왔습니다. 그중 297개는 status: active 상태였으며 원격 엔드포인트 URL을 광고하고 있었습니다 (나머지는 네트워크를 통해 조사할 수 없는 stdio/로컬 패키지입니다).

각 서버에 대해 스트리밍 가능한 HTTP를 통해 10초의 타임아웃을 설정하고 익명의 JSON-RPC initialize 요청을 한 번씩 보냈습니다:

{
  "jsonrpc": "2.0", "id": 1, "method": "initialize",
  "params": {
...

그 후 응답을 분류했습니다: protocolVersion 또는 serverInfo를 포함하는 유효한 result가 있으면 정상 작동(up)으로 간주하고, 401/403은 인증 제한(auth-gated)으로, 그 외의 모든 것은 실제 실패 유형에 따라 분류했습니다.

결과 (n = 297)

"절반이 작동하지 않는다"는 말이 나오는 이유

처음 두 행을 보십시오. 이 엔드포인트의 55.2%는 익명 핸드셰이크를 완료하지 못할 것인데, 이는 사람들이 인용하는 수치와 의심스러울 정도로 가깝습니다.

하지만 이 164개 중 134개는 깔끔하게 401 또는 403 응답을 반환하고 있습니다. 이들은 작동 중입니다. 응답을 하고 있습니다. 단지 API 키를 요구할 뿐이며, 이는 호스팅된 서비스가 요구할 수 있는 매우 합리적인 사항입니다.

이들을 작동하지 않는 것으로 계산하면 실패율이 대략 5배 정도 부풀려지게 됩니다.

이것은 단순한 결벽증의 문제가 아닙니다. 만약 생태계의 절반이 폐허라고 믿는다면, 당신은 잘못된 대상에 대해 방어적으로 구축하게 됩니다. 실제 실패 분포는 진정으로 죽어버린 호스트들의 작은 꼬리 부분(small tail)에 불과합니다. 대부분은 더 이상 해석되지 않는 DNS (DNS that no longer resolves) 문제인데, 이는 불안정한 서비스라기보다는 방치된 데모의 전형적인 특징입니다.

수치가 포착하지 못하는 실패

생존 여부(Liveness)는 쉬운 질문이며, 당신을 괴롭힐 질문도 아닙니다.

서버가 완벽한 핸드셰이크 (handshake)를 반환하더라도 그에 의존하는 모든 에이전트 (agent)를 망가뜨릴 수 있습니다. 왜냐하면 에이전트가 실제로 소비하는 것은 도구 계약 (tool contract), 즉 이름, 설명, 그리고 입력 스키마 (input schemas)이기 때문입니다. 도구의 이름을 바꾸거나, 필수 파라미터 (parameter)를 추가하거나, 열거형 (enum)을 엄격하게 제한하면, 엔드포인트 (endpoint)는 정상(green) 상태를 유지하지만 당신의 에이전트는 실행 도중 호출 시점에 실패하게 되며, 이는 마치 모델 오류처럼 보일 것입니다.

다운타임 (Downtime)은 요란하게 발생합니다. 스키마 드리프트 (Schema drift)는 조용히 발생하며, "오늘따라 AI가 이상하네"라는 식으로 나타납니다.

따라서 URL에 핑 (ping)을 보내는 업타임 (uptime) 체크는 가용한 속성 중 가장 흥미 없는 속성을 측정하는 것입니다. 당신이 관찰해야 할 것은 도구 인벤토리 (tool inventory)와 스키마가 마지막으로 확인했을 때 이후로 변경되었는지 여부입니다.

솔직하게 밝히는 주의사항

• 익명의 핸드셰이크는 하한선입니다. 인증 (Auth)이 걸린 서버들은 인증 장벽 뒤에서 작동하지 않을 수도 있습니다. 저는 그 너머를 볼 수 없으며, 그렇지 않다고 주장하지도 않습니다. 10.1%는 "고장 난" 상태의 천장이 아니라 바닥입니다.
• 단 한 번의 탐색, 단 한 순간. UTC 14:00에 타임아웃 (timeout)이 발생했던 서버가 지금은 괜찮을 수도 있습니다. 이것은 스냅샷 (snapshot)이지, 업타임 백분율이 아닙니다.
• 레지스트리에 등록된 것만 해당. 수많은 MCP 서버들이 등록되지 않은 상태로 존재하며, 이 결과는 그들에 대해 아무것도 말해주지 않습니다.
• 리다이렉트 (Redirects)는 사용 불가능한 것으로 간주. 4개의 서버가 307/308 응답을 반환했습니다. 관대한 클라이언트라면 이를 따랐겠지만, 저는 따르지 않았습니다. 리다이렉트를 맹목적으로 따르는 것이 엔드포인트 체크 도구가 SSRF (Server-Side Request Forgery) 벡터가 되는 방식이기 때문입니다.

재현하기

전체 스캔 과정은 약 60줄 정도입니다. /v0/servers를 페이지 단위로 탐색하고, 원격 URL(remote URL)이 있는 활성 항목을 유지하며, 하나의 initialize를 POST하고, 응답을 버킷(bucket)에 담는 방식입니다. 만약 이 과정을 실행했을 때 결과 수치가 실질적으로 다르게 나온다면, 저는 진심으로 그 이유를 알고 싶습니다.

또한 저는 이 체크 도구를 무료 도구로 공개했습니다. 이 도구는 핸드셰이크(handshake), 도구 인벤토리(tool inventory), 그리고 스키마 드리프트(schema-drift) 비교를 수행하며, 라이브 MCP 서버 (레지스트리의 io.github.park11innyc-lgtm/mcp-uptime) 및 Apify Actor 형태로 제공됩니다. 인증도 필요 없고 비용도 들지 않습니다.

일반적인 교훈

저는 도구가 전문성을 주장하는 바로 그 도메인에 대해, 검증되지 않은 수치를 README의 공개 페이지에 게시했습니다.

이는 제가 다른 관점에서도 계속해서 쓰고 있는 것과 동일한 실수입니다. 즉, 결과물(artifact) 대신 상태(status) 필드를 신뢰하는 것, 그리고 튜토리얼에서 생략되는 MCP의 운영적인 부분들에 관한 문제입니다. 널리 반복되는 통계 수치는 상태 필드와 같습니다. 그것은 지식처럼 느껴지지만, 실제로는 누군가의 검증되지 않은 주장이 전달된 것에 불과합니다.

이를 측정하는 데는 한 시간도 채 걸리지 않았습니다.