MCP가 사라져야 하는 이유

USB-C의 꿈은 실패였나

MCP는 'AI 생태계의 USB-C'가 될 것이라는 기대를 받았다. 어떤 AI 모델이든, 어떤 도구든 표준화된 방식으로 연결한다는 비전이었다. Quandri 엔지니어링팀이 실제 업무에서 MCP를 써본 결과는 달랐다. 매일 쓰다 보니 문제가 쌓였다.

문제 1: 컨텍스트 낭비

MCP 서버 4개를 연결하면 Claude의 20만 토큰 컨텍스트 중 10.5%가 도구 정의로 소비된다. 실제 작업을 시작하기도 전에 예산의 10분의 1이 사라진다. Linear 하나만으로도 42개의 도구 정의, 1만 2800토큰이 날아간다. MCP는 CLI보다 동일한 작업에 65배 많은 토큰을 쓴다.

문제 2: 운영 신뢰성

초기화 실패, 인증 오류, API 직접 호출 대비 3배 느린 응답 속도, 세션 중 충돌, 불명확한 권한 범위. 이론과 달리 현장에서 MCP는 디버깅의 블랙홀이다.

문제 3: 기존 인프라와의 중복

MCP가 해결하려는 문제는 이미 CLI와 API로 해결되어 있다. CLI는 구성 가능성과 디버깅 측면에서 MCP를 앞선다. 터미널에서 바로 확인할 수 있고, 기존 워크플로우와 자연스럽게 통합된다.

그래도 MCP가 유효한 세 가지 상황

Quandri 팀이 MCP를 완전히 버리라는 것은 아니다. CLI가 없는 웹 전용 서비스, 개발자가 아닌 사용자 대상 제품, 실시간 양방향 통신이 필요한 경우에는 여전히 MCP가 최선이다. 나머지 상황에서는 경량 CLI 통합과 컨텍스트 효율적인 스킬 패턴이 낫다.