Model Context Protocol (MCP) 생태계가 거의 20,000개의 서버로 폭발적으로 성장했습니다. 대부분은 소음(noise)에 불과합니다. 저는 설정 파일에 영구적으로 등록할 만한 가치가 있는 소수의 서버를 찾기 위해, 주로 Claude Code 내부에서 100개의 서버를 설치하고 연결하며 스트레스 테스트를 진행했습니다. 여기 살아남은 12개의 서버와 제가 삭제한 서버들, 그리고 MCP 서버를 판매하는 누구도 인정하고 싶어 하지 않는 불편한 2026년의 진실을 소개합니다.

내가 이 토끼굴에 빠진 이유

2024년 말 Anthropic이 **Model Context Protocol (MCP)**을 오픈 소스로 공개했을 때, 그 취지는 간단했습니다. 모든 도구와 데이터 소스에 대해 맞춤형 통합(bespoke integration)을 작성하는 대신, 하나의 개방형 표준을 기반으로 구축하라는 것이었습니다. 그들이 사용한 프레임링은 "AI 애플리케이션을 위한 USB-C 포트" — 하나의 커넥터로 많은 장치를 연결한다는 개념이었습니다. 또 다른 추상화 계층(abstraction layer)이 생기는 것에 회의적이었던 저는, 이를 북마크만 해두고 넘어갔습니다.

18개월 후, 저는 이를 무시할 수 없게 되었습니다. 공식 modelcontextprotocol/servers 리포지토리는 **87,000개 이상의 스타(stars)**를 기록했으며 **900명 이상의 기여자(contributors)**가 참여하고 있습니다. PulseMCP와 같은 디렉토리에는 이제 거의 20,000개의 서버가 나열되어 있으며 매주 수백 개씩 추가되고 있습니다. Anthropic은 직접 관리하던 서버 목록을 은퇴시키고 제대로 된 MCP Registry (registry.modelcontextprotocol.io)를 도입했습니다. 이 프로토콜은 Claude뿐만 아니라 Zed, Replit, Sourcegraph, Cursor, VS Code, Windsurf, Cline, Codex 등 툴링(tooling) 세계 전반에 걸쳐 채택되었습니다. Block과 Apollo는 이를 프로덕션 환경에 연결했습니다. 이는 더 이상 Anthropic만의 것이 아니라 _산업(industry)_의 표준이 되었습니다.

수치가 이를 증명합니다. 생태계에서 가장 트래픽이 많은 단일 서버인 Microsoft의 Playwright는 주당 약 550만 명의 방문자를 기록하는 것으로 추정됩니다. Chrome DevTools는 250만 명, Context7은 거의 100만 명입니다. 이것들은 더 이상 데모가 아닙니다. 실제 엔지니어링 워크플로우에서 핵심적인 역할을 하는 인프라입니다.

그래서 저는 당연한 일을 했습니다. Anthropic의 스티어링 그룹(steering group)에서 관리하는 레퍼런스 서버, 공식 벤더 서버(GitHub, Supabase, Sentry, Notion), 그리고 방대한 커뮤니티 프로젝트를 포함하여 100개의 MCP 서버를 설치했습니다. 그리고 제가 실제로 수행하는 작업들, 즉 코드 배포, PR(Pull Request) 리뷰, 운영 환경의 인시던트(incident) 디버깅, 데이터베이스 관리, Figma 프레임을 컴포넌트로 변환하기, 성능 저하(performance regression) 추적 등에 이 서버들을 적용해 보았습니다. 저는 각 서버에 점수를 매겼습니다. 대부분은 한 시간 이내에 삭제되었습니다.

이것은 살아남은 최종 후보 명단입니다. 12개의 서버입니다. 100개가 아닙니다. 그리고 2만 개 중 12개라는 이 숫자는 이 글의 핵심 논지이며, 목록을 공개하기 전에 다시 한번 언급하겠습니다.

요약 (TL;DR)

• MCP는 에이전트(agent)를 도구 및 데이터와 연결하기 위한 개방형 표준(open standard)입니다. 하나의 프로토콜, 수천 개의 서버, 그리고 모든 주요 클라이언트가 이를 지원합니다.
• 서버가 많다고 해서 더 좋은 것은 아닙니다. 연결된 모든 서버는 도구 스키마(tool schemas)를 통해 사용자의 컨텍스트 윈도우(context window)에 부담을 줍니다. 최선의 설정은 최대화하는 것이 아니라, 작고 의도적인 구성입니다.
• 아래에 소개할 저의 12개 엄선 서버는 문서, 파일, 버전 관리, 브라우저, 데이터베이스, 디자인, 관측성(observability), 추론(reasoning), 그리고 메모리(memory)를 다루며, 이는 실제 엔지니어링 작업의 중추 역할을 합니다.
• 2026년의 반전: 심지어 Microsoft조차도 순수한 토큰 경제성(token economy)을 위해, 처리량이 높은 코딩 에이전트에게는 **MCP보다 CLI + 스킬(Skills)**을 권장하고 있습니다. 현명한 방법은 언제 MCP 서버를 사용하지 말아야 할지 아는 것입니다.
• 보안은 선택 사항이 아닙니다. MCP 서버는 사용자의 자격 증명(credentials)을 가지고 실행되며, 프롬프트 인젝션(prompt-injection) 벡터가 될 수 있습니다. 신뢰하기 전에 반드시 감사(audit)하십시오.

30초 요약: MCP 서버란 무엇인가?

MCP는 클라이언트-서버 프로토콜입니다. 사용자의 에이전트(Claude Code, 데스크톱 앱, IDE 등)가 **클라이언트(client)**가 됩니다. **MCP 서버(MCP server)**는 해당 클라이언트에 세 가지 종류의 요소를 노출하는 작은 프로그램입니다:

• Tools (도구) — 모델이 호출할 수 있는 동작 (run_query, create_issue, take_screenshot). 이것들은 동사(verbs) 역할을 합니다.
• Resources (리소스) — 모델이 읽을 수 있는 데이터 (파일, 데이터베이스 행, 문서, 지식 그래프). 이것들은 명사(nouns) 역할을 합니다.
• Prompts (프롬프트) — 서버가 제공하는 재사용 가능한 매개변수화된 워크플로 템플릿으로, 사용자가 직접 다시 작성할 필요가 없습니다.

이 프로토콜은 전송 방식에 구애받지 않지만(transport-agnostic), 실제로는 서버가 두 가지 방식으로 실행되며, 이 차이는 배포 및 보안 방식에 있어 매우 중요합니다:

• Local (로컬, stdio 전송) — npx (TypeScript 서버) 또는 uvx/pip (Python 서버)를 통해 사용자의 로컬 머신에서 실행되는 프로세스입니다. 클라이언트는 표준 입력/출력(standard input/output)을 통해 서버와 통신합니다. 파일, Git, localhost의 데이터베이스와 같이 로컬 상태에 접근해야 하는 모든 작업에 이상적입니다. 데이터가 사용자의 머신을 벗어나지 않습니다.
• Remote (원격, HTTP / Streamable HTTP / SSE 전송) — URL을 통해 연결하는 호스팅된 엔드포인트이며, 인증을 위해 OAuth 2.1을 전면에 배치하는 경우가 점점 늘어나고 있습니다. 직접 실행하고 싶지 않은 SaaS(GitHub, Notion, Sentry, Zapier)에 이상적입니다. 트레이드오프(trade-off)는 데이터와 자격 증명이 이제 네트워크 경계를 통과하므로, 신뢰와 권한 범위(scoping)가 더욱 중요하다는 점입니다.

로컬 서버를 위한 최소한의 Claude Desktop / Claude Code 설정 항목은 다음과 같습니다:

{
  "mcpServers": {
    "filesystem": {
...

원격 서버는 훨씬 더 간단합니다. 단순히 URL(그리고 대개 헤더에 포함된 키)만 있으면 됩니다:

{
  "mcpServers": {
    "context7": {
...

그게 전부입니다. 클라이언트를 재시작하면 에이전트가 서버의 도구를 사용할 수 있습니다. filesystem 예시의 경우, 허용된 디렉토리 내부의 파일을 읽고 쓸 수 있으며, 오직 해당 디렉토리 내에서만 가능합니다. 이 마지막 조항은 단순한 각주가 아닙니다. 이것이 보안 모델의 핵심이며, 나중에 다시 다루겠습니다.

클라이언트에 관한 짧은 참고 사항

클라이언트가 없다면 서버는 무용지물입니다. 2026년의 MCP 클라이언트 생태계는 매우 광범위합니다: Claude Code, Claude Desktop, VS Code, Cursor, Windsurf, Cline, Codex, Gemini CLI, Goose, JetBrains, Warp, Kiro, Antigravity 등이 있습니다. 이 표준의 핵심은 동일한 서버가 이 모든 클라이언트에서 작동한다는 것입니다. 즉, 한 번 작성하면 어디든 연결할 수 있습니다. 이 글에 언급된 모든 내용은 주로 Claude Code에서 테스트되었으며, 데스크톱 앱에서 부분적인 점검을 거쳤으나, 선정된 서버들은 특정 클라이언트에 종속되지 않습니다.

잠시 옆길로: 2026년 MCP에 관한 불편한 진실

목록을 공개하기 전, "최고의 MCP 서버 50선!"과 같은 클릭베이트(clickbait)를 올리는 누구도 말해주지 않는 사실이 있습니다: 연결하는 모든 MCP 서버는 컨텍스트(context) 비용을 발생시킨다는 점입니다.

서버가 등록될 때, 해당 서버의 도구 스키마(tool schemas) — 이름, 설명, 전체 JSON 파라미터 정의 — 가 모델의 컨텍스트 창(context window)에 로드됩니다. 수다스러운 서버 12개를 연결하면, 에이전트가 사용자의 코드를 단 한 줄 읽기도 전에 수천 개의 토큰을 소모할 수 있습니다. 더 나쁜 것은, 80개의 도구를 바라보는 모델이 8개의 도구를 바라보는 모델보다 잘못된 도구를 선택할 확률이 더 높다는 것입니다. 도구의 확산(Tool sprawl)은 정확도와 지연 시간(latency) 측면에서 실제로 측정 가능한 비용(tax)입니다.

이것이 바로 Microsoft의 Playwright 팀이 코딩 에이전트를 위해 Playwright MCP 서버 대신 자신들의 CLI + Skills 방식을 권장하는 이유입니다. 리포지토리(repo)의 내용을 의역하자면 다음과 같습니다: CLI 호출은 대규모 도구 스키마와 장황한 접근성 트리(accessibility trees)를 컨텍스트에 로드하는 것을 피하기 때문에 토큰 효율성이 더 높으며, 에이전트가 간결하고 목적에 맞게 설계된 명령을 통해 동작할 수 있게 합니다. 이는 제한된 컨텍스트 창 내에서 브라우저 자동화와 대규모 코드베이스, 테스트, 추론 사이의 균형을 맞춰야 하는 고처리량(high-throughput) 코딩 에이전트에게 CLI + Skills 방식이 더 적합하게 만듭니다. MCP는 여전히 지속적인 상태(persistent state)와 풍부한 자기 성찰(introspection)로부터 이득을 얻는 특화된 에이전트 루프(specialized agentic loops) — 탐색적 자동화, 자가 치유 테스트(self-healing tests), 장기 실행 자율 워크플로우 등 — 에 있어서는 우위에 있지만, 거대한 리포지토리를 다루는 코딩 에이전트에게는 더 가벼운 방식이 더 빠릅니다.

지구상에서 가장 인기 있는 단일 MCP 서버를 만든 팀의 그 하나의 설계 결정은, 탄광 속의 카나리아(canary in the coal mine, 위험을 알리는 전조)와 같습니다. 그것은 말로 표현하기 조심스러운 사실을 명확히 드러냅니다: MCP는 강력한 도구이지만, 기본값(default)은 아닙니다. 생태계의 리더들조차 이제 가장 사용량이 많은 유스케이스(use case)에 대해서는 여러분이 MCP를 사용하지 않도록 적극적으로 유도하고 있습니다.

언급할 가치가 있는 관련 2차 효과가 하나 더 있습니다: 바로 **도구 이름 충돌(tool-name collisions)과 모호성(ambiguity)**입니다. 각각 search 도구를 노출하는 세 개의 서버를 연결하면, 모델은 호출할 때마다 그 사이에서 무엇을 사용할지 식별(disambiguate)해야 합니다. delete 도구가 있는 서버를 create 도구가 있는 서버 옆에 연결하면, 혼란에 빠지거나 주입(injected)된 에이전트가 피해를 입힐 수 있는 표면적(surface)을 넓히는 꼴이 됩니다. 더 적고 날카로운(sharper) 서버를 사용하는 것은 단순히 토큰(token)을 절약하는 것뿐만 아니라, 일이 잘못될 수 있는 경로의 수를 줄여줍니다.

이 글 전체를 관통하는 핵심 결론은 다음과 같습니다: 무자비하게 큐레이션(curate ruthlessly)하십시오. 적절한 수의 MCP 서버란 여러분이 찾을 수 있는 가장 큰 집합이 아니라, 실제 워크플로우(workflow)를 커버할 수 있는 가장 작은 집합입니다. 12개도 이미 관대한 편입니다. 저는 보통 평소에 다섯 개를 실행합니다: Filesystem, Git, Context7, 그리고 눈앞의 작업에 매핑되는 나머지 두 개입니다. *뺄셈(subtraction)*의 규율은 거의 아무도 이야기하지 않지만, MCP 활용에 있어 가장 레버리지가 높은(highest-leverage) 기술입니다.

이러한 프레임워크를 확립한 상태에서, 알아둘 가치가 있는 12개의 서버를 소개합니다. 상세 내용을 살펴보기 전에 한눈에 확인할 수 있는 표를 먼저 제시합니다.

12개 서버 한눈에 보기

"Reference" = MCP 운영 그룹(steering group)에서 표준 예시로 유지 관리함. "Official" = 해당 제품을 통합하는 벤더(vendor)가 유지 관리함. "Community" = 제3자 제공, 매우 우수할 수 있으나 신뢰하기 전에 검토(audit) 필요.

100개의 서버를 평가한 방법

각 서버는 다섯 가지 축을 기준으로 점수가 매겨졌습니다:

1. 신호 대 토큰 비율 (Signal-to-token ratio) — 몇 개의 날카로운 도구를 제공하는가, 아니면 컨텍스트(context)를 오염시키는 40개의 중복된 도구를 제공하는가?
2. 신뢰성 (Reliability) — 결정론적(Deterministic)이고 타입이 잘 지정된(well-typed) 응답을 주는가, 아니면 실패를 환각(hallucinate)하는 불안정한 래퍼(wrapper)인가?
3. 실제 워크플로우 적합성 (Real workflow fit) — 단순한 눈요기용 기술(party trick)이 아니라, 내가 매주 수행하는 업무를 해결해 주는가?
4. 유지보수 (Maintenance) — 활발한 리포지토리(repo), 실제 릴리스 주기, 그리고 스펙(spec)에 대한 신속한 대응이 이루어지는가?
5. 안전성 태세 (Safety posture) — 권한 범위(scoped permissions)가 제한되어 있는가, 예기치 않은 네트워크 호출은 없는가, 자격 증명(credentials)이 합리적으로 처리되는가?

두 개 이상의 축에서 5점 만점에 3점 미만을 받은 서버는 모두 제외되었습니다. 이 과정에서 제가 시도했던 것들의 약 80%가 탈락했습니다.

설치할 가치가 있는 12개의 MCP 서버 (순위별)

1. Context7 — 환각된 API 문제를 해결하는 서버

Upstash · ~58k⭐ · MIT · ~951k weekly visitors

이 서버는 새로운 환경을 구축할 때 제가 가장 먼저 설치하는 서버입니다. 이 서버가 해결하는 문제는 다음과 같습니다. LLM은 과거의 스냅샷을 기반으로 학습되었기 때문에, 1년 전 라이브러리 버전에 맞춰 코드를 자신 있게 생성하곤 합니다. 즉, 더 이상 존재하지 않는 메서드를 만들어내거나, 두 버전 전에 이름이 바뀐 API를 임포트(import)하거나, 현재 사용 중이지 않은 메이저 버전에 대한 설정을 구성합니다. 여러분도 이런 경험이 있을 것입니다. 코드는 그럴듯해 보이고 머릿속으로는 컴파일이 되는 것 같지만, 실행하는 순간 무너져 버리는 상황 말입니다.

Context7은 최신 버전의 특정 문서와 코드 예제를 소스에서 직접 가져와 프롬프트(prompt)에 직접 주입합니다. 작동 방식은 깔끔합니다. 이 서버는 두 가지 도구를 노출합니다: resolve-library-id(

버전을 고정하거나(How do I set up Next.js 14 middleware? use context7) 정확한 라이브러리 ID를 참조(use library /supabase/supabase)하여 해결(resolution) 단계를 완전히 건너뛸 수 있습니다. 이 서버는 두 가지 모드로 제공됩니다. 클래식한 MCP 서버 (MCP server) (https://mcp.context7.com/mcp) 모드, 또는 시사하는 바가 큰 CLI + Skills 모드 (npx ctx7 setup)입니다. 후자는 MCP가 전혀 필요하지 않습니다. 두 번째 옵션은 앞서 언급한 토큰 경제(token-economy)의 교훈이 제품에 그대로 녹아들어 있는 형태입니다.

사용 시점: Next.js, Supabase, Tailwind와 같이 변화가 빠른 프레임워크를 대상으로 코드를 작성할 때, 또는 지난달에 파괴적 변경(breaking change)이 발생한 라이브러리를 다룰 때 사용하세요. 솔직히 말해서, 항상 켜두는 것을 권장합니다.

2. Filesystem — 기초 (The foundation)

Anthropic 레퍼런스 서버 · 주간 방문자 약 23.9만 명

사용자가 명시적으로 허용한 디렉토리에 대해 제어되고 샌드박스(sandboxed) 처리된 읽기/쓰기 권한을 제공합니다. 화려하지는 않지만 절대적으로 필수적인 기능입니다. 에이전트가 가설적으로 무엇을 할지 설명하는 데 그치지 않고, 실제로 사용자의 프로젝트에서 작업할 수 있게 해주는 핵심 요소입니다. 파일을 읽고, 쓰고, 이동 및 이름 변경을 하고, 트리 구조 전체를 검색하며, 디렉토리 구조를 조사할 수 있습니다.

액세스 제어 모델(access-control model)이 이 기능의 핵심입니다. 하나 이상의 허용된 디렉토리를 인자로 전달하면, 서버는 물리적으로 해당 범위를 벗어난 동작을 거부합니다. 경로 탐색(path-traversal)을 통한 탈출이나 SSH 키를 예기치 않게 읽는 일은 발생하지 않습니다. 이는 생태계 전체에서 권한 범위 지정(capability scoping)이 제대로 이루어진 가장 깔끔한 사례입니다. 에이전트의 권한은 '착한 행동'이 아니라 '설정'에 의해 제한됩니다. 아키텍트로서, 저는 모든 서버가 이 패턴을 따르기를 바랍니다.

사용 시점: 항상 사용하세요. 이는 모든 로컬 에이전트 워크플로우의 기본 요건(table stakes)입니다. 만약 단 하나의 서버만 설치해야 한다면, 바로 이 서버를 설치하십시오.

3. Git — 에이전트가 추론할 수 있는 버전 관리 (Version control the agent can reason about)

Anthropic 레퍼런스 서버 · 주간 방문자 약 19.4만 명