Namsang LABS
Radar · #ai #mcp #cli #developer-tools #ai-agent

MCP, 개인에게 불필요하고 조직에게 불완전하다

· Sangkyoon Nam
Also in English , 日本語

2026년 3월 25일, MCP(Model Context Protocol)의 월간 SDK 다운로드가 9,700만을 찍었다. 2024년 11월 출시 이후 16개월 만이다. 숫자만 보면 MCP는 승리했다.

그 숫자의 뒷면은 조금 다르다.

  • 퍼플렉시티 CTO Denis Yarats가 Ask 2026 컨퍼런스에서 “프로덕션에 너무 비싸다”며 자사 주력 제품에서 MCP를 빼기 시작했다.
  • Y콤비네이터 CEO Garry Tan이 X에 “MCP sucks honestly”라고 올린 뒤 30분 만에 CLI를 대안으로 직접 만들었다.
  • 2025년 7월, 보안 업체 Knostic이 인터넷에 노출된 MCP 서버 1,862개 중 119개를 수동 검증했는데, 실제로 단 하나도 인증을 요구하지 않았다. 2026년 현재, OAuth 적용률은 8.5%에 그친다.

9,700만 다운로드가 말해주지 않는 것들이 있다.

#스키마가 잡아먹는 공간

MCP는 스키마(어떤 명령이 있고, 어떤 인자를 받고, 뭘 반환하는지)를 모델의 컨텍스트 윈도우에 넣는 구조다. 도구를 하나 연결할 때마다 해당 스키마가 컨텍스트를 차지하고, 그만큼 모델이 실제 작업에 쓸 수 있는 공간이 줄어들 뿐 아니라 정확도까지 떨어진다.

Yarats가 Ask 2026 컨퍼런스에서 그 규모를 수치로 공개했다. MCP 스키마가 에이전트 컨텍스트 윈도우의 72%를 차지하고 있었고, 유저 쿼리가 처리되기도 전에 작업 공간의 대부분이 사라진 상태였고, 대화가 길어질수록 더 악화된다. 에이전트가 도구를 반복 호출하면 스키마 오버헤드는 복리로 쌓인다.

“MCP sucks honestly. It eats too much context window and you have to toggle it on and off and the auth sucks.”

MCP는 솔직히 별로다. 컨텍스트 윈도우를 너무 잡아먹고, 토글로 켜고 꺼야 하고, 인증이 구리다.

— Garry Tan, X

Tan의 체감은 더 구체적이었다. 도구 2개만 붙여도 컨텍스트의 20%가 날아간다고 했다. 퍼플렉시티는 결국 자체 Agent API(REST 기반, OpenAI 호환)로 전환했다. MCP 서버 자체는 유지하되, 주력 제품에서는 빼는 방향을 택했다.

#CLI를 주면 LLM은 알아서 쓴다

2026년 2월 28일, Eric Holmes가 글 하나로 논쟁에 불을 붙였다.

“LLMs are really good at using command-line tools. They’ve been trained on millions of man pages, Stack Overflow answers, and GitHub repos full of shell scripts.”

LLM은 커맨드라인 도구를 매우 잘 쓴다. 수백만 개의 man page, Stack Overflow 답변, 셸 스크립트로 가득한 GitHub 저장소로 훈련됐으니까.

— Eric Holmes, “MCP is dead. Long live the CLI”

Holmes의 논점은 세 가지였다.

  • 디버깅: MCP는 JSON 로그를 뒤져야 한다. CLI는 jira issue view 한 줄이면 에이전트가 본 것과 같은 결과를 직접 확인할 수 있다.
  • 인증: MCP는 자체 인증 체계를 새로 구현해야 한다. CLI는 AWS SSO, GitHub CLI, kubeconfig 같은 기존 인증을 그대로 쓴다. 사람이 쓰든 에이전트가 쓰든 추가 작업이 없다.
  • 운영: MCP 서버는 별도 프로세스를 띄우고 상태를 관리해야 한다. CLI는 설치된 명령어를 실행하면 끝이다.

이 글이 Hacker News에서 퍼진 뒤, Tan의 포스트와 퍼플렉시티의 이탈이 연쇄적으로 이어졌다. 설문 결과도 같은 방향이다. Pragmatic Engineer가 900명을 대상으로 실시한 설문(2026년 1~2월)에서 가장 많이 쓰이는 AI 도구 1위는 Claude Code였다. 터미널에서 파일을 직접 읽고 쓰는 에이전트이고, MCP 없이도 동작한다.

다만 이 논리에는 한계가 있다. Holmes의 주장이 깔끔하게 작동하는 건 git, curl, jq처럼 LLM 훈련 데이터에 이미 대량으로 포함된 도구에 한해서다. 사내에서 만든 커스텀 CLI는 사정이 다르다. LLM이 처음 보는 도구에는 결국 스키마가 필요하고, 이 지점에서 CLI의 “스키마 불필요” 주장은 성립하지 않게 된다. 커스텀 도구가 많은 조직일수록 CLI만으로는 부족해진다.

#인증을 강제하지 않는 스펙

보안 쪽 숫자는 더 심각하다. 2025년 7월, Knostic이 인터넷에서 MCP 서버 1,862개 중 119개를 수동 검증했는데, 단 하나도 인증을 요구하지 않았고, CVSS 9점대 CVE도 이미 세 건이 쌓여 있었다. 9개월이 지난 2026년에도 상황은 크게 달라지지 않았다. 2026년 2월 Astrix가 5,200개 오픈소스 MCP 서버를 분석한 결과, 88%가 인증을 요구하긴 했지만 그중 절반 이상(53%)이 정적 API 키나 PAT 같은 장기 유효 시크릿에 의존하고 있었다. 인증이 있긴 한데, 뚫기 쉬운 인증이다. MCP 스펙에 OAuth 2.1이 추가됐지만 실제 적용률은 8.5%에 그친다.

근본 원인은 생태계의 미성숙이 아니다. MCP 스펙 자체가 인증을 선택사항으로 설계했기 때문이다. 스펙이 강제하지 않으니 서버를 만드는 사람들이 빼는 것이고, 생태계의 75%가 기업이 아니라 개인이 만든 서버라는 점을 감안하면 예측 가능한 결과다. 시간이 지나면 해결되는 종류의 문제가 아니다. 스펙이 바뀌어야 한다.

#그래서 MCP는 죽었는가

9,700만 다운로드가 보여주듯 MCP는 여전히 인기 있는 도구이다. 다만 쓰임새가 이전과 달라지고 있다.

“Individual usage of coding agents looks very different from organizational adoption.”

개인이 코딩 에이전트를 쓰는 것과 조직이 도입하는 것은 완전히 다른 문제다.

— Charles Chen, “MCP is Dead; Long Live MCP!”

개인 개발자에게 MCP는 오버헤드다. gh pr create를 치면 끝나는 일에 MCP 서버를 띄울 이유가 없다. Holmes가 맞고, Claude Code가 1위인 이유가 여기에 있다. 그렇다고 “조직에서는 MCP가 필요하다”도 너무 쉬운 결론이다. gh, aws, gcloud 같은 CLI 도구는 이미 조직 단위로 SSO와 감사 로그를 지원하고 있고, 조직이라는 이유만으로 MCP가 자동으로 필요해지는 건 아니다.

MCP가 실제로 필요해지는 조건은 더 좁다. 수백 명이 사내 커스텀 도구 수십 개에 접근해야 하고, 중앙 인증과 감사가 필요하고, 도구 카탈로그가 자주 바뀌는 환경이다. 대부분의 팀은 아직 여기에 도달하지 않았다. MCP 2026 로드맵에서 엔터프라이즈 준비 항목이 아직 pre-RFC 단계라는 사실이 이 간극을 잘 보여준다. 필요는 명확한데 스펙이 없다.

개인에게 MCP는 이미 불필요하다. 조직에게 MCP는 아직 불완전하다. MCP가 살아남으려면 이 간극을 인정하는 데서 시작해야 한다.

#참고 자료

Share this post