MCP는 죽었다? CLI가 다시 주목받는 이유와 실무에서의 선택 기준

최근 Anthropic이 발표한 Model Context Protocol(MCP) 이후, 많은 기업과 개발팀이 MCP 서버를 구축하며 새로운 표준에 올라타려 했습니다. 하지만 현장에서는 오히려 “MCP는 과연 필요한가?”라는 의문이 커지고 있습니다.

이 글에서는 MCP의 개념과 한계를 짚어보고, 왜 다시 CLI(Command Line Interface) 중심 접근이 더 실용적이라는 주장이 나오는지 정리합니다. 특히 LLM(대규모 언어 모델)과의 궁합, 디버깅, 인증, 조합성 측면에서 어떤 차이가 있는지 실무 관점에서 살펴보겠습니다.

---

1. MCP란 무엇인가?

MCP(Model Context Protocol)는 LLM이 외부 도구와 통신하기 위한 표준화된 프로토콜입니다.
기존 CLI 대신 별도의 서버 엔드포인트와 인증 체계를 두고, LLM이 JSON 기반 인터페이스를 통해 도구를 호출하도록 설계됐습니다.

등장 배경은 명확합니다.

• LLM이 외부 시스템을 안전하고 구조화된 방식으로 사용하도록 하기 위함
• 도구 호출을 표준화해 개발 생산성을 높이려는 목적

하지만 실제 현장에서는 기대만큼의 이점을 체감하지 못하고 있습니다.

---

2. LLM은 이미 CLI에 능숙하다

핵심 주장 중 하나는 이것입니다.

LLM은 이미 CLI 사용에 최적화돼 있다.

LLM은 수백만 건의 man page, Stack Overflow 답변, GitHub 셸 스크립트 등을 학습했습니다.
즉, CLI 명령어 구조와 사용 패턴을 이미 충분히 이해하고 있습니다.

예를 들어:

gh pr view 123

이 명령을 Claude에게 지시하면, 별도의 프로토콜 없이도 그대로 실행이 가능합니다.

MCP는 더 깔끔한 인터페이스를 약속했지만, 결국 다음과 같은 작업은 동일하게 필요합니다.

• 도구 설명 작성
• 파라미터 문서화
• 사용 시점 정의

즉, 기존 기능을 대체한다기보다 중복하는 구조가 되어버렸다는 지적입니다.

---

3. CLI는 인간과 LLM이 동일한 환경을 공유한다

CLI의 가장 큰 강점은 공통 실행 환경입니다.

예를 들어 Jira가 예상과 다르게 동작한다면:

jira issue view ABC-123

이 명령어를 사람이 직접 실행해 동일한 결과를 재현할 수 있습니다.

반면 MCP에서는:

• 도구가 LLM 대화 내부에 존재
• JSON 요청/응답 로그를 직접 뒤져야 함
• 별도 프로토콜 이해 필요

디버깅에 프로토콜 디코더가 필요한 구조는, 실무에서 큰 부담이 됩니다.

CLI는 입력과 출력이 명확합니다.
문제가 발생하면 그대로 재현하고, 로그를 보고, 수정하면 됩니다.

---

4. 조합성(Composability): CLI의 진짜 힘

CLI는 파이프라인 조합이 가능합니다.

예시: 대규모 Terraform 플랜 분석

terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'

이 한 줄은:

• JSON 변환
• jq 필터링
• 리소스 변경 카운트 계산

을 모두 수행합니다.

MCP로 동일 작업을 하려면:

1. 전체 플랜을 컨텍스트 윈도우에 덤프 (비용 높고 종종 불가능)
2. MCP 서버에 커스텀 필터링 로직 구현

즉, 이미 존재하고 잘 문서화된 CLI 도구들을 활용하는 편이 더 단순하고 유지보수가 쉽습니다.

---

5. 인증(Auth) 측면의 현실

MCP는 인증에 대해 비교적 독단적인 구조를 취합니다.
반면 CLI는 이미 검증된 인증 체계를 사용합니다.

예시:

• aws → 프로파일 + SSO
• gh → gh auth login
• kubectl → kubeconfig

인간이 사용하든, Claude가 실행하든 동일한 인증 흐름을 따릅니다.

문제 발생 시:

aws sso login
gh auth refresh

기존 방식으로 해결 가능합니다.
MCP 전용 인증 트러블슈팅이 필요하지 않습니다.

---

6. 운영 관점: “가동 부품이 없다(No Moving Parts)”

로컬 MCP 서버는:

• 별도 프로세스 실행 필요
• 상태 관리 필요
• 초기화 문제 발생 가능

특히 Claude Code에서 자식 프로세스로 실행될 경우 간헐적인 오류가 발생하기도 합니다.

반면 CLI는 단순합니다.

• 디스크에 있는 바이너리 파일
• 백그라운드 프로세스 없음
• 별도 초기화 절차 없음

운영 복잡도가 낮습니다. 이 차이는 실무에서 체감됩니다.

---

7. 실무에서 드러난 MCP의 불편함

1) 초기화 불안정

MCP 서버가 기동되지 않아 Claude Code를 재시작해야 하는 경우 발생.

2) 반복적 재인증

여러 MCP 도구 사용 시 각각 인증 필요.
CLI는 SSO 또는 장기 자격증명으로 해결 가능.

3) 권한 제어의 한계

Claude Code에서 MCP 도구를 이름 기준으로 허용 가능하지만:

• 읽기 전용 제한 불가
• 파라미터 범위 제한 불가

반면 CLI는 다음과 같이 세밀한 통제가 가능합니다.

• gh pr view는 허용
• gh pr merge는 승인 필요

실무 보안 정책 적용이 훨씬 수월합니다.

---

8. 그렇다면 MCP는 완전히 쓸모없는가?

그렇지는 않습니다.

다음과 같은 경우는 MCP가 적합할 수 있습니다.

• CLI에 해당하는 도구가 전혀 없는 경우
• 표준화된 인터페이스가 반드시 필요한 경우
• CLI보다 MCP 구조가 더 적합한 특수 유스케이스

다만 대부분의 일반적인 작업에서는 CLI가 더 단순하고 빠르며 신뢰성이 높다는 것이 핵심 주장입니다.

---

9. 기업과 빌더에게 주는 메시지

이 논의에서 얻을 수 있는 교훈은 명확합니다.

최고의 도구는 인간과 기계 모두에게 작동하는 도구다.

CLI는 수십 년간의 설계 반복을 거쳤습니다.

• 조합 가능
• 디버깅 용이
• 기존 인증 체계와 통합
• 운영 복잡도 낮음

MCP는 더 나은 추상화를 시도했지만, 이미 충분히 좋은 추상화가 존재하고 있었던 셈입니다.

전략적 제안

• MCP 서버 구축에 투자하기 전, 공식 CLI 제공 여부를 점검
• 좋은 API → 좋은 CLI 순서로 제공
• 에이전트는 CLI를 자연스럽게 활용 가능

불필요한 프로토콜 복잡성을 줄이면 생산성과 유지보수성이 동시에 향상됩니다.

---

728x90

단순함이 이긴다

MCP는 흥미로운 시도였습니다.
그러나 실무에서 중요한 것은 이론적 우아함이 아니라, 단순하고 재현 가능하며 유지보수가 쉬운 구조입니다.

CLI는:

• 인간과 LLM이 같은 명령을 사용하고
• 동일한 인증 체계를 공유하며
• 동일한 방식으로 디버깅할 수 있는

이미 검증된 도구입니다.

앞으로의 AI 도구 생태계에서 중요한 질문은 이것입니다.

새로운 프로토콜을 만들 것인가,
아니면 이미 잘 작동하는 인터페이스를 더 잘 활용할 것인가?

대부분의 경우, 답은 의외로 단순할지도 모릅니다.

300x250

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

MCP is dead. Long live the CLI