MCP 1년, 생태계는 어디까지 왔나
2024년 11월, Anthropic이 Model Context Protocol(MCP)을 공개했을 때 반응은 미적지근했습니다. AI 어시스턴트가 외부 도구와 데이터 소스에 연결하는 방식을 표준화한다는 아이디어였는데, "또 하나의 Anthropic 독자 규격 아닌가?" 하는 시선이 많았죠. 그런데 17개월이 지난 지금 분위기가 꽤 달라졌네요. OpenAI가 붙고, Google이 붙고, Microsoft까지 붙었습니다. 월간 SDK 다운로드가 9,700만 건을 넘고, 거버넌스가 Linux Foundation으로 이전됐습니다. 무엇이 바뀌었고, 무엇이 아직 남아 있는지 정리합니다.
1년 만에 사실상 표준이 됐다
MCP가 "이기는 중"이라는 신호는 경쟁자들의 채택 시점에서 읽힙니다.
시점 |
사건 |
|---|---|
2024년 11월 |
Anthropic이 MCP 오픈소스 공개 |
2025년 3월 |
OpenAI, Agents SDK / Responses API / ChatGPT 데스크톱에 MCP 지원 |
2025년 4월 |
Google DeepMind Demis Hassabis, Gemini에 MCP 지원 확인 |
2025년 5월 |
GitHub·Microsoft, Build 2025에서 MCP 스티어링 커미티 합류 |
2025년 7월 |
Microsoft, Copilot Studio에 MCP 통합 |
2025년 11월 |
1주년. 새 사양 발표. SDK 월간 다운로드 9,700만 건 |
2025년 12월 |
Anthropic이 MCP를 Linux Foundation 산하 AAIF에 기증 |
2026년 현재 공개된 MCP 서버가 10,000개 이상, 공식 레지스트리 등록 수만 2,000개에 가깝습니다. VS Code, Cursor, JetBrains 같은 IDE에서 Claude, ChatGPT, Gemini까지 사실상 모든 주요 AI 클라이언트가 MCP를 지원합니다.
왜 이렇게 빠르게 번졌을까요? 이유는 비교적 단순한 것 같습니다. LLM이 외부 도구를 쓰는 문제는 모든 플레이어가 공통으로 풀어야 하는 문제였고, 각자 독자 규격을 만드는 건 누가 봐도 비효율이었죠. Anthropic이 먼저 선점하고 오픈소스로 풀었으니, 따라오는 게 합리적이었네요.
거버넌스 이전: Anthropic에서 Linux Foundation으로
2025년 12월, Anthropic은 MCP를 리눅스 재단 산하에 신설된 Agentic AI Foundation(AAIF) 에 기증했습니다. 공동 창립 멤버는 OpenAI, Anthropic, Google, Microsoft, AWS, Block입니다. Cloudflare, Bloomberg도 지원 멤버로 참여했습니다.
이 이전이 중요한 이유가 있습니다. MCP가 Anthropic의 프로젝트로 남아 있었다면 다른 AI 기업들이 장기적으로 의존하기 불편했을 겁니다. Linux Foundation으로 넘어가면서 MCP는 특정 기업의 자산이 아니라 공동 인프라가 됐죠. 같은 시기 Google의 A2A(Agent-to-Agent) 프로토콜도 AAIF 산하로 들어왔고, 두 프로토콜이 같은 거버넌스 아래 공존하게 됐습니다.
프로토콜 스택: MCP, A2A, 그리고 사라진 ACP
MCP가 정착하면서 주변에 경쟁처럼 보이는 프로토콜들이 등장했습니다. 정확하게는 경쟁이 아니라 레이어가 다릅니다.
MCP (Model Context Protocol) — AI 에이전트와 외부 도구·데이터 소스의 연결. "에이전트의 손"에 해당합니다. GitHub, Slack, Postgres, Figma 같은 외부 시스템과 에이전트를 잇습니다.
A2A (Agent-to-Agent) — Google이 2025년 4월 공개. 에이전트끼리 서로 발견하고 통신하는 방식의 표준화입니다. "에이전트들의 회의실"이라고 보면 되겠네요. 멀티에이전트 시스템의 HTTP 역할이고, 2025년 6월 Linux Foundation에 기증됐습니다.
ACP (Agent Communication Protocol) — IBM 주도로 시작된 병렬 시도. 2025년 8월 A2A에 흡수·통합됐습니다. 현재는 독립적인 표준이 아닙니다.
쉽게 정리하면 이렇습니다.
[외부 도구·DB·API] ←── MCP ──→ [에이전트] ←── A2A ──→ [다른 에이전트]
실제 프로덕션 멀티에이전트 시스템은 두 프로토콜을 함께 씁니다. MCP로 도구를 연결하고, A2A로 에이전트들이 협력하죠.
기술 진화: Streamable HTTP와 OAuth 2.1
초기 MCP의 기술적 약점은 원격 배포였습니다. 로컬에서 stdio(표준 입출력)로 통신하는 구조는 편했지만, 네트워크 너머 서버로 배포하기가 어색했죠. 이 문제를 2025년 3월 사양 업데이트에서 해결했습니다.
Streamable HTTP — 단일 엔드포인트, 무상태(stateless) 가능 트랜스포트. 로드 밸런서와 프록시를 통과하고 조직 경계를 넘어 동작합니다. 모든 요청에 Authorization: Bearer 헤더가 붙기 때문에 인프라 레벨에서 매 메시지를 검증할 수 있습니다.
OAuth 2.1 + PKCE — 엔터프라이즈가 요구하던 인증·인가 프레임워크. 동적 클라이언트 등록, RFC 8707 Resource Indicators 지원. 2025년 11월부터 클라이언트 애플리케이션에 PKCE가 필수화됐습니다.
이 두 가지가 원격 MCP 서버 배포를 현실적으로 만들었고, 공식 레지스트리 등록 서버 수가 이 시점부터 폭발적으로 늘었네요.
실제로 뭐가 만들어졌나
2026년 현재 공개된 MCP 서버의 범위입니다.
개발 도구 - GitHub — 이슈, PR, 코드 검색, 저장소 관리 - GitLab — 동일 범위 - Docker — 컨테이너 빌드·실행 - Kubernetes — 클러스터 상태 조회·배포 - Sentry — 에러 조회
데이터베이스 - PostgreSQL, MySQL, SQLite — 쿼리 실행, 스키마 조회 - MongoDB, Redis — 데이터 조회 - Supabase — 풀스택 접근
협업·생산성 - Slack — 메시지 읽기·쓰기, 채널 검색 - Notion, Linear, Jira — 이슈 생성·조회 - Google Drive, Gmail, Calendar - Figma — 디자인 컨텍스트 읽기
외부 서비스 - Stripe — 결제, 고객 데이터 - Cloudflare — Workers, DNS, 분석 - AWS, GCP, Azure — 클라우드 리소스
커뮤니티 서버 디렉터리는 mcp-awesome.com과 mcpservers.org에서 브라우징할 수 있습니다. 1,200개 이상의 품질 검증된 서버 목록이 있네요.
균열: 보안 문제와 남은 한계
빠르게 번진 만큼 문제도 빠르게 드러났습니다. 솔직히 풀어보죠.
프롬프트 인젝션이 제1 위협이에요. 2025~2026년 MCP 프로덕션 사고 1위는 도구 결과값을 통한 프롬프트 인젝션입니다. 에이전트가 외부 콘텐츠(이슈, 문서, 웹페이지)를 읽을 때, 그 안에 악의적인 명령이 숨어 있을 수 있죠. 그리고 LLM은 그 명령을 "사용자 지시"처럼 따릅니다. 이게 핵심 문제입니다.
Tool Poisoning도 만만치 않습니다. 도구 등록 단계에서 도구 설명(description) 자체에 악성 명령을 심는 공격이에요. 에이전트가 도구 목록을 읽을 때 이 설명도 컨텍스트로 들어가는데, 잘못 작성된 설명 한 줄이 에이전트 행동을 통째로 바꿀 수 있습니다. 여러 MCP 서버가 연결된 환경에서는 악의적인 서버가 신뢰된 서버로의 호출을 가로챌 수도 있고요.
실제 사고도 있었습니다. 2025년 5월, 공식 GitHub MCP 통합에서 공격자가 공개 저장소에 악성 이슈를 만들어 AI 에이전트를 납치하는 공격이 발견됐죠. GitHub MCP를 Personal Access Token으로 구성한 개발자들은 에이전트가 해당 토큰 권한 내 모든 저장소에 접근할 수 있었기 때문에 노출 범위가 넓었습니다.
감사 추적 부재도 걸립니다. 어떤 에이전트가 어떤 도구를 어떤 파라미터로 호출했고 결과가 무엇이었는지, 구조화된 로그를 의무화하는 사양이 아직 없네요. 컴플라이언스가 필요한 기업 환경에서 이건 실질적인 걸림돌이 되고 있습니다.
수평 스케일링 문제도 남아 있고요. Streamable HTTP로 원격 배포는 쉬워졌지만, 상태 있는(stateful) 세션이 로드 밸런서와 충돌합니다. 프로덕션에서 수평 확장을 하려면 세션 상태를 별도로 관리해야 하는데 표준 방법이 없는 상황이에요.
마지막으로 컨텍스트 블리딩. MCP 세션이 제대로 격리되지 않으면 한 사용자의 민감한 데이터가 다른 세션으로 새어나올 수 있습니다.
2026 로드맵
공식 2026 로드맵에 나온 우선순위입니다.
- 트리거와 이벤트 드리븐 업데이트 — 현재 MCP는 클라이언트가 도구를 폴링하는 구조입니다. 서버가 먼저 이벤트를 발행하는 구조로 전환합니다. Slack 메시지가 왔을 때, DB 레코드가 바뀌었을 때 에이전트에게 알릴 수 있게 되죠.
- 스트리밍 결과 타입 — 대용량 파일이나 긴 응답을 청크로 나눠 전달하는 방식 표준화.
- 보안 및 인가 강화 — 감사 로그 의무화, 세션 격리 표준, 프롬프트 인젝션 방어 가이드라인.
- 서버 디스커버리 — 레지스트리나 크롤러가 서버에 직접 연결하지 않고 서버가 무엇을 하는지 알 수 있는 표준.
지금 어디까지 왔나
MCP는 17개월 만에 "Anthropic이 만든 규격"에서 "AI 도구 연결의 사실상 표준"으로 바뀌었네요. 경쟁자들이 채택했고, Linux Foundation으로 거버넌스가 넘어갔고, 10,000개 이상의 서버가 생겼습니다. 이 정도면 프로토콜 전쟁은 사실상 끝났다고 봐도 되지 않을까 싶네요.
아직 남은 균열은 보안과 스케일링입니다. 프롬프트 인젝션과 tool poisoning은 이론적 위협이 아니라 이미 실제 사고로 이어졌고, 감사 추적 부재는 엔터프라이즈 채택의 발목을 잡고 있죠. 2026 로드맵이 이 부분을 정면으로 다루고 있다는 건 긍정적인 신호인 것 같습니다.
에이전트가 혼자 일하는 시대는 이미 지났습니다. 에이전트가 도구를 쓰고, 에이전트끼리 협력하는 시대가 왔죠. MCP가 그 인프라의 절반, A2A가 나머지 절반을 채우는 중이고요. 보안 균열이 어디까지 정리될지는 지켜봐야겠지만, 적어도 "표준 없음" 시대보다는 훨씬 나은 자리에 와 있는 것 같습니다.