MCP Registry

MCP 서버를 직접 만들어서 사용하고 계신가요? 아니면 남이 만든 MCP 서버를 찾아서 쓰고 싶은데 어디서 구해야 할지 막막하셨나요? 🤔

MCP(Model Context Protocol)가 AI와 외부 시스템 간의 표준 통신 규격으로 자리 잡으면서 MCP 서버 수가 엄청나게 늘고 있습니다. 2026년 2월 기준으로 공개된 MCP 서버만 1만 개가 넘어요. 그런데 이 많은 서버 중에서 원하는 걸 어떻게 찾고, 믿을 만한 서버인지 어떻게 판단할까요?

이 문제를 해결하려고 Anthropic, GitHub, Microsoft, PulseMCP가 힘을 합쳐 MCP Registry를 만들었습니다. npm이 JavaScript 패키지의 허브가 된 것처럼 MCP 서버 생태계의 중심을 잡겠다는 프로젝트인데요. 이 글에서는 MCP Registry가 무엇이고 어떻게 활용하는지 살펴보겠습니다.

MCP Registry란?

MCP Registry는 공개된 MCP 서버의 메타데이터를 모아 놓은 공식 저장소입니다. 2025년 9월에 프리뷰로 출시되었고, 2026년 2월 현재 518개의 서버가 등록되어 있어요.

여기서 중요한 점은 MCP Registry가 실제 코드나 바이너리를 호스팅하지 않는다는 겁니다. 대신 “이 서버는 npm에서 이 패키지로 설치할 수 있어요”라는 메타데이터만 관리합니다. 실제 패키지는 npm, PyPI, Docker Hub 같은 기존 패키지 레지스트리에 그대로 올라가 있죠. 이런 구조 덕분에 기존 생태계를 중복하지 않으면서도 MCP 서버를 한곳에서 검색하고 발견할 수 있게 됩니다.

비유하자면, MCP Registry는 음식 배달 앱과 비슷합니다. 배달 앱이 직접 음식을 만들지 않고 레스토랑 정보만 모아서 보여주듯이, MCP Registry도 서버의 코드를 호스팅하지 않고 “어디서 받을 수 있는지” 정보만 모아서 보여줍니다.

생태계 구조

MCP Registry의 생태계는 세 개의 층으로 나뉩니다.

공식 MCP Registry가 꼭대기에 있어요. 모든 MCP 서버 메타데이터의 원본 출처이자 서버 개발자가 직접 등록하는 곳입니다. 그 아래로 서브레지스트리(Subregistry)와 어그리게이터(Aggregator)가 공식 레지스트리의 데이터를 가져가서 사용자 평점이나 보안 스캔 결과, 큐레이션 같은 부가 가치를 더합니다. 여러 배달 앱이 같은 레스토랑 데이터를 가져가면서도 자체 리뷰 시스템을 운영하는 것과 비슷하죠.

그리고 Claude, ChatGPT, Cursor, VS Code 같은 MCP 호스트 애플리케이션은 이 서브레지스트리를 통해 MCP 서버를 검색하고 설치합니다. 공식 레지스트리를 직접 쓰도록 설계된 게 아니라 중간 단계를 거치게끔 의도적으로 만들어진 구조에요.

graph TD
    A[공식 MCP Registry<br/>메타데이터 원본] --> B[서브레지스트리 / 어그리게이터<br/>큐레이션, 평점, 보안 스캔]
    B --> C[MCP 호스트 앱<br/>Claude, ChatGPT, Cursor, VS Code]

npm이 하나의 거대한 레지스트리로 모든 걸 처리하는 것과 대조적이죠? MCP Registry는 처음부터 연합(federation) 모델을 염두에 두고 설계되었습니다.

server.json 형식

MCP Registry에 서버를 등록하려면 server.json 파일이 필요합니다. 이 파일은 서버의 신원, 설치 방법, 실행 방법을 표준화된 형식으로 담고 있어요.

server.json

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.my-username/weather",
  "description": "날씨 정보를 제공하는 MCP 서버",
  "repository": {
    "url": "https://github.com/my-username/mcp-weather-server",
    "source": "github"
  },
  "version": "1.0.1",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.1",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

이 파일에서 눈여겨볼 부분이 몇 가지 있습니다.

우선 name 필드는 역방향 DNS(Reverse DNS) 형식을 씁니다. io.github.my-username/weather처럼요. Java 개발자라면 패키지 네이밍에서 이 방식을 보셨을 텐데, 소유자를 명확히 식별할 수 있어서 네임스페이스 충돌을 방지합니다. GitHub 사용자라면 io.github.{username}/*, 자체 도메인이 있다면 com.example.*/* 형식으로 등록해요.

packages 배열은 이 서버를 어떤 패키지 레지스트리에서 받을 수 있는지 알려줍니다. npm뿐 아니라 PyPI, Docker Hub, NuGet 등 여러 레지스트리를 동시에 지정할 수 있어요. 같은 MCP 서버를 TypeScript로도, Python으로도 배포하는 경우에 유용합니다.

transport 필드는 서버의 통신 방식을 지정합니다. 로컬에서 실행되는 서버는 stdio를, 원격 서버는 streamable-http이나 sse를 사용합니다.

지원하는 패키지 타입

MCP Registry는 다양한 패키지 레지스트리를 지원합니다. 각 타입별로 소유권을 확인하는 방법이 다른데요.

npm — package.json에 mcpName 필드를 추가하여 소유권 확인
PyPI — README에 mcp-name: 텍스트를 포함 (HTML 주석도 가능)
NuGet — README에 mcp-name: 텍스트를 포함
Docker/OCI — Docker 라벨 io.modelcontextprotocol.server.name으로 확인. Docker Hub, ghcr.io, Google/Azure CR 지원
MCPB — GitHub/GitLab 릴리즈 바이너리. URL에 “mcp”를 포함해야 하며 fileSha256 필수

npm의 경우를 예로 들면, package.json에 다음과 같이 mcpName을 추가합니다.

package.json

{
  "name": "@my-username/mcp-weather-server",
  "version": "1.0.1",
  "mcpName": "io.github.my-username/weather"
}

이 mcpName 값이 server.json의 name과 일치해야 소유권 검증을 통과합니다. 레지스트리가 npm에서 패키지를 가져와서 mcpName이 맞는지 확인하는 방식이에요.

원격 서버 등록

MCP 서버를 사용자 로컬에 설치하는 대신 원격으로 호스팅할 수도 있습니다. 이 경우 packages 대신 remotes 속성을 사용해요.

원격 서버 설정

{
  "name": "com.example/analytics",
  "description": "분석 데이터를 제공하는 원격 MCP 서버",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://analytics.example.com/mcp"
    }
  ]
}

URL에 템플릿 변수도 쓸 수 있어서 https://{tenant_id}.example.com/mcp 같은 멀티테넌트 구조도 지원합니다. packages와 remotes를 동시에 지정하면 “로컬 설치도 가능하고 원격으로도 쓸 수 있는” 하이브리드 서버도 만들 수 있죠.

MCP 서버 등록하기

직접 만든 MCP 서버를 레지스트리에 등록하는 과정을 TypeScript/npm 기준으로 살펴볼게요.

먼저 mcp-publisher CLI를 설치합니다.

# macOS/Linux
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher && sudo mv mcp-publisher /usr/local/bin/

# Homebrew
brew install mcp-publisher

npm 패키지의 package.json에 mcpName을 추가하고 npm에 배포합니다.

npm publish --access public

그 다음 server.json을 생성합니다. init 명령어가 템플릿을 만들어 줘요.

mcp-publisher init

GitHub 계정으로 로그인한 뒤 배포합니다.

# GitHub OAuth 로그인
mcp-publisher login github

# 레지스트리에 등록
mcp-publisher publish

등록이 잘 됐는지 확인해 봅시다.

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"

--dry-run 옵션을 쓰면 실제 등록 없이 유효성만 검사할 수 있어서, 처음에는 이걸로 먼저 확인해 보는 게 좋습니다.

mcp-publisher publish --dry-run

인증 방법

서버를 등록하려면 자신이 해당 네임스페이스의 소유자임을 증명해야 합니다. MCP Registry는 네 가지 인증 방법을 지원해요.

가장 간편한 건 GitHub OAuth입니다. mcp-publisher login github를 실행하면 브라우저에서 GitHub 로그인을 거쳐 io.github.{username}/* 네임스페이스에 대한 권한을 받습니다.

CI/CD 파이프라인에서는 GitHub OIDC를 쓸 수 있어요. 별도의 시크릿 없이 GitHub Actions의 OIDC 토큰으로 인증합니다.

자체 도메인을 가지고 있다면 DNS 인증이나 HTTP 인증을 사용합니다. DNS 인증은 도메인의 TXT 레코드에 공개키를 등록하는 방식이고, HTTP 인증은 .well-known/mcp-registry-auth 경로에 인증 파일을 호스팅하는 방식입니다.

DNS TXT 레코드 예시

example.com. IN TXT "v=MCPv1; k=ed25519; p=${PUBLIC_KEY}"

DNS나 HTTP 인증을 사용하면 com.example.*/* 같은 도메인 기반 네임스페이스를 쓸 수 있어서, 회사나 조직 단위로 서버를 관리할 때 적합합니다.

GitHub Actions로 자동화

서버를 업데이트할 때마다 수동으로 mcp-publisher publish를 실행하기 번거롭다면 GitHub Actions로 자동화할 수 있습니다. OIDC 방식이 가장 깔끔한데, 시크릿을 별도로 관리할 필요가 없거든요.

.github/workflows/mcp-publish.yml

name: Publish to MCP Registry
on:
  release:
    types: [published]

permissions:
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install mcp-publisher
        run: |
          curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_linux_amd64.tar.gz" | tar xz mcp-publisher
          sudo mv mcp-publisher /usr/local/bin/

      - name: Login and publish
        run: |
          mcp-publisher login github-oidc
          mcp-publisher publish

이렇게 설정하면 GitHub 릴리즈를 생성할 때마다 자동으로 MCP Registry에 새 버전이 등록됩니다.

PAT(Personal Access Token)이나 DNS 인증을 사용하는 경우에는 시크릿을 통해 토큰이나 프라이빗 키를 전달합니다.

PAT 방식

- run: mcp-publisher login github --token ${{ secrets.MCP_GITHUB_TOKEN }}
- run: mcp-publisher publish

REST API 활용하기

MCP Registry는 REST API를 제공하므로 프로그래밍 방식으로 서버를 검색하고 정보를 가져올 수 있습니다. 현재 API 버전은 v0.1이고, 안정성 검증을 위해 동결(freeze) 상태에요.

서버 목록 조회가 가장 기본적인 API입니다.

# 서버 목록 조회 (최대 100개)
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100"

키워드로 검색도 할 수 있어요.

# 'weather' 키워드로 검색
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=weather"

특정 서버의 상세 정보를 가져올 때는 서버 이름과 버전을 지정합니다.

# 특정 서버의 최신 버전 조회
curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.username%2Fweather/versions/latest"

최근 업데이트된 서버만 필터링하려면 updated_since 파라미터를 씁니다. 어그리게이터가 주기적으로 변경된 데이터만 가져갈 때 유용해요.

# 특정 시점 이후 업데이트된 서버만 조회
curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2026-01-01T00:00:00.000Z"

API 응답은 다음과 같은 구조입니다.

API 응답 예시

{
  "servers": [
    {
      "server": {
        "name": "io.github.username/weather",
        "description": "날씨 정보를 제공하는 MCP 서버",
        "version": "1.0.0",
        "packages": [...]
      },
      "_meta": {
        "status": "active",
        "publishedAt": "2026-01-15T10:00:00Z",
        "updatedAt": "2026-02-01T14:30:00Z"
      }
    }
  ],
  "metadata": {
    "count": 100,
    "nextCursor": "com.example/my-server:1.0.0"
  }
}

페이지네이션은 커서 기반이라 nextCursor 값을 다음 요청의 cursor 파라미터로 넘기면 됩니다.

어그리게이터 구축하기

MCP Registry의 데이터를 활용해서 자체 마켓플레이스나 큐레이션 서비스를 만들 수도 있습니다. 이런 서비스를 어그리게이터(Aggregator) 또는 서브레지스트리(Subregistry)라고 부릅니다.

어그리게이터는 읽기 전용 REST API를 소비하면서 자체적인 부가 가치를 더합니다. 사용자 평점, 다운로드 수, 보안 스캔 결과 같은 데이터를 _meta 필드에 넣어서 확장할 수 있어요.

어그리게이터의 확장 메타데이터

{
  "_meta": {
    "com.example.marketplace/custom": {
      "user_rating": 4.5,
      "download_count": 12345,
      "security_scan": {
        "last_scanned": "2026-02-20T12:00:00Z",
        "vulnerabilities_found": 0
      }
    }
  }
}

서브레지스트리는 공식 레지스트리와 동일한 OpenAPI 스펙을 구현합니다. 클라이언트 입장에서는 공식이든 서브든 같은 방식으로 쓸 수 있어요. 마켓플레이스끼리 호환되는 셈이죠.

공식 레지스트리는 어그리게이터가 주기적으로(예: 1시간에 한 번) 데이터를 가져가도록 권장하고 있어요. updated_since 파라미터를 활용하면 변경된 데이터만 효율적으로 동기화할 수 있습니다.

보안과 신뢰

MCP 서버를 AI 에이전트에 연결한다는 건 꽤 큰 신뢰를 주는 행위입니다. 악의적인 MCP 서버가 민감한 데이터에 접근하거나 예상치 못한 동작을 할 수 있으니까요.

MCP Registry는 이 문제를 네임스페이스 인증으로 해결합니다. io.github.alice/weather라는 서버를 등록하려면 반드시 GitHub 사용자 alice임을 증명해야 해요. com.example/analytics를 등록하려면 example.com 도메인의 소유권을 증명해야 하고요. 이런 방식으로 서버의 출처를 보장합니다.

다만 주의할 점도 있어요. 2026년 2월 보안 감사에 따르면 레지스트리에 등록된 518개 서버 중 41%(214개)가 MCP 프로토콜 수준의 인증을 구현하지 않고 있다고 합니다. 레지스트리가 서버의 출처는 보장하지만 서버 자체의 보안까지 책임지지는 않는다는 뜻이에요. MCP 서버를 쓸 때는 그 서버가 어떤 도구와 리소스에 접근하는지 꼼꼼히 확인하는 게 좋습니다.

스팸 방지를 위해서는 네임스페이스 인증 요구와 문자 수 제한, 정규식 검증 같은 장치가 마련되어 있고 커뮤니티 기반 모더레이션으로 악성 서버를 신고하고 차단할 수도 있습니다.

현재 상태와 전망

MCP Registry는 현재 프리뷰(Preview) 상태입니다. 정식 출시 전까지 호환성이 깨지는 변경이나 데이터 리셋이 있을 수 있어요. API는 v0.1 버전으로 동결되어 있어서 당분간 큰 변경 없이 안정성을 검증하고 있습니다.

성장세는 꽤 가파릅니다. 2025년 9월 출시 당시 약 90개였던 등록 서버가 2026년 2월에는 518개로 늘었어요. MCP SDK의 월간 다운로드 수도 Python과 TypeScript를 합쳐 9,700만 건에 달하고요.

GitHub의 Toby Padilla는 “다양한 하위 레지스트리가 존재하는 것이 목표이며, 지금처럼 비공식 레지스트리가 난립하는 상황을 정리하려는 것”이라고 밝혔고, Microsoft의 Taylor Black은 “API는 존재한다고 힘을 얻는 것이 아니라, 찾을 수 있고 신뢰할 수 있을 때 힘을 얻는다”고 레지스트리의 의미를 설명했습니다.

마치며

MCP Registry는 MCP 생태계가 “프로토콜” 단계에서 “플랫폼” 단계로 넘어가고 있다는 신호입니다. npm이 Node.js 생태계를 키운 것처럼 MCP Registry가 AI 도구 생태계에서 비슷한 역할을 해줄 수 있을지 지켜볼 만하죠.

아직 프리뷰 단계라 부족한 부분도 있지만 Anthropic, GitHub, Microsoft 같은 회사들이 함께 만들고 있으니 기대해 볼 만합니다. MCP 서버를 만들고 있다면 지금 바로 등록해 보시고, 찾고 있다면 레지스트리를 한번 둘러보세요.

더 깊이 공부하고 싶다면 MCP 공식 문서를 살펴보세요. GitHub이 공식으로 제공하는 MCP 서버가 궁금하다면 GitHub MCP 서버 연동 가이드도 확인해보세요.

This work is licensed under CC BY 4.0