Hacker News가 다시 짚은 MCP, CLI 단순성과 원격 MCP가 동시에 필요한 이유

드물게 더 구체적으로 흘러간 MCP 논쟁

2026년 3월 14일 Hacker News에 올라온 "MCP is dead; long live MCP"는 크롤링 시점 기준 231 points와 181 comments를 기록했다. 이 글이 눈에 띈 이유는 Model Context Protocol 자체를 부정하는 자극적 선언이 아니라, MCP를 어디서 어떤 방식으로 쓰는지에 따라 판단이 달라진다는 점을 분리해서 설명했기 때문이다. 연결된 글은 지금의 "CLI가 MCP보다 낫다"는 담론이 일부 현실을 짚고 있으면서도, 그 결론을 너무 넓게 일반화한다고 본다.

핵심 주장은 로컬 stdio MCP가 많은 경우 과하다는 것이다. 팀이 작은 CLI를 직접 제공하거나 REST endpoint를 얇게 감싸는 것만으로 충분하다면, 별도의 MCP schema는 오히려 오버헤드가 될 수 있다. 특히 git, curl, jq, aws처럼 모델의 학습 데이터에 이미 풍부하게 들어 있는 CLI는 모델이 사용법을 더 쉽게 떠올릴 수 있어서, 굳이 추가 schema를 밀어 넣지 않아도 된다는 설명이 나온다. 데이터 추출과 변환을 체인으로 나눠 context를 줄이는 방식도 MCP 없이 가능하다는 점이 함께 언급된다.

그렇다고 MCP가 사라지는 것은 아니다

하지만 글이 흥미로워지는 지점은 bespoke CLI를 다룰 때다. 모델이 한 번도 본 적 없는 커스텀 CLI는 결국 설명과 예시, help text가 필요하다. 다시 말해 context 비용이 사라지는 것이 아니라 README, AGENTS.md, 혹은 여러 번의 --help 탐색으로 이동할 뿐이라는 것이다. 이 글의 요지는 MCP가 항상 더 낫다는 것이 아니라, 커스텀 CLI의 context 절감 효과가 실제보다 과장되는 경우가 많다는 데 있다.

그래서 작성자는 로컬 stdio MCP와 streamable HTTP 기반의 원격 MCP를 분리해서 봐야 한다고 주장한다. 전자는 더 단순한 인터페이스로 대체하기 쉽지만, 후자는 조직 차원의 다른 문제를 해결한다. 중앙화된 MCP server는 OAuth 뒤에 secret을 숨길 수 있고, 얇은 로컬 CLI보다 더 풍부한 backend capability를 노출할 수 있으며, GitHub 같은 ephemeral runtime에서도 동일한 tool surface를 제공할 수 있다. 또한 standardized telemetry를 남기기 쉽고, MCP의 prompts와 resources는 즉흥적인 vibe coding에서 반복 가능한 internal agent engineering으로 넘어갈 때 의미가 있다는 점도 강조된다.

왜 HN에서 반응했는가

이 framing 덕분에 이 글은 Hacker News에서 설득력을 얻었다. MCP 찬반 이분법이 아니라, tool이 어디서 실행되고 누가 공유하며 어떤 운영 보장이 필요한지에 따라 인터페이스 선택이 달라진다는 이야기이기 때문이다. 개인 workflow에서는 CLI가 가장 깔끔한 선택일 수 있다. 반대로 인증, observability, shared agent tooling이 필요한 조직이라면 원격 MCP가 여전히 가장 명확한 표준화 계층 중 하나라는 것이 글의 결론이다.

원문: Charles Chen의 글. 커뮤니티 논의: Hacker News.