🛠️ 05. MCP vs CLI 판단 기준

“MCP는 죽고 CLI가 답이다”라는 주장은 자극적이지만, 현업에서 겪는 불편(초기화 실패, 재인증, 디버깅 난이도)을 정확히 찌른다는 점에서 꽤 설득력이 있습니다. 다만 결론을 한 줄로 고정하기보다, 업무 성격에 따라 MCP와 CLI를 분기하는 운영 기준을 갖는 편이 실무 효율이 훨씬 좋습니다.

흐름 한 장 요약

flowchart LR
A[문제 인지: 도구 연동이 느리고 불안정] --> B[원인 분해: 초기화/인증/권한/디버깅/조합성]
B --> C[대응 선택: CLI 우선 or MCP 우선]
C --> D[실행 검증: 20분 루틴 + 실패 로그 기준]

원문 핵심 주장(누락 없이)

원문(MCP is dead. Long live the CLI)의 요지는 아래 8개입니다.

1. LLM은 별도 프로토콜 없이도 CLI를 잘 쓴다.
2. MCP를 도입해도 결국 문서화(도구 설명/파라미터/사용 시점)는 여전히 필요하다.
3. CLI는 사람이 같은 명령을 바로 재현해 디버깅하기 쉽다.
4. 조합성(pipe, jq, grep 등)에서 CLI가 압도적으로 유리하다.
5. 인증은 CLI 생태계(aws, gh, kubectl)가 이미 충분히 성숙했다.
6. MCP 로컬 서버는 프로세스 수명/초기화 실패 같은 운영 리스크가 있다.
7. 권한 제어가 도구 단위 allowlist에 머물면 세밀한 통제가 어렵다.
8. 단, CLI 대안이 없는 도구라면 MCP가 실용적인 선택일 수 있다.

핵심은 “MCP 전면 부정”보다, 기본값을 CLI로 두고 MCP를 예외적으로 쓰자는 운영 철학에 가깝습니다.

1) 개념 정리: MCP가 하려는 일 vs CLI가 이미 하는 일

MCP 공식 소개를 보면 목적은 간단합니다. 모델과 외부 도구를 표준화된 방식으로 연결해 재사용성을 높이자는 것입니다. 방향 자체는 타당합니다.

문제는 실제 운영 단에서 발생합니다. 이미 팀이 gh, aws, kubectl 같은 CLI를 쓰고 있고, 인증/권한/로그/재현 루틴이 정착돼 있다면 MCP를 붙이는 순간 “새 레이어”가 하나 더 생깁니다. 레이어가 늘면 유연성도 생기지만, 장애 지점도 같이 늘어납니다.

즉,

• MCP 장점: 표준 인터페이스, 도구 노출 구조화
• CLI 장점: 기존 자산 즉시 활용, 사람·에이전트 공용 실행 경로

실무에서는 “더 멋진 구조”보다 장애 났을 때 5분 안에 복구 가능한가가 더 중요합니다.

2) 왜 마찰이 생기나: 현업에서 자주 터지는 5가지

① 초기화/세션 안정성

MCP 서버 프로세스가 제때 올라오지 않거나 중간에 멈추면, 모델은 도구를 못 씁니다. 반면 CLI는 바이너리 실행만 되면 바로 시작됩니다.

② 인증 재작업

CLI는 이미 인증 수명이 길거나 SSO 흐름이 확립돼 있습니다.

• GitHub CLI: gh auth
• AWS CLI SSO: AWS CLI SSO 설정

반대로 MCP 도구가 여러 개면 도구별 인증 상태 점검이 반복되기 쉽습니다.

③ 조합성 부족

원문이 든 Terraform 예시처럼, 대용량 JSON을 jq로 잘라 처리하는 패턴은 CLI의 본진입니다. (jq: 공식 매뉴얼)

④ 디버깅 경로가 멀어짐

CLI는 같은 명령을 사람이 바로 재현할 수 있습니다. MCP는 대화 컨텍스트·전송 로그·서버 상태까지 같이 봐야 해서 장애 추적 비용이 커집니다.

⑤ 권한 제어 세밀도

실무에서는 “읽기 명령은 자동, 쓰기/머지는 승인”처럼 행위 단위 통제가 중요합니다. 이때 CLI allowlist/승인 정책이 더 직관적으로 작동하는 경우가 많습니다.

🧠 칠판 치트시트

• 기본값은 CLI 우선, MCP는 CLI 대안이 없을 때 선택.
• 장애 복구 시간(5~10분 내) 기준으로 도구 경로를 평가.
• 인증/권한/디버깅은 “사람이 직접 재현 가능한가”를 최우선으로 본다.
• 대용량 데이터 처리(파이프/필터)는 CLI 파이프라인을 먼저 설계.
• 표준화가 필요하면 MCP를 붙이되, 운영 책임(로그·헬스체크)도 같이 설계.

3) 미니 사례 2개

사례 A (CLI가 유리한 경우)

• 상황: PR 리뷰 자동화에서 읽기 작업(gh pr view, gh pr diff)이 대부분이고, 병합은 승인 후 수동 처리.
• Before: MCP 도구 연결이 불안정해 세션 재시작이 잦음.
• After: CLI allowlist 기반으로 읽기 자동화, merge만 승인 단계 유지.
• 핵심 변화: 디버깅 시간이 줄고 실패 원인 파악이 빨라짐.

사례 B (MCP가 유리한 경우)

• 상황: 사내 전용 시스템이라 공식 CLI가 없고, API 스키마가 복잡함.
• Before: 모델이 직접 HTTP 호출 시 파라미터 실수 잦음.
• After: MCP 서버에서 입력 스키마와 검증 로직을 고정.
• 핵심 변화: 호출 안정성은 올라가지만, 서버 운영(배포/헬스체크) 부담은 증가.

둘 다 맞는 사례입니다. 결론은 기술 우열이 아니라 운영 조건 적합성입니다.

4) 20분 도입 루틴 (바로 적용)

0~5분: 도구 목록 분류

• 업무에 쓰는 도구를 CLI 있음 / CLI 없음으로 나눕니다.

5~10분: 기본 경로 지정

• CLI 있음은 기본 실행 경로를 CLI로 고정합니다.
• CLI 없음만 MCP 후보로 남깁니다.

10~15분: 실패 기준 정의

• 아래 3개를 측정 항목으로 정합니다.
  • 초기화 실패율
  • 재인증 빈도
  • 장애 재현 시간

15~20분: 승인 정책 고정

• 읽기/조회는 자동 허용, 변경/삭제/배포는 승인 필요로 분리합니다.

5) 최종 판단 프레임 (MECE)

• 개념: MCP는 표준 인터페이스, CLI는 실행 표준.
• 원인: 실제 마찰은 프로토콜 자체보다 운영 복잡도(초기화/인증/권한/디버깅)에서 발생.
• 대응: CLI-first + MCP-exception 정책.
• 실행: 20분 루틴으로 팀 기준 문서화 후, 1주일 로그로 재평가.

이 프레임을 쓰면 “MCP냐 CLI냐” 논쟁이 감정전이 아니라 운영 지표 기반 의사결정으로 바뀝니다.

다음 읽기

• 33. Agent Teams vs Subagent
• 31. 바이브코딩 실전 워크플로우
• 29. 프롬프트 캐싱 안 먹을 때 해결
• 11. skills 실전

출처

• 원문: MCP is dead. Long live the CLI
• MCP 공식: modelcontextprotocol.io
• Claude Code 문서: Anthropic Docs
• GitHub CLI: cli.github.com
• AWS CLI SSO: AWS 공식 문서

AI 활용 고지: 이 문서는 생성형 AI를 사용해 원문을 분석·재구성한 요약/실무 가이드입니다.