# MCP는 죽었다. CLI 만세 > Clean Markdown view of GeekNews topic #27129. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27129](https://news.hada.io/topic?id=27129) - GeekNews Markdown: [https://news.hada.io/topic/27129.md](https://news.hada.io/topic/27129.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-02T17:32:59+09:00 - Updated: 2026-03-02T17:32:59+09:00 - Original source: [ejholmes.github.io](https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html) - Points: 36 - Comments: 8 ## Summary MCP의 복잡한 프로토콜보다 **CLI의 단순함이 실무에서 더 강력하게 작동**합니다. LLM은 이미 명령줄 환경에 익숙해 별도 서버나 인증 체계 없이도 대부분의 작업을 수행할 수 있으며, 인간과 동일한 명령으로 실행·디버깅이 가능합니다. CLI는 조합성과 인증, 권한 제어 면에서도 안정적이며, 기업은 MCP 서버 구축보다 **API와 CLI 제공에 집중**하는 편이 생산성과 유지보수성 모두에서 유리합니다. 사내용 서비스도 CLI로 만들어 보세요. ## Topic Body - **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** 순서로 제공하면 에이전트가 알아서 활용함 - 불필요한 프로토콜 복잡성을 줄이고 **생산성과 유지보수성을 향상**할 수 있음 ## Comments ### Comment 52277 - Author: sonnet - Created: 2026-03-03T16:34:51+09:00 - Points: 2 MCP가 이점이 없는 게 아니라 MCP의 이점이 없는 용도에 무차별적으로 사용하던 환상에서 깨어난거죠. 마이크로 서비스를 LLM을 위해 개방할때도 CLI쓸거 아니고 MCP는 'API' 프로토콜이니까요. ### Comment 52279 - Author: brainer - Created: 2026-03-03T16:57:57+09:00 - Points: 1 - Parent comment: 52277 - Depth: 1 그때도 API쓰면 되죠. 사실 MCP를 썼던 이유는 long context 한계때문에 썼던건데 이제는 그 한계를 대부분 극복했으니까요. ### Comment 52254 - Author: jamsya - Created: 2026-03-03T12:35:37+09:00 - Points: 2 격한 공감입니다. aws mcp 안 깔아도 클로드 코드가 알아서 aws cli로 필요한 거 가져다 쓰더라구요 😂 ### Comment 52179 - Author: neo - Created: 2026-03-02T17:32:59+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47208398) - 나는 오랫동안 이 말을 피하려 했지만, 이제는 **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](https://github.com/echomindr/echomindr)는 팟캐스트에서 창업자 의사결정을 추출한 DB를 MCP로 제공함 Claude가 스타트업 관련 질문을 받으면 실제 창업자 경험을 검색해 답변함 CLI는 사람이 어떤 도구를 쓸지 이미 아는 경우에 적합하고, MCP는 **발견형 툴 선택**에 적합함 - 글쓴이가 AI 사용을 개발자 중심으로만 본 것 같음 대부분의 사용자는 ChatGPT 같은 **웹 기반 인터페이스**로 LLM을 사용함 기업 입장에서는 마케팅, 세일즈, 프로젝트 관리 도구를 연결하기에 MCP가 훨씬 적합함 - MCP 자체는 나쁘지 않지만, **stdio MCP가 과도하게 설계됨** 대신 Streamable HTTP + OAuth Discovery 방식이 요즘 가장 효율적인 AI 통합 방법임 예를 들어 [Sentry MCP](https://mcp.sentry.dev/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](https://benoitessiambre.com/entropy.html) - MCP와 CLI 비교는 마치 **OpenAPI와 문자열(JSON)** 을 비교하는 것과 같음 MCP는 형식적으로 정의된 반면, CLI는 `(String, List String, Map Int Stream) -> PID` 수준의 추상적 인터페이스임 결국 둘 다 API일 뿐, 중요한 건 **목표를 달성하기 위한 적절한 도구 선택**임 - 하지만 CLI는 `--help`로 완전한 문서를 제공하므로, LLM이 이를 이해할 수 있다면 MCP 표준화가 더 낫다고 보기 어려움 - 이론보다 **실제 사용 경험**이 중요함. MCP와 CLI가 같다고 말하려면, 예를 들어 Playwright CLI와 MCP가 동일한 **토큰 사용량과 구성 가능성**을 보여주는 예시를 만들어야 함 그렇지 않다면 현실적으로 두 접근은 다르다는 점을 직접 체감하게 될 것임 ### Comment 52293 - Author: develosopher - Created: 2026-03-03T19:08:10+09:00 - Points: 1 어떤 사람이 saas를 개발했는데 AI 통합을 위해서 cli vs mcp 둘 중 하나를 고민한다면, 아마 mcp를 먼저 선택할 것 같아요. CLI를 지원하는 것은 관리 포인트가 늘어나는 일이니까요. 양립할 수는 있어도 사라지지는 않을 것 같아요. ### Comment 52276 - Author: hanje3765 - Created: 2026-03-03T16:33:13+09:00 - Points: 1 llm의 지능이 높아지면서 mcp의 필요성이 모호해졌다고 하는 것 같네요. 저도 실제로 그렇게 느끼고 있습니다. ### Comment 52264 - Author: m00nlygreat - Created: 2026-03-03T13:58:45+09:00 - Points: 1 원격 실행은 mcp, 로컬 실행은 skills로 정리되는 것 같습니다. ### Comment 52258 - Author: hulryung - Created: 2026-03-03T13:11:29+09:00 - Points: 1 저도 MCP보다 CLI로 툴을 직접 만들어쓰기 시작했습니다.