▲

MCP는 죽었다; MCP 만세

 (chrlschn.dev)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 최근 CLI 중심의 유행이 확산되며 MCP가 과거의 기술로 평가받고 있으나, 글은 조직 단위의 AI 엔지니어링에서는 여전히 MCP가 핵심임을 강조
  • CLI는 토큰 절약과 단순성에서 장점이 있으나, 맞춤형 CLI의 경우 LLM이 사용법을 학습하지 못해 오히려 비효율이 발생
  • MCP는 HTTP 기반 중앙화 구조를 통해 인증, 보안, 텔레메트리, 콘텐츠 동기화 등 조직 운영에 필요한 관리 기능을 제공
  • MCP Prompts와 Resources는 서버에서 최신 문서와 스킬을 동적으로 제공해, 모든 팀과 리포지토리에서 일관된 지식 전달을 가능하게 함
  • 개인 개발자에게는 과도할 수 있으나, 엔터프라이즈 환경에서의 가시성·보안·품질 관리를 위해 MCP는 여전히 필수적 도구로 평가됨

요약

  • 최근 업계 담론은 MCP에서 CLI로 이동했으며, MCP는 과거의 과대광고로 여겨지고 있음
    • 그러나 글은 MCP의 구조적 가치가 여전히 유효하다고 지적
    • 특히 조직적 도입과 운영에서는 MCP가 필수적임을 강조

인플루언서 주도의 하이프 사이클

  • 6개월 전까지만 해도 Model Context Protocol(MCP) 관련 제품이 폭발적으로 등장했으나, 현재는 CLI 중심으로 여론이 이동
  • MCP는 단순히 API 래퍼로 인식되어 직접 API 호출보다 비효율적이라는 평가를 받음
  • 글은 AI 인플루언서들이 유행을 주도하며 기술 담론을 왜곡한다고 비판
  • CLI가 유용한 경우도 있지만, 모든 상황에 적합하지 않으며 MCP의 역할을 대체하지 못함

오해의 이해

  • MCP가 모든 경우에 적합하지 않다는 점은 인정하지만, CLI와 MCP의 효율성 논쟁에는 오해가 많음
  • CLI는 모델 학습 데이터에 포함된 표준 도구(jq, curl, git 등)일 때만 토큰 절약 효과가 있음
    • 맞춤형 CLI는 LLM이 사용법을 모르는 경우가 많아 추가 문서와 지시어가 필요
  • CLI 체인으로 데이터 추출·변환 시 일부 절약이 가능하지만, 이는 MCP만의 한계가 아님
  • 점진적 컨텍스트 소비는 가능하나, 복잡한 CLI 구조에서는 오히려 더 많은 상호작용이 필요
  • MCP의 “복잡성” 비판은 과장되었으며, 스마트한 MCP 설계가 있다면 CLI 대비 손실이 크지 않음

MCP의 이중성

  • stdio 기반 MCP는 과도하지만, HTTP 기반 스트리밍 MCP는 조직 단위 도입의 핵심 요소로 평가
  • 중앙화된 MCP 서버는 보안, 인증, 상태 관리, 텔레메트리를 통합적으로 처리 가능
  • Ephemeral 환경(GitHub Actions 등) 에서도 MCP는 설치 없이 복잡한 백엔드 접근을 지원
  • 인증은 OAuth 기반 중앙 관리로 단순화되며, 개발자별 키 노출을 방지
  • OpenTelemetry 통합을 통해 팀 단위의 도구 사용 현황과 실패 지점을 추적 가능

표준화된 최신 콘텐츠 제공

  • MCP는 구독 및 알림 기능을 통해 클라이언트에 최신 업데이트를 자동 전달
  • MCP Prompts는 서버 제공 SKILL.md, MCP Resources는 서버 제공 /docs 역할 수행
  • 이를 통해 조직은 다음을 실현 가능
    1. 동적 콘텐츠 생성 – 문서와 스킬을 실시간으로 업데이트
    2. 자동 동기화 – 로컬 파일 관리 없이 항상 최신 상태 유지
    3. 조직 전체 지식 공유 – 모든 팀이 동일한 표준 문서와 스킬을 활용
  • MCP 클라이언트 설정만으로 배포가 완료되며, 업데이트 관리 부담이 제거됨

결론

  • 업계는 빠르게 변하며 인플루언서 중심의 유행이 반복되고 있음
  • MCP는 개인 개발자에게는 과도할 수 있으나, 조직적 엔지니어링 체계 구축에는 필수적
  • 보안·품질·일관성·관찰 가능성을 확보하기 위해 MCP는 여전히 최적의 선택
  • AI 에이전트가 생산한 코드를 운영·유지하려면, ‘바이브 코딩’에서 ‘에이전트 중심 엔지니어링’으로의 전환이 필요
  • MCP는 이러한 전환을 가능하게 하는 현재와 미래의 핵심 인프라로 제시됨
▲
GN⁺ 5시간전  [-]
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를 만드는 게 낫다고 생각함

답변달기