⚰️인사이트

MCP는 죽었다, CLI 만세 - 왜 개발자들이 MCP를 버리고 CLI로 돌아가는가

Anthropic의 MCP 프로토콜이 실무에서 외면받는 이유와, CLI가 LLM 도구 통합에 더 적합한 이유를 분석합니다.

#MCP#CLI#LLM#개발도구#에이전트

MCP의 몰락과 CLI의 부활

Anthropic이 야심차게 발표한 Model Context Protocol(MCP)이 빠르게 관심을 잃고 있습니다. 많은 기업들이 앞다투어 MCP 서버를 구축했지만, 정작 실무에서는 전통적인 CLI(Command Line Interface)가 더 효과적이라는 평가가 나오고 있습니다.

LLM은 이미 CLI를 잘 사용합니다

LLM은 수백만 건의 man page, Stack Overflow 답변, GitHub 셸 스크립트를 학습했기 때문에 CLI 도구 사용에 매우 능숙합니다.

bash

# Claude에게 이렇게 요청하면 바로 동작합니다
gh pr view 123
jira issue view PROJ-456

MCP가 깔끔한 인터페이스를 약속했지만, 결국 각 도구의 설명과 파라미터를 문서화해야 하는 것은 동일합니다.

CLI의 결정적 장점들

1. 인간도 함께 사용 가능

LLM과 개발자가 동일한 명령어를 사용할 수 있습니다. Jira에서 문제가 발생하면 같은 jira issue view 명령어로 직접 재현할 수 있습니다.

MCP에서는 LLM 대화 내부에만 존재하는 도구를 디버깅하려면 JSON 로그를 뒤져야 합니다.

2. 뛰어난 조합성(Composability)

CLI는 파이프라인으로 자유롭게 조합할 수 있습니다.

bash

# Terraform 플랜에서 변경사항만 필터링
terraform show -json plan.out |   jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'

MCP로는 전체 데이터를 컨텍스트에 덤프하거나, 서버에 커스텀 필터를 구현해야 합니다.

3. 검증된 인증 체계

CLI 도구들은 이미 성숙한 인증 방식을 갖추고 있습니다:

▸`aws`: 프로파일과 SSO

▸`gh`: `gh auth login`

▸`kubectl`: kubeconfig

인증 문제 발생 시 aws sso login처럼 기존 방식으로 해결하면 되며, MCP 전용 트러블슈팅이 필요 없습니다.

4. 간단한 운영

CLI는 디스크의 바이너리 파일일 뿐입니다. MCP처럼 별도 프로세스를 시작하고 유지할 필요가 없습니다.

MCP의 실무 문제점

실제 사용자들이 겪는 문제들:

▸

초기화 불안정: MCP 서버가 기동되지 않아 Claude Code를 자주 재시작

▸

반복적 재인증: 세션마다 OAuth 플로우 반복

▸

권한 제어 부재: 도구에 대한 세밀한 권한 관리 불가

▸

디버깅 어려움: 프로토콜 디코더가 필요한 복잡한 구조

결론: 기업이 우선해야 할 것

대부분의 경우 CLI가 더 단순하고 신뢰성 높은 선택입니다. 기업들은 MCP 서버 구축보다는:

1.좋은 API 제공에 집중

2.잘 문서화된 CLI 도구 개발

3.인간과 LLM이 동일하게 사용 가능한 인터페이스 구축

이것이 진정한 LLM 시대의 도구 통합 방식입니다.