MCP가 CLI보다 의미가 있을 때는 언제인가?

Source: Hacker News

나는 대담한 주장을 할 것이다: MCP는 이미 사라지고 있다. 아직 완전히 깨닫지 못했을 수도 있지만, 징후는 분명히 있다. OpenClaw는 이를 지원하지 않는다. Pi도 이를 지원하지 않는다. 그리고 그럴 만한 이유가 있다.

Anthropic이 Model Context Protocol을 발표했을 때, 업계 전체가 정신을 잃었다. 모든 기업이 “AI first”임을 증명하기 위해 MCP 서버를 급히 출시하기 시작했다. 새로운 엔드포인트, 새로운 와이어 포맷, 새로운 인증 스킴에 막대한 자원이 쏟아졌고, 이는 LLM이 이미 대화할 수 있던 서비스와 대화할 수 있게 하기 위한 것이었다.

솔직히 말해서, 나는 그 필요성을 완전히 이해하지 못했다. LLM이 정말 잘하는 것이 뭔지 아는가? 스스로 문제를 해결하는 것이다. CLI와 몇 페이지의 문서만 주면 금방 달려들어 해결한다.

오랫동안 이 글을 쓰는 것을 피하려고 했지만, 나는 MCP가 실제 세계에서 아무런 이점을 제공하지 않으며, 오히려 없애는 것이 더 나을 것이라고 확신한다. 이유를 설명하겠다.

LLM은 특수 프로토콜이 필요하지 않다

LLM은 명령줄 도구를 사용하는 데 정말 능숙합니다. 수백만 개의 매뉴얼 페이지, Stack Overflow 답변, 그리고 셸 스크립트가 가득한 GitHub 저장소를 학습했기 때문이죠. 제가 Claude에게 gh pr view 123을 사용하라고 하면, 그냥 작동합니다.

MCP는 더 깔끔한 인터페이스를 약속했지만, 실제로는 여전히 같은 문서를 작성하게 됩니다: 각 도구가 무엇을 하는지, 어떤 매개변수를 받는지, 그리고 더 중요한 것은 언제 사용해야 하는지. LLM은 새로운 프로토콜을 필요로 하지 않았습니다.

CLI는 인간을 위한 것이기도 합니다

Claude가 Jira와 관련해 예상치 못한 동작을 할 때, 나는 동일한 jira issue view 명령을 실행해서 정확히 Claude가 본 것을 확인할 수 있습니다. 같은 입력, 같은 출력, 의문이 없습니다.

MCP에서는 도구가 LLM 대화 안에만 존재합니다. 문제가 발생하면 명령을 직접 실행하는 대신 JSON 전송 로그를 파헤쳐야 합니다. 디버깅에 프로토콜 디코더가 필요해서는 안 됩니다.

조합성

여기서 격차가 크게 벌어집니다. CLI는 조합이 가능합니다. jq로 파이프하고, grep으로 체인하고, 파일로 리다이렉트할 수 있습니다. 이것은 단순히 편리한 것이 아니라, 종종 유일하게 실용적인 접근 방식입니다.

대규모 Terraform 플랜을 분석하는 경우를 생각해 보세요:

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에 특화된 트러블슈팅은 필요하지 않습니다.

움직이는 부품이 없음

Local MCP 서버는 프로세스입니다. 이들은 시작하고, 계속 실행되며, 조용히 멈추지 않아야 합니다. Claude Code에서는 이들이 자식 프로세스로 생성되는데, 이는 상황에 따라 작동하지 않을 수도 있습니다.

CLI 도구는 디스크에 있는 바이너리일 뿐입니다. 백그라운드 프로세스가 없고, 관리할 상태도 없으며, 초기화 과정도 없습니다. 필요할 때는 존재하고, 필요 없을 때는 보이지 않습니다.

The practical pain

• Initialization is flaky. I’ve lost count of the times I’ve restarted Claude Code because an MCP server didn’t come up. Sometimes it works on retry, sometimes I’m clearing state and starting over.
• Re‑auth never ends. Using multiple MCP tools? Have fun authenticating each one. CLIs with SSO or long‑lived credentials just don’t have this problem. Auth once and you’re done.
• Permissions are all‑or‑nothing. Claude Code lets you allowlist MCP tools by name, but that’s it. You can’t scope to read‑only operations or restrict parameters. With CLIs, I can allowlist gh pr view but require approval for gh pr merge. That granularity matters.

그렇다면 MCP가 언제 의미가 있을까?

MCP가 완전히 쓸모 없다고 말하는 것은 아닙니다. 도구에 실제로 CLI 대응이 없을 경우, MCP가 올바른 선택일 수 있습니다. 저는 여전히 일상에서 많이 사용합니다—그것이 유일한 옵션일 때 말이죠.

표준화된 인터페이스를 갖는 것에 어느 정도 가치가 있다고 주장할 수도 있고, CLI보다 더 합리적인 경우도 있을 것이라고 생각합니다.

하지만 대부분의 작업에서는 CLI가 더 간단하고, 디버깅이 빠르며, 더 신뢰할 수 있습니다.

실제 교훈

가장 좋은 도구는 인간과 기계 모두에게 유용한 도구입니다. CLI는 수십 년에 걸친 디자인 반복을 거쳐 왔습니다. 이들은 조합 가능하고 디버깅이 쉬우며, 이미 존재하는 인증 시스템을 활용합니다.

MCP는 더 나은 추상화를 만들려고 시도했습니다. 그런데 이미 꽤 좋은 추상화가 있었던 것으로 드러났습니다.

건설자를 위한 호소

만약 여러분이 MCP 서버에 투자하고 있지만 공식 CLI가 없다면, 멈추고 현재 하고 있는 일을 재고하십시오. 좋은 API를 제공하고, 그 다음에 좋은 CLI를 제공하십시오. 에이전트들이 알아낼 것입니다.