6개월 전, MCP(Model Context Protocol)는 AI 개발 커뮤니티에서 모두가 이야기하는 핫 키워드였습니다. 그런데 최근 분위기가 달라졌습니다. “MCP는 오버헤드에 불과하다”, “CLI로 충분하다”는 목소리가 Hacker News를 달구며 빠르게 퍼졌고, 일부에선 아예 사망 선고까지 내렸습니다. 정말 그럴까요?
이 논쟁의 발화점은 엔지니어 Eric Holmes의 글 “MCP is dead. Long live the CLI”입니다. CLI는 더 단순하고, LLM이 이미 gh, kubectl, aws 같은 도구를 학습 데이터로 알고 있으니 MCP 래퍼가 필요 없다는 주장이었죠. Motion의 엔지니어 Charles Chen과 AI 개발자 Allen Hutchison은 각각 이 주장에 정면 반박하는 글을 내놓았습니다. 두 사람의 핵심 메시지는 같습니다. “당신에게 CLI가 통하는 건 당신의 환경이 특수하기 때문입니다.”
출처:
- MCP is Dead; Long Live MCP! – chrlschn.dev
- MCP isn’t dead, you just aren’t the target audience – allen.hutchison.org
CLI 토큰 절감, 과장된 부분이 있다
CLI 지지자들의 핵심 근거는 토큰 절감입니다. MCP는 연결 시점에 전체 툴 스키마를 선언해야 해서 맥락 창을 미리 잡아먹지만, CLI는 --help를 호출하며 점진적으로 로딩할 수 있다는 것이죠.
실제로 한 벤치마크에 따르면 도구 43개를 주입한 MCP 에이전트는 아무 작업도 하기 전에 44,000토큰 이상을 소모한 반면, CLI 에이전트는 같은 작업에 1,365토큰만 썼습니다.
그런데 여기엔 빠진 부분이 있습니다. git, curl, jq 같이 LLM 학습 데이터에 포함된 표준 CLI는 별도 설명 없이 바로 쓸 수 있어 유리하지만, 팀 내부에서 직접 만든 커스텀 CLI는 다릅니다. LLM은 그 도구의 존재 자체를 모르니 AGENTS.md나 README에 설명을 채워야 하고, 결국 맥락 창에 올라가는 정보량은 MCP 스키마와 크게 다르지 않아집니다. 또한 Anthropic이 최근 100만 토큰 컨텍스트 창을 지원하면서 이 격차의 의미 자체도 점점 줄고 있습니다.
터미널이 없는 에이전트의 세계
CLI 논쟁에서 가장 자주 빠지는 전제가 있습니다. “에이전트는 터미널 위에서 돌아간다”는 것입니다.
Allen Hutchison은 이 전제가 틀렸음을 직접 구축 경험으로 보여줍니다. 그는 노트 앱 Obsidian 내부에서 돌아가는 AI 에이전트 Gemini Scribe를 1년 반째 개발 중입니다. Obsidian은 Electron 기반이라 샌드박스로 격리된 환경에서 돌아가고, $PATH도 없고 외부 프로세스 실행도 제한적입니다. 모바일(iOS·Android)에선 이 제약이 더 심합니다. 서브프로세스 실행 자체가 불가능합니다.
그가 구글 캘린더나 Gmail을 에이전트에 연결하고 싶었을 때 CLI는 선택지가 아니었습니다. MCP만이 HTTP나 stdio를 통해 런타임에 무관하게 기능을 노출하는 방법이었죠. 서버에서 돌아가는 자동화 에이전트도 마찬가지입니다. 사람이 명령을 내리지 않고 혼자 돌아가는 에이전트에게 셸 접근 권한을 주는 것은 보안 위협이 됩니다. 프롬프트 인젝션 하나로 bash -c가 공격 통로가 될 수 있기 때문입니다. MCP는 에이전트가 쓸 수 있는 행동을 read_file, create_issue 같은 구조화된 도구로 제한해 폭발 반경을 줄여줍니다.
개인 개발자와 팀·조직은 다른 문제를 풀고 있다
두 글이 공통적으로 짚는 핵심입니다. CLI가 강력한 이유는 그것이 개인 워크플로에 최적화되어 있기 때문입니다. 자신의 자격증명이 이미 로컬에 있고, 터미널을 직접 다루는 개발자 한 명이라면 gh pr view 하나가 그 어떤 MCP 래퍼보다 빠릅니다.
그런데 팀 단위, 조직 단위로 가면 질문이 달라집니다. Charles Chen이 강조하는 MCP over HTTP(streamable HTTP 모드)가 여기서 등장합니다. 로컬에서 실행되는 stdio 모드와 달리, 중앙 서버에서 돌아가는 HTTP 모드 MCP는 보안과 가시성 면에서 CLI가 줄 수 없는 것을 제공합니다.
인증 측면에서는, 개발자 각각이 API 키를 관리하는 대신 OAuth로 MCP 서버에 인증하고 민감한 키는 서버 밖으로 나가지 않습니다. 팀원이 떠나면 토큰 하나만 폐기하면 됩니다. 도구 사용 현황도 OpenTelemetry로 중앙 집중 수집할 수 있어서, 어떤 도구가 실제로 효과적인지 CLI 기반에선 파악하기 어려운 정보를 얻을 수 있습니다. 덜 알려진 기능이지만, MCP Prompts와 Resources를 쓰면 서버에서 팀 공용 가이드라인이나 문서를 동적으로 생성해 에이전트에게 배포할 수도 있습니다. 레포마다 AGENTS.md를 수동으로 동기화할 필요 없이, Claude Code든 GitHub Copilot이든 어떤 에이전트 프런트엔드든 항상 최신 내용을 받아갑니다.
CLI와 MCP는 경쟁이 아니다
Hutchison이 제안하는 “Bridge Pattern”은 이 논쟁을 정리하는 실용적 관점입니다. 핵심 기능을 공유 라이브러리로 구현하고, 그 위에 CLI·stdio MCP·HTTP MCP 세 가지 인터페이스를 얹는 방식입니다. 그는 자신의 프로젝트에서 이미 이 구조로 운영 중입니다. 버그 수정은 한 번에, 각 런타임은 자신의 방식대로 접근합니다.
어떤 에이전트가 셸을 갖고 있다면 CLI가 더 빠릅니다. 셸이 없거나, 여러 에이전트 호스트에서 같은 기능을 써야 하거나, 팀 전체의 에이전트 동작을 관측하고 통제해야 한다면 MCP가 답입니다.
두 원문은 MCP의 현재 구현이 아직 거칠다는 점도 솔직하게 인정합니다. 서버 초기화가 불안정하고, 디버깅 경험이 나쁘고, 관측 도구도 미숙합니다. 하지만 이건 아키텍처의 문제가 아니라 성숙도의 문제라는 것이 이들의 결론입니다. LSP(Language Server Protocol)도 초기엔 언어 서버가 자주 죽고 기능이 들쭉날쭉했지만, 추상화 방향이 옳았기에 결국 모든 에디터의 표준이 됐습니다.
조직 규모의 AI 에이전트 도입을 고민한다면, 두 원문에는 실제 구현 사례와 아키텍처 판단 근거가 더 자세히 담겨 있습니다.
참고자료:
- MCP is dead. Long live the CLI – Eric Holmes
- MCP vs CLI benchmark – ScaleKit
답글 남기기