MCP는 죽었다, CLI 만세 - LLM 도구 통합의 현실적 대안
목차
개요
Eric Holmes가 MCP(Model Context Protocol)의 근본적인 한계를 지적하고, CLI가 LLM의 도구 통합에 더 우월한 접근 방식이라고 주장하는 글을 발표했다. MCP가 산업에서 빠르게 관심을 잃고 있으며, 기존 CLI 도구가 에이전트와의 통합에 더 실용적이라는 것이 핵심 논지다.
MCP의 문제점
LLM은 이미 CLI에 능숙하다
LLM은 수백만 건의 man page, Stack Overflow 답변, GitHub 셸 스크립트를 학습 데이터로 사용했다. 따라서 CLI 도구 사용에 이미 최적화되어 있다. CLI와 문서만 제공하면 LLM이 바로 활용할 수 있다. MCP는 더 깔끔한 인터페이스를 약속했지만, 기존 접근 방식 대비 의미 있는 이점을 제공하지 못했다.
디버깅의 어려움
CLI는 인간과 LLM이 동일한 명령을 공유할 수 있다. Claude가 예상치 못한 동작을 했을 때, 사용자가 동일한 명령을 수동으로 실행하여 문제를 진단할 수 있다. 반면 MCP 문제는 전송 로그를 검사해야 하므로 트러블슈팅이 복잡해진다.
조합 가능성의 부재
CLI는 파이프라인과 리디렉션을 통해 강력한 도구 체이닝이 가능하다. jq, grep 등과 결합하여 유연한 데이터 처리가 가능하다. 예를 들어 Terraform 리소스 변경 사항을 jq와 grep 체인으로 필터링할 수 있다. MCP는 서버의 반환 형식에 갇혀 있어 이런 조합이 불가능하거나, 과도한 컨텍스트 윈도우를 소비하게 된다.
불필요한 인증 복잡성
기존 CLI 도구들인 aws, gh, kubectl 등은 이미 검증된 인증 방식을 갖추고 있다. AWS 프로필, gh auth login, kubeconfig 등이 인간과 에이전트 모두에게 일관되게 작동한다. MCP는 인증 체계에 불필요한 복잡성을 추가한다.
운영상의 마찰
MCP 서버는 다양한 운영 문제를 발생시킨다.
| 문제 | 설명 |
|---|---|
| 초기화 불안정 | MCP 서버 시작이 불안정하여 재시작 필요 |
| 반복적 재인증 | 여러 도구가 반복적인 인증 사이클 요구 |
| 세밀한 권한 부재 | 전부 허용 또는 전부 차단만 가능 |
| 프로세스 관리 | 별도 백그라운드 프로세스 관리 필요 |
CLI는 상태 비저장(Stateless) 바이너리로 백그라운드 프로세스나 초기화 절차가 불필요하다.
CLI가 더 나은 이유
최고의 도구는 인간과 기계 모두에게 동일하게 작동하는 도구다. CLI는 수십 년간 다듬어진 설계, 기존 인증 인프라, 그리고 본질적인 조합 가능성을 활용한다.
좋은 API를 먼저 만들고, 그 위에 좋은 CLI를 제공하면 에이전트가 자동으로 활용할 수 있다. 불필요한 프로토콜 복잡성을 줄이는 것이 핵심이다.
MCP가 필요한 경우
CLI 대안이 진정으로 존재하지 않는 특정 시나리오에서는 MCP가 여전히 유용할 수 있다. 비개발자용 도구나 웹 인터페이스 통합에서는 MCP의 역할이 있다는 의견도 있다. 하지만 이는 예외적인 경우이며 일반적인 규칙은 아니다.
결론
MCP 서버를 구축하는 대신, 견고한 API와 양질의 CLI를 우선 제공하는 것이 에이전트 시대에 더 효과적인 전략이다. CLI의 투명성, 디버깅 용이성, 조합 가능성은 MCP가 따라올 수 없는 근본적인 강점이다. 개발자와 AI 에이전트 모두에게 동일하게 작동하는 도구를 만드는 것이 올바른 방향이다.