MCP를 비판적으로 살펴보기

• 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의 단순함을 우선시하는 것이 산업 성장에 중요함