공식 MCP 레지스트리 vs Smithery vs Glama vs PulseMCP vs mcp.so: 2026 최신 MCP 서버 레지스트리 신뢰도 비교 완전 가이드

글쓴이김성진·발행일2026년 8월 10일

AI 에이전트에 도구를 붙이는 표준으로 MCP(Model Context Protocol)가 자리를 잡으면서, “MCP 서버를 어디서 받나”라는 질문이 생겼습니다. 답은 하나가 아닙니다. 공식 레지스트리가 있고, 그보다 훨씬 많은 서버를 담은 상용 디렉터리가 넷 더 있습니다.

문제는 이 다섯 곳이 같은 서버를 서로 다르게 설명한다는 것입니다. 어떤 곳은 등급을 매기고, 어떤 곳은 배지를 붙이고, 어떤 곳은 아무것도 하지 않습니다. 그리고 원본 저장소에 문제가 생겼을 때 그 사실이 각 목록에 반영되는 속도도 전부 다릅니다.

이 글은 2026년 8월 10일에 다섯 레지스트리를 직접 조회해서 그 차이를 실측한 기록입니다.

30초 요약

한 줄 결론: 이름을 신뢰해야 한다면 공식 레지스트리, 폭넓게 찾아야 한다면 Glama, 그리고 어느 쪽이든 설치 직전에 원본 저장소를 직접 열어봐야 합니다.

1. 2026년 8월 10일, 무슨 일이 있었나

오늘 새벽 인기 MCP 서버 하나가 GitHub에서 사라졌습니다.

Blender MCP는 3D 도구 블렌더를 AI 에이전트에 붙이는 서버로, MCP 생태계 초기에 가장 널리 알려진 프로젝트 중 하나였습니다. 메인테이너 본인이 공개적으로 GitHub 계정이 탈취돼 저장소 소유권을 잃었다고 밝혔고, 같은 내용이 해커뉴스에도 한국 시간 오전 9시 58분경 등록됐습니다(항목 번호 49238028, 확인 시점 19포인트·댓글 4개).

여기서부터는 제가 직접 확인한 것입니다. 2026년 8월 10일 기준입니다.

읽는 법이 중요합니다. 계정이 사라진 게 아닙니다. 프로필은 정상 응답합니다. 저장소만 다른 조직으로 옮겨졌고, 옮겨간 그 조직 자체가 지금은 열리지 않습니다. 소유권이 이전된 뒤 GitHub 쪽 조치가 진행 중일 때 나타나는 모습에 가깝습니다.

스타 수는 본인이 밝힌 값이 약 25,000개(Blender MCP), 약 2,600개(Ableton MCP)입니다. 저장소가 열리지 않으므로 GitHub에서 직접 재확인할 수 없고, 뒤에 나오는 PulseMCP 리스팅이 25.4k로 캐시하고 있어 간접 확인만 가능합니다.

오해하기 쉬운 지점 세 가지

첫째, 이건 레지스트리가 뚫린 사건이 아닙니다. 공식 레지스트리에 ahujasid를 검색하면 결과가 0건입니다. 이 서버는 애초에 공식 레지스트리에 올라온 적이 없습니다. 사건의 성격은 개발자 계정 탈취이고, 레지스트리의 공급망이 깨진 것이 아닙니다.

둘째, 따라서 “공식 레지스트리를 썼다면 막을 수 있었다”는 말은 이 사례에는 성립하지 않습니다. 이 글이 보려는 것은 사고를 막았느냐가 아니라, 사고가 난 뒤 각 목록이 얼마나 빨리 그 사실을 반영하느냐입니다.

셋째, 6월에 공개된 CVE 두 건과 섞으면 안 됩니다. Blender MCP에는 CVE-2026-10661과 CVE-2026-10662가 있지만 둘 다 CVSS v4.0 기준 2.1 LOW이고, 깃허브 권고의 심각도 라벨도 Low입니다. 공개일도 6월 2~3일로 두 달 전입니다. 이번 계정 탈취와는 별개의 건입니다.

2. 다섯 레지스트리는 지금 이 서버를 어떻게 보여주고 있나

같은 서버, 같은 시각, 다섯 곳의 응답입니다.

각각을 조금 더 자세히 보겠습니다.

공식 레지스트리는 API가 명확한 답을 줍니다.

GET /v0/servers?search=ahujasid
→ {"servers":[],"metadata":{"count":0}}

없는 것은 없다고 말합니다. 등재 기준이 있으니 미등재도 정보가 됩니다.

Glama는 페이지가 정상적으로 열립니다. 문서 안에 ahujasid/blender-mcp가 75회, github.com/ahujasid가 6회 등장하고, License·Quality·Maintenance 세 등급이 그대로 표시됩니다. warning, archived, unavailable 문자열은 0회입니다. 지금 열리지 않는 저장소를 가리키면서 초록불이 켜져 있는 상태입니다.

PulseMCP도 리스팅이 살아 있고 25.4k 스타를 표시합니다. 다만 이 페이지에는 다른 곳에 없는 문장이 하나 있습니다.

“We (PulseMCP) are temporarily managing this server.json file until the maintainer publishes it to the official registry.” (메인테이너가 공식 레지스트리에 게시할 때까지 우리가 이 server.json 파일을 임시로 관리하고 있습니다.)

경고는 아니지만, 누가 이 항목을 관리하고 있는지 밝히는 문장입니다. 다섯 곳 중 이 정보를 노출한 곳은 여기뿐이었습니다.

mcp.so는 가장 흥미롭습니다. 페이지에 박힌 데이터에 이런 필드들이 있습니다.

마지막 동기화가 약 한 달 전입니다. 오늘 벌어진 일을 모르는 게 당연합니다. 그리고 그 사실이 페이지 데이터에 그대로 적혀 있습니다. 화면에 크게 보여주지는 않지만, 판단에 필요한 정보를 숨기지는 않은 셈입니다.

Smithery는 상세가 열리지 않았습니다. 이 판정에는 함정이 있어서, 뒤에서 따로 다루겠습니다.

중요한 단서

이 표는 관측이지 평가가 아닙니다. 세 곳이 경고를 띄우지 않은 이유가 “방치”인지 “아직 갱신 주기가 돌아오지 않음”인지는 밖에서 알 수 없습니다. 갱신 주기를 공개한 곳이 없기 때문입니다. mcp.so처럼 마지막 동기화 시각을 노출한 곳만 그 판단이 가능합니다.

그래서 이 사건에서 끌어낼 수 있는 교훈은 “어느 레지스트리가 나쁘다”가 아니라 이것입니다. 레지스트리의 초록불은 실시간 신호가 아니라 과거 어느 시점의 스냅숏이다.

3. 레지스트리 5곳 전체 비교표

숫자를 읽을 때 주의할 점을 먼저 밝힙니다.

• 합산하면 안 됩니다. 개별 공표치만 더해도 12만을 넘지만, 같은 서버가 여러 곳에 중복 등재됩니다. 중복 제거를 한 곳이 없으므로 “전 세계 MCP 서버 N개”라는 숫자는 만들 수 없습니다.
• 공식 레지스트리의 총계는 단정할 수 없습니다. API 응답의 metadata에는 nextCursor와 현재 페이지 count만 있고 전체 총계 필드가 없습니다. 커서로 한 페이지씩 넘기며 세는 방법밖에 없는데, 직접 401페이지(4만 건)까지 넘겨도 다음 커서가 계속 남아 있었습니다. 다만 중복 등재를 걸러내지 않은 값이라 이 글에서는 숫자로 쓰지 않았습니다. “제일 작은 목록”이라는 통념은 최소한 사실이 아닙니다.
• mcp.so는 홈에 자체 총계를 공표하지 않았습니다. 페이지에 큰 숫자가 보이지만 다른 서비스를 소개하는 문구 안의 값이라 mcp.so의 등재 수가 아닙니다.

4. 공식 MCP 레지스트리 — 유일하게 “이름”을 지키는 곳

registry.modelcontextprotocol.io입니다. 나머지 넷과 결정적으로 다른 점이 하나 있습니다. 이름의 소유권을 증명하게 합니다.

네 가지 증명 방식

이 절차가 있어서 io.github.<계정>/<서버> 같은 이름은 그 계정의 소유자만 게시할 수 있습니다. 다른 넷은 원본 저장소 URL을 긁어 목록을 만들 뿐, 이름을 배타적으로 배정하지 않습니다.

이름 탈취를 막는 일은 계속되고 있습니다

가장 최근 릴리스는 **v1.8.1(2026년 8월 6일)**입니다. 14개의 변경 중에 이런 항목이 있습니다.

fix(auth): reject github.io domains in DNS/HTTP token exchange (org namespace takeover)

DNS·HTTP 토큰 교환에서 github.io 도메인을 거부하도록 고친 것입니다. GitHub Pages는 누구나 <계정>.github.io를 가질 수 있으니, 이걸 도메인 증명에 쓰면 남의 조직 이름을 가져갈 여지가 생깁니다.

다만 이것을 “보안 패치 긴급 배포”로 읽으면 과장입니다. 14개 PR이 묶인 정기 릴리스 안의 한 줄이고, 대응하는 보안 권고(GHSA/CVE)도 없으며 실제 악용 정황이 공개된 것도 아닙니다. 정확히는 “이름 탈취 경로 하나를 사전에 막은 정기 릴리스”입니다.

거버넌스 — 흔한 오해 하나

공식 레지스트리를 “앤트로픽·깃허브·마이크로소프트 공동 운영”으로 소개하는 글이 있는데, 저장소가 명시하는 워킹그룹 메인테이너는 다음 네 명입니다.

저장소 스타는 확인 시점 7.1k입니다.

여기서 눈여겨볼 것은 두 번째 줄입니다. PulseMCP 쪽 인물이 공식 레지스트리의 메인테이너입니다. 상용 레지스트리 운영자가 표준 레지스트리를 함께 만들고 있는 구조인데, 앞에서 본 “우리가 임시로 관리하고 있다”는 안내 문장도 이 맥락에서 이해됩니다. 이해충돌로 볼 여지도 있지만, 최소한 누가 관여하는지가 공개돼 있다는 점은 나머지 셋과 다릅니다.

이런 사람에게

• 사내 표준으로 MCP 서버를 배포해야 하는 팀
• 이름을 도용당하면 곤란한 오픈소스 메인테이너
• “이 이름은 정말 그 회사가 낸 것인가”를 기계적으로 확인해야 하는 경우

한계: 등재가 자발적입니다. 오늘 사례의 서버처럼 스타 2만 개가 넘는 유명 프로젝트도 여기에는 없을 수 있습니다. 그리고 총계 API가 없어 규모를 파악하려면 커서 페이징으로 직접 세는 수밖에 없습니다.

5. Glama — 가장 크고, 가장 많이 판단해 주는 곳

확인 시점 화면 표기는 이렇습니다.

70,261 servers. Updated 2026-08-10 09:25

다섯 곳 중 갱신 시각을 화면에 직접 적어 두는 유일한 곳입니다. 별것 아닌 것 같지만, 목록형 서비스에서 이 값은 신뢰의 핵심입니다. 언제 기준인지 모르는 목록은 판단에 쓸 수 없기 때문입니다.

등급 3종

자동 분석으로 매기는 값입니다. 서버 하나하나를 사람이 검수했다는 뜻은 아닙니다.

그리고 오늘 확인된 것처럼, 원본이 열리지 않게 된 뒤에도 이 등급은 그대로 남아 있었습니다. Maintenance 등급이 “유지보수되고 있다”가 아니라 “마지막으로 봤을 때 유지보수되고 있었다”임을 보여주는 사례입니다.

이런 사람에게

• 목적에 맞는 MCP 서버를 폭넓게 탐색하고 싶은 사람
• 라이선스를 먼저 걸러야 하는 상업 프로젝트
• 후보를 여러 개 모아 비교하는 단계

한계: 등급을 최종 판정으로 읽으면 위험합니다. 등급은 스냅숏입니다.

6. PulseMCP — 검수했다고 말하지 않는 정직함

확인 시점 표기는 **“Showing 1 - 42 of 22,078 servers”**입니다. 분류는 세 가지뿐입니다.

출처가 어디냐로만 나눕니다. 품질 점수도, 등급도 없습니다.

이걸 기능 부족으로 볼 수도 있지만 저는 반대로 봅니다. 페이지 어디에도 검수·심사 절차를 설명하는 문장이 없고, 없는 것을 있는 것처럼 말하지 않습니다. 자동 분석 결과에 A~F를 붙여 두면 사용자는 그것을 사람의 판단으로 오해하기 쉽습니다.

앞서 본 “우리가 임시로 server.json을 관리 중”이라는 안내도 같은 성격입니다. 관리 주체를 드러내는 문장이니까요.

이런 사람에게

• “공식 제공사가 직접 낸 것”만 쓰고 싶은 사람
• 등급을 믿기보다 직접 판단하려는 사람

한계: 규모가 Glama의 3분의 1이고, 갱신 시각을 알 수 없습니다. 오늘 사례에서도 25.4k 스타 캐시가 그대로 남아 있었습니다.

7. Smithery — 설치가 중심, 그리고 판정의 함정

확인 시점 홈 표기는 **“Browse 14,143+ MCPs”**입니다. 개별 리스팅에 verified 배지가 붙는데, 그 기준을 설명하는 문서를 찾을 수 없었습니다. verified가 몇 개인지도 공개돼 있지 않습니다. 기준을 모르는 배지는 판단 근거로 쓰기 어렵습니다.

여기서 저는 한 번 틀릴 뻔했습니다

문제의 서버 페이지를 열었더니 HTML 안에 이런 문자열이 있었습니다.

"404: Server Not Found or Removed"

“Smithery는 이미 내렸구나” 하고 쓸 뻔했습니다. 그런데 살아 있는 게 확실한 다른 리스팅을 열어 봐도 같은 문자열이 똑같이 들어 있었습니다. 최신 프런트엔드 프레임워크가 에러 화면 컴포넌트를 미리 실어 보내기 때문입니다. 화면에 안 보여도 HTML에는 있습니다.

그래서 기준선을 만들었습니다. 존재할 리 없는 주소를 하나 만들어 함께 재 봤습니다.

문제의 페이지는 가짜 주소와 사실상 같은 크기입니다. 즉 상세 내용이 실려 있지 않습니다. 반면 정상 리스팅은 두 배 가까이 큽니다.

여기서 말할 수 있는 것은 “확인 시점에 상세가 서빙되지 않았다”까지입니다. 언제부터 그랬는지, 원래 있었는지는 알 수 없습니다. 사고에 대응해 내린 것인지, 애초에 그 경로에 없었던 것인지 밖에서는 구분되지 않습니다.

이 대목이 이 글에서 가장 실용적인 부분일지도 모릅니다. 페이지에 특정 단어가 있는지로 상태를 판정하면 틀립니다. 반드시 정상 사례와 비정상 사례를 함께 재서 기준선을 잡아야 합니다.

이런 사람에게

• 설치 명령까지 한 번에 끝내고 싶은 사람
• 클라이언트 설정 파일을 손으로 쓰기 번거로운 사람

한계: verified 기준이 공개되지 않았습니다.

8. mcp.so — 화면보다 데이터가 정직한 곳

홈에 자체 등재 총계를 공표하지 않습니다. 대신 개별 리스팅의 페이지 데이터에 판단 재료가 들어 있습니다. 오늘 확인한 값이 앞서 본 그 표입니다. lastSyncedAt이 2026년 7월 9일, lastCommitAt이 6월 11일, qualityScore 30, verified와 archived는 모두 false였습니다.

archived: false는 틀린 값이 아닙니다. 한 달 전 기준으로는 맞았습니다. 그리고 그 “한 달 전”이라는 사실이 같은 데이터 안에 함께 들어 있습니다.

화면에 크게 띄우지 않는 건 아쉽지만, 판단에 필요한 정보를 감추지는 않았습니다. 다섯 곳 중 마지막 동기화 시각을 확인할 수 있었던 곳은 여기와 Glama(전체 갱신 시각) 둘뿐입니다.

이런 사람에게

• 여러 소스를 한 화면에서 훑고 싶은 사람
• 리스팅 데이터의 신선도를 직접 따져 보려는 사람

9. “신뢰”는 하나가 아니라 네 가지입니다

레지스트리를 비교하다 보면 신뢰라는 말이 서로 다른 네 가지를 뭉뚱그리고 있음을 알게 됩니다.

두 번째 줄이 핵심입니다. 다섯 곳 중 어디도 서버 코드가 안전한지 검사한다고 말하지 않습니다. Glama의 Quality는 코드 품질 지표이지 보안 감사가 아니고, Smithery의 verified는 기준이 공개돼 있지 않으며, mcp.so의 qualityScore도 마찬가지입니다.

레지스트리에 있다는 것은 “존재한다”는 뜻이지 “안전하다”는 뜻이 아닙니다.

10. 상황별 추천

11. MCP 서버 설치 전 체크리스트

레지스트리가 대신해 주지 않는 일들입니다. 오늘 사례가 그대로 근거가 됩니다.

1. 원본 저장소를 직접 연다. 레지스트리 링크를 클릭해 실제로 열리는지 봅니다. 오늘 세 곳이 지금 열리지 않는 주소를 가리키고 있었습니다.
2. 리다이렉트를 확인한다. 주소창이 다른 소유자로 바뀌면 소유권이 이전된 것입니다. 목록에는 옛 주소가 남아 있습니다.
3. 마지막 커밋 날짜를 본다. 등급이 아니라 날짜입니다.
4. 버전을 고정한다. latest로 물어두면 소유자가 바뀐 뒤의 코드가 자동으로 들어옵니다.
5. 권한을 최소로 준다. 파일 시스템 전체·셸 실행·네트워크를 한꺼번에 열어 주는 설정을 피합니다.
6. 이름을 눈으로 읽는다. 한 글자 다른 유사 이름이 표준적인 수법입니다.
7. 공식 레지스트리에 있는지 교차 확인한다. 없다고 위험한 것은 아니지만, 있으면 이름 소유권만큼은 검증된 것입니다.

12. 자주 묻는 질문

Q. 공식 레지스트리에 없으면 위험한 서버인가요? 아닙니다. 오늘 사례의 서버도 미등재였지만 스타 2만 개가 넘는 유명 프로젝트였습니다. 등재는 이름 소유권이 증명됐다는 뜻이지 품질 인증이 아닙니다.

Q. 그럼 등급이나 배지는 왜 있나요? 후보를 좁히는 데는 쓸모가 있습니다. 라이선스가 불명확한 것을 먼저 거르는 식입니다. 최종 판단으로 쓰지 말라는 것이지, 무용하다는 뜻이 아닙니다.

Q. 전 세계 MCP 서버는 몇 개인가요? 알 수 없습니다. 각 목록의 공표치를 더하면 12만이 넘지만 중복 등재가 제거되지 않았습니다. 중복을 제거한 고유 개수를 공개한 곳은 없습니다.

Q. 오늘 그 저장소는 복구되나요? 이 글을 쓰는 시점에는 알 수 없습니다. 넘겨받은 조직 주소가 404라는 것은 조치가 진행 중이라는 신호로 읽히지만, 결과는 확정되지 않았습니다.

Q. 이 글의 수치는 언제까지 유효한가요? 관측 값은 2026년 8월 10일 기준입니다. 등재 수는 매일 바뀌고, 리스팅 상태는 몇 시간 안에도 바뀔 수 있습니다. 표의 숫자보다 판단하는 방법을 가져가시는 편이 오래갑니다.

13. 정리

MCP 레지스트리는 다섯 곳이 서로 다른 일을 합니다.

• 공식 레지스트리는 이름의 원장입니다. 규모는 가장 작지만 이름 소유권을 증명하게 하는 유일한 곳이고, 8월 6일 v1.8.1에서도 이름 탈취 경로를 하나 더 막았습니다.
• Glama는 가장 큰 카탈로그이고 갱신 시각을 화면에 적는 유일한 곳입니다. 다만 등급은 과거 시점의 스냅숏입니다.
• PulseMCP는 출처로만 분류하고 검수했다고 말하지 않습니다. 관리 주체를 밝히는 문장도 여기에만 있었습니다.
• Smithery는 설치가 중심이고, verified 기준은 공개돼 있지 않습니다.
• mcp.so는 화면보다 데이터가 정직합니다. 마지막 동기화 시각이 그대로 들어 있습니다.

오늘 하루의 관측에서 남는 문장은 하나입니다. 레지스트리의 초록불은 실시간 상태가 아니라 과거 어느 시점의 스냅숏입니다. 그러니 설치 직전에 원본 저장소를 한 번 열어보는 30초가, 어떤 등급이나 배지보다 확실합니다.

MCP를 에이전트에 붙이는 프레임워크 자체를 고르는 단계라면 AI 에이전트 프레임워크 비교 글을 함께 보시면 도움이 됩니다.