MCP를 비판적으로 살펴보기

 (raz.sh)
1P by GN⁺ | ★ favorite | 댓글 1개
  • MCP는 LLM/Agent가 외부 도구와 데이터 소스를 표준 방식으로 다루게 하려는 JSON-RPC 기반 프로토콜이지만, HTTP 전송 설계와 문서 품질이 구현 부담을 키운다는 비판을 받음
  • 가장 큰 쟁점은 단순한 양방향 통신을 HTTP에서 구현하면서 HTTP+SSE와 Streamable HTTP로 WebSocket에 가까운 동작을 우회적으로 재구성했다는 점임
  • Streamable HTTP는 세션 생성, SSE 연결, 응답 전달 경로가 여러 갈래로 나뉘어 상태 관리와 디버깅, 상호운용성, 확장성, 보안 부담을 늘림
  • HTTP 전송에는 OAuth2 중심 권한 부여 요구가 붙지만 stdio는 환경 변수에서 자격 증명을 가져오도록 되어 있어 인증 모델이 전송 방식마다 달라짐
  • HTTP 전송은 stdio의 입력·출력 스트림에 가장 가까운 WebSocket으로 단순화하고, 예외 사례보다 일반적인 사용 사례에 맞춰 설계를 최적화해야 함

MCP가 빠르게 확산되는 상황

  • MCP(Model Context Protocol)는 애플리케이션이 LLM에 컨텍스트를 제공하는 방식을 표준화하는 공개 프로토콜임
  • Anthropic은 MCP를 AI 애플리케이션의 USB-C 포트에 비유하며, AI 모델을 다양한 데이터 소스와 도구에 연결하는 표준 방식으로 설명함
  • 최근 한 달 동안 MCP가 빠르게 확산됐고, MCP Server와 Client가 매일 만들어져 mcp.so와 pulsemcp.com 같은 사이트에서 확인 가능함
  • IBM은 MCP와 “직교하는 표준”으로 Agent Communication Protocol(ACP)을 공개했고, Google도 Agent2Agent(A2A)를 발표함
  • 대형 업체들이 모델 학습과 튜닝에는 막대한 비용을 쓰면서도 문서, SDK, 구현 가이드의 성숙도는 낮다는 점이 핵심 비판으로 남음

프로토콜 자체와 전송 계층

  • MCP는 LLM과 함께 쓰도록 미리 정의된 메서드와 엔드포인트를 가진 JSON-RPC 프로토콜임
  • 주요 전송 방식은 로컬 실행에 가까운 stdio와 HTTP 기반 전송으로 나뉨

    • stdio

      • 로컬 MCP Server를 시작하고 stdout, stdin 파이프를 Client와 연결해 JSON을 주고받으며, stderr를 로깅에 사용함
      • Unix/Linux 파이프 패러다임을 양방향 통신에 쓰는 점은 비판 여지가 있지만, 모든 운영체제에서 쉽게 동작하고 소켓 처리가 필요 없어 이해하기 쉬움

    • HTTP 기반 전송

      • HTTP 위에서 동작하는 방식으로 HTTP+SSE와 이를 대체하려는 Streamable HTTP가 있음
      • 두 방식 모두 단순한 양방향 메시지 교환을 HTTP 요청과 SSE 연결 조합으로 구현하려 하면서 복잡도가 커짐

HTTP+SSE와 Streamable HTTP 비판

  • 기존 HTTP 전송은 HTTP+SSE(Server-Sent Events) 방식이고, 새 사양에서는 이를 Streamable HTTP로 대체하려 함
  • HTTP+SSE는 full duplex를 만들기 위해 Client가 GET /sse 같은 요청으로 읽기용 SSE 세션을 열고, 첫 응답에서 쓰기용 URL을 받은 뒤 POST /a-endpoint?session-id=1234 같은 요청을 보냄
    • 서버는 202 Accepted와 빈 본문을 반환함
    • 실제 응답은 이미 열려 있는 /sse 연결에서 읽어야 함
  • Streamable HTTP는 세션 ID를 별도 엔드포인트 대신 HTTP 헤더로 다루고, GET 또는 POST /mcp로 SSE 세션을 열 수 있음
    • 응답은 새 SSE 스트림으로 올 수 있음
    • POST 응답 본문에 200으로 올 수 있음
    • 기존 SSE 스트림 중 하나로 나중에 전달될 수 있음
  • 이 설계는 SSE 위에서 WebSocket처럼 동작하려는 구조에 가깝고, 실제 WebSocket을 쓰지 않기 위한 논리가 modelcontextprotocol/pull/206에서 논의됨
  • HTTP 전송은 stdio를 모방하려 하지만 실제 소켓이 아니기 때문에, 서버 구현이 여러 HTTP 호출과 연결을 결합(join) 해야 하는 부담을 떠안음

구현 경험에서 드러난 문서와 SDK 문제

  • Go로 MCP Server를 구현하려는 시도에서 공식 Go SDK가 없었고, 프로토콜을 이해하려면 사실상 역공학이 필요했음
  • modelcontextprotocol.io의 문서는 중요한 프로토콜 세부 사항을 넘기거나 빠뜨리고, 대화 흐름 예시도 제공하지 않음
  • 웹사이트는 표준 자체를 읽기보다 SDK 구현 튜토리얼로 이동하도록 유도하는 성격이 강함
  • 예제 서버는 Python 또는 JavaScript로 구현되어 있고, 로컬에서 stdio로 실행하는 것을 전제로 함
    • Python과 JavaScript는 다른 사람의 컴퓨터에서 안정적으로 동작해야 하는 로컬 도구에는 좋지 않은 선택으로 비판됨
    • 예제가 Docker 컨테이너로도 제공되는 점은 이 문제를 어느 정도 인식한 결과로 보임
  • 로컬 MCP 실행에는 Rust, Go, Java, C#처럼 더 이식성 있는 언어나 VM 기반 선택지가 더 적합하다는 판단이 제시됨

Streamable HTTP가 만드는 복잡도

  • Streamable HTTP에서는 새 세션을 세 가지 방식으로 만들 수 있음
    • 빈 GET 요청
    • 빈 POST 요청
    • RPC 호출을 담은 POST 요청
  • SSE도 네 가지 경로로 열릴 수 있음
    • 초기화를 위한 GET
    • 이전 세션에 합류하기 위한 GET
    • 세션 초기화를 위한 POST
    • 요청을 담고 SSE로 응답하는 POST
  • 요청 응답은 다시 세 가지 방식으로 전달될 수 있음
    • RPC 호출을 담은 POST의 HTTP 응답
    • 해당 POST에 대한 응답으로 열린 SSE 이벤트
    • 이전에 열린 임의의 SSE 이벤트
  • 같은 결과를 얻는 경로가 많아지면서 인지 부하, 디버깅 난이도, 유지보수 부담이 커짐
  • Client와 Server가 각자 필요하다고 판단한 일부만 구현하면 상호운용성 문제가 생기고, 예상치 못한 동작으로 이어질 수 있음
  • 여러 머신에 걸친 서버 구성에서는 연결 상태와 응답 메커니즘 관리가 확장성 병목을 만들 수 있음

보안과 권한 부여의 문제

  • Streamable HTTP의 유연성은 여러 보안 우려를 낳음
    • HTTP와 SSE에 걸친 세션 상태 관리는 복잡하며, 세션 탈취, 재생 공격, DoS 가능성을 만들 수 있음
    • 세션 생성과 SSE 연결 진입점이 많아져 공격 표면이 넓어짐
    • 세션 시작과 응답 전달 방식이 다양해 악성 활동을 숨기는 데 쓰일 수 있음
  • 최신 프로토콜의 authorization 사양은 HTTP 기반 전송 구현이 해당 사양을 따르도록 권고함
  • 같은 사양에서 STDIO 전송 구현은 해당 사양을 따르지 말고, 환경에서 자격 증명을 가져오도록 권고함
  • 이 구조에서는 HTTP 전송을 사용하면 OAuth2 절차를 구현해야 하는 반면, stdio에서는 API key 수준 접근이 가능해 보인다는 불만이 나옴

제안: HTTP 전송은 WebSocket으로 단순화

  • MCP에는 하나의 JSON-RPC 프로토콜이 있고, stdio가 명확히 선호되는 전송 방식처럼 보임
  • HTTP 전송은 stdio와 최대한 비슷하게 만들고, 꼭 필요할 때만 차이를 둬야 함
  • stdio의 환경 변수는 HTTP의 HTTP 헤더에 대응할 수 있음
  • stdio의 소켓 같은 입력·출력 스트림은 HTTP에서 WebSocket에 대응할 수 있음
  • WebSocket을 쓰면 세션을 위한 복잡한 서버 간 상태 관리와 많은 코너 케이스를 줄일 수 있음
  • 다만 권한 부여가 경우에 따라 더 복잡해질 수 있고, 일부 방화벽이 WebSocket을 차단할 수 있으며, 짧은 세션에서는 오버헤드가 생기고 끊긴 세션 재개가 더 어려울 수 있음
  • MCP 사양 자체도 양방향 메시지 교환을 지원하는 어떤 통신 채널에서도 구현 가능한 transport-agnostic 프로토콜이라고 밝힘
  • 업계는 코너 케이스가 아니라 가장 일반적인 사용 사례에 맞춰 최적화해야 함

ACP와 A2A에 대한 부가 평가

  • MCP는 API를 LLM에 노출하는 프로토콜이고, ACP와 A2A는 Agent를 LLM에 노출하는 프로토콜에 가까움
  • A2A 사양을 보면 필요성이 제한적으로 보이며, A2A의 많은 기능은 MCP 그대로 또는 작은 추가만으로 처리 가능해 보임
  • ACP와 A2A는 별도 프로토콜이라기보다 MCP Server의 도구로 구현될 수도 있음
  • IBM도 ACP Agent를 MCP 리소스로 보고 MCP 도구로 호출할 수 있다는 관점을 MCP adapter 문서에서 제시함
  • ACP는 IBM의 agent-building-tool인 BeeAI 홍보 성격이 있어 보인다는 평가를 받음
  • ACP와 A2A가 가져오는 장점은 더 온전한 전송 계층과 Agent 발견 방식임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 문서가 형편없는 건 거의 확실히 LLM으로 문서를 쓰기 때문이고, 아직도 매우 나쁜 생각임
    MCP 명세에는 LLM 흔적이 가득함: https://modelcontextprotocol.io/specification/2025-03-26
    명세나 RFC에서는 문서를 쓰는 과정 자체가 절반의 핵심인데, 현재 생각의 허점·부족함·누락을 찾아내고 경계 조건을 검토하며 모든 질문에 답하도록 다듬어야 함
    MCP 명세가 LLM 산물처럼 보이는 가장 큰 이유는 incoherent한 문체나 글머리표 남발이 아니라, 주요 명세치고 인간이 깊게 고민한 흔적이 너무 적다는 데 있음

    • DeepSeek 문서는 다른 문제가 있는데, 오탈자와 이상한 문법이 everywhere에 보임
      그래도 대체로 읽기 쉬워서 큰 문제는 아니지만, 언어를 다루는 회사이고 한때 세계 최고 수준의 영어 LLM을 만들었던 회사가 철자·문법 오류 없는 전문 문서를 못 만든다는 건 이상함
    • 흥미로운 문학은 몇 시간씩 읽고 이상한 생각도 글로 풀어낼 수 있는데, LLM식 장황한 글은 몇 단어도 못 읽겠어서 ADHD인지 콘텐츠가 유발하는 건지 헷갈림
      Reddit의 AITA 분노 유도 봇 글처럼 늘 같은 패턴을 따르는 건 그렇다 쳐도, 같은 LLM으로 기술 명세를 만들고 저자가 모르는 헛소리까지 들어갈 수 있다는 걸 정상처럼 받아들이는 건 걱정스러움
    • 이 명세도 LLM이 만든 것 같다는 강한 느낌이 듦
      제품 대부분이 “가장 그럴듯한 평균 결과”로 만들어졌다고 투자자에게 말하면 IPO 스토리로는 좋을지도 모름
    • DeepSeek 문서는 급히 만든 것처럼 보이지만 나쁘진 않음
      이게 LLM이 문서를 쓰는 것에 대해 무엇을 말해주는지는 잘 모르겠음
    • 사실이라면 아쉬운 일임
      Anthropic에는 정말 뛰어난 사람들이 있고, MCP는 새로 생기는 생태계에서 중요한 기반 블록임

  • 암호화폐 쪽이 “왜 금융 규제와 표준이 있는지”를 빠르게 재현했던 것처럼, LLM 쪽은 지금 소프트웨어 패러다임을 만드는 법을 속성으로 재현 중임
    이들이 하려는 “호출자가 질의할 수 있는 방식으로 원격 함수들을 노출”하는 개념은 DLL, gRPC, SOAP, IDL, dCOM 등 기존 예가 많지만, 그런 것들을 배운 것 같지도 않고 존재를 아는지도 의문임
    그래도 몇 달 더 지나면 성숙해질 가능성은 있고, 인증 패턴은 기존 레일과 개념을 쓰게 되었으니 나머지도 천천히 삼켜야 함

    • 초창기 Python 생태계처럼, 빠르게 위 계층 도구들이 쌓이면서 하위 스택의 실수가 영구 고착될 수도 있음
      게다가 초기 Python과 달리 AI 생태계에는 변명의 여지가 없음. 지금 저지르는 정확히 같은 실수의 역사적 사례가 이미 존재하기 때문임
    • MCP를 처음 다뤘을 때 COM/DCOM이 떠올랐고, 악명 높은 DLL Hell로 이어졌던 악몽도 생각났음
      MCP가 어떻게 흘러갈지 지켜볼 일임
      https://embracethered.com/blog/posts/2025/model-context-prot...
    • 전형적인 Worse is Better 상황임
      대부분의 사용자는 구현에는 관심 없고, MCP가 작은 코드 박스들을 최소 노력으로 붙여 멋진 일을 쉽게 하게 해주는지에 관심 있음
      그래서 개발자의 상상력을 자극하고 진입 비용을 낮추기 때문에 앞으로 치고 나갈 가능성이 큼
      구현은 분명 개선될 수 있지만, WebSocket이 더 낫다고 확신하진 않음. 방화벽 문제로 악명 높고 이런 작업에서는 중단 요인이 될 수 있음
      문서가 좋아지면 Go나 Arm 어셈블리 등 원하는 언어로 커스텀 구현도 가능해야 함. 이제는 고정 문서를 손으로 갱신하고 코딩하는 대신, LLM에게 물어보며 대화식으로 탐색하고 코드 생성까지 시킬 수 있는 지점에 가까워지고 있음
    • 아직도 MCP가 무엇인지 제대로 설명한 글을 못 찾겠음
      예전 개발자 언어로 말하면 이게 뭐임?
    • 이런 엄격하고 선언적인 프로토콜에는 잠재 공간과 LLM의 의미론적 강점을 활용하는 부분이 빠져 있음
      /.well-known 웹 폴더 루트에 agents.json을 두고 에이전트가 의미론적 대화로 “알아서 파악”하게 하면 충분한가?
      그러면 기본적으로 HTTP가 에이전트의 표준 입출력처럼 쓰이게 됨

  • 글 전체에 거의 동의함
    MCP 사이트에 들어갔을 때 실질적인 내용이 없어서 당황한 게 나만이 아니어서 반가움
    RFC는 읽기 고통스러울 수 있지만, “그냥 우리 SDK 라이브러리를 쓰라”는 것보다는 훨씬 나음

    • MCP 채택은 잠시 멈출 필요가 있음
      업계 표준이 되기에는 기술적 기반이 충분히 단단하게 설계되지 않았고, LangChain 같은 프로젝트 때처럼 과열된 상태로 보임
      구현을 파고들수록 사람들이 원하던 것이 아니라는 걸 깨닫게 될 가능성이 큼. 몇 사람이 급히 엮은 해킹에 가깝고, WebSocket은 여러 의심스러운 결정 중 하나일 뿐임
    • 사이트에 명확한 명세가 있으면 좋겠지만 없음: https://modelcontextprotocol.io/specification/2025-03-26
      절반쯤은 Sonnet 출력처럼 보이고, 프로토콜이 실제로 어떻게 동작하는지 설명하지 않음
      흠은 많아도 GraphQL 명세는 매우 잘 쓰여 있음: https://spec.graphql.org/October2021/
    • SDK 코드를 읽어도 당혹감은 끝나지 않음
      코드 품질, 구조, 기존 도구를 활용하지 않는 방식까지 엉망이고, 명세 자체도 “트렌치코트를 입은 JSON 스키마 5개” 같은 수준임

  • MCP의 Streamable HTTP 출시 때, 원격 MCP 서버는 그냥 HTTP 요청으로 단순화하면 되지 않느냐는 이슈를 올렸음
    https://github.com/modelcontextprotocol/modelcontextprotocol...
    MCP는 LLM과 도구를 연결하는 보편적 방식으로서 명세 자체는 유망하지만, 실제로는 인증, 도구 응답 스트리밍, 도구별 커스텀 지시, 도구 진위 검증 같은 경계 조건에 빠르게 부딪힘
    원격 서버 기준으로 REST API로는 못 하고 MCP로만 할 수 있는 게 무엇인지는 아직 명확하지 않고, REST 쪽이 훨씬 단순한 통합 경로로 보임
    OpenAI와 Gemini가 MCP를 채택하겠다고 했지만, 곧 UI 요소나 상호작용 계층처럼 명세를 넘어서는 일을 하고 싶어질 것임. 사용자에게 “10 Best MCP Integrations” 링크에서 찾은 Bob의 Stripe 통합을 설치하고 비밀 키를 공유하게 만들면, 브랜드에 안 맞는 망가진 경험이나 자격 증명 탈취로 이어질 수 있음

    • 정렬 문제도 예상됨
      Anthropic은 Anthropic 경험을 좋게 만들기 위해 MCP를 만들지만, 트래픽은 ChatGPT가 월등히 큼. Anthropic은 월 2천만, ChatGPT는 주 4억, Gemini는 월 3억5천만이라고 주장함
      OpenAI와 Google이 Anthropic 팀이나 위원회가 통합 명세를 주도하게 얼마나 오래 둘지 인센티브 구조가 어긋나 있음
      소비자는 이런 것들과 거의 상호작용해본 적이 없고, 한 번 있었던 ChatGPT Plugins는 실패했음. OpenAI 입장에서는 기술 구현 문제가 아니라 소비자 경험 문제였는데, 최종 사용자 경험의 한계를 정의하는 일을 다른 회사가 이끌게 하는 게 잘 이해되지 않음
      낙관적으로 보면 커뮤니티가 독립적으로 문제를 풀 만큼 강하고 동기부여되어 있으며, 실제 견인력도 있음. 어떻게 전개될지 흥미로움
    • 원격 서버 기준으로 MCP가 REST API보다 할 수 있는 건 없어 보임
      다만 매우 중요한 차이는 MCP 프로토콜에 메서드 발견이 내장되어 있다는 것임
      LLM에게 어떤 REST 엔드포인트가 있고 무엇을 하는지 “가르칠” 필요가 없고, 프로토콜에 포함되어 있음. 코드를 작성하고 MCP 프로토콜을 따르면 LLM이 자동으로 그 코드가 무엇을 하고 어떻게 써야 하는지 알게 됨
      그 점에서는 강력하지만, 그 외에는 특별한 건 아님. REST 이전의 API 설계 형식들도 REST API가 할 수 있는 일을 모두 할 수 있었던 것과 비슷함
    • 이런 관점으로 수렴하는 사람이 보여서 다행임. 과열 분위기를 이해 못 해서 미친 건가 싶었음
      LLM과 도구를 연결하는 표준 방식은 필요하지만, 현재 상태의 MCP는 해결책이 아님
    • 블로그 글을 올린 뒤 비슷한 일을 했음: https://github.com/modelcontextprotocol/modelcontextprotocol...
      이 이슈를 읽어보니 크게 기대하긴 어려워 보임
      이건 망치기엔 너무 중요한 일처럼 느껴짐

  • MCP는 처음부터 상태 없는 HTTP였어야 함
    지금 본 서버 대부분은 요청/세션 수준에서 상태를 가질 좋은 이유가 없음. 상태는 서버가 전역으로 들고 있거나, 어떤 형태의 세션 식별자로 충분히 동작함

    • MCP 상호작용의 로지스틱스를 이해 못 하겠음
      왜 상태가 없어서는 안 되는지, 왜 연결을 계속 열어둬야 하는지 설명해줄 수 있나?
    • 경험이 많다고 하긴 어렵지만, 요청이 끝나면 다음 요청 때 연결을 다시 열어야 한다는 직감이 듦
      세션을 열어두는 것과 닫는 것 중 무엇이 더 효율적인지는 사용 패턴, 세션이 소비하는 메모리 등에 따라 달라짐

  • 최근 공식 JavaScript SDK를 쓰려다 실패한 뒤 Node로 MCP 서버를 작성했음
    비판에 동의하고, 이건 경력상 본 것 중 최악일 수 있는 놀랍도록 나쁜 명세임. 작성자들이 실제로 사용해본 것 같지 않음
    “모든 응답과 알림을 받으려면 단일 연결을 열어둬야 한다”를 “장기 실행 요청 수만큼 연결을 열고, 알림용으로 하나를 더 열어야 한다”로 고치는 건 완전히 이상함
    명세를 읽어보면 클라이언트에게 그렇게 요구하고 있다는 사실을 알고 있는지도 확신이 안 듦

  • 인증 관련 코멘트는 조금 오래된 내용임
    Anthropic 및 더 넓은 보안 커뮤니티와 협력해서 MCP의 해당 부분을 업데이트했고, 역할 측면에서 리소스 서버(RS)와 인증 서버(AS)를 제대로 분리하도록 바꿨음
    새 프로토콜 버전이 비준될 때까지 초안에 있음: https://modelcontextprotocol.io/specification/draft/basic/au...

    • MCP 명세의 몇 퍼센트가 LLM 출력이었거나 지금도 그런가?
      내 안의 LLM 탐지 경보가 온갖 알람을 울리고 있는데, 뭔가를 제대로 짚은 건지 감지가 잘못 보정된 건지 궁금함
    • OAuth 초안을 되풀이하는 게 별로 유용해 보이지 않고, HTTP를 쓰면 왜 강제로 OAuth 쪽으로 가야 하는지도 모르겠음
      무인 시스템이 HTTP로 상호작용하려는 활용 사례가 많고, 보통 OAuth 말고 다른 것도 많이 씀
      전부 “클라이언트는 OAuth2를 구현해야 한다 / 서버는 OAuth2를 구현할 수 있다” 정도로 대체 가능했을 것 같음
    • 인증 이야기는 아니지만, MCP의 주요 “명세”는 LSP(Language Server Protocol)에서 영감을 받았다고 함
      오히려 HATEOAS 같은 것이 더 적절하지 않았을까?

  • 더 큰 문제의 일부임
    AI의 거의 모든 것이 수학자, 데이터 과학자, 학생, 아마추어 열성가에 의해 만들어지고 있고, 전문 소프트웨어 엔지니어가 만드는 게 아님
    그래서 소프트웨어 엔지니어링 기준으로 보면 거의 모든 것이 주말에 만든 개인 프로젝트처럼 보임

    • 내 경험과는 다름
      대부분의 작업이 전문 소프트웨어 엔지니어들에 의해 이루어지는 걸 봄
    • 수학 교육을 받았고 20년 넘게 소프트웨어 제품을 출시해온 입장에서 이 말에는 반대함
      많은 AI 작업은 넓지만 깊이가 없는 “대시형” 사람들이 하고 있음
      연구 진전을 이끄는 몇몇 I형 사람들과, 학습 실행이 돌아가도록 인프라를 만드는 몇몇 T형 사람들이 있음
      하지만 프로토콜 같은 것은 행렬을 계속 곱하게 해야 하는 I형이나 T형이 아니라, 대시형 사람이 설계할 가능성이 큼

  • MCP 레지스트리 중 하나인 https://glama.ai/mcp/servers의 창업자임
    글쓴이의 코멘트에 어느 정도 동의하지만, 프로토콜은 아직 극초기 개발 단계이고 내년에 많이 진화할 가능성이 큼
    처음부터 이렇게 큰 관심을 받을 거라고는 아무도 예상하지 못했을 것임. 레지스트리 작업을 시작했을 때 서버는 몇십 개도 안 됐는데, 몇 주 뒤 갑자기 천 개가 되었고 계속 늘어남
    다만 그 서버들 중 많은 수가 동작하지 않음. 대부분의 시간을 다양한 자동 테스트로 실제 동작하는 서버를 식별하는 데 쓰고 있음. MCP가 성숙하기 전에 주류 AI 사용자층에 먼저 퍼졌기 때문임
    지금은 상황이 나아지고 있음. 프로토콜의 어려운 부분을 추상화하는 프레임워크, 동작하는 서버를 잘 드러내는 레지스트리, MCP를 지원하는 클라이언트가 생겼음. 반년도 안 되는 시간에 이 정도가 나온 건 드문 일임
    MCP의 결함을 찾기는 쉽지만, 모든 일이 매우 짧은 시간 안에 일어났다는 점도 인정해야 함. 속도가 유지된다면 MCP의 미래는 밝음
    시작하는 사람에게 유용할 수 있는 자료들도 유지하고 있음: https://github.com/punkpeye/awesome-mcp-servers/, https://github.com/punkpeye/awesome-mcp-devtools/, https://github.com/punkpeye/awesome-mcp-clients/

    • 그래서 더더욱 겸손하게 명세를 만들어야 함
      프로토콜 설계 초기에 실수하면 영원히 안고 살아야 함. SSE로 만든 루브 골드버그 기계를 정말 영원히 유지하고 싶은가?
      프로토콜에 무작정 깨지는 변경을 넣을 수 있다고 생각한다면 NPM에서는 될지 몰라도, 기업 고객은 난리를 칠 것이고 실제로는 실수에 갇히게 됨
    • MCP의 실제 프로토콜은 어찌 됐든 계속 진화하고 성숙할 것임
      처음부터 완벽할 수는 없었음
      하지만 에이전트형 도구 API의 표준화는 표준의 구체적 모양과 무관하게 엄청나게 강력함
      코드를 작성해 배포하면 AI가 곧바로 사용법을 알게 됨. 직접 경험해야 체감되는 부분임
    • 바로 그게 두려움임
      너무 빠르게 움직이다가 MCP가 몇 년, 몇십 년 동안 떼어내기 어려운 전송 프로토콜을 받아들이게 될 수 있음
      90년대 브라우저 전쟁이 떠오름. 모두가 가장 빨리 달리려다 표준과 브라우저가 갈라졌고, 20년 넘게 제대로 정리되지 않았음. IE11도 너무 오래 남아 있었음
    • 그렇다면 개발자들과 이야기해서 MCP 찬양을 여기저기 도배하지 않게 해야 함
      인내심을 갖고 먼저 작성과 테스트를 끝내야 함

  • HTTP+SSE 모드에서 클라이언트가 읽기용으로 /sse에 SSE 세션을 열고, 첫 읽기에서 쓰기 URL을 받은 뒤, 쓰기는 별도 엔드포인트에 POST하고, 응답은 기존 /sse 연결에서 읽는 구조는 불필요하게 복잡해 보임
    한 엔드포인트에 쓰고 다른 곳에서 응답을 읽는 건 매우 이상함
    대안으로 클라이언트가 채팅 시작 시 세션 ID를 생성하고, 그 ID를 쿼리 문자열이나 헤더로 넘기며 HTTP 호출을 하면 됨. 그러면 202만 보내는 대신 응답을 정상적으로 돌려주면 됨
    여기서 SSE가 주는 이점이 무엇인지 모르겠음. 세션 시작과 종료는 클라이언트가 ID를 만들어 결정하고, 서버는 내부적으로 그 세션을 유지하면 됨

    • 응답이 HTTP 요청/응답 주기 안에서 만들어지는 게 아니라 비동기로 생성되어 나중에 SSE로 전달됨
      하지만 HTTP 요청+SSE로 WebSocket을 흉내 내는 건 확실히 찜찜함
    • WebSocket이 주는 이점은 무엇인가?
      그것도 똑같이 한 엔드포인트로 보내고 다른 핸들러에서 응답을 들어야 함
답변달기