MCP 서버를 열심히 만들고 있는 회사라면 한 번쯤 이 질문을 받을 때가 올 겁니다. “그냥 CLI 있으면 안 돼요?”

인프라 엔지니어 Eric Holmes가 개인 블로그에 올린 글이 조용히 화제가 되고 있습니다. 제목은 “MCP is dead. Long live the CLI” — MCP 없이도 CLI만으로 LLM 에이전트를 충분히 활용할 수 있다는 주장입니다. 같은 시기 구글은 WebMCP라는 이름으로 MCP를 브라우저까지 확장하겠다는 계획을 발표했는데, 두 흐름이 묘하게 엇갈립니다.

출처: MCP is dead. Long live the CLI – Eric Holmes

LLM은 원래 CLI를 잘 씁니다

Holmes의 핵심 논지는 단순합니다. LLM은 수백만 개의 man 페이지, Stack Overflow 답변, 셸 스크립트로 훈련됐기 때문에 CLI 도구를 별도 프로토콜 없이도 잘 사용할 수 있다는 겁니다. Claude에게 gh pr view 123을 쓰라고 하면 그냥 됩니다.

MCP가 “더 깔끔한 인터페이스”를 약속했지만, 실제로는 MCP 서버에도 결국 똑같은 문서를 작성해야 했다고 그는 말합니다. 각 도구가 무엇을 하는지, 어떤 파라미터를 받는지, 언제 써야 하는지. LLM이 새 프로토콜을 필요로 해서가 아니라, 도구 설명은 어차피 사람이 써야 하기 때문입니다.

CLI가 MCP보다 나은 세 가지 이유

디버깅이 쉽습니다. Claude가 Jira에서 이상한 동작을 했을 때, CLI라면 똑같은 명령어를 터미널에서 직접 실행해 볼 수 있습니다. 같은 입력, 같은 출력. MCP라면 JSON 전송 로그를 뒤지는 일이 됩니다.

조합이 자유롭습니다. CLI는 파이프로 연결됩니다. jq, grep, 파일 리다이렉트를 자유롭게 엮을 수 있죠. Terraform 플랜처럼 큰 데이터를 분석할 때 CLI는 이미 있는 도구들을 조합해 처리합니다. MCP라면 컨텍스트 윈도우에 전부 밀어넣거나, MCP 서버 안에 필터링 로직을 직접 구현해야 합니다.

인증이 이미 해결돼 있습니다. aws는 SSO 프로파일을, gh는 gh auth login을, kubectl은 kubeconfig를 씁니다. 수년간 다듬어진 인증 흐름이 인간이 쓸 때나 에이전트가 쓸 때나 동일하게 작동합니다. MCP 도구를 여러 개 쓰면 각각 따로 인증해야 하고, 문제가 생기면 MCP 특유의 방식으로 디버깅해야 합니다.

그럼 MCP는 언제 씁니까

Holmes도 MCP가 완전히 쓸모없다고 주장하진 않습니다. CLI가 없는 도구라면 MCP가 합리적인 선택일 수 있고, 표준화된 인터페이스로서 가치가 있는 케이스도 존재한다고 인정합니다. 하지만 대부분의 실무 상황에서는 CLI가 더 단순하고, 디버깅이 빠르고, 신뢰할 수 있다는 게 그의 결론입니다.

그의 제안은 명확합니다. MCP 서버를 구축하기 전에 공식 CLI가 있는지 먼저 따져보라는 것. 좋은 API를 만들고, 그다음 좋은 CLI를 만들면 에이전트는 알아서 활용한다고 봅니다.

MCP 생태계는 오히려 확장 중

흥미로운 건 이 회의론이 나오는 동시에, 구글이 WebMCP 얼리 프리뷰를 발표했다는 점입니다. 웹사이트가 AI 에이전트와 상호작용하는 표준 방식을 브라우저 차원에서 제공하겠다는 구상입니다. HTML 폼 기반의 선언적 API와 JavaScript 실행이 가능한 명령형 API, 두 가지를 통해 항공권 예약이나 고객 지원 티켓 같은 작업을 에이전트가 웹에서 직접 수행할 수 있게 만들겠다는 거죠.

CLI 기반 회의론과 브라우저 기반 MCP 확장이 동시에 진행되는 셈입니다. 개발자 도구 영역에서는 CLI로 충분하다는 목소리가 커지는 반면, 웹 에이전트 영역에서는 MCP가 새로운 표준으로 자리잡으려 하고 있습니다.

결국 MCP의 미래는 “어떤 맥락에서 에이전트를 쓰느냐”에 달린 것 같습니다. 개발자가 터미널에서 Claude Code를 쓰는 상황과, 에이전트가 웹사이트에서 사용자 대신 항공권을 예약하는 상황은 본질적으로 다른 문제니까요.

참고자료: WebMCP is available for early preview – Chrome for Developers