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를 제공하면 에이전트가 스스로 활용 가능

불필요한 프로토콜 복잡성을 줄이고 생산성과 유지보수성 향상