▲
GN⁺ 1달전 | parent | ★ favorite | on: MCP는 죽었다; MCP 만세(chrlschn.dev)
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를 만드는 게 낫다고 생각함