# MCP는 죽었다; MCP 만세

> Clean Markdown view of GeekNews topic #27530. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27530](https://news.hada.io/topic?id=27530)
- GeekNews Markdown: [https://news.hada.io/topic/27530.md](https://news.hada.io/topic/27530.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-16T04:34:27+09:00
- Updated: 2026-03-16T04:34:27+09:00
- Original source: [chrlschn.dev](https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/)
- Points: 19
- Comments: 6

## Summary

**MCP와 CLI의 논쟁**은 에이전트 도구 인터페이스의 방향성을 가르는 중요한 분기점으로 떠올랐습니다. 이 글에서는 개인 개발자에게는 학습 데이터에 이미 포함된 CLI가 효율적일 수 있지만, **조직 단위에서는 MCP의 중앙 집중형 구조**가 보안·일관성·관찰가능성을 동시에 확보할 수 있어 유리하다고 주장합니다. 특히 **Streamable HTTP 기반 MCP**는 OAuth 인증과 텔레메트리 표준화를 통해 엔터프라이즈 환경에서 에이전틱 엔지니어링을 실현하는 핵심 인프라로 자리 잡고 있습니다.

## Topic Body

- **CLI**가 에이전트 도구 인터페이스의 새로운 트렌드로 부상했지만, 맞춤형 CLI도 MCP와 동일한 **컨텍스트 문제**를 겪으며 구조화와 여러 장점을 포기해야 함  
- 로컬 `stdio` 모드의 MCP와 **Streamable HTTP** 기반 원격 MCP는 완전히 다른 유즈케이스이며, 이 구분이 현재 논쟁에서 간과되고 있음  
- MCP의 **Prompts와 Resources** 기능은 조직 전체에 표준화된 스킬과 문서를 실시간으로 배포하는 메커니즘으로, 바이브 코딩에서 체계적 에이전틱 엔지니어링으로의 전환에 핵심  
- 중앙 집중형 MCP 서버는 **OAuth 인증, 텔레메트리, 관찰가능성**을 표준화하여 조직 차원의 보안과 도구 효과 측정을 가능하게 함  
- 개인 개발자에게는 CLI가 적합할 수 있지만, **조직과 엔터프라이즈 수준**에서는 MCP가 일관성·보안·품질을 보장하는 현재이자 미래의 도구  
  
---  
  
### 인플루언서 주도 하이프 사이클  
  
- 6개월 전만 해도 **Model Context Protocol(MCP)** 이 업계 최대 화두였으며, 모든 벤더가 MCP 관련 제품을 출시하려 했음  
- 당시에도 "그냥 API인데 왜 래퍼가 필요한가"라는 회의적 시각이 있었고, 실제로 MCP 하이프 사이클을 건너뛰고 REST API 엔드포인트 위에 간단한 **도구 래퍼**를 작성하는 방식을 선택한 팀도 존재  
- 대부분의 유즈케이스에서 MCP는 API를 직접 호출하는 것 대비 **불필요한 오버헤드**라는 인식이 확산  
- 현재 업계 담론은 MCP 비판과 **CLI 찬양**으로 전환되었으며, 이는 AI 인플루언서들이 관심을 유지하기 위해 끊임없이 새로운 트렌드를 만들어내는 구조와 관련  
- Garry Tan, Andrew Ng 같은 저명인사들조차 개인적 경험을 일반화하는 경향이 있으며, FOMO와 하이프를 만들어내는 인플루언서 문화가 이 분야의 담론을 왜곡하고 있음  
- CLI가 에이전트 도구 인터페이스로서 더 적합한 경우가 실제로 있지만, **모든 경우에 그런 것은 아님**  
  
### CLI의 토큰 절감: 실체와 한계  
  
#### 학습 데이터에 포함된 CLI 도구  
- `jq`, `curl`, `git`, `grep`, `psql`, `aws` 등 LLM의 **학습 데이터셋에 포함된 CLI 유틸리티**는 추가 지시, 스키마, 컨텍스트 없이도 에이전트가 즉시 사용 가능  
- MCP는 `tools/list` 응답에서 도구를 사전 선언해야 하므로, 이미 알려진 CLI 도구 대비 오버헤드 발생  
- 학습 데이터에 이미 있는 CLI 도구는 **항상 MCP보다 우선 사용**하는 것이 맞음  
  
#### 맞춤형 CLI의 한계  
- 맞춤형(bespoke) CLI 도구는 LLM이 사용법을 알 수 없으므로, `AGENTS.md`나 `README.md`에 **설명을 제공해야 함**  
- `/cli-tools` 디렉토리를 지정하고 설명적 이름에 의존할 수 있지만, 에이전트는 이런 방식으로는 자주 실수하며 결국 더 많은 설명 문서가 필요  
- `curl` 같은 도구도 맞춤형 **OpenAPI 스키마**를 이해해야 하는 순간 토큰 절감 효과가 사라짐  
  
#### 체인형 추출 및 변환  
- CLI 체인으로 데이터 검색 후 변환하여 컨텍스트 윈도우에 들어가는 데이터를 줄일 수 있음  
- 그러나 HTML, JSON, XML 등 포맷화된 콘텐츠는 **DOM/CSS, JSONPath, XPath** 같은 셀렉터로도 추출 가능하여, CLI만의 고유 장점은 아님  
  
#### 점진적 컨텍스트 소비  
- MCP가 전체 도구셋과 스키마를 사전 로드하는 반면, CLI는 `--help`를 통해 **점진적으로 컨텍스트를 로드** 가능  
- 그러나 맞춤형 CLI 도구의 경우 에이전트가 여러 턴에 걸쳐 help 콘텐츠를 탐색해야 하며, 결과적으로 **MCP 스키마와 유사한 정보를 구조 없이 로드**하게 됨  
- 충분히 복잡한 플로우에서는 에이전트가 결국 대부분의 트리를 탐색하게 되어 절감 효과가 미미  
- **Vercel의 연구 결과**에 따르면 전체 문서 인덱스를 `AGENTS.md`에 배치했을 때 에이전트의 문서 활용도가 향상되었으며, 전체 스키마를 사전 제공하는 것이 올바른 도구 선택에 유리  
- Anthropic이 현재 **100만 토큰 컨텍스트 윈도우**를 제공하는 상황에서 토큰 절감이 여전히 결정적 논거인지 의문  
  
### MCP의 이중성: stdio vs Streamable HTTP  
  
#### stdio 모드의 한계  
- `stdio` 모드에서는 MCP 서버가 에이전트와 로컬에서 실행되며, 간단한 CLI 작성 대비 **불필요한 복잡성**을 추가  
- 대부분의 유즈케이스에서 `stdio` 모드 MCP는 불필요  
  
#### Streamable HTTP의 혁신적 가치  
- **Streamable HTTP** 전송 방식의 MCP는 동일한 로직을 **중앙 집중형 서버**에서 실행 가능하게 하며, 조직과 엔터프라이즈 채택에서 바이브 코딩을 에이전틱 엔지니어링으로 전환하는 핵심 요소  
- 대부분의 인플루언서들이 이 두 모드의 구분을 하지 못하고 있음  
  
### 중앙 집중형 MCP 서버의 장점  
  
#### 풍부한 백엔드 기능  
- 중앙 서버에서는 **Postgres 인스턴스**나 **Apache AGE** 기반 Cypher 그래프 쿼리 같은 풍부한 플랫폼 기능을 도구에 활용 가능  
- 에이전트에서는 HTTP 엔드포인트와 인증 토큰만 설정하면 되어 배포가 간단  
- SQLite 같은 로컬 DB도 가능하지만, 조직 전체 상태 공유에는 한계  
  
#### 임시(Ephemeral) 에이전트 런타임  
- **GitHub Actions** 같은 임시 런타임 환경에서 원격 MCP 서버를 통해 복잡한 백엔드가 필요한 도구를 설치 없이 사용 가능  
- 상태 비저장(stateless) 환경에서의 **상태 저장(stateful) 워크로드 관리**를 중앙 서버에 위임  
  
#### 인증과 보안  
- CLI로 보안 API에 접근하려면 모든 개발자가 **API 키에 직접 접근**해야 하며, 이는 운영팀에 큰 부담  
- MCP 서버 뒤에 중앙화하면 개발자는 **OAuth로 MCP 서버에 인증**하고, 민감한 API 키와 시크릿은 서버 뒤에서 통제  
- 팀원 이탈 시 **OAuth 토큰만 폐기**하면 되며, 해당 인원은 애초에 다른 키와 시크릿에 접근한 적이 없음  
  
#### 텔레메트리와 관찰가능성  
- 중앙 집중형 MCP 서버에서 **OpenTelemetry** 트레이스와 메트릭을 표준 도구로 수집 가능  
- 어떤 도구가 효과적인지, 어떤 에이전트 런타임을 사용하는지, 도구 실패 지점은 어디인지 파악 가능  
- CLI 도구로도 가능하지만, **로컬 배포는 소비자 업데이트가 필요**하고 각 CLI 도구마다 텔레메트리 스캐폴딩을 재현해야 함  
  
#### 표준화된 즉시 배포와 자동 업데이트  
- 분산 도구(패키지)는 **API 버전 호환성** 문제를 야기하지만, MCP는 **Subscriptions과 Notifications**를 통해 서버가 클라이언트에 업데이트를 알림  
- **MCP Prompts**는 서버에서 전달되는 `SKILL.md`에 해당하고, **MCP Resources**는 서버에서 전달되는 `/docs`에 해당  
  
### MCP Prompts와 Resources의 조직적 가치  
  
- **동적 콘텐츠**: 리포지토리의 `*.md` 파일은 수동 업데이트가 필요한 정적 파일이지만, 서버 기반 프롬프트와 리소스는 실시간으로 **동적 생성** 가능  
  - 특정 컨텍스트에서만 유용한 문서, 가격 데이터, 현재 시스템 상태 등을 도구 호출 없이 **동적 주입** 가능  
- **자동 일관성 업데이트**: 리포지토리나 패키지로 배포된 `*.md` 파일은 동기화가 필요하지만, MCP 프롬프트로 전달되면 **항상 최신 상태** 유지  
  - 서드파티 공식 문서도 서버를 통해 프록시하면 리포지토리에 수동 복제·업데이트 불필요  
- **조직 전체 지식 공유**: 보안, 텔레메트리 베스트 프랙티스, 인프라 배포 고려사항 등 조직 전체에 적용되는 콘텐츠를 **모든 리포지토리, 모든 워크플로우, 모든 에이전트 프론트엔드**(Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode 등)에 일관되게 배포  
  - 마이크로서비스 환경에서 한 팀이 다른 서비스의 문서에 접근해야 하거나, 서비스 팀이 배포 시마다 동적으로 스킬을 제공하는 것도 가능  
- OpenCode, Claude Code CLI 등에서 MCP 프롬프트와 리소스가 실제 작동하는 사례가 확인되며, MCP 클라이언트 설정만으로 **배포 후 별도 관리 불필요**  
  
### 결론: 조직 수준에서 MCP는 현재이자 미래  
  
- 6개월 전 MCP가 최고의 화두였다가 현재는 컨텍스트 블로트의 주범으로 비난받지만, 맞춤형 CLI의 **유사한 트레이드오프와 함정**은 간과되고 있음  
- 팀이 바이브 코딩에서 에이전틱 엔지니어링으로 전환하는 방법을 고민하면, MCP의 설계와 미션에 자연스럽게 도달  
- **Amazon AWS 부서의 최근 사례**(AI 지원 변경사항에 시니어 엔지니어 승인을 요구)에서 보듯, 팀은 결국 AI 에이전트가 생산한 소프트웨어 시스템을 **운영·유지보수해야 함**  
- Garry Tan, Andrew Ng의 조언은 **개인의 동질적 환경**에서 유효할 수 있지만, 다양한 기술 수준과 경험을 가진 팀이 **일관된 품질로 수렴**해야 하는 조직 환경에는 그대로 적용하기 어려움  
- 신뢰할 수 있고 유지보수 가능한 소프트웨어를 출시하려면, 일관성·보안·품질·정확성을 보장하는 **엔지니어링 규율**이 필요하며, 이를 위해 MCP가 현재 조직과 엔터프라이즈에 적합한 도구

## Comments



### Comment 53141

- Author: slowandsnow
- Created: 2026-03-16T18:26:51+09:00
- Points: 1

cli는 로컬 도구고, mcp는 서버라서 용도가 너무 다름.

### Comment 53241

- Author: cnaa97
- Created: 2026-03-17T18:40:08+09:00
- Points: 2
- Parent comment: 53141
- Depth: 1

CLI를 서버에서 돌리면 같지 않을까요?

### Comment 53138

- Author: ng0301
- Created: 2026-03-16T17:45:03+09:00
- Points: 1

예토전생 MCP !

### Comment 53106

- Author: edunga1
- Created: 2026-03-16T11:58:09+09:00
- Points: 1

연관 문서: [MCP는 죽었다. CLI 만세](https://news.hada.io/topic?id=27129)

### Comment 53100

- Author: hmmhmmhm
- Created: 2026-03-16T11:23:38+09:00
- Points: 1

모바일 앱에서도 CLI 도구가 사용가능하게 무언가 CLI 샌드박스 기능이 논의가 더 발전되면 좋겠어요, 실제 모바일을 호환시키려 하다보면 결국 병목은 샌드박싱이 화두인 것 같습니다.

### Comment 53067

- Author: neo
- Created: 2026-03-16T04:34:27+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47380270) 
- 요즘 나오는 **AI 통합 기능**들은 대부분 설계가 허술하다고 느낌  
  기본 명령어조차 표준화되지 않은 상황에서, 문서 대신 LLM이 생성한 **부정확한 도움말**만 넘쳐남  
  결국 “AI 표준”이라 불리는 것들이 반복적으로 생겼다가 사라질 것 같음. LLM은 본질적으로 텍스트 기반이라 네트워크 프로토콜처럼 정밀하게 동작하기 어려움. 이런 **텍스트 중심 엔지니어링**은 결국 불안정한 추상화 피라미드를 만들게 됨  

- AI 도구 중 가장 유용한 건 **확률적 에이전트**를 **결정적 게이트**로 감싸는 구조라고 생각함  
  그래서 나는 MCP를 HTTP 위에서 사용함. 예를 들어 NanoClaw는 WhatsApp 메시지를 결정적으로 필터링하고 API 키를 프록시함으로써 보안을 강화함. 이런 구조가 AI를 더 신뢰할 수 있게 만듦
  - 나도 비슷한 패턴을 따름. 내 자율 에이전트 Smith는 MCP를 서비스 메시로 연결해 정책(OPA)과 모니터링을 중앙에서 관리함  
    이 구조는 **보안성과 관리 용이성**이 높고, 도구 카탈로그에서 CLI를 자동 생성할 수도 있음  
    구현 예시는 [smith-gateway](https://github.com/sibyllinesoft/smith-gateway)에서 볼 수 있음
  - 에이전트가 침해되더라도 경계가 유지되어야 함. 우리는 작업 단위로 범위가 제한된 **암호학적 위임 토큰**을 사용하고, MCP 도구 경계에서 검증함  
    오픈소스 코어는 [tenuo](https://github.com/tenuo-ai/tenuo)에서 확인 가능함
  - 요즘 좋은 AI 툴링의 핵심은 자유를 주는 게 아니라 **제약을 주는 것**임  
    MCP는 AI의 의사결정과 시스템의 결정적 실행을 명확히 분리함. 나는 Claude Code와 MCP 서버를 함께 쓰는데, 창의적 문제 해결은 AI가 하고 실행은 예측 가능한 경로로 처리되어 매우 효율적임  

- MCP는 AI 앱 간 통신을 위한 **고정된 프로토콜 사양**임  
  기존의 “통합(integration)” 방식처럼 앱 간 API를 억지로 묶는 게 아니라, HTTP·FTP·SMTP처럼 **재사용 가능한 통신 추상화**를 제공함  
  AI가 다양한 서비스와 상호작용하려면 이런 공통 언어가 필요하다고 생각함  
  사양은 [modelcontextprotocol.io/specification/2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)에서 볼 수 있음
  - 하지만 어떤 사람은 “이건 문제를 잘못 짚은 해결책”이라 말함  
    사실 필요한 건 새로운 프로토콜이 아니라, **점진적으로 탐색 가능한 CLI나 API 명세**임. MCP는 초기 에이전트가 CLI를 실행하지 못했을 때의 임시방편일 뿐이라고 주장함
  - 또 다른 의견은 “AI가 AI라면 왜 HTTP나 FTP를 이해하기 위한 별도 프로토콜이 필요한가”임  
    MCP는 결국 **기술 미성숙의 임시 해결책**이라는 시각임
  - “새로운 프로토콜을 만들 필요가 있느냐”는 근본적인 의문도 제기됨
  - MCP는 사실상 **JSON-RPC 위에 얹은 맞춤형 API 정의**일 뿐이라, 기존 방식보다 표준적이거나 재사용성이 높다고 보기 어렵다는 비판도 있음
  - CLI 도구도 결국 “재사용 가능한 통신 추상화”라는 점에서 MCP와 다를 바 없다는 의견도 있음  

- MCP가 처음 나왔을 때 **과도하게 설계된 쓰레기**처럼 보여서 관심을 두지 않았음  
  지금까지도 후회하지 않음. LangChain도 마찬가지임. 인기 있다고 따라가는 건 위험함
  - 하지만 나는 지금 모든 코드에 MCP 인터페이스를 붙이고 있음. LLM이 디버깅하기 훨씬 쉬워지고, **UI만큼 중요한 구성 요소**가 되었음  
    아주 작은 시간 투자로도 큰 효율을 얻을 수 있음
  - 물론 ‘냄새 테스트(sniff test)’는 유용하지만, 그것만으로는 충분치 않음  
    가끔은 **투박한 도구**가 오히려 복잡한 통합 문제를 단순하게 해결해 살아남기도 함  
    처음부터 못생겼다고 무시하면 나중에 표준 인프라가 될 기회를 놓칠 수도 있음
  - LangChain은 과설계가 아니라, **아예 설계가 없는 혼돈**임
  - 어떤 사람은 오히려 MCP가 **너무 단순해서** 인기를 얻었다고 말함  
    과설계라기보다 명확하고 직관적인 구조라는 평가임
  - 여전히 LangChain이 정확히 뭔지 모르겠다는 사람도 있음  

- 원격 MCP는 인증이 자동 처리되어 **서비스 접근이 간편**하다는 점에서 괜찮음  
  하지만 CLIs + Skills 조합에 비해 **맥락 부하(context bloat)** 가 크고, 파이프라인 처리나 heredoc 입력 등 Unix CLI의 장점을 잃음  
  CLI는 `--help` 출력으로부터 자동으로 skill을 생성할 수 있어 효율적임  
  MCP는 지속 프로세스가 필요하지만 CLI는 필요할 때만 실행 가능함
  - 물론 CLI는 설치가 필요하지만, MCP는 단순히 **설정만으로 동작**한다는 장점이 있음  

- 나는 여전히 MCP가 **불필요한 계층**이라고 생각함  
  CLI > MCP라는 점에는 동의하지만, 문서화와 중앙화 이점은 다른 방식으로도 해결 가능함  
  예를 들어 **Skills**를 사용하면 CLI와 API 모두에 대한 지침을 담을 수 있고, 필요한 시점에만 로드됨  
  중앙화된 MCP의 장점도 사실 **기존 프록시나 AWS SSO**로 충분히 구현 가능함  
  결국 Skills로 문서화하고, 실제 상호작용은 CLI나 REST API로 처리하는 게 낫다고 봄
  - 하지만 이에 대한 반론도 있음  
    Skills의 내용이 결국 **맥락에 포함되어 부하를 유발**하고, 프록시로 MCP의 기능을 완전히 대체할 수 없다는 주장임  
    MCP는 `/` 명령과 `@` 참조로 프롬프트와 리소스를 활성화할 수 있는데, 이는 프록시로는 불가능함  
    관련 데모는 글 마지막의 .gif들과 [MCP 사양](https://modelcontextprotocol.io/specification/2025-11-25)에서 확인 가능함  

- 나는 MCP가 **소비자용 환경**에 더 적합하다고 느낌  
  개발 환경에서는 복잡하고 비효율적이지만, 일반 사용자는 MCP를 통해 모델이 어떤 기능을 수행할 수 있는지 쉽게 파악할 수 있음  
  환경 설정이 필요 없고, GUI에서 **Siri나 Google Assistant처럼 응답을 시각화**할 수도 있음  
  - 그 GUI 응답 시스템은 [MCP progress spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/progress)에 정의되어 있음  

- 기업 내 비개발자 사용자에게 AI 도구를 제공하는 입장에서, **중앙화된 MCP 접근**이 매우 유용했음  
  브랜드 톤, 내부 용어, 공통 데이터 접근, 도메인 컨텍스트 등을 일관되게 관리할 수 있었음  
  MCP의 **리소스 메서드**를 통해 표준화된 “skills”를 제공하고, 데이터 연결 패턴을 통제함  

- 글쓴이는 여러 개념을 다각도로 살피지만, **Token Notation(TOON)** 같은 기존 개념을 모르는 듯함  
  마치 그런 게 존재하길 바라는 듯한 인상을 받음  

- MCP의 진짜 문제는 **유지보수 부담**임  
  예를 들어 GitHub 연동이 필요하면 이미 문서가 잘 된 API 대신 npm 래퍼에 의존해야 함  
  나는 그냥 `gh` CLI나 `curl`을 사용함. API가 바뀌면 에이전트가 새 문서를 읽고 적응함  
  MCP는 중간 래퍼가 업데이트될 때까지 기다려야 함  
  **보안성 주장도 모순적**임 — 초기에 인증 없이 나왔으면서 지금은 보안을 장점으로 내세움  
  실제로는 chroot나 scoped token 같은 오래된 방식이 이미 해결한 문제임  
  MCP가 유일하게 유리한 건 **비개발자용 OAuth 플로우**뿐임. 개발자 도구로는 그냥 더 나은 CLI를 만드는 게 낫다고 생각함