AI 에이전트를 실무에 붙여보셨나요? 처음엔 MCP가 신기해서 이것저것 연결해봤는데, 어느 순간 응답이 느리고 에러도 자꾸 나고, "이거 써도 되는 건가" 싶어지는 순간이 옵니다.

"MCP는 죽었다, CLI 만세." 주장 자체는 자극적이지만 그 안에 실제로 따져볼 만한 수치와 논리가 있었습니다.

MCP와 CLI, 개념부터 다시 잡기

MCP는 컨시어지입니다. 호텔 컨시어지에게 "8시쯤 이탈리안 레스토랑 예약해줘"라고 말하면, 알아서 식당을 찾고 예약까지 넣어줍니다. 말의 의도를 파악해서 행동으로 이어주는 것이 핵심입니다.

CLI는 자판기입니다. git commit -m "메시지"처럼 정해진 명령을 정확히 입력하면 정해진 동작이 실행됩니다. 판단이 없습니다.

설계 철학이 다릅니다. MCP는 자연어 의도를 행동으로 바꾸고, CLI는 명확한 명령을 빠르게 실행합니다.

MCP의 토큰 문제

MCP를 연결하면 툴 정보를 시스템 컨텍스트에 계속 올려놓아야 합니다. 툴이 22개라면, 정의 자체가 전체 토큰의 8.1%를 차지합니다.

MCP는 CLI 대비 43배 많은 토큰을 사용하고, CLI가 94% 더 저렴합니다.

왜 불안정한가

• MCP 프로토콜이 상대적으로 새로움

• 서버 구현 품질이 제각각

• 응답 결과가 텍스트로 오면서 토큰 추가 소모

• 공식 MCP를 써도 에러가 종종 발생

💡 Claude나 Cursor에서 MCP가 느리다면, 불필요한 MCP 서버 연결을 끊어보세요. 그것만으로도 체감 속도가 달라집니다.

CLI가 빠른 건 조건이 있다

CLI가 효율적인 건 LLM이 이미 아는 도구에만 해당합니다.

LLM이 아는 도구 (CLI 추천)

• git, aws, kubectl, npm → 별도 설명 없이 바로 실행

LLM이 모르는 도구 (MCP 추천)

• 회사 내부 배포 도구, 팀 전용 스크립트, 신규 CLI → MCP로 툴 정의를 넘겨주는 방식이 적합

MCP가 더 나은 상황

MCP는 스트리머블 HTTP 방식으로 중앙 서버에서 인증 처리, 도구 자동 업데이트가 가능합니다.

• 팀 단위로 같은 도구를 공유할 때

• 인증과 보안을 중앙에서 처리할 때

• 도구가 자주 업데이트되는 환경

• LLM이 학습하지 않은 신규 내부 도구 연결

상황별 선택 기준

• 잘 알려진 도구 (git, AWS, kubectl) → CLI

• 새 내부 도구, 신규 서비스 → MCP

• 혼자 개인 프로젝트 → CLI (94% 비용 절감)

• 팀/조직 권한 관리 → 원격 MCP

• 비용 최소화 최우선 → CLI (43배 절감)

• 자연어 다단계 자동화 → MCP

결론

"MCP는 죽었다"는 자극적인 표현이었습니다. 실제로는 두 도구 모두 살아있고, 각자 잘 풀리는 문제가 다릅니다.

지금 MCP가 느리고 불안정하다면, 물어봐야 할 질문: "이 도구, LLM이 이미 알고 있나? 팀 단위 제어가 필요한가?"

한 줄 요약: 잘 알려진 도구는 CLI, 팀 단위 제어가 필요하면 원격 MCP.