MCP는 죽었다, CLI 만세 — Eric Holmes의 도발적 주장과 한국 개발자 반응 : MCP vs CLI, 개발자는 무엇을 써야 하는가?

안녕하세요! 갓대희 입니다.

2026년 2월 28일, Eric Holmes가 도발적인 제목의 글을 올렸다. "MCP is dead. Long live the CLI."

MCP(Model Context Protocol)가 AI 에이전트의 표준 인터페이스로 자리잡는 분위기 속에서, "MCP보다 CLI가 낫다"는 주장이 개발자 커뮤니티에 파문을 일으켰다. GeekNews에서도 이 글이 빠르게 공유되며 찬반 논쟁이 이어졌다.
MCP는 정말 죽어가고 있는가? CLI는 AI 에이전트 시대에도 여전히 최선의 선택인가? 이 글에서는 Holmes의 주장을 정리하고, 한국 개발자 커뮤니티의 반응까지 종합해 이 논쟁의 핵심을 짚어본다.

목차

1. MCP란 무엇인가 — 5분 복습
   • 공식 정의와 아키텍처
   • 현재 지원 현황
2. "MCP가 죽었다"는 주장의 배경
3. CLI의 5가지 핵심 강점
   • LLM의 CLI 친숙도
   • 디버깅 투명성
   • 구성 가능성(Composability)
   • 기존 인증 체계 재활용
   • 운영 단순성
4. MCP의 현실적 문제점 3가지
5. CLI vs MCP 비교표
6. MCP가 여전히 적합한 상황
7. 한국 개발자 커뮤니티 반응 (GeekNews)
8. 개발자에게 주는 시사점
9. 참고 자료

핵심 요약

• Eric Holmes(2026.02.28)는 "LLM은 이미 CLI에 능숙하므로, MCP 대신 CLI를 우선해야 한다"고 주장 (출처: ejholmes.github.io)
• CLI의 강점: LLM 친숙도, 디버깅 투명성, 파이프라인 조합, 기존 인증 재활용, 운영 단순성
• MCP의 문제: 초기화 불안정, 반복 재인증, 권한 제어 부재
• GeekNews 커뮤니티는 "CLI가 좋지만 MCP가 적합한 상황도 존재한다"는 절충론이 다수
• 결론: "좋은 API를 만들고, 좋은 CLI를 만들어라. 에이전트는 알아서 해낼 것이다" (출처: 원문 블로그)

 

1. MCP란 무엇인가 — 5분 복습

논쟁의 핵심으로 들어가기 전에, MCP가 무엇인지 간략히 짚고 넘어가자.

 

공식 정의와 아키텍처

MCP(Model Context Protocol)는 Anthropic이 2024년 말 공개한 오픈 프로토콜이다. AI 모델이 파일 시스템, 데이터베이스, 외부 API 같은 리소스와 표준화된 방식으로 상호작용하도록 설계되었다. (출처: modelcontextprotocol.io)

 

MCP의 구조는 세 가지 역할로 나뉜다:

역할	설명	예시
Host	MCP 클라이언트를 포함하는 AI 애플리케이션	Claude Code, Cursor, VS Code GitHub Copilot
Client	MCP 서버와 연결을 유지하는 컴포넌트	Host 내부에 내장됨
Server	특정 도구·리소스를 AI에 노출하는 경량 프로그램	Filesystem MCP, GitHub MCP, Fetch MCP

 

현재 지원 현황

Claude Code, Cursor, VS Code GitHub Copilot 등 주요 AI 개발 도구가 MCP를 지원한다. 커뮤니티에서 다양한 MCP 서버가 공개되어 있으며, 기업들도 자체 MCP 서버를 구축·운영하고 있다.

그렇다면 왜 "MCP가 죽었다"는 말이 나오는 걸까?

MCP 채택이 빠르게 늘고 있는 상황에서 나온 이 주장은, "MCP가 기술적으로 실패했다"는 의미가 아니다. 오히려 "CLI로 충분한데 왜 MCP를 쓰는가?"라는 실용주의적 반문에 가깝다.

 

2. "MCP가 죽었다"는 주장의 배경

Eric Holmes는 2026년 2월 28일, 자신의 블로그에 "MCP is dead. Long live the CLI."라는 제목의 글을 올렸다. (출처: ejholmes.github.io, 2026.02.28)

Holmes의 핵심 전제는 단순하다. "LLM은 이미 CLI를 매우 잘 사용할 줄 안다." 수백만 건의 man page, StackOverflow 답변, README 파일로 훈련된 LLM에게 CLI 도구는 이미 친숙한 인터페이스다. MCP라는 별도의 추상 계층이 굳이 필요한가?

Holmes의 주장 핵심 (원문 요약)

• "MCP는 더 깔끔한 인터페이스를 약속했지만, 결국 동일한 문서화가 필요하다"
• "최고의 도구는 인간과 기계 모두에게 동일하게 작동하는 것이다. CLI는 수십 년의 설계 반복을 거쳐왔다"
• "기업은 MCP 서버에 투자하기 전에 좋은 API와 CLI를 먼저 제공해야 한다"

 

3. CLI의 5가지 핵심 강점

Holmes가 CLI를 선호하는 이유는 단순한 취향이 아니다. 그는 다섯 가지 구체적인 근거를 제시한다.

 

3-1. LLM의 CLI 친숙도

LLM은 수백만 건의 man page, StackOverflow 답변, GitHub README, 기술 블로그로 훈련되었다. gh pr view 123, aws s3 ls, kubectl get pods 같은 명령어는 LLM에게 완전히 자연스러운 언어다.

// LLM이 자연스럽게 이해하고 실행하는 CLI 명령 예시

$ gh pr view 123 --json title,body,reviews
$ aws ec2 describe-instances --filters "Name=tag:Env,Values=prod"
$ kubectl logs -n production deploy/api-server --tail=100

토큰 효율성에서도 CLI가 유리하다

MCP를 사용하면 초기화 메시지, 도구 목록 스키마, JSON-RPC 통신 레이어가 모두 컨텍스트에 포함된다. 반면 CLI는 실제 명령 출력만 컨텍스트에 들어간다. 컨텍스트 윈도우가 제한된 에이전트 환경에서 이 차이는 무시하기 어렵다.

토큰 소비량은 MCP 서버 구현 방식과 도구 수에 따라 크게 달라질 수 있습니다.

반면 MCP 서버는 별도의 API 스펙을 정의해야 하며, LLM이 이를 이해하려면 추가적인 문서화가 필요하다. 결국 CLI와 동일한 수준의 설명이 필요하다는 역설이 생긴다.

 

3-2. 디버깅 투명성

CLI를 사용하면 개발자가 동일한 명령어를 터미널에서 직접 실행해 LLM이 보는 것과 동일한 결과를 확인할 수 있다. 문제가 생기면 즉시 재현하고 디버깅할 수 있다.

Holmes의 말 (원문 요약)

"문제가 생기면 명령어를 직접 실행하는 대신 JSON 전송 로그를 뒤져야 한다. 디버깅에 프로토콜 디코더가 필요해서는 안 된다."

(출처: ejholmes.github.io, 2026.02.28)

 

3-3. 구성 가능성 (Composability)

CLI의 가장 강력한 특징은 파이프라인 조합이다. jq, grep, awk, 파일 리디렉션을 자유롭게 엮을 수 있다.

// 원문 예시: Terraform 플랜에서 변경 리소스 수 추출

terraform show -json plan.out \
  | jq '[.resource_changes[]
         | select(.change.actions[0] == "no-op" | not)] | length'

MCP 서버에서 동일한 작업을 하려면 전체 결과를 컨텍스트에 넣거나, 서버에서 필터링 로직을 추가 구현해야 한다. CLI는 Unix 철학("작은 도구를 조합하라") 덕분에 이런 작업이 자연스럽다.

 

3-4. 기존 인증 체계 재활용

AWS 프로파일, GitHub 인증, kubectl 컨텍스트 등 기존 인증 체계는 수십 년에 걸쳐 검증되었다. CLI는 이를 그대로 활용한다.

// 이미 개발자에게 익숙한 인증 방식

$ aws sso login --profile prod
$ gh auth refresh
$ kubectl config use-context my-cluster

반면 MCP는 새로운 인증 방식을 별도로 요구하거나, 기존 인증과 별개로 추가 설정이 필요한 경우가 있다.

 

3-5. 운영 단순성

CLI 바이너리는 필요할 때만 실행된다. 백그라운드 프로세스를 관리할 필요가 없다. 반면 로컬 MCP 서버는 별도 프로세스로 관리되어야 하며, 시작 실패나 무한 대기 같은 문제가 발생할 수 있다.

 

4. MCP의 현실적 문제점 3가지

Holmes는 이론적 주장에 그치지 않고, MCP를 직접 사용하며 겪은 실무 문제를 세 가지로 정리한다.

 

문제 1: 초기화 불안정

로컬 MCP 서버가 시작에 실패하면 Claude Code 자체를 재시작해야 하는 상황을 겪었다고 한다. MCP 서버는 별도 프로세스이기 때문에, 프로세스 관리의 복잡성이 그대로 개발 워크플로우에 영향을 준다.

실제 문제 상황

• MCP 서버 프로세스 시작 실패 → 전체 AI 세션 재시작 필요
• 서버가 응답 없이 멈추는 "무한 대기" 현상
• CLI라면 해당 명령만 다시 실행하면 될 일

 

문제 2: 반복 재인증

여러 MCP 도구를 함께 사용할 때 각각 별도로 인증해야 하는 경우가 발생한다. CLI였다면 이미 로그인된 세션을 모든 도구가 공유하지만, MCP 서버는 자체 인증 흐름을 가지는 경우가 많다.

 

문제 3: 권한 제어의 부재

Holmes가 지적하는 가장 날카로운 문제다. CLI에서는 세밀한 권한 제어가 가능하다.

// CLI에서는 명령어 단위 권한 제어가 가능하다

gh pr view 123   허용 (읽기 전용)
gh pr merge 123  거부 (파괴적 작업)

MCP에서는 읽기 전용 제한이나 특정 매개변수 스코핑이 쉽지 않다. MCP 서버가 한 번 활성화되면, 그 서버가 제공하는 모든 도구를 LLM이 사용할 수 있는 구조다.

보안 관점에서의 위험

이 문제는 별도의 보안 글에서 자세히 다뤘다. MCP 서버의 권한 관리 문제는 실제로 Tool Poisoning 공격의 진입점이 되기도 한다. (관련 글: MCP 보안 위협 완전 분석)

 

5. CLI vs MCP 비교표

두 방식의 차이를 한눈에 비교해보자.

비교 항목	CLI	MCP
LLM 친숙도	훈련 데이터에 이미 풍부	도구별 별도 학습 필요
디버깅	터미널에서 직접 재현 가능	프로토콜 레이어 추가로 복잡
조합성	파이프라인, grep, jq 자유 조합	서버 내 구현 또는 전체 컨텍스트 전달
인증	기존 AWS/GitHub/kubectl 재활용	MCP별 추가 인증 필요할 수 있음
권한 제어	명령어 단위 세밀한 제어	세밀한 스코핑 어려움
운영 복잡도	백그라운드 프로세스 없음	별도 프로세스 관리 필요
CLI 없는 서비스	CLI가 없으면 사용 불가	API만 있어도 MCP 서버 구축 가능
비개발자 환경	터미널 실행 환경 필요	클라이언트에서 추상화 가능
중앙화된 텔레메트리	별도 구현 필요	HTTP MCP에서 일원화 가능

 

6. MCP가 여전히 적합한 상황

Holmes 자신도 MCP를 완전히 부정하지는 않는다. GeekNews 커뮤니티의 반론도 타당한 지점이 있다. MCP가 CLI보다 나은 상황은 분명히 존재한다.

 

상황 1: CLI가 없는 서비스

Notion, Linear, Slack 같은 SaaS 서비스는 공식 CLI를 제공하지 않거나 기능이 제한적이다. 이런 경우 MCP 서버가 유일한 현실적 선택지가 된다.

MCP가 실제로 빛나는 순간

• Slack 채널의 최근 대화를 요약하거나, MCP를 통해 특정 채널에 메시지를 전송하는 경우
• Notion 페이지를 읽고 요약하는 작업
• Linear 이슈를 조회하고 상태를 업데이트하는 워크플로우

 

상황 2: 비개발자 환경

CLI는 터미널 실행 환경이 있어야 한다. 웹 기반 AI 인터페이스나 모바일 앱처럼 셸 접근이 불가능한 환경에서는 CLI를 실행할 수 없다. MCP는 이 격차를 자연스럽게 메워준다.

 

상황 3: HTTP MCP (원격 MCP)

로컬 MCP 서버의 문제 대부분은 HTTP 기반 원격 MCP로 해소할 수 있다는 의견도 있다. 팀 전체가 공유하는 중앙화된 MCP 서버는 인증을 일원화하고, 텔레메트리를 수집하며, 버전 관리도 쉬워진다.

GeekNews 커뮤니티 의견 (원문 번역 요약)

"중앙화된 인증과 텔레메트리 측면에서 HTTP MCP가 효율적이다. 로컬 MCP의 문제가 원격 MCP에서는 해소될 수 있다."

 

7. 한국 개발자 커뮤니티 반응 (GeekNews)

GeekNews에서 이 글이 공유되자 (news.hada.io/topic?id=27129), 다양한 관점의 댓글이 달렸다.

 

찬성 의견: "실무에서 이미 CLI로 쓴다"

• @jamsya "claude code가 aws cli로 필요한 거 알아서 가져다 씀" — 별도 MCP 없이 CLI만으로 에이전트가 충분히 작동한다는 실무 경험
• @hulryung "저도 MCP보다 CLI로 툴을 직접 만들어쓰기 시작했습니다" — MCP 대신 CLI 기반 도구를 직접 만들어 쓰기 시작했다는 실무 전환 경험
• @hanje3765 "LLM의 지능이 높아지면서 MCP 필요성이 모호해진다" — 모델 성능 향상으로 MCP의 상대적 가치가 줄어든다는 시각
• @brainer "MCP를 썼던 주된 이유가 long context 한계 때문이었는데, 이제 그 한계가 극복되면서 MCP의 필요성이 줄었다" — 모델 성능 향상으로 MCP 의존도가 자연스럽게 낮아졌다는 경험담

 

반대 의견: "MCP의 강점이 있다"

• @sonnet "마이크로서비스처럼 여러 서비스를 연결할 때는 MCP가 적합한 API 프로토콜이 될 수 있다" — 서비스 통합 맥락에서 MCP의 강점을 지적
• "웹 기반 인터페이스에서는 CLI 실행 자체가 불가능하다" — 환경 제약에서 오는 MCP의 존재 이유

 

절충 의견: "상황에 따라 다르다"

커뮤니티 절충안

• "CLI에 해당하는 도구가 없을 때 MCP가 적합하다" — 가장 많은 공감을 얻은 관점
• @m00nlygreat "원격 실행은 mcp, 로컬 실행은 skills로 정리되는 것 같습니다" — 실행 맥락에 따른 역할 분담이 자연스럽게 형성된다는 관점
• @develosopher "SaaS 서비스를 개발하는 입장에서는 자연스럽게 CLI보다 MCP를 선택하게 된다" — 서비스 특성과 개발자 역할에 따라 MCP/CLI 선택이 달라진다는 절충적 관점
• "중앙화된 인증과 텔레메트리 측면에서 HTTP MCP는 여전히 효율적이다" — 로컬 MCP 문제를 원격 MCP로 보완 가능하다는 절충안

 

8. 개발자에게 주는 시사점

이 논쟁에서 어느 한쪽이 완전한 승자가 되기는 어렵다. 하지만 몇 가지 실용적인 시사점은 분명하다.

 

기업/서비스 제공자라면

우선순위 결정 가이드

1. 좋은 REST API를 먼저 제공하라 — AI 에이전트와 사람 모두에게 필요하다
2. 공식 CLI를 만들어라 — LLM은 자연스럽게 활용한다
3. CLI로 해결이 안 되는 영역에 MCP 서버를 고려하라

 

개인 개발자라면

상황	권장 선택	이유
GitHub, AWS, kubectl 작업	CLI	이미 훌륭한 CLI가 있음
CLI 없는 SaaS 연동	MCP	실질적 대안이 없음
팀 공유 AI 인프라 구축	HTTP MCP	중앙화 인증·텔레메트리
복잡한 파이프라인 작업	CLI	파이프라인 조합성 우월
세밀한 권한 제어 필요	CLI	명령어 단위 제어 가능

마무리

"MCP는 죽었다"는 말은 다소 과장된 표현이다. 그러나 이 논쟁이 던지는 핵심 질문은 유효하다: "우리는 지금 정말 MCP가 필요한가, 아니면 CLI로 충분한가?"

 

LLM이 이미 CLI를 잘 사용할 줄 알고, CLI가 없는 서비스에만 MCP가 진정한 가치를 발휘한다면, 개발자로서 우선순위를 다시 점검해볼 필요가 있다. Holmes의 마지막 말처럼, "좋은 API를 만들고, 좋은 CLI를 만들어라. 에이전트는 알아서 해낼 것이다." (원문: "Ship a good API, then ship a good CLI. The agents will figure it out.") 새로운 서비스를 AI 에이전트에 연동하기 전에 먼저 물어보자 — "좋은 CLI가 있는가?"

 

9. 참고 자료

자료	링크	비고
원문 블로그	ejholmes.github.io	Eric Holmes, 2026.02.28
GeekNews 토론	news.hada.io/topic?id=27129	한국 커뮤니티 반응
MCP 공식 문서	modelcontextprotocol.io	Anthropic 공식