▲

MCP는 죽었다; MCP 만세

 (chrlschn.dev)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 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가 현재 조직과 엔터프라이즈에 적합한 도구
▲
GN⁺ 7시간전  [-]
Hacker News 의견들

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

  • AI 도구 중 가장 유용한 건 확률적 에이전트를 결정적 게이트로 감싸는 구조라고 생각함
    그래서 나는 MCP를 HTTP 위에서 사용함. 예를 들어 NanoClaw는 WhatsApp 메시지를 결정적으로 필터링하고 API 키를 프록시함으로써 보안을 강화함. 이런 구조가 AI를 더 신뢰할 수 있게 만듦

    • 나도 비슷한 패턴을 따름. 내 자율 에이전트 Smith는 MCP를 서비스 메시로 연결해 정책(OPA)과 모니터링을 중앙에서 관리함
      이 구조는 보안성과 관리 용이성이 높고, 도구 카탈로그에서 CLI를 자동 생성할 수도 있음
      구현 예시는 smith-gateway에서 볼 수 있음
    • 에이전트가 침해되더라도 경계가 유지되어야 함. 우리는 작업 단위로 범위가 제한된 암호학적 위임 토큰을 사용하고, MCP 도구 경계에서 검증함
      오픈소스 코어는 tenuo에서 확인 가능함
    • 요즘 좋은 AI 툴링의 핵심은 자유를 주는 게 아니라 제약을 주는 것임
      MCP는 AI의 의사결정과 시스템의 결정적 실행을 명확히 분리함. 나는 Claude Code와 MCP 서버를 함께 쓰는데, 창의적 문제 해결은 AI가 하고 실행은 예측 가능한 경로로 처리되어 매우 효율적임

  • MCP는 AI 앱 간 통신을 위한 고정된 프로토콜 사양임
    기존의 “통합(integration)” 방식처럼 앱 간 API를 억지로 묶는 게 아니라, HTTP·FTP·SMTP처럼 재사용 가능한 통신 추상화를 제공함
    AI가 다양한 서비스와 상호작용하려면 이런 공통 언어가 필요하다고 생각함
    사양은 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 사양에서 확인 가능함

  • 나는 MCP가 소비자용 환경에 더 적합하다고 느낌
    개발 환경에서는 복잡하고 비효율적이지만, 일반 사용자는 MCP를 통해 모델이 어떤 기능을 수행할 수 있는지 쉽게 파악할 수 있음
    환경 설정이 필요 없고, GUI에서 Siri나 Google Assistant처럼 응답을 시각화할 수도 있음

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

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

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

답변달기