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

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

· Sangkyoon Nam
Also in English , 日本語

왼쪽 받침대에서는 터미널이 짧은 케이블 하나로 공구함에 바로 이어져 있고 MCP 어댑터는 옆으로 밀려나 있다. 오른쪽 받침대의 큰 MCP 허브에는 여러 터미널의 케이블이 꽂혀 있지만 자물쇠 자리는 비어 있다

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가 별로라고 쓰면서, 그날 밤 30분 만에 Playwright CLI 래퍼를 만들어 MCP 대신 쓰고 있다고 덧붙였다.

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

#스키마가 잡아먹는 공간

대부분의 MCP 클라이언트는 도구의 스키마를 모델의 컨텍스트 윈도우에 미리 넣는다. 어떤 명령이 있고 어떤 인자를 받고 무엇을 돌려주는지가 도구마다 들어가니, 도구를 하나 붙일 때마다 모델이 작업에 쓸 공간이 줄고 정확도도 떨어지기 쉽다.

Yarats가 든 이유는 컨텍스트 윈도우 소비와 인증 둘이었다. 2차 보도에는 스키마가 컨텍스트의 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이 대신 만든 것은 Playwright CLI 래퍼였고, 만들고 보니 Vercel이 이미 같은 것을 만들어 두었더라고 했다. 퍼플렉시티는 MCP 서버는 유지하되 주력 제품을 REST 기반의 자체 에이전트 API로 옮겼다.

이 비용이 프로토콜의 숙명은 아니다. 2025년 11월 Anthropic은 도구 정의를 전부 미리 넣는 대신 에이전트가 코드로 필요한 도구만 불러오는 방식을 공개했고, 예시에서 15만 토큰이 2천 토큰으로 줄었다고 했다. 그런데 그 글 자체가 대부분의 MCP 클라이언트는 모든 도구 정의를 컨텍스트에 미리 넣는다고 적었다. 지연 로딩은 클라이언트가 따로 구현해야 하는 우회로지 흔한 구현의 기본 동작이 아니고, 위의 숫자들은 도구 정의를 미리 넣는 흔한 방식에서 나온다.

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

2026년 2월 28일, Eric Holmes는 LLM이 이미 커맨드라인 도구를 잘 쓴다고 썼다. 수백만 개의 man page와 Stack Overflow 답변, 셸 스크립트로 가득한 GitHub 저장소로 훈련됐기 때문이다. 그의 논점은 셋이었다.

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

Holmes와 같은 방향의 설문 결과도 있다. Pragmatic Engineer가 2026년 초 900명에게 물은 설문에서 1위를 한 Claude Code는 MCP를 지원하지만, 기본 동작은 터미널에서 파일과 CLI를 직접 다루는 것이다. 그 설문의 응답자 사이에서 가장 많이 쓰이는 도구가 MCP 없이 돌도록 설계됐다는 뜻이다.

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

인증 쪽 숫자는 더 나쁘다. 2025년 7월 보안 업체 Knostic이 인터넷에 노출된 MCP 서버 1,862개 가운데 119개를 손으로 검증했다. 인증 없이 도구 목록을 내주는 서버가 119개 전부였다. 도구를 실제로 실행해 보지는 않았다고 연구진은 적었다.

석 달 뒤인 2025년 10월, Astrix가 오픈소스 MCP 서버 5,200개를 분석했을 때는 88%가 자격 증명을 요구했다. 그런데 전체의 53%는 정적 API 키나 개인 액세스 토큰 같은 장기 시크릿에 기대고 있었고, OAuth를 쓰는 서버는 8.5%뿐이었다. 인증이 있긴 한데, 키가 한 번 새면 그대로 열리는 인증이다. 이 숫자가 센 것은 MCP 서버가 GitHub나 Postgres 같은 뒤쪽 서비스에 어떤 키로 붙느냐다. 클라이언트가 MCP 서버에 어떻게 인증하느냐는 여기에 들어 있지 않다. 스펙이 다루는 인증은 앞쪽이고, 뒤쪽은 제3자 OAuth 토큰의 보관 책임을 적어 둔 정도일 뿐 정적 키의 발급과 교체와 폐기까지 표준화하지는 않는다.

내가 보기에 앞쪽의 0건은 생태계가 미성숙해서가 아니라 MCP 스펙이 HTTP 전송에서 인증을 선택 사항으로 두었기 때문이고, 뒤쪽의 53%는 스펙이 그 자리를 거의 다루지 않기 때문이다. 스펙이 강제하지 않으니 서버를 만드는 쪽에서 빼거나 정적 키로 때우고, 오픈소스 서버가 수천 개씩 쏟아지는 생태계에서 이 결과는 예측 가능한 쪽이다. 시간이 지나면 해결되는 종류의 문제가 아니다. 스펙이 바뀌어야 한다.

#그래서 MCP는 죽었는가

9,700만 다운로드가 보여 주듯 MCP는 여전히 쓰인다. 다만 처방은 쓰는 쪽에 따라 다르다. Charles Chen이 구분했듯, 개인이 코딩 에이전트를 쓰는 것과 조직이 도입하는 것은 다른 문제다.

코딩 에이전트를 쓰는 개인 개발자에게 MCP는 오버헤드다. gh pr create를 치면 끝나는 일에 MCP 서버를 띄울 이유가 없다. 그렇다고 조직에서는 MCP가 필요하다는 것도 너무 쉬운 결론이다. gh, aws, gcloud 같은 CLI는 이미 조직 단위의 SSO와 감사 로그를 지원하고, 조직이라는 이유만으로 MCP가 자동으로 필요해지지는 않는다.

훈련 데이터에 이미 넘치게 들어간 git이나 curl 같은 도구에서는 Holmes의 CLI 주장이 통하지만, 사내에서 만든 커스텀 CLI는 LLM이 처음 보는 도구라 스키마가 다시 필요해진다. 커스텀 도구가 많은 조직일수록 CLI만으로는 모자란다.

MCP가 필요해지는 조건은 그래서 더 좁다. 수백 명이 사내 커스텀 도구 수십 개에 접근해야 하고, 중앙 인증과 감사가 필요하고, 도구 카탈로그가 자주 바뀌는 환경이다. 그 환경에서도 스펙이 인증을 강제하기 전까지는 제한된 조건에서만 쓸 수 있다. MCP 2026 로드맵에서 엔터프라이즈 준비 항목이 아직 정식 제안 전 논의 단계라는 사실이 이 간극을 보여 준다. 필요는 명확한데 스펙이 없다.

코딩 에이전트를 쓰는 개인 개발자에게 MCP는 이미 불필요하다. 조직에게 MCP는 아직 불완전하다.

#참고 자료

Share this post