생태계가 폭발했다. Anthropic이 2024년 말 Model Context Protocol을 오픈소스로 공개한 이후 불과 18개월 만에 MCP 서버 수는 약 20,000개에 달했다. 공식 레포는 87,000개 스타를 넘겼고, Cursor·VS Code·Windsurf·Claude Code까지 주요 AI 코딩 클라이언트가 모두 MCP를 지원한다. Microsoft의 Playwright MCP 서버 하나가 주간 550만 방문을 기록한다는 사실은 이게 더 이상 데모 레이어가 아님을 증명한다.
그런데 dev.to에 올라온 한 실험 보고서가 이 흥분에 찬물을 끼얹는다. 저자는 100개의 MCP 서버를 직접 설치하고 실전 워크플로우—PR 리뷰, 프로덕션 디버깅, DB 쿼리, Figma-to-component 변환—에 돌렸다. 결과는 12개 생존. 나머지 88개는 한 시간 안에 삭제됐다. 숫자 자체가 메시지다.
왜 많이 연결할수록 느려지나
MCP 서버를 연결하면 해당 서버가 노출하는 Tool 스키마 전체가 모델의 컨텍스트 윈도우에 적재된다. 서버 12개를 동시에 연결하면 에이전트가 코드 한 줄 읽기 전에 수천 토큰이 이미 소진된다. 더 큰 문제는 정확도다. 80개의 툴을 쳐다보는 모델은 8개를 쳐다보는 모델보다 엉뚱한 툴을 더 자주 고른다. Tool sprawl은 이론적 리스크가 아니라 측정 가능한 지연·오류 세금이다.
이 문제를 가장 직접적으로 인정한 곳은 아이러니하게도 생태계에서 가장 인기 있는 MCP 서버를 만든 팀이다. Microsoft Playwright 팀은 공식 레포에서 "고처리량 코딩 에이전트에는 Playwright MCP 서버 대신 CLI + Skills 방식을 권장한다"고 밝혔다. 이유는 명확하다. CLI 호출은 대형 툴 스키마와 장황한 접근성 트리를 컨텍스트에 올리지 않아서 토큰 효율이 높다. 세상에서 가장 많이 쓰이는 MCP 서버를 만든 팀이 스스로 '특정 상황에서는 MCP를 쓰지 말라'고 말하는 것—이게 신호다.
선별 기준: 어떤 서버가 살아남았나
실험에서 살아남은 12개는 문서·파일시스템·버전 컨트롤·브라우저 자동화·데이터베이스·디자인·옵저버빌리티·추론·메모리 영역을 커버한다. 공통점이 있다. 지속 상태(persistent state)와 풍부한 인트로스펙션이 필요한 작업에서만 MCP가 CLI 대비 실질적 우위를 가진다. 반복적 단순 조회, 단발성 명령 실행은 CLI가 더 빠르다.
툴 이름 충돌도 체크리스트에 넣어야 한다. search 툴을 노출하는 서버 세 개를 동시에 연결하면 모델은 매번 disambiguate해야 한다. delete와 create가 서로 다른 서버에 혼재하면 혼란스러운 에이전트가 의도치 않은 액션을 실행할 수 있는 표면이 넓어진다. 서버 수를 줄이는 건 토큰 절약만이 아니라 에러 표면 축소다.
팀 리드 관점에서의 ROI 계산
팀에 MCP 서버를 도입할 때 내가 쓰는 판단 기준은 세 가지다. 첫째, 이 서버가 없으면 에이전트가 컨텍스트 스위칭을 강제하는가? 그렇다면 연결할 가치가 있다. 둘째, 이 서버가 추가하는 툴 스키마 크기가 얻는 기능 대비 합리적인가? 스키마가 무거운데 한 달에 두 번 쓰는 기능이라면 잘라낸다. 셋째, 서버가 팀원 자격증명으로 실행되는 보안 경계를 감당할 수 있는가? MCP 서버는 프롬프트 인젝션 벡터가 될 수 있다. 신뢰하지 못하는 서버는 연결하지 않는다.
온보딩 관점에서 한 가지 더. 새 팀원이 합류했을 때 MCP 설정이 50개짜리 서버 리스트라면, 그건 온보딩 문서가 아니라 인지 부채다. 팀 공유 설정 파일에는 실제로 매일 쓰는 서버만 남겨야 한다. 나머지는 개인 설정으로 분리하거나 아예 삭제한다.
실용 워크플로우와 MCP의 연결점
dev.to의 또 다른 가이드는 AI를 일상 개발 워크플로우에 통합하는 방식을 정리한다. 핵심 프레임은 간단하다. AI는 "시니어가 아닌 주니어 팀원처럼" 다루라—초안·변형·빠른 리서치는 잘하지만 정보 출처로는 믿지 말라. 이 원칙은 MCP 선별에도 그대로 적용된다. MCP 서버는 에이전트의 행동 반경을 확장하는 도구다. 행동 반경이 넓어질수록 검증 책임도 같이 늘어난다.
실제로 MCP 서버가 ROI를 낼 수 있는 워크플로우 유형은 명확하다. 반복 빈도가 높고, 판단보다 데이터 이동이 병목인 작업이다. PR 리뷰 시 연관 이슈를 GitHub에서 자동으로 끌어오거나, Sentry 에러를 코드베이스 컨텍스트와 함께 에이전트에 전달하거나, Supabase 스키마를 직접 조회해 타입 생성을 자동화하는 것—이런 사례에서 MCP는 CLI 대비 실질적 차이를 만든다.
결론: 작게 시작하고 명시적으로 확장하라
20,000개의 서버 앞에서 '많이 깔수록 AI가 더 강해진다'는 직관은 틀렸다. 정반대다. 팀 MCP 설정의 목표는 최소한의 서버로 실제 워크플로우 병목을 제거하는 것이다. 시작점은 세 개면 충분하다. 파일시스템, GitHub, 그리고 팀이 매일 여닫는 핵심 서비스 하나. 거기서 실제 마찰이 생기는 곳에만 한 개씩 추가한다.
2026년의 MCP 생태계는 USB-C처럼 '연결하면 다 된다'는 약속으로 시작했지만, 현장 데이터는 다른 교훈을 가리킨다. 커넥터가 많다고 컴퓨터가 빨라지지 않는다. 팀의 MCP 설정은 기술 스택이 아니라 워크플로우 설계 결정이다. 그 결정을 내리는 기준이 없으면, 20,000개의 서버는 20,000개의 잠재적 컨텍스트 세금이 된다.