MCP 97M 설치 돌파 — 에이전트 AI의 표준이 된 Model Context Protocol 생태계
Anthropic의 Model Context Protocol이 16개월 만에 9,700만 설치를 기록했다. 5,800개 서버 생태계, OpenAI·Google 전원 채택, 프로덕션 과제, 2026 로드맵까지 정리한다.
한 줄 요약: Anthropic이 만든 Model Context Protocol(MCP)이 2026년 3월 25일 기준 누적 97M(9,700만) 설치를 돌파했다. 16개월 만에 OpenAI, Google, Mistral까지 전원 채택 — MCP는 더 이상 실험이 아니라 에이전트 AI의 기반 인프라다.
AI 에이전트가 외부 도구를 호출하는 방식은 2024년까지 제각각이었다. 각 플랫폼마다 다른 플러그인 API, 다른 인증 방식, 다른 스키마. MCP는 이 파편화를 하나의 프로토콜로 통합했고, 결과적으로 Kubernetes가 컨테이너 오케스트레이션을 표준화한 것과 같은 위치를 16개월 만에 차지했다. 이 글은 MCP가 어떻게 여기까지 왔는지, 현재 생태계 규모, 프로덕션 도입 시 알아야 할 과제, 그리고 2026 로드맵을 정리한다.
※ 이 글은 2026년 3월 기준, MCP 공식 블로그·The New Stack·Linux Foundation AAIF 발표 자료를 참조하여 작성됐습니다.
97M 설치가 의미하는 것
2026년 3월 25일, MCP 공식 npm 패키지와 Python SDK의 누적 설치 수가 9,700만 건을 넘었다. 이 수치가 왜 이례적인지는 비교하면 명확하다.
프로토콜/표준
유사 규모 도달 시간
비고
MCP
16개월
2024년 11월 출시 → 2026년 3월 97M
Kubernetes
~4년
2014년 출시 → 2018년 엔터프라이즈 표준
GraphQL
~3년
2015년 오픈소스 → 2018년 주류 채택
OpenAPI(Swagger)
~5년
2011년 시작 → 2016년 OAI 합류 후 확산
Anthropic은 2024년 11월 MCP를 오픈 프로토콜로 공개했고, 2025년 12월 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기부했다. AAIF는 Anthropic, Block(Square), OpenAI가 공동 설립했으며, Google, Microsoft, Mistral이 이후 합류했다. 사실상 AI 업계 전체가 하나의 프로토콜에 합의한 것이다.
MCP 누적 설치 수 추이 (출처: MCP 공식 블로그, npm trends)
5,800개 서버 생태계의 실체
MCP의 진짜 가치는 설치 수가 아니라 서버 생태계에 있다. MCP 서버는 AI 에이전트가 호출할 수 있는 도구(tool)를 노출하는 엔드포인트다. 2026년 3월 기준 커뮤니티와 기업이 만든 MCP 서버가 5,800개 이상이다 — 16개월 전 수십 개의 레퍼런스 구현에서 시작한 것과 비교하면 4,750% 성장이다.
개발 도구: GitHub, GitLab, Jira, Linear, Sentry, Datadog
생산성: Slack, Notion, Google Workspace, Microsoft 365
커머스/CRM: Stripe, Shopify, Salesforce, HubSpot
이것이 의미하는 바는 명확하다. AI 에이전트가 "Stripe에서 이번 달 매출을 조회하고, Slack에 요약을 보내고, Linear에 태스크를 생성해"라는 지시를 받으면, 각 서비스의 MCP 서버를 통해 하나의 프로토콜로 모든 작업을 수행할 수 있다. REST API마다 인증 방식을 따로 구현할 필요가 없다.
OpenAI와 Google까지 채택한 이유
MCP가 경쟁사까지 채택하게 된 데는 구조적 이유가 있다.
1. 도구 통합의 비용 문제. OpenAI의 Function Calling, Google의 Vertex AI Extensions, 각자의 플러그인 시스템은 서로 호환되지 않았다. SaaS 기업 입장에서 3~4개 AI 플랫폼에 각각 플러그인을 만드는 것은 비효율적이었다. MCP는 "한 번 만들면 모든 AI에서 작동"하는 표준을 제공했고, 도구 제공자(SaaS 기업)가 먼저 MCP를 선호하기 시작했다.
2. 에이전트 간 상호운용성. 2026년의 AI 워크플로우는 단일 모델이 아니라 여러 에이전트가 협업하는 구조다. Claude가 코드를 작성하고, GPT가 리뷰하고, Gemini가 테스트를 생성하는 멀티에이전트 시나리오에서, 도구 호출 방식이 다르면 오케스트레이션이 불가능하다.
3. Linux Foundation 거버넌스. Anthropic이 MCP를 자체 소유 대신 AAIF에 기부한 것이 결정적이었다. 경쟁사 입장에서 Anthropic 소유 프로토콜을 채택하는 것은 부담이지만, Linux Foundation 산하 중립 재단의 표준을 채택하는 것은 전략적으로 합리적이다.
MCP 클라이언트-서버 아키텍처 (출처: modelcontextprotocol.io)
프로덕션 도입 시 부딪히는 3가지 과제
97M 설치에도 불구하고, MCP를 프로덕션에 도입하면 "데모에서는 됐는데 실환경에서 깨지는" 문제를 만난다. The New Stack은 이를 MCP의 가장 큰 성장통이라고 표현했다.
1. 인증(Auth)이 가장 큰 장벽이다. MCP 서버가 Stripe API에 접근하려면 OAuth 토큰이 필요하고, 이 토큰의 발급·갱신·폐기를 누가 관리하는지가 불명확하다. 현재 TypeScript SDK v1.27이 OAuth 디스커버리 캐싱을 추가했지만, SSO 통합이나 엔터프라이즈 IdP 연동은 아직 표준화되지 않았다. 공식 로드맵에서도 인증을 "works in demo, breaks in production" 실패의 1순위 원인으로 꼽았다.
2. 감사 로그와 옵저빌러티. 엔터프라이즈에서는 "어떤 에이전트가 어떤 도구를 언제 호출했는지"를 감사 로그로 남겨야 한다. 현재 MCP는 요청-응답 단위의 로깅은 가능하지만, 에이전트 체인 전체를 추적하는 분산 트레이싱 표준은 아직 없다.
3. 상태 관리. 서버가 도구 호출 중 추가 정보가 필요하면(elicitation), 실행을 중단하고 클라이언트 응답을 기다린다. 이때 서버는 상태를 메모리에 유지해야 하고, 서버가 재시작되면 상태가 사라진다. 로드맵은 이를 해결하기 위해 "프로토콜 자체는 stateless, 애플리케이션은 stateful" 구조를 제안하고 있다.
2026 로드맵 — 올해 해결될 것과 아닌 것
MCP 코어 메인테이너가 공개한 2026 로드맵의 4대 우선순위는 다음과 같다:
영역
목표
현재 상태
인증 표준화
OAuth 2.1 + 엔터프라이즈 IdP 통합
SEP 진행 중
Stateless 프로토콜
서버 재시작에도 elicitation 복구
설계 단계
게이트웨이 표준
프록시/로드밸런서 동작 규격
RFC 초안
옵저빌러티
분산 트레이싱 + 감사 로그 표준
논의 단계
인증과 stateless 프로토콜은 2026년 내 SEP(Specification Enhancement Proposal)가 완료될 가능성이 높다. 반면 게이트웨이 표준과 옵저빌러티는 연내 완전한 규격화는 어려울 전망이다. 당장 프로덕션에 MCP를 도입하려는 팀은 인증 부분에서 자체 래퍼를 만들 각오가 필요하다.
MCP 2026 로드맵 4대 우선 영역 (출처: blog.modelcontextprotocol.io)
개발자가 지금 해야 할 3가지
1. 내부 도구를 MCP 서버로 노출하라. 사내 DB 조회, 배포 트리거, 모니터링 대시보드 같은 내부 도구를 MCP 서버로 만들면, Claude Code나 Cursor 같은 AI 코딩 도구에서 바로 호출할 수 있다. TypeScript SDK의 @modelcontextprotocol/sdk 패키지로 서버를 만드는 데 1~2시간이면 충분하다.
2. MCP 보안 체크리스트를 적용하라..mcp.json 파일에 API 키를 평문으로 넣는 사례가 여전히 많다. 환경 변수 참조, 토큰 스코프 최소화, 서버별 접근 권한 분리는 기본이다. Claude Code 보안 가이드(1017편)에서 MCP 보안 설정을 다루고 있다.
3. 에이전트 워크플로우에서 MCP를 기본 도구 인터페이스로 쓰라. LangChain, CrewAI, AutoGen 등 에이전트 프레임워크 대부분이 MCP를 지원한다. 커스텀 도구 호출 코드를 작성하는 대신 MCP 서버를 연결하면, 에이전트 프레임워크를 바꿔도 도구 통합 코드를 다시 쓸 필요가 없다.
