MCP는 죽었다. CLI 만세

• 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를 제공하면 에이전트가 스스로 활용 가능
  • 불필요한 프로토콜 복잡성을 줄이고 생산성과 유지보수성 향상