MCP는 죽었는가? Model Context Protocol과 CLI 우선 전략의 평가

Model Context Protocol (MCP)은 Large Language Models (LLMs)를 GitHub, Slack, Notion과 같은 외부 도구에 연결하는 보편적 표준을 약속하며 "AI 생태계의 USB-C"로 칭송받았습니다. 그러나 개발자들이 이러한 도구들을 일상적인 워크플로우에 통합함에 따라, 중요한 논쟁이 발생했습니다: 공식화된 프로토콜의 오버헤드가 그 이점보다 더 큰가?

Quandri 엔지니어링 팀의 최근 분석에 따르면, 많은 기술적 워크플로우에서 MCP는 과잉 엔지니어링일 수 있습니다. MCP를 "Skills" 및 직접적인 CLI (Command Line Interface) 사용과 비교함으로써, 그들은 업계가 에이전트 상호작용의 더 단순하고 효율적인 모델로 이동하고 있을 수 있다고 주장합니다.

MCP에 반대하는 논거: 컨텍스트, 신뢰성, 그리고 중복성

MCP에 대한 주요 비판은 세 가지 주요 페인 포인트에 집중됩니다: 컨텍스트 창 소비, 운영 안정성, 그리고 기존 개발자 도구와의 중복성입니다.

1. 컨텍스트 창 세금 (The Context Window Tax)

LLMs는 유한한 컨텍스트 창 내에서 작동합니다. MCP 서버가 연결되면, 도구 정의(LLM에게 도구가 무엇인지, 어떻게 호출해야 하는지를 알려주는 스키마)가 해당 창에 로드되어야 합니다.

Quandri의 측정 결과에 따르면 상당한 "컨텍스트 세금"이 드러났습니다. 네 개의 서버(Linear, Notion, Slack, 그리고 Postgres)가 연결된 스택에서, 200K 토큰 컨텍스트 창(Claude)의 10.5%와 128K 창(GPT-4o)의 16.5%가 도구 정의만으로 소비되었습니다.

예를 들어, Linear MCP 서버는 42개의 도구 정의를 제공합니다. 개발자가 단 하나의 이슈를 가져오기만 하면 되더라도, LLM은 42개 도구 전체에 대한 정의를 모두 지니고 있어야 하며, 일부 개별 도구(예: save_issue)는 각각 600 토큰 이상을 소비합니다.

2. 운영 신뢰성

MCP는 종종 LLM과 기본 API 사이에 추가적인 프로세스 계층을 도입하기 때문에, 지연 시간과 불안정성을 초래할 수 있습니다. 벤치마크 결과, MCP는 직접적인 REST API 호출보다 현저히 느릴 수 있음이 나타났습니다. 때로는 호출당 최대 3배, 초기화 오버헤드로 인해 첫 번째 호출에서는 거의 10배까지 느려질 수 있습니다.

일반적인 실패 모드는 다음과 같습니다:

초기화 실패: 반복적인 재인증 요구 사항.
세션 중간 크래시: 대화 도중 MCP 서버 프로세스가 실패함.
불투명한 권한: 특정 도구가 정확히 어떤 권한을 보유하고 있는지 감사하기 어려움.

3. CLI와의 중복성

개발자에게 CLI는 이미 강력하고 조합 가능한 인터페이스입니다. 이 기사는 MCP가 터미널에서 이미 존재하는 기능을 복제하는 경우가 많다고 주장합니다.

대안: CLI 우선 전략과 "Skills" 패턴

이러한 문제를 완화하기 위해, Quandri는 두 가지 대안을 제안합니다:

대안 1: CLI 우선 전략

프로토콜 대신, LLM에게 CLI, API, 그리고 문서를 제공하십시오. LLM은 이미 방대한 양의 기술 문서와 man pages를 학습했으므로, 최소한의 추가 프롬프팅만으로 기존 CLI를 사용할 수 있는 경우가 많습니다.

대안 2: Skills 패턴

MCP가 "테이블 위에 모든 메뉴를 미리 펼쳐 놓는 것"이라면, Skills 패턴은 "사서에게 당신이 필요한 책만 요청하는 것"입니다. Skill은 압축된 명령어 세트(예: 특정 curl 명령어와 API 엔드포인트)로, 특정 상황에서 호출될 때만 컨텍스트 창에 로드됩니다. 이는 MCP의 영구적인 컨텍스트 세금 문제를 해결합니다.

MCP에 대한 반론: MCP가 여전히 중요한 이유

비판에도 불구하고, OpenAI의 엔지니어들을 포함한 커뮤니티는 MCP의 가치가 단순히 함수를 호출하는 방법이 아니라, 발견 및 전송 프로토콜로서의 역할에 있다고 주장합니다.

비기술적 사용자에게 접근성 확대

CLI는 개발자에게는 강력하지만, HR, 재무, 또는 프로젝트 매니저에게는 접근하기 어렵습니다 MCP는 비기술적 사용자가 터미널을 만지지 않고도 복잡한 서비스를 이용할 수 있게 해주는 추상화 계층을 제공합니다. 한 댓글러는 "HR이나 재무 팀원들에게 CLI를 설치하라고 해보세요"라고 언급했습니다.

"API-less" 세상에서의 서비스 발견

많은 기업이 강력한한 CLI나 공개 API를를하지 않습니다. 이러한 조직들에게, MCP 서버를 구축하는 것은 그들의 서비스를 "AI-ready"로 만드는 가장 빠른 방법입니다. 이 관점에서 MCP는 단순한 통신 계층이 아닙니다. 서비스가 에이전트에게 자신의 기능을 광고하는 방식입니다.

안전 및 거버넌스

프로덕션 환경에서 MCP는 중요한 안전 계층을 역할을 합니다. CLI 기반 에이전트가 명령어를 환각(hallucinate)하여 데이터베이스에 DROP TABLE을 실행할 수 있습니다. 반면, MCP 서버는 읽기 전용 모드를 강정하고 쿼리를 데이터베이스에 전달하기 전에 서버 수준에서 검사할 수 있습니다.

종합: 적절한 도구 선택하기

논쟁의점은 어떤 기술이 "더 나은가"가 아니라, 어떤 기술이 특정 사례에 적적절한지입니다. 논의를 통해 다음과 같은 프레임워크워크가 도출되었습니다:

Bash + CLI 사용: 로컬 개발, 개인용 도구, 그리고 강력한 기존 CLI(예: gh, aws)가 있는 서비스용. 이것이 가장 빠르고 토큰 효율적인 방법입니다.
Skills 사용: 모든 프롬프트에 활리할 필요가 없는, 반복 가능하고 다단계 워크플로우용.
Use MCP: CLI가 없는 서비스, CLI가 없는 비기술적 최종 사용자, 또는 엄격한 권한 범위 지정 및 쿼리 안전성이 필수적인 프로덕션 환경용.

결론

"MCP는 죽었다"는 서사는 실질적인 실효성 문제를 강조하지만(특히 컨텍스트 팽창과 지연 시간과 관련하여), AI 에이전트 접근성을 민감하게 하는 민주화의 역할을 간로한합니다. 파워 유저에게는 CLI가 여전히 왕입니다. 에코시스템을 위한 서비스 발견 및 인증을 위한 표준화된 프로토콜은 필수적입니다. 미래는 아마도 하이브리드 접근 방식이 될 것입니다: 지연 로딩(컨텍스트 세금 문제를 해결함)과 MCP가 단순한 함수 호출 래퍼가 아닌 OAuth-like identity 및 discovery layer로서 기능하는 방향으로의 전환이할 것입니다.