원문: https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html
저는 과감한 주장을 하려 합니다. MCP는 이미 죽어가고 있습니다. 아직 완전히 체감하지 못했을 수는 있지만, 징후는 분명합니다. OpenClaw도, Pi도 MCP를 지원하지 않습니다. 거기에는 그럴 만한 이유가 있습니다.
Anthropic이 모델 컨텍스트 프로토콜(Model Context Protocol)을 발표했을 때 업계는 일제히 열광했습니다. 모든 회사가 자신들이 "AI-first"라는 걸 보여 주기 위해 앞다퉈 MCP 서버를 내놓았습니다. 새로운 엔드포인트, 새로운 와이어 포맷, 새로운 인증 체계에 막대한 자원이 들어갔습니다. 하지만 결국 그 목적은, LLM이 원래도 접근할 수 있던 서비스와 다시 통신하게 만드는 것이었습니다.
솔직히 말해서, 전 그게 왜 필요한지 완전히 이해한 적이 없습니다. 여러분은 LLM이 정말 잘하는 게 무엇인지 아시나요? 바로 스스로 문제를 알아내는 능력입니다. CLI랑 문서 몇 개만 쥐여주면 LLM은 바로 해결하기 시작합니다.
오랫동안 이 글을 쓰지 않으려고 애썼지만, MCP가 실질적인 이점을 제공하지 못하고 오히려 없는 편이 더 나을 것이라는 확신이 들었습니다. 이유를 설명드리겠습니다.
LLM에는 특별한 프로토콜이 필요하지 않습니다
LLM은 명령줄 도구를 사용하는 데 정말 능숙합니다. 수백만 개의 man 페이지, Stack Overflow 답변, 셸 스크립트로 가득 찬 GitHub 저장소를 통해 학습되었기 때문입니다. 제가 Claude에게 gh pr view 123을 사용하라고 하면 바로 작동합니다.
MCP는 더 깔끔한 인터페이스를 약속했지만, 실제로는 결국 똑같은 문서를 다시 작성해야 했습니다. 각 도구가 무엇을 하는지, 어떤 매개변수를 허용하는지, 그리고 가장 중요한 것은 언제 사용해야 하는지에 대한 문서 말입니다. LLM에는 새로운 프로토콜이 필요하지 않았습니다.
CLI는 사람을 위한 것이기도 합니다
클로드가 지라에서 예상치 못한 작업을 수행하더라도, 저는 동일한 jira issue view 명령을 실행하여 클로드가 무엇을 보았는지 정확히 확인할 수 있습니다. 동일한 입력에 동일한 출력이 나오므로, 아무런 의문도 없습니다.
MCP를 사용하면 해당 도구는 LLM 대화 내에서만 존재합니다. 문제가 발생하면 직접 명령어를 실행하는 대신 JSON 전송 로그를 뒤져야 합니다. 디버깅에 프로토콜 디코더가 필요해서는 안 됩니다.
조합 가능성
바로 이 부분에서 격차가 커집니다. CLI는 명령어를 조합할 수 있습니다. jq로 넘기고, grep 과 연결하고, 파일로 리디렉션할 수 있습니다. 이는 편리할 뿐만 아니라, 종종 유일하게 실용적인 접근 방식입니다.
대규모 Terraform plan을 분석한다고 해 보겠습니다.
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'MCP에서는 선택지가 둘뿐입니다. 전체 플랜을 컨텍스트 창에 그대로 쏟아붓거나(비용도 많이 들고, 대개 현실적이지도 않습니다), 아니면 MCP 서버 자체에 맞춤형 필터링 로직을 넣는 겁니다. 어느 방법을 선택하든, 결과는 좋지 않으면서 작업량은 더 늘어납니다. CLI 방식은 이미 존재하는 도구를 활용하고, 이러한 도구들은 문서화가 잘 되어 있으며, 사람과 에이전트 모두가 이해할 수 있습니다.
인증은 이미 잘 동작합니다
MCP는 인증에 대해 인증 문제에 대해 지나치게 자기 방식대로 접근합니다. LLM에게 사용할 도구를 제공하는 프로토콜이 왜 인증에 신경 써야 할까요?
CLI 도구는 신경 쓰지 않습니다. aws는 프로필과 SSO를 사용하고, gh는 gh auth login을 사용하며, kubectl은 kubeconfig를 사용합니다. 이러한 인증 방식은 제가 직접 키보드를 잡고 있든, Claude가 대신 작업하든 똑같이 작동합니다. 이미 검증된 방식이기도 하고요. 인증에 문제가 생기면 항상 하던 대로 aws sso login 이나 gh auth refresh 로 해결합니다. MCP 관련 문제 해결은 필요하지 않습니다.
운영해야 할 별도 프로세스가 없습니다
로컬 MCP 서버는 프로세스입니다. 시작되어야 하고, 실행 상태를 유지해야 하며, 조용히 멈춰서는 안 됩니다. Claude Code에서는 자식 프로세스로 생성되는데, 이는 처음에는 잘 작동하지만 어느 순간 문제가 발생합니다.
CLI 도구는 디스크에 저장된 바이너리 파일일 뿐입니다. 백그라운드 프로세스도 없고, 관리해야 할 상태도 없고, 초기화 과정도 없습니다. 필요할 때 나타나고, 필요 없을 때는 보이지 않습니다.
현실적인 고통
설계 철학 차원의 문제를 떠나, MCP는 일상적인 업무에서도 여러 불편한 점이 있습니다.
초기화가 불안정합니다. MCP 서버가 시작되지 않아서 Claude Code를 재시작한 횟수는 셀 수 없을 정도입니다. 재시도하면 되는 경우도 있지만, 상태를 초기화하고 처음부터 다시 시작해야 하는 경우도 있습니다.
재인증은 끝이 없습니다. 여러 MCP 도구를 사용하시나요? 각 도구마다 인증하는 데 애쓰시나요? SSO나 장기 인증 자격 증명을 사용하는 CLI 도구는 이런 문제가 없습니다. 한 번 인증하면 모든 과정이 끝납니다.
권한은 전부 아니면 전무입니다. Claude Code는 MCP 도구를 이름으로 허용 목록에 추가할 수 있지만, 그게 전부입니다. 읽기 전용 작업으로 범위를 지정하거나 매개변수를 제한할 수는 없습니다. CLI를 사용하면 gh pr view 허용 목록에 추가하고 gh pr merge 는 승인을 받도록 설정할 수 있습니다. 이러한 세밀함이 중요합니다.
MCP는 언제 유용할까요?
MCP가 완전히 쓸모없다는 말은 아닙니다. 어떤 도구에 CLI로 대체할 수 있는 방법이 전혀 없다면 MCP가 적절한 선택일 수 있습니다. 저도 다른 방법이 없을 때는 여전히 일상 업무에서 MCP를 많이 사용합니다.
표준화된 인터페이스를 갖는 것이 어느 정도 가치가 있으며, 특정 사용 사례에서는 CLI보다 표준화된 인터페이스가 더 적합할 수 있다고 주장할 수도 있습니다.
하지만 대다수의 작업에서 CLI는 더 간단하고, 디버깅 속도가 빠르며, 더 안정적입니다.
진정한 교훈
최고의 도구는 사람과 기계 모두에게 유용한 도구입니다. CLI는 수십 년에 걸쳐 설계가 개선되어 왔습니다. CLI는 구성 가능하고 디버깅이 용이하며 기존 인증 시스템을 활용합니다.
MCP는 더 나은 추상화를 구축하려고 노력했습니다. 하지만 이미 꽤 괜찮은 추상화가 존재했습니다.
빌더들에게 드리는 부탁
MCP 서버에 투자하는 회사인데 공식 CLI가 없다면, 지금 당장 다시 생각해 보세요. 먼저 제대로 된 API를 제공하고, 그 다음에 제대로 된 CLI를 제공하세요. 에이전트가 알아서 처리해 줄 겁니다.
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!
옮긴이 메모
이 글을 재미있게 읽으셨다면, 저희 동아리에서 함께 활동하는 분들이 만든 CLI도 추천드립니다. :)
좋은 글 감사합니다