MCP를 비판적으로 살펴보기
(raz.sh)- MCP(Model Context Protocol) 는 LLM이 외부 세계와 상호작용하도록 표준화된 연동 방식을 제공함
- 최근 IBM의 ACP와 Google의 A2A 등 유사한 표준들이 등장하며, MCP 구현 및 관련 도구들이 빠르게 늘어남
- 그러나 설계상 혼란, 문서 미흡, 실제 프로토콜 명세 부족 등 성숙하지 못한 엔지니어링 관행이 문제점으로 지적됨
- HTTP+SSE 및 Streamable HTTP 같은 현재 제안된 전송 방식은 복잡성과 보안 이슈를 증가시키며, WebSocket 사용이 대안으로 권장됨
- 최신 프로토콜은 인가 및 세션 관리에서 비일관적이고 과도한 복잡성을 추가하고 있음
MCP와 최근 동향 검토
- MCP는 애플리케이션이 대형 언어 모델(LLM) 에 문맥을 제공하는 방법을 표준화하기 위해 만든 공개 프로토콜임
- 최근 한 달, MCP가 LLM을 에이전트로 만드는 핵심 표준으로 부상하며 급속히 활용 및 구현이 확산 중임
- IBM의 ACP나 Google의 A2A 등과 같이, 비슷한 목적을 가진 오소독스한 표준들이 빠르게 등장함
엔지니어링 관행과 프로토콜 명세 문제점
- 실제 구현 및 문서화 수준이 낮음이 여러 곳에서 드러남
- 대형 기술 기업들은 모델 훈련에는 막대한 투자를 하면서, SDK나 문서는 수준이 낮아 사용자의 혼란을 초래함
- MCP 역시 비슷한 문제를 보이며, 일부 설계가 불합리하고 명세나 예제, 가이드라인이 부족한 상태임
전송 프로토콜(Transport) 논의
stdio 전송 방식
-
Stdio는 MCP 서버와 클라이언트를 로컬에서 파이프(
stdout,stdin)로 직접 연결하는 전통적 방식임 - 복잡한 소켓 처리나 OS별 이슈가 적고, 환경변수, 입출력 스트림 등 간결한 환경 구성이 가능함
HTTP+SSE / Streamable HTTP 방식
- 웹 시대에 맞추어 HTTP 기반에도 대응하겠다는 의도 아래, HTTP+SSE와 Streamable HTTP 방식이 채택됨
- 그러나 이 방식은 WebSocket 대체를 목표로 하면서 오히려 더 많은 모호함, 설계 상의 혼란, 복잡성을 유발함
- 하나의 세션과 연결이 여러 방식으로 생성·종료될 수 있어, 서버의 상태 관리와 보안 측면에 크게 부담이 됨
MCP 서버/클라이언트 구현 사례에서의 어려움
- 공식 Go SDK 부재 등 여러 언어에서 지원 미흡 문제가 두드러짐
- 문서와 명세가 불명확하여 실제로 역공학을 통해 구현해야 하는 경우가 많음
- 예시 서버가 대부분 Python, JavaScript 기반임에도, 의존성 및 이식성 이슈로 현업 환경 적용이 힘듦
- 서버 구현 시 SSE/Streamable HTTP가 소켓을 가장하려 하나, 실제로는 세션과 연결 상태를 일관되게 유지하기 어렵고, 메시지 큐 등 별도 인프라 필요임
HTTP+SSE 및 Streamable HTTP의 구조와 문제점
HTTP+SSE 모드
- 클라이언트는 서버와 SSE 세션을 열고, 별도의 엔드포인트로 쓰기 요청을 하면, 서버가 202 응답을 반환하고 기존 SSE 연결을 통해 응답 전송함
- 세션 연결 및 상태 동기 유지 등이 필요하나, 이 과정이 문서화도 미흡하고 운용 복잡성이 매우 높음
Streamable HTTP 모드
- 세션 생성·SSE 오픈·응답 전달 모두 여러 방식이 혼용되어 하나의 요청~응답 흐름이 일관되지 않음
- 복수의 상태 관리, 다양한 엔드포인트 및 헤더 방식이 혼재하여 실질적 구현과 확장성에 심각한 장애 요인 발생
일반적 함의
- 기술 복잡성 증가와 함께, 개발자 인지 부하·유지보수가 커지고, 다양한 서버·클라이언트 구현 가운데 호환성 불일치, 예측 불가한 동작 문제가 대두됨
- 서버는 모든 상태와 연결 상황을 트래킹해야 하고, 분산 환경에서는 효율적 확장 및 상태 동기화가 더욱 어려움
보안적 함의
- 미시적이고 다양한 연결/세션 방식은 세션 하이재킹, 재생 공격, 서비스 거부(DoS) 와 같은 상태 관리 보안 취약성을 높임
- 여러 진입점과 응답 방식이 공격 표면을 확대하고, 의도치 않은 흐름으로 악의적 활동을 은폐 가능하게 함
권한 관리(Authorization) 프로토콜의 혼란
- 현재 명세는 HTTP 전송일 때만 OAuth2 등 강제, STDIO 전송일 때는 임의로 환경변수 사용 등 비일관적 규칙을 적용함
- 왜 HTTP 전송만 복잡한 OAuth2 구현을 강요하는지 등 혼란/부조리가 있음
개선 방안 제언
- 하나의 JSON RPC 프로토콜에, 전송 방식은 실질적으로 Stdio와 WebSocket만을 중심으로 단순화 필요함
- Stdio 환경의 변수는 HTTP 환경의 헤더로, 입력·출력은 각각 WebSocket의 양방향 스트림으로 매핑하는 방식이 바람직함
- 불필요한 세션 추적, 상태 관리, 수많은 예외 처리를 배제할 수 있음
- WebSocket이 모든 HTTP 기반 전송의 표준 선택지가 되어야 하며, 복잡한 상태 동기화 이슈도 해결할 수 있음
대안 프로토콜과 비교, 시장 동향
- IBM의 ACP 및 Google의 A2A는 에이전트 상호연동 측면에서 더 간결한 Transport 설계, 에이전트 탐색 기능을 제공함
- 하지만 본질적으로는 대부분 MCP 구축 환경 내에서 별도 도구로 통합될 수 있는 수준임
- 새로운 프로토콜이 계속 등장하는 현상은 표준 난립으로 이어질 리스크가 있으므로, Transport의 단순함을 우선시하는 것이 산업 성장에 중요함
Hacker News 의견
- LLM 벤더들이 작성한 문서들이 혼란스러운 이유는 바로 LLM을 활용해서 문서를 작성하고 있기 때문임을 확신함, 이는 매우 좋지 않은 접근임, 특히 사양(specification) 작업에서 LLM을 사용하는 것은 좋은 문서 작성에 LLM을 사용하는 것보다 훨씬 더 나쁜 방식임, 사양을 쓰는 과정 자체가 핵심이며 인간 디자이너들이 사려 깊게 결함과 미비점을 찾아내고 케이스를 다루는 게 중요한데 MCP 사양에서는 그런 인간적인 고심의 흔적이 부족함을 봄, 특유의 밋밋한 스타일과 산만함 그리고 목록 위주의 구성이 딱 LLM이 쓴 결과물임
- DeepSeek의 문서는 오히려 맞춤법과 문법 오류가 아주 많은 점이 문제임, 이런 회사는 온종일 언어를 다루는 기업이고 한때 세계 최고의 영어 LLM까지 가졌었음에도, 직업적으로 보일 만큼의 프로페셔널한 문서를 생산하지 못하는 게 정말 이상함
- 나 역시 이 사양도 LLM이 쓴 결과라고 강하게 느낌, 모든 증거가 그걸 가리킴, 대부분의 제품이 이미 가장 그럴듯한 결과를 평균 내는 방식으로 만들어졌음을 투자자들에게 자랑할 IPO용임을 추측함
- 그게 사실이라면 정말 안타까운 일임, Anthropic에는 똑똑한 인재들도 많음에도 중요 생태계의 핵심 구성요소에서 이런 일이 일어난다는 건 유감스러운 상황임
- AI 코딩 벤더들이 문서를 일부러 이해 못 하게 만드는 동기가 있다는게 이제서야 떠오름, 인간이 이해하지 못하고 오로지 그들의 AI만 해석할 수 있는 코드를 만들어 냄으로써 사용자를 자신들의 특정 AI 서비스에 완전히 의존하게 만들려는 것임, 만약 그들이 2년 안에 진짜 프로그래머를 완전히 대체하지 못한다면 이 전략은 소비자를 모두 사라지게 만들고 자신들의 시장까지 무너뜨리게 될 것임, 결국 인간과 AI 변환 불가의 거대한 코드더미만 남게 됨
- LLM이 쓴 산문을 읽을 때 집중력이 깨지는게 나만의 문제가 아니라, 기계가 올리는 반복적이고 맥락 없는 글이 깊은 생각도 담겨 있지 않고 점점 정서적 피로마저 유발함을 느낌, 이것과 같은 LLM이 기술 사양까지 써낼 때 결국 저자도 이해 못 하는 내용이 무의식적으로 섞여 들어가게 됨, 이런 게 점점 더 걱정임
- DeepSeek의 문서는 대체로 나쁘지 않게 보였음, 빠르게 뚝딱 만들어낸 듯하지만 나쁘지 않은 수준임, 이게 LLM이 문서를 작성하면 전부 나쁘다는 논리에 대한 예외가 있을 수 있음을 의미함
- 요즘 LLM 분야가 소프트웨어 패러다임을 마치 치트키 쓰듯이 빠르게 흉내내고 있음, 원격 함수를 노출하는 방법은 이미 DLL, gRPC, SOAP, IDL, dCOM 등 과거에 많은 예시가 있음에도 현재 LLM 진영에서는 이들의 존재조차 잘 모르는 듯 보임, 시간이 지나면 좀 더 성숙해질 것으로 기대하지만 결국 남은 숙제를 처리해야 함
- 몇 달만 더 지나면 분명 성숙해지겠지만, 초기 파이썬 생태계를 보면 실수들이 아래 스택에 정착되어버리고 모두가 그 위에 새로운 도구를 쌓는 모습을 떠올리게 됨, 이번에는 이미 동일했던 과거 실수의 역사가 있는데도 AI 생태계가 똑같이 나아가는 원인이 더더욱 안타까움
- MCP를 처음 접할 때 COM/DCOM이 떠올랐고, 옛날 DLL Hell이 생각남, 앞으로 MCP도 어떻게 굴러갈지 지켜볼 생각임
- 아직 MCP가 정확히 무엇인지 알 수 있는 설명을 못 찾았고, 과거 개발 언어로 무엇이라 부를 수 있을지 궁금함
- 이런 엄격하고 선언적인 프로토콜에서는 LLM의 잠재적 의미 공간과 의미론적 강점이 빠져버림을 지적하고 싶음, 그냥 agents.json 파일을 웹 루트에 넣고 의미적인 대화를 통해 자동으로 에이전트들이 알아서 해결하는 방식이 더 직관적일 수 있음, 결과적으로 HTTP가 에이전트 표준 입출력이 됨
- 제시한 예시들 모두 적절하다고 생각함
- MPC가 JSON-RPC 기반인지 궁금함
- 글의 전체적인 내용에 동의함, 특히 MCP 사이트에서 실질적인 정보를 찾지 못했던 당황스러웠던 경험을 공유함, RFC는 읽기 힘들지만 "SDK만 사용해라" 보다 훨씬 나음
- 많은 이들이 이 블로그의 중요성을 인식했으면 좋겠음, MCP 도입을 잠시 멈추고 근본적으로 튼튼한 기술 기반이 있는지 다시 봐야 함, 열광이 많지만 실제로 구현 단계로 깊이 들어가면 실망하게 될 것임, 핵심 기능에서 웹소켓 등 다양한 결정이 의문스럽고 전부는 아니지만 일종의 임시방편으로 급하게 만든 느낌임
- 사이트에 분명한 사양이 없어 아쉬움, 사양의 절반은 Sonnet로 뽑아낸 것 같고, 실제 프로토콜 작동 원리가 명확히 기술되어 있지 않음, 그에 비해 GraphQL 사양은 훨씬 잘 쓰여 있음
- 현재 AI 분야 대다수 작업이 수학자, (데이터) 과학자, 학생, 그리고 아마추어 열정가들이 주로 담당하고 있음, 전문 소프트웨어 엔지니어의 기준에선 주말 프로젝트 수준으로 보일 만큼 성숙하지 못한 것이 많음
- 자신은 전문 소프트웨어 엔지니어들이 실제로 다수의 일을 하고 있다고 생각함
- MCP는 처음부터 stateless HTTP로 갔어야 함, 대부분의 서버에서 상태 유지가 필요 없으며, 전역적으로 상태를 보관하거나 세션 식별자만 있으면 충분함
- MCP의 실제 상호작용의 구조를 이해하지 못하겠음, 왜 무상태가 아닌지, 왜 연결을 계속 열어 두어야 하는지 이유를 알고 싶음
- 개인적으로 경험은 적지만, 요청 후 연결을 닫으면 다음 요청을 위해 다시 연결해야 함, 세션을 계속 열지 닫아야 할지는 사용 패턴, 메모리 사용량 등 여러 변수에 달림
- 나는 ninja.ai라는 Ruby on Rails 기반 MCP 서비스를 만들고 있음, 이는 클릭 한 번으로 MCP 서버를 설치하는 앱스토어임, 클라이언트 기기에 Model Context Protocol 서버를 Tauri를 써서 설치함, Rails로 클라우드 MCP 서버도 제공함, HTTP+SSE나 Streamable HTTP 기능에 비판적임, 쌍방향 실시간 통신에는 WebSockets가 더 낫고, Rails의 SSE 지원은 제한적이라 Falcon 웹서버로 엔드포인트를 마이그레이션 하게 됨, Shopify 엔지니어들이 Streamable HTTP를 선택한 배경이 궁금함, 아마도 인프라/배포상의 제약 때문일 수 있음, MCP 전송 계층이 추상화되어 있음도 주목할 필요가 있음, 미래 구현에는 WebSockets나 WebRTC 도입도 충분히 열려 있음
- 나는 MCP 레지스트리 중 하나(glama.ai/mcp/servers) 운영자임, 글쓴이 의견에 부분 동의하지만 프로토콜은 아직 아주 초기 단계라 앞으로 상당히 변화할 수 있음, 예상보다 훨씬 많은 관심을 받아 극초반에 수십대 서버에서 갑자기 수천 대 서버가 늘었지만, 실제 작동하는 서버는 그 중 일부라 계속 거르는 데 많은 시간 씀, MCP가 성숙해지기 전에 대중의 이목을 받아 벌어진 현상임, 그러나 최근에는 코드 프레임워크, 레지스트리, MCP 지원 클라이언트 등 생태계가 놀랍게 빠르게 성장함, 불과 반 년 만에 이런 변화는 유례 없는 일임, 앞으로도 이 추세라면 전망이 밝다고 생각함, 시작하는 이들에게 유용한 자료 모음도 제공함
- 프로토콜 설계 초기에 실수하면 그 실수를 영원히 안고가야 하므로 겸손하게 스펙을 구성해야 함, 한 번 SSE 같은 골드버그식 구조(SSE Rube Goldberg machine)를 고치지 못하고 영구적으로 남을 수 있음, 엔터프라이즈 레벨에선 어떤 파괴적(protokol breaking) 변화도 쉽지 않으므로 변경 없이 초기의 결정에 오래 갇힐 수 있음
- MCP 프로토콜 자체는 뭐, 시간이 지나면서 계속 발전한다는 점은 당연하게 생각함, 초반부터 완성도를 기대하는 게 더 이상함, 무엇보다 에이전틱 API 표준화가 정말 강력한 변화임, 직접 코드 작성하고 배포하면 AI가 곧바로 인식하여 자동 사용 가능해지는 건 직접 경험해 봐야 실감함
- 내 걱정은 이런 속도에서 mcp가 얼마나 오래갈 전송 계층 디자인을 너무 일찍 받아들이지 않을지임, 90년대 브라우저 전쟁처럼 표준 분화가 오랜 시간 해소되지 않는 사례 떠오름, IE11이 너무 오래 남아있던 것처럼
- 권한(Authentication) 관련 논란은 이미 업데이트가 진행됨, Anthropic 및 보안 커뮤니티와 협력해서 MCP에서 리소스 서버(RS)와 권한 서버(AS) 역할 분리를 구현했음, 새 프로토콜 버전이 공식화되기 전까지 임시로 초안 명세를 공개함
- MCP 스펙의 어떤 비율이 LLM 출력인지 궁금함, 경고 신호가 자꾸 떠서 본능적으로 눈치 챈 건지 궁금함
- 나름 중립적 입장이지만 OAuth 초안만 대충 베껴 쓴 것 같고, HTTP를 쓸 때 선택권이 없이 무조건 따라야 하는 구조가 불만임, 사실 클라이언트와 서버 각각이 OAuth2 지원 여부를 선택적으로 갖도록 더 명확하게 정리할 수도 있었을 것임
- MCP의 Streamable HTTP 출시 관련해서 모든 걸 그냥 HTTP 요청으로 만들 수 없을지 이슈를 올린 적 있음, MCP 명세는 LLM과 도구 연결의 범용적 해법으로 유망하지만 실제로는 인증, 스트리밍, 도구별 커스텀 명령, 도구의 신뢰성 검증 등 다양한 어려움에 직면함, 실제로 REST API만으로 통합하는 게 더 간단하다고 봄, OpenAI나 Gemini 등도 MCP를 채택하겠다고 했지만 곧 명세가 원하지 않는 UI, 상호작용 계층 등에서 불일치에 부딪혀서 브랜드와 맞지 않거나 인증이 탈취되는 식의 문제가 발생할 거라 예상함
- Anthropic이 MCP를 구축해도, ChatGPT와 비교하면 규모가 현저히 작음, OpenAI, Google 같은 대기업들이 과연 한 외부팀이 사용자 경험의 한계를 정하는 명세를 오래도록 수용할지 의문임, 예전 ChatGPT Plugins처럼 멋진 엔지니어링보다는 소비자 경험의 한계 때문에 실패한 전례가 있음, 그럼에도 강력한 커뮤니티의 힘에 기대를 걸어볼 의향은 있음
- 블로그를 올린 이후 비슷한 이슈를 직접 남긴 적 있음, 정말 중요한 일인만큼 실수하면 되돌리기 어렵다고 느낌
- MCP가 왜 이렇게 뜨는지 의아하지만, 어쨌든 트렌드임, OpenAPI 사양이랑 비교했을 때 MCP가 어떤 면에서 낫다는 설명을 듣고 싶음
- 내 생각엔 MCP 인기의 대부분은 최근 LLM 도구 사용성이 실제로 좋아진 덕분임, 2023년 OpenAI 플러그인은 당시 LLM이 도구 사용에 충분히 믿을 만하지 않아서 실패했고, MCP는 타이밍이 훨씬 잘 맞았음
- MCP 서버 첫 시작이 아주 쉽고, 진입 장벽이 낮다는 점도 큰 요인임, 도구가 많아지면 LLM에 보내는 텍스트도 많아지는데 OpenAPI 제공 시 개별 경로 상세정보와 설명 메시지를 전달하면 Claude도 훌륭히 연동 가능함
- MCP가 중요한 이유 중 하나는 OpenAPI는 정적 문서라 LLM이 모든 요청 생성 과정을 책임져야 하지만, MCP 서버는 추상화로 그런 부담을 줄여줌, 결과적으로 LLM 입장에서 더 쉽고, 빠르고, 안전함
- 나는 MCP가 완벽하다고 보진 않지만 OpenAPI보다 LLM에 더 적합한 점이 몇 가지 있음, 우선 MCP 툴은 훨씬 짧고 간단히 명세할 수 있고, OpenAPI 명세는 너무 커서 LLM 컨텍스트를 지나치게 차지하게 됨, LLM은 실제로 호출을 만드는 게 아니라 출력 텍스트만 생성하기 때문에 MCP 방식이 더 자연스러움, 그리고 MCP는 도구의 추가/변경 등 동적인 구조에 훨씬 더 유연함, OpenAPI의 정적 한계가 극복됨, 물론 문제도 분명히 있고 특히 전송 계층이 더 개선될 여지가 있음, 대표 라이브러리도 꽤 잘 구현되어 있음