▲

MCP는 죽었다. CLI 만세

 (ejholmes.github.io)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • MCP(Model Context Protocol) 이 업계에서 빠르게 관심을 잃고 있으며, CLI 기반 접근이 더 실용적이라는 주장
  • 대형 언어 모델(LLM)은 이미 명령줄 도구 사용에 능숙하며, 별도의 프로토콜 없이도 문서와 CLI만으로 충분히 작업 수행 가능
  • CLI는 인간과 LLM 모두가 동일한 환경에서 실행·디버깅 가능해 문제 원인 파악이 단순함
  • 조합성과 인증 체계, 안정성 측면에서도 CLI가 MCP보다 효율적이고 유지보수가 쉬움
  • 대부분의 경우 CLI가 더 단순하고 신뢰성 높은 선택지이며, 기업은 MCP 서버보다 우선적으로 API와 CLI 제공에 집중해야 함

MCP의 한계와 CLI의 우위

  • MCP는 실질적 이점이 없으며 OpenClaw와 Pi 등 주요 도구가 지원하지 않음
    • LLM이 이미 CLI와 문서를 통해 작업을 수행할 수 있음
    • MCP는 새로운 엔드포인트와 인증 체계를 추가하지만, 기존 기능을 중복함
  • LLM은 명령줄 도구 사용에 최적화되어 있음
    • 수많은 매뉴얼, Stack Overflow 답변, GitHub 스크립트로 학습되어 있음
    • 예를 들어 gh pr view 123 명령을 Claude가 문제없이 실행 가능

CLI의 인간 친화성

  • CLI는 인간과 LLM이 동일한 명령을 공유할 수 있음
    • Jira 예시에서 jira issue view 명령을 직접 실행해 LLM의 결과를 재현 가능
  • MCP는 내부 JSON 로그를 확인해야 해 디버깅이 복잡함
    • CLI는 입력과 출력이 명확해 문제 추적이 쉬움

조합성과 효율성

  • CLI는 파이프라인 조합이 가능해 복잡한 작업을 단순화함
    • 예: terraform show -json plan.out | jq ... 형태로 데이터 필터링 가능
  • MCP는 전체 데이터를 컨텍스트 창에 넣거나 서버에 필터링 기능을 추가해야 함
    • 결과적으로 더 많은 작업과 낮은 효율성 초래

인증과 안정성

  • CLI는 검증된 인증 체계를 그대로 활용
    • aws, gh, kubectl 등은 프로필, SSO, kubeconfig를 사용
    • 인증 오류 시 기존 방식(aws sso login, gh auth refresh)으로 해결 가능
  • MCP는 불필요하게 인증 정책을 강제함
    • 별도 문제 해결 절차가 필요해 복잡성 증가

운영상의 문제점

  • MCP 서버는 프로세스 관리가 필요하며, 실행 실패나 중단이 잦음
    • Claude Code에서 자식 프로세스로 실행되지만 안정적이지 않음
  • CLI는 단일 바이너리로 동작, 별도 상태 관리나 초기화 과정이 없음
    • 필요할 때 즉시 실행 가능

실무에서의 불편함

  • 초기화 불안정: MCP 서버가 자주 실패해 재시작 필요
  • 반복 인증 요구: 여러 MCP 도구 사용 시 매번 인증 필요
  • 권한 제어 한계: MCP는 도구 단위 화이트리스트만 가능, 세부 권한 설정 불가
    • CLI는 gh pr view는 허용하고 gh pr merge는 승인 필요 등 세밀한 제어 가능

MCP가 유용할 수 있는 경우

  • CLI 대안이 없는 도구에는 MCP가 유용할 수 있음
    • 일부 상황에서는 표준화된 인터페이스로서 가치 존재
  • 그러나 대부분의 작업에서는 CLI가 더 단순하고 신뢰성 높음

결론: 인간과 기계 모두를 위한 도구

  • CLI는 수십 년간의 설계 개선을 거친 안정된 인터페이스
    • 조합 가능성, 디버깅 용이성, 인증 호환성 확보
  • MCP는 더 나은 추상화를 시도했지만, 이미 충분히 좋은 CLI가 존재함

개발자와 기업에 대한 제언

  • MCP 서버 개발보다 API와 CLI 구축에 집중해야 함
    • 우수한 API와 CLI를 제공하면 에이전트가 스스로 활용 가능
    • 불필요한 프로토콜 복잡성을 줄이고 생산성과 유지보수성 향상
▲
GN⁺ 8시간전  [-]
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가 동일한 토큰 사용량과 구성 가능성을 보여주는 예시를 만들어야 함
      그렇지 않다면 현실적으로 두 접근은 다르다는 점을 직접 체감하게 될 것임
답변달기