MCP는 죽었다. CLI 만세

(ejholmes.github.io)

36P by GN⁺ 1달전 | ★ favorite | 댓글 8개

MCP가 업계에서 빠르게 관심을 잃고 있으며, 이제 CLI 기반 접근이 더 실용적임
LLM은 이미 명령줄 도구 사용에 능숙하며, 별도의 프로토콜 없이도 문서와 CLI만으로 충분히 작업 수행 가능
CLI는 인간과 LLM 모두가 동일한 환경에서 실행·디버깅 가능해 문제 원인 파악이 단순함
조합성(composability)과 인증 체계, 안정성 측면에서도 CLI가 MCP보다 효율적이고 유지보수가 쉬움
MCP는 초기화 불안정, 반복적 재인증, 권한 제어의 부재 등 실무에서 지속적인 마찰을 유발
대부분의 경우 CLI가 더 단순하고 신뢰성 높은 선택지이며, 기업은 MCP 서버보다 우선적으로 API와 CLI 제공에 집중해야 함

MCP의 한계와 CLI의 우위

Anthropic의 Model Context Protocol(MCP) 발표 이후 업계가 앞다투어 MCP 서버를 구축했지만, OpenClaw과 Pi 등 주요 도구가 이를 지원하지 않으며 실질적 이점이 없음
- LLM이 이미 CLI와 문서를 통해 작업을 수행할 수 있음
- MCP는 새로운 엔드포인트와 인증 체계를 추가하지만, 기존 기능을 중복함
LLM은 CLI 도구 사용에 최적화되어 있으며, 매우 능숙함
- 수백만 건의 man page, Stack Overflow 답변, GitHub 셸 스크립트를 학습
- 예를 들어 gh pr view 123 같은 명령어를 Claude에게 지시하면 그대로 동작
MCP가 더 깔끔한 인터페이스를 약속했지만, 실제로는 각 도구의 설명·파라미터·사용 시점을 동일하게 문서화해야함

CLI는 인간에게도 유용

CLI는 인간과 LLM이 동일한 명령을 공유할 수 있음
Jira에서 예상치 못한 동작을 할 때, 동일한 jira issue view 명령어를 직접 실행해 재현 가능
MCP에서는 도구가 LLM 대화 내부에만 존재하여, 문제 발생 시 JSON 전송 로그를 뒤져야 하는 번거로움 발생
디버깅에 프로토콜 디코더가 필요해서는 안 됨
CLI는 입력과 출력이 명확해 문제 추적이 쉬움

조합 가능성(Composability)

CLI는 jq, grep, 파일 리다이렉트 등과 파이프라인으로 조합 가능
대규모 Terraform 플랜 분석 예시:
- terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
MCP로는 전체 플랜을 컨텍스트 윈도우에 덤프(비용 높고 종종 불가능)하거나, MCP 서버 자체에 커스텀 필터링을 구현해야 함
CLI 방식은 이미 존재하고 잘 문서화된 도구를 활용하며, 인간과 에이전트 모두 이해 가능

인증(Auth) 문제

MCP는 인증에 대해 불필요하게 독단적(opinionated) 임
CLI 도구는 이미 검증된 인증 체계 사용: aws는 프로파일과 SSO, gh는 gh auth login, kubectl은 kubeconfig
인간이 직접 사용하든 Claude가 구동하든 동일한 인증 플로우 적용
인증 문제 발생 시 aws sso login, gh auth refresh 등 기존 방식으로 해결 가능하며, MCP 전용 트러블슈팅 불필요

운영상의 문제점: 가동 부품 없음(No Moving Parts)

로컬 MCP 서버는 별도 프로세스를 시작·유지해야 하며, Claude Code에서는 자식 프로세스로 생성되어 간혹 문제 발생
CLI 도구는 디스크에 있는 바이너리 파일일 뿐, 백그라운드 프로세스·상태 관리·초기화 절차 불필요

실무에서의 불편함

초기화 불안정: MCP 서버가 기동되지 않아 Claude Code를 재시작하는 일이 빈번하며, 상태 초기화 후 재시도 필요
반복적 재인증: 여러 MCP 도구 사용 시 각각 인증해야 하지만, SSO나 장기 유효 자격증명을 쓰는 CLI에는 이 문제 없음
권한 제어의 조잡함: Claude Code에서 MCP 도구를 이름 기준으로 허용할 수 있지만, 읽기 전용 제한이나 파라미터 범위 지정은 불가
- CLI는 gh pr view는 허용하고 gh pr merge는 승인을 요구하는 등 세밀한 권한 제어 가능

MCP가 유효한 경우

CLI에 해당하는 도구가 전혀 없는 경우 MCP가 적합할 수 있음
표준화된 인터페이스로서의 가치와, CLI보다 MCP가 더 적합한 유스케이스가 존재할 가능성은 인정
그러나 대부분의 작업에서 CLI가 더 단순하고, 디버깅이 빠르며, 신뢰성 높음

핵심 교훈과 빌더에게 보내는 요청

최고의 도구는 인간과 기계 모두에게 작동하는 도구이며, CLI는 수십 년간의 설계 반복을 거쳐 조합 가능하고 디버깅 용이하며 기존 인증 시스템과 통합됨
MCP는 더 나은 추상화를 만들려 했지만, 이미 충분히 좋은 추상화가 존재했음
MCP 서버에 투자하면서 공식 CLI가 없는 회사는 전략을 재고해야 하며,
좋은 API → 좋은 CLI 순서로 제공하면 에이전트가 알아서 활용함
불필요한 프로토콜 복잡성을 줄이고 생산성과 유지보수성을 향상할 수 있음

▲

sonnet 1달전 [-]

MCP가 이점이 없는 게 아니라 MCP의 이점이 없는 용도에 무차별적으로 사용하던 환상에서 깨어난거죠. 마이크로 서비스를 LLM을 위해 개방할때도 CLI쓸거 아니고 MCP는 'API' 프로토콜이니까요.

답변달기

▲

brainer 1달전 [-]

그때도 API쓰면 되죠. 사실 MCP를 썼던 이유는 long context 한계때문에 썼던건데 이제는 그 한계를 대부분 극복했으니까요.

답변달기

▲

jamsya 1달전 [-]

격한 공감입니다.
aws mcp 안 깔아도 클로드 코드가 알아서 aws cli로 필요한 거 가져다 쓰더라구요 😂

답변달기

▲

GN⁺ 1달전 [-]

Hacker News 의견들

나는 오랫동안 이 말을 피하려 했지만, 이제는 MCP가 실질적인 이점이 없다는 확신이 생김
내 개발 워크플로 전체를 셸 명령으로 제어하는 AI 에이전트를 운영 중인데, 이들이 CLI 플래그를 처음 봐도 --help 출력만으로 잘 파악함
반면 MCP 서버는 항상 불안정하고 관리가 필요했음
CLI는 jq, grep, 파일 리다이렉션 등으로 조합이 가능한데 MCP는 서버가 반환하는 형식에 갇혀 있음
결국 MCP 채택은 기술적 이유보다 ‘AI-first’ 마케팅 신호에 불과하다고 생각함
- MCP는 2024년에 급성장했지만, 2025년 초 터미널 에이전트(Claude Code) 가 등장하면서 메타가 빠르게 바뀐 사례라고 봄
- 나는 반대로 MCP를 선호함. CLI보다 에러 처리와 디버깅이 훨씬 깔끔하고, 위험한 플래그를 제한하거나 결과를 페이지네이션으로 나눌 수 있음
  MCP는 REST나 gRPC처럼 단순히 래퍼 개념으로 이해하면 됨
- 나도 MCP를 피함. JIRA MCP를 써봤는데 엉망이었음. 대신 LLM이 API를 직접 호출하고 스크립트를 작성하게 하니 훨씬 효율적이었음
  지금은 LLM CLI 도구가 정점이라고 생각함
- 우리 회사는 내부 위키 같은 웹 전용 도구를 MCP로 노출시켜 Claude가 로그와 메트릭을 직접 조회하도록 함
  다만 MCP 결과가 항상 컨텍스트 창으로 들어가는 건 불편함. 파일시스템으로 덤프할 수 있으면 좋겠음
- MCP 서버는 LLM이 덜 발전했을 때 만들어진 과도기적 산물 같음. CLI 데이터로 학습하는 게 훨씬 낫다고 생각함
MCP는 설치나 리소스 프로비저닝 없이 바로 호출할 수 있는 블랙박스 API 같음
반면 CLI는 로컬 환경에 접근할 수 있어 훨씬 정밀함
jq, duckdb CLI를 이용해 대규모 데이터 파일을 샘플링하고, Opus 4.6이 자동으로 쿼리를 조정하며 탐색함
CLI는 실시간 반응성이 좋아서 탐색적 데이터 분석에 특히 유용함
자주 쓰는 CLI로는 showboat, br, psql, roborev 등이 있음
- 나도 같은 경험을 함. CLI의 텍스트 입출력은 LLM 학습 방식과 가장 잘 맞음
  duckdb를 ChatGPT와 함께 쓸 때 즐거웠는데, 로컬 DB를 유지하도록 시스템 프롬프트를 설정하는지 궁금함
- CLI 대신 Docker 컨테이너에서 명령을 실행하면 설치 문제를 피할 수 있음. 이런 접근을 자동화하는 ‘skill’을 만들 수도 있을 듯
- 영어 비원어민으로서 MCPs처럼 복수형을 쓰는 게 재밌게 느껴짐
MCP는 CLI에 없는 도구를 발견하고 맥락적으로 호출할 때 의미가 있음
예를 들어 내가 만든 echomindr는 팟캐스트에서 창업자 의사결정을 추출한 DB를 MCP로 제공함
Claude가 스타트업 관련 질문을 받으면 실제 창업자 경험을 검색해 답변함
CLI는 사람이 어떤 도구를 쓸지 이미 아는 경우에 적합하고, MCP는 발견형 툴 선택에 적합함
글쓴이가 AI 사용을 개발자 중심으로만 본 것 같음
대부분의 사용자는 ChatGPT 같은 웹 기반 인터페이스로 LLM을 사용함
기업 입장에서는 마케팅, 세일즈, 프로젝트 관리 도구를 연결하기에 MCP가 훨씬 적합함
MCP 자체는 나쁘지 않지만, stdio MCP가 과도하게 설계됨
대신 Streamable HTTP + OAuth Discovery 방식이 요즘 가장 효율적인 AI 통합 방법임
예를 들어 Sentry MCP는 단일 URL만으로 인증과 데이터 접근이 가능함
문제는 MCP 구현 방식임. bash로 호출하는 대신 MCP를 HTTP 엔드포인트로 노출하면 훨씬 유연하게 작동함
- CLI나 MCP 모두 권한 시스템이 API 수준에서 일관되게 설계되어야 함. Streamable HTTP 부분은 좀 더 설명이 필요함
- 나도 같은 입장임. 중앙화된 인증과 텔레메트리가 훨씬 간단함. 다만 올바른 용도에만 써야 함
내 고객 중 일부는 MCP 서버가 없는데, 개발자들이 그것을 요구함
결국 Postman API를 JSON으로 내보내서 제공했지만, 개발자들은 MCP 서버를 원함
MCP 지원 여부가 마케팅 체크리스트처럼 작동하는 현실임
이 블로그는 개발자 중심 시각에 치우친 듯함
비개발자용 도구나 서비스와 연결할 때는 MCP가 훨씬 자연스러움
- 맞음. 채팅 인터페이스에서는 CLI 실행이 불가능하고, 비개발자용 서비스는 CLI 자체가 없음
- ChatGPT나 LeChat 같은 웹·모바일 인터페이스에서 CLI를 돌릴 수 있는지도 의문이었음
- 비개발자용 인터페이스는 이미 OpenClaw, Claude Cowork 같은 형태로 진화 중임
“MCP 5년 경력자 모집” 같은 구인공고가 결국 무의미한 밈이 된 셈임
CLI가 MCP보다 나은 이유 중 하나는 정보 이론적으로 최적화된 형식을 갖고 있기 때문임
Unix 도구의 출력은 관련 정보가 가까이 배치되어 있어 LLM의 주의 메커니즘이 효율적으로 작동함
JSON은 파싱은 쉽지만 읽고 추론하기엔 불편함
CLI 형식은 인간과 LLM 모두에게 직관적임
관련 참고: Entropy and Information Layout
MCP와 CLI 비교는 마치 OpenAPI와 문자열(JSON) 을 비교하는 것과 같음
MCP는 형식적으로 정의된 반면, CLI는 (String, List String, Map Int Stream) -> PID 수준의 추상적 인터페이스임
결국 둘 다 API일 뿐, 중요한 건 목표를 달성하기 위한 적절한 도구 선택임
- 하지만 CLI는 --help로 완전한 문서를 제공하므로, LLM이 이를 이해할 수 있다면 MCP 표준화가 더 낫다고 보기 어려움
- 이론보다 실제 사용 경험이 중요함. MCP와 CLI가 같다고 말하려면, 예를 들어 Playwright CLI와 MCP가 동일한 토큰 사용량과 구성 가능성을 보여주는 예시를 만들어야 함
  그렇지 않다면 현실적으로 두 접근은 다르다는 점을 직접 체감하게 될 것임