Model Context Protocol (MCP) 생태계는 2026년 5월에 13,000개의 서버를 돌파했습니다. 매주 새로운 GitHub 리포지토리(repos), 새로운 발표, 그리고 어떤 AI 코딩 에이전트가 가장 많은 서버를 설치하는지 비교하는 새로운 벤치마크가 등장합니다. 내러티브는 성장, 성장, 그리고 성장뿐입니다.

여기 마케팅 슬라이드에는 아무도 넣지 않는 부분이 있습니다: MCP는 동일한 도구에 대한 직접적인 API 호출보다 10배에서 32배 더 많은 토큰을 소모합니다.

이것은 버그가 아닙니다. 수학입니다.

아무도 계산하지 않은 컨텍스트 세금 (Context Tax)

Claude를 MCP 서버에 연결하면, 모든 도구 호출(tool call)은 프로토콜 레이어를 통한 왕복 과정이 됩니다. LLM은 도구에 대한 구조화된 설명을 받습니다. 도구가 실행됩니다. 결과가 다시 컨텍스트(context)에 채워집니다. 단순한 ls 호출 하나만으로도, 이전에는 없었던 500~2,000개의 토큰이 프롬프트 창에 추가됩니다.

이제 이를 확장해 봅시다.

저는 세 가지 프로젝트, 즉 코드 리뷰 파이프라인, 자동화된 PR 분류 봇, 그리고 문서 업데이트 도구를 대상으로 실험을 진행했습니다. 각 사례에서 제가 찾을 수 있는 모든 "권장" MCP 서버(GitHub, Filesystem, Playwright, Slack, Linear 등 전체 스택)를 연결했습니다. 결과는 일관적이었고 불편했습니다:

에이전트는 더 잘 작동했습니다. 그 점은 인정합니다. 하지만

1. 에이전트가 취하는 주요 동작을 위한 하나의 도구 서버 (One tool server) (코드 리뷰 흐름을 위한 GitHub, 데이터 에이전트를 위한 데이터베이스 MCP, 콘텐츠 에이전트를 위한 브라우저 MCP)
2. 에이전트의 환각 (Hallucination)을 방지하는 하나의 컨텍스트 서버 (One context server) (코드 검색 서버, 지식 베이스 조회)
3. 에이전트가 유능해 보이게 만드는 지루한 작업들을 위한 하나의 유틸리티 서버 (One utility server) (설정 파일 읽기를 위한 Filesystem, 상태 업데이트 전송을 위한 Slack)

그게 전부입니다. "그리고 이것도"라는 유혹은 실재합니다. MCP 서버를 설정하는 것은 즐겁고, 생태계는 인상적이며, "나는 11개의 MCP 서버를 실행한다"라고 말하는 것이 "나는 3개를 실행한다"라고 말하는 것보다 더 전문적으로 들리기 때문입니다. 이를 저항하십시오. 당신이 추가하는 모든 서버는 매 프롬프트(Prompt)마다 지불해야 하는 컨텍스트 세금 (Context tax)입니다.

아무도 감사(Audit)하지 않는 보안 표면 (Security Surface)

두 번째 문제는 이것입니다: MCP 서버는 에이전트 환경의 권한으로 실행됩니다. 당신의 파일 시스템에 쓸 수 있는 서버를 연결할 때, 당신은 단순히 Claude에게 파일을 읽을 수 있는 능력을 주는 것이 아닙니다. 당신은 해당 서버의 런타임 (Runtime)이 당신의 환경에서 실행될 수 있는 능력을 부여하는 것입니다.

서버 생태계가 파편화됨에 따라 이 문제는 더욱 중요해집니다. 2026년 중반에 카탈로그화된 13,000개 이상의 MCP 서버 중, Linux Foundation의 AAIF로의 거버넌스 이전은 최근에 이루어졌습니다. 커뮤니티에서 유지 관리되는 서버들에 대한 보안 검토 프로세스는 여전히 성숙해가는 단계입니다. 일부 서버는 보안 감사 이력이 없는 단일 개발자의 프로젝트입니다.

커뮤니티 서버를 사용하지 말라는 뜻이 아닙니다. 모르는 유지 관리자의 package.json에 있는 의존성 (Dependency)을 감사하는 방식과 동일하게 서버를 감사하라는 뜻입니다. 요청된 권한을 확인하십시오. 서버가 그 권한으로 실제로 무엇을 하는지 확인하십시오. 그런 다음 결정하십시오.

2026년에 실제로 작동하는 것들

충분한 시행착오를 거친 끝에, 새로운 프로젝트의 첫날에 제가 설치할 짧은 목록은 다음과 같습니다:

• RunContext7 — 언제나 필수입니다. 컨텍스트 압축 (Context compression) 기능이 진정으로 유용하며, 다른 서버들을 괴롭히는 토큰 오버헤드 (Token overhead)를 줄여줍니다.
• GitHub MCP — 코드 리뷰, PR 관리 또는 리포지토리 (Repo) 분석을 수행하는 모든 에이전트용입니다. API 표면 (API surface)이 깔끔하고 토큰 오버헤드가 합리적입니다.
• Playwright MCP — 브라우저 자동화 (Browser automation)를 조금이라도 수행한다면 필수입니다. 대안들 (Puppeteer, Selenium)은 만큼 깔끔하게 통합되지 않으며, 규모가 커질수록 토큰 오버헤드의 차이가 유의미하게 나타납니다.
• 하나의 앱 전용 서버 — 사용 중인 스택에 따라 Notion, Linear 또는 Supabase 중 하나를 선택하세요. 팀이 실제로 사용하는 도구를 선택하십시오.

그 외의 모든 것들은, 해당 서버가 해결할 수 있는 구체적이고 측정 가능한 문제가 있을 때만 추가하십시오. 단순히 새롭기 때문이어서는 안 됩니다. 벤치마크 (Benchmark) 결과가 좋아 보여서도 안 됩니다. 에이전트가 특정 작업에서 실패하고 있고, 이 서버가 그것을 해결할 수 있기 때문이어야 합니다.

벤치마크의 함정

벤치마크에 대해 말하자면: 작업당 비용 (Cost-per-task)을 포함하지 않는 모든 MCP 비교는 의심하십시오.

생태계는 "어떤 에이전트가 가장 많은 MCP 서버를 사용하는가"에 대한 리더보드, "MCP 서버 개수" 지표, 그리고 효율성이 아닌 폭을 측정하는 기능 비교를 게시하는 습관이 생겼습니다. 이러한 수치들은 실제 토큰 사용량과 곱하여 월간 청구서를 확인하기 전까지는 인상적으로 보일 뿐입니다.

정말로 중요한 벤치마크는 다음과 같습니다: 작업을 안정적으로 완료하는 데 비용이 얼마나 드는가? 얼마나 많은 서버가 연결되어 있는가가 아닙니다. 에이전트가 얼마나 빨리 실행되는가도 아닙니다. 이번 주에 어떤 화려한 새 서버가 출시되었는지도 아닙니다.

작업당 비용 (Cost per task). 100회의 실행을 통해 측정하십시오. 각 서버를 사용했을 때와 사용하지 않았을 때를 비교하며 측정하십시오.

내가 배운 것들

MCP는 단순한 신기한 기능이 아니라 실제 인프라 (Infrastructure)입니다. 이 프로토콜은 LLM에 구조화되고 신뢰할 수 있는 도구 접근 권한을 부여한다는 진정한 문제를 해결하며, 생태계는 누구의 예상보다 빠르게 성장했습니다. 그것은 좋은 현상입니다.

하지만 성장이 규율 (Discipline)을 앞질렀습니다. 제가 대화하는 대부분의 팀은 MCP 설정의 토큰 비용을 추적하지 않고 있습니다. 대부분은 서버를 감사 (Auditing)하지 않습니다. 그리고 벤치마크에 대한 논의는 무엇이 가능한지에 대해서만 다룰 뿐, 무엇이 비용 효율적인지에 대해서는 다루지 않습니다.

13,000개의 서버는 하나의 특징(feature)이자 경고입니다. 프로토콜을 사용하되, 서버를 신중하게 선택하십시오. 그리고 토큰(token) 수를 계산하십시오.

12개의 MCP 서버를 실행하는 에이전트가 3개의 서버를 실행하는 에이전트보다 더 뛰어난 것은 아닙니다. 그저 비용이 더 많이 들 뿐입니다.