MCP는 끝났다. 다운로드 수는 아직 그 사실을 모를 뿐이다.

60일 동안 30개의 CVE, 아무도 경고하지 않은 유지보수 비용, 그리고 엔지니어들이 조용히 갈아타고 있는 것.

당신의 AI 에이전트(AI agent)가 지난달 가짜 데이터베이스에 쿼리(query)를 실행했습니다.

실제 결과가 나왔습니다. 도구는 완벽하게 작동했습니다. 당신의 SSH 키는 백그라운드에 남겨져 있었습니다.

에이전트는 이를 알리지 않았습니다. 레지스트리(registry)도 잡아내지 못했습니다. 아무도 당신에게 경고하지 않았습니다.

이것은 가설이 아닙니다. 월간 다운로드 9,700만 회를 기록하고 Linux Foundation의 지원을 받는 2026년의 MCP 상황입니다.

열풍은 실재했습니다. 균열 또한 실재합니다.

첫째: MCP란 무엇이며, 왜 당신이 관심을 가져야 하는가

만약 당신이 이전에 AI 에이전트를 구축해 본 적이 없다면, 이 내용은 중요합니다. 경험이 있다면 건너뛰셔도 좋습니다.

실제 업무를 수행해야 하는 AI 어시스턴트(AI assistant)를 구축한다고 가정해 봅시다:

데이터베이스에서 고객 기록 조회
Jira에 티켓 생성
Slack 메시지 전송
Google Drive에서 파일 가져오기

이 각각은 서로 다른 시스템에 존재합니다. 서로 다른 API, 서로 다른 인증(auth), 서로 다른 데이터 형식(data format)을 가집니다.

당신의 AI를 이 모든 것에 연결하려면, 각 도구마다 커스텀 통합(custom integration) 코드를 작성해야 합니다. 도구가 두 개라면 괜찮습니다. 하지만 열 개라면 고통스러워집니다. 그러다 모델을 바꾸면 모든 것을 다시 작성해야 합니다.

이것이 바로 N×M 문제입니다. N개의 도구에 M개의 AI 모델을 곱하면, 아무도 유지보수하고 싶어 하지 않는 엄청난 양의 글루 코드(glue code)가 발생합니다.

MCP — 모델 컨텍스트 프로토콜 (Model Context Protocol) — 이 문제를 해결합니다. 2024년 11월 Anthropic에 의해 출시된 이 프로토콜은 AI 모델이 외부 도구와 통신할 수 있는 하나의 보편적인 방법을 제공하는 개방형 표준(open standard)입니다. 도구를 중심으로 MCP 서버(MCP server)를 한 번만 구축하면, MCP와 호환되는 모든 AI가 이를 사용할 수 있습니다.

당신의 에이전트  →  MCP 클라이언트 (MCP Client)  →  MCP 서버 (MCP Server)  →  실제 도구 (Slack, Postgres, GitHub)

세 가지 구성 요소:

MCP Host: 사용자의 앱 (Claude Desktop, VS Code, 커스텀 에이전트 등)
MCP Client: 앱 내부에서 MCP와 통신하며, 도구(tools)를 탐색하고 호출하는 구성 요소
MCP Server: 실제 도구를 래핑(wrapping)하여 어떤 MCP 클라이언트라도 사용할 수 있는 형식으로 노출하는 작은 프로세스

이것이 전부입니다. N×M 문제가 사라집니다. 도구당 하나의 통합만 있으면 모든 AI와 작동합니다.

그 제안은 실질적이었고, 채택(adoption)이 이를 증명했습니다.

MCP가 14개월 만에 제로에서 어디에나 존재하는 기술이 된 과정

채택은 빠르게 일어났습니다. 이례적으로 빠르게 말이죠.

2024년 11월 — Anthropic이 MCP를 출시합니다. 월간 SDK 다운로드 수 약 200만 건.
2025년 4월 — OpenAI가 이를 채택합니다. 다운로드 수가 2,200만 건으로 급증합니다.
2025년 7월 — Microsoft가 Copilot Studio에 통합합니다. 4,500만 건.
2025년 11월 — AWS가 지원을 추가합니다. 6,800만 건.
2026년 3월 — 모든 주요 AI 벤더가 합류합니다. 다운로드 9,700만 건. 10,000개 이상의 공개 MCP 서버.

2025년 12월, Anthropic은 OpenAI 및 Block과 공동 설립한 Linux Foundation 산하의 Agentic AI Foundation에 MCP를 기부했습니다. 이로써 MCP는 Anthropic의 프로토콜이 아닌 업계의 프로토콜이 되었습니다.

"AI를 위한 USB-C"라는 비교가 어디에나 퍼졌습니다. 모두가 연결되었습니다.

그리고 엔지니어들이 이를 프로덕션(production) 환경에서 실행하기 시작했습니다.

개발자들이 MCP를 싫어하는 이유

포럼, GitHub 이슈, 그리고 비공개 Slack 채널에서는 몇 달 동안 불만이 쌓여왔습니다. MCP를 오해한 사람들이 아니라, 프로덕션에서 직접 실행해 보고 똑같은 문제들에 놀란 사람들이 내놓은 목소리입니다.

"기본적으로 인증(unauthenticated)이 되지 않습니다."

기본 설정 상태에서 MCP 서버는 자신에게 연결되는 무엇이든 신뢰합니다.

서버가 주장하는 본인이 맞는지 확인하는 내장된 검증 절차가 없습니다. 클라이언트가 주장하는 본인이 맞는지 확인하는 내장된 검증 절차도 없습니다. 해당 계층을 추가하는 것은 사용자의 책임입니다.

대부분의 튜토리얼은 이 점을 언급하지 않습니다.

"STDIO 전송 방식(transport)이 임의의 OS 명령을 실행합니다."

공식 MCP STDIO 전송 방식은 서버를 실행하기 위해 지정된 모든 OS 명령을 실행합니다. 심지어 서버 시작이 실패할 때조차도 말이죠. 정화(sanitization) 경고도 없습니다. 개발자 툴체인(toolchain)에서 이를 경고하는 기능도 없습니다.

OX Security는 2026년 4월에 이 내용을 문서화했습니다.

Anthropic의 답변: 예상된 동작(expected behavior)이며, 정화(sanitization)는 개발자의 책임입니다. LangChain도 똑같이 말했습니다. Microsoft도 마찬가지였습니다.

세 개의 주요 벤더(vendor). 답변은 모두 동일했습니다: "당신의 문제입니다."

"스펙은 변하지만, 커뮤니티 서버는 변하지 않습니다."
커뮤니티 레지스트리(registry)에 게시된 MCP 서버들은 스펙 업데이트를 따라가지 못하는 경우가 빈번합니다. 지난달에는 잘 작동하던 서버가 프로토콜이 업데이트된 후에는 다르게 동작할 수 있습니다. 레지스트리에는 강제적인 메커니즘이 없습니다. 당신은 운영 환경(production)에 도달해서야 이 사실을 알게 됩니다.

"이미 보유한 모든 REST API에 새로운 래퍼(wrapper) 프로세스가 필요합니다."

이미 깔끔한 REST API를 갖춘 도구에 MCP를 추가한다는 것은, 그 도구를 중심으로 전체 MCP 서버를 구축해야 함을 의미합니다.

해당 서버는 다음과 같은 요건을 충족해야 합니다:

배포 및 모니터링되어야 함
기반이 되는 API가 변경될 때 업데이트되어야 함
에이전트(agent) 및 도구(tool)와 별도로 보안 조치가 이루어져야 함

기존 API가 10개라면, 관리해야 할 새로운 프로세스가 10개 늘어나는 것입니다. 운영 3개월 차가 되면, 당신은 그 모든 프로세스의 무게를 실감하게 됩니다.

"레지스트리들은 기본적으로 2015년경의 npm과 같습니다."

2026년 초, OX Security는 mcp-server-postgres를 복제하여 mcp-server-postgress(s가 하나 더 붙음)라고 이름을 붙였습니다. 기능적으로는 동일했습니다. 동일한 쿼리, 동일한 응답을 반환했습니다.

그 안에 숨겨진 것은: SSH 키와 환경 설정 파일(environment files)을 외부 서버로 조용히 탈취하는 페이로드(payload)였습니다.

그들은 이를 11개의 주요 MCP 레지스트리에 제출했습니다.

그중 9곳이 이를 게시했습니다. 자동화된 보안 검토도, 소스 코드 분석도 없었습니다. 아무것도 없었습니다.

"사용자가 아무 말도 하기 전에 내 컨텍스트 윈도우(context window)를 다 잡아먹습니다."

MCP 클라이언트가 서버에 연결하면, 모든 도구의 이름, 설명, 매개변수(parameter)를 포함한 전체 도구 스키마(tool schema)를 컨텍스트 윈도우에 로드합니다.

서버 1개, 도구 5개: 첫 메시지를 보내기도 전에 약 500개의 토큰(token) 소모
서버 10개: 첫 메시지를 보내기도 전에 2,000~3,000개의 토큰 소모

모델은 사용자가 단 한 마디를 입력하기도 전에 이미 더 적은 예산(budget)을 가지고 추론을 시작해야 합니다.

이것들은 예외적인 사례(edge cases)가 아닙니다. 로컬 데모 단계를 넘어선 사람이라면 누구나 겪게 되는 표준적인 경험입니다.

실제 운영 시스템을 망가뜨리는 3가지 문제

신뢰 문제

당신의 에이전트는 MCP 서버가 주장하는 본인이 맞는지 확인할 방법이 없습니다.

OX Security 사고는 이를 현실로 만들었습니다. 11개의 레지스트리 중 9개가 타이포스쿼팅(typosquatted)된 자격 증명 탈취 패키지를 수락했습니다. 악성 서버는 정상적으로 작동했습니다. 데이터베이스 쿼리를 실행했고, 결과를 반환했습니다. 그리고 백그라운드에서 당신의 SSH 키를 조용히 빼돌렸습니다. 프로토콜의 그 어떤 것도 이를 감지하지 못했습니다.

2026년 1월 이후, 연구자들은 60일 동안 MCP 생태계에 대해 30개의 CVE를 보고했습니다. 도구 설명(tool descriptions)을 통한 프롬프트 인젝션 (Prompt injection). 설정 파일 읽기를 통한 자격 증명 탈취. 서버 설명이 에이전트의 다음 결정을 조작하는 "도구 포이즈닝 (Tool poisoning)". 이것들은 생소한 공격 벡터가 아닙니다.

당신의 에이전트는 당신의 Postgres 서버와 공격자의 서버를 구분할 수 없습니다. 이것은 코드 버그가 아닙니다. 설계상의 공백입니다.

MCP는 신뢰할 수 있는 로컬 환경을 위해 구축되었습니다. 운영 환경(Production)은 그렇지 않습니다.

래퍼 비용 (The wrapper tax)

MCP에 연결하는 모든 도구는 각각의 MCP 서버가 필요합니다. 도구가 10개라면 관리해야 할 프로세스도 10개가 추가됩니다.

각 프로세스는 다음을 수행해야 합니다:

기반 도구의 API가 변경될 때 동기화 상태 유지
운영 환경에서의 장애 모니터링
에이전트 및 도구 자체와 별도로 보안 적용
인프라의 일부로 배포

처음 두 개의 도구까지는 관리할 만합니다. 하지만 15개의 통합(integration)을 사용하는 3개월 차가 되면, 그것은 하나의 업무(job)가 됩니다.

N×M 문제는 해결되었습니다. 대신 "N개의 새로운 프로세스" 문제가 조용히 그 자리를 대신했습니다.

컨텍스트 윈도우 청구서 (The context window bill)

도구 스키마 (Tool schemas)는 공짜가 아닙니다. 그것들은 토큰입니다. 그리고 사용자 메시지가 도착하기도 전에 먼저 도착합니다.

10개의 MCP 서버에 연결된 고객 서비스 에이전트를 구축하는 팀은, 첫 번째 사용자 질문이 도착하기도 전에 가용 추론 예산(reasoning budget)이 30% 감소했다는 사실을 발견했습니다. 동일한 모델, 동일한 프롬프트. 단지 도구가 더 많아졌을 뿐입니다.

긴 다단계 에이전트 세션에서 스키마 토큰은 복리로 쌓입니다. 품질은 저하되고, 비용은 상승합니다. 대부분의 팀은 컨텍스트 윈도우 (context window)에 실제로 무엇이 들어있는지 확인하기 전까지는, 이를 도구 스키마 오버헤드 때문이라고 추적하지 못합니다.

엔지니어들이 대신 사용하는 것

위와 같은 문제에 직면한 팀들 사이에서 몇 가지 패턴이 나타났습니다.

직접적인 REST API 호출 (Direct REST API calls)

기존 API가 깔끔하게 잘 갖춰진 도구의 경우, MCP를 완전히 건너뜁니다. 에이전트(Agent)에서 API를 직접 호출하십시오. 유지 관리해야 할 새로운 서버도 없고, 스키마 오버헤드(Schema overhead)도 없으며, 기존 인증(Auth) 체계로 충분합니다.

도구를 직접 제어할 수 있고 API가 안정적일 때 잘 작동합니다. 하지만 여러 AI 시스템이 동일한 통합(Integrations) 기능을 공유해야 할 때는 확장성이 떨어집니다.

네이티브 제공자 도구 사용 (Native provider tool use)

Anthropic과 OpenAI는 모두 MCP 인프라가 필요 없는 내장 도구 호출(Tool calling) 기능을 갖추고 있습니다. 도구 스키마(Tool schema)를 인라인(Inline)으로 정의하고 요청과 함께 전달하면, 모델이 이를 호출합니다.

서버 프로세스 없음
레지스트리(Registry) 없음
인증(Auth)이 호출에 직접 적용됨

2026년에 집중된 단일 목적의 에이전트를 운영하는 대부분의 팀은 이 방식을 사용하고 있습니다. 추론하기는 더 간단하지만, 시스템 간에 공유하기는 더 어렵습니다.

UTCP (Universal Tool Calling Protocol)

UTCP는 래퍼(Wrapper)를 완전히 생략합니다. 도구를 MCP 서버로 감싸는 대신, 상단에 디스커버리 레이어(Discovery layer)를 두고 도구의 기존 HTTP 엔드포인트(Endpoints)를 직접 호출합니다.

2026년 초 기준:

GitHub 스타 1,000개 이상
Python, Go, TypeScript 구현체 존재
더 낮은 지연 시간(Latency)과 적은 인프라 오버헤드를 원하는 팀들로부터 커뮤니티 성장 중

별도의 서버 레이어를 원하지 않으면서 잘 설계된 기존 API를 보유한 팀에게 가장 적합합니다. 생태계의 폭을 필요로 한다면 MCP의 완전한 대체제는 아니지만, 많은 프로덕션(Production) 유스케이스에서 실질적으로 더 단순합니다.

게이트웨이 레이어를 갖춘 MCP (MCP with a gateway layer)

MCP를 고수하는 팀의 경우, 위 문제들에 대한 대부분의 해답은 MCP 게이트웨이(MCP gateway)입니다. 이는 에이전트와 서버 사이의 제어된 레이어입니다.

사용자 에이전트  →  MCP 게이트웨이  →  MCP 서버 1  →  도구
                            →  MCP 서버 2  →  도구
                            →  MCP 서버 N  →  도구

게이트웨이는 다음을 처리합니다:

인증 (Authentication) — 에이전트가 무언가를 호출하기 전에 서버의 신원을 확인합니다.
도구 필터링 (Tool filtering) — 모든 도구를 불러오는 것이 아니라, 현재 작업과 관련된 스키마 (Schema)만 로드합니다.
감사 로그 (Audit logging) — 규정 준수 및 디버깅 (Debugging)을 위해 모든 도구 호출을 기록합니다.
속도 제한 (Rate limiting) — 통제 불능의 도구 호출이 예산을 초과하는 것을 방지합니다.

2026년 4월 기준으로, AI 에이전트 파일럿 프로젝트의 86~89%가 프로덕션 (Production) 단계에 도달하기 전에 실패합니다. 거버넌스 (Governance) 공백과 감사 가시성 (Audit visibility)이 가장 흔한 두 가지 이유입니다. 게이트웨이는 이 두 가지를 모두 해결하는 수단입니다.

그래서 우리는 실제로 MCP가 필요한가요?

네. 하지만 중요한 전제 조건이 있습니다.

다음과 같은 경우에는 MCP를 사용하세요:

여러 AI 시스템이 동일한 도구를 공유해야 할 때
SaaS 기업으로서 AI 에이전트에게 자사 제품에 대한 접근 권한을 부여할 때
대규모 통합 생태계 전반에 걸쳐 동적인 도구 발견 (Dynamic tool discovery)이 필요할 때

다음과 같은 경우에는 MCP를 건너뛰세요:

이미 보유하고 있는 두세 개의 도구만 사용하는 집중형 에이전트를 구축할 때
직접 제어할 수 있는 깔끔한 REST API를 가진 도구를 사용할 때
낮은 지연 시간 (Low latency)과 최소한의 인프라 오버헤드 (Infrastructure overhead)가 필요할 때

"모든 것에 MCP를 적용하는" 시대는 끝났습니다. 표준화가 규모의 경제를 통해 이득을 줄 때가 적절한 선택입니다. 이미 제어하고 있는 API에 에이전트가 접근하기만 하면 되는 상황에서, MCP는 인프라를 가장한 오버헤드일 뿐입니다.

치트 시트: 실제로 무엇을 해야 하는가

상황	적절한 선택
로컬 개발, 한두 개의 도구, 단순 탐색 중	최소한의 MCP 또는 네이티브 도구 호출 (Native tool calls). 과도하게 설계하지 마세요.
...

실제 현황

MCP가 사라지지는 않을 것입니다. 다운로드 수는 실제이며, Linux Foundation의 거버넌스는 진지합니다. 여러 벤더의 채택은 이 프로토콜이 제도적인 생존력을 갖추었음을 의미합니다.

하지만 초기 튜토리얼에서 보여준 MCP — 커뮤니티 서버를 설치하고, 연결하면 끝나는 방식 — 의 버전은 죽었습니다.

그 방식은 프로덕션 환경에 결코 안전하지 않았습니다. 애초에 그렇게 설계되지도 않았습니다.

UTCP나 직접적인 API 호출로 이동하는 엔지니어들은 MCP가 실패했기 때문에 버리는 것이 아닙니다. 그들은 자신들이 구축하려는 목적에 맞게 설계되지 않은 부분들을 우회하고 있는 것입니다.

저는 계속해서 OX Security 테스트를 떠올리게 됩니다. 11개의 레지스트리 중 9개에서 문제가 발생했습니다. 자동화된 검토(automated review)는 없었습니다. 에이전트(agent)는 가짜 서버를 호출하고, 쿼리(queries)를 실행했으며, 자신이 무엇을 넘겨주고 있는지조차 모른 채 자격 증명(credentials)을 건네주었습니다.

여러분의 에이전트는 자신이 신뢰하는 도구(tools)가 시키는 대로 행동합니다.

MCP는 무엇을 신뢰할지 결정하는 방식에 대해 아직 완전한 답을 내놓지 못했습니다. 그 답이 나오기 전까지는, 모든 커뮤니티 MCP 서버를 2015년의 무작위 npm 패키지를 대하듯 취급하십시오.

그 시대가 어떻게 끝났는지 여러분도 잘 알고 계실 겁니다.