MCP 책임 과부하
흔한 비판 중 하나는 MCP가 너무 많은 책임을 맡고 있다는 것입니다. 저자는 MCP가 LLM이 외부 리소스에 액세스하고 상호 작용하기 위한 관문 역할만 해야 한다고 주장합니다. 이를 단순한 ‘문’ 또는 ‘다리’로 보는 것이 목적과 한계를 명확히 하는 데 도움이 됩니다.
우발적인 데이터 노출, 프롬프트 주입 취약성 및 비용 통제 결함과 같은 문제를 MCP에 직접적으로 돌리는 것은 책임을 잘못 묻는 것입니다. 이러한 문제는 개발자가 통제하는 범위 내에서 해결해야 합니다. 개발자는 프로토콜에 관계없이 속도 제한을 구현하고 사용량을 모니터링해야 합니다. 이를 과속에 대해 도로를 탓하는 것에 비유하는 것이 적절합니다. 인프라는 개인의 행동에 책임이 없습니다.
궁극적으로 제기된 많은 우려는 AI 에이전트에 작업을 위임하는 것과 관련된 더 광범위한 문제입니다. 개발자는 API 자체에 모든 것을 처리하도록 기대하기보다는 특정 애플리케이션 내에서 이러한 문제를 관리할 책임을 져야 합니다.
LLM과 프롬프트 주입의 양날의 검
MCP에 대한 최근 논의는 종종 날카로운 칼의 내재된 위험에 대한 경고와 유사합니다. 부주의하게 다루면 베일 수 있습니다. 프롬프트 주입은 중요한 문제이며 LLM 자체의 특성으로 인한 결과입니다. 프롬프트 주입 위험을 제거하려는 시도는 LLM을 가치 있게 만드는 기능을 저하시킬 수 있습니다.
기존 시스템에서 흔히 볼 수 있는 ‘제어 대 데이터’ 분리 개념은 LLM에는 자연스럽게 존재하지 않습니다. LLM은 이러한 엄격한 분리가 없기 때문에 강력함과 일반성을 얻습니다. 이러한 내재적 특성으로 인해 프롬프트 주입 공격에 취약합니다.
원격 MCP 서비스가 위험을 초래할 수 있지만, 잘못은 프로토콜 자체가 아니라 신뢰할 수 없는 제3자에게 중요한 작업을 맡기는 데 있습니다. 이 비유는 칼을 불안정한 룸바에 덕트 테이프로 붙이는 아이디어로 확장됩니다. 문제는 칼 자체가 아니라 예측할 수 없는 장치에 칼을 부착하기로 한 결정입니다.
‘조심하라’는 훈계나 보호 장비에 대한 제안은 기술적으로 정확하지만 핵심 문제를 놓치고 있습니다. 날카로운 도구를 통제되지 않은 시스템과 결합하는 잘못된 결정입니다.
확장성 문제
보안 문제 외에도 MCP는 기본적인 확장성 한계에 직면해 있습니다. 저자는 LLM 신뢰성과 제공되는 교육적 컨텍스트 양 사이의 부정적인 상관관계를 강조합니다. 이는 더 많은 데이터와 통합을 추가하면 문제가 자동으로 해결될 것이라는 일반적인 믿음에 도전합니다. 도구 및 통합 수가 증가함에 따라 에이전트의 성능이 저하될 수 있으며 동시에 각 요청의 비용이 증가합니다.
저자는 MCP가 특정 임계값을 초과하여 확장되지 않는다고 강조합니다. 에이전트 컨텍스트에 무제한의 도구를 추가하려고 시도하면 필연적으로 해당 기능에 부정적인 영향을 미칩니다. 이러한 제한은 MCP 개념에 내재되어 있으며 인증 문제보다 더 많은 주의가 필요합니다.
사용자는 더 많은 MCP 서버를 활성화함에 따라 결국 성능 저하를 경험하여 서버 간에 간섭이 발생할 수 있습니다. 이는 비간섭이 기본 속성인 일반적인 패키지 관리 시스템과 극명한 대조를 이룹니다.
MCP의 핵심 문제는 실제 동작이 사용자 기대와 다르다는 것입니다. MCP는 결과 없이 무제한의 도구를 원활하게 통합하는 플러그 앤 플레이 솔루션이 아니라는 점을 인식하는 것이 중요합니다.
UI 및 도구 관리로 한계 해결
MCP의 한계를 해결하기 위해 제안된 한 가지 해결책은 사용자 인터페이스를 개선하는 것입니다. 도구가 의도치 않게 실행된 경우 UI는 도구를 비활성화하거나 의도된 사용법을 명확히 하기 위해 설명을 수정하는 쉬운 방법을 제공해야 합니다.
저자는 또한 컨텍스트 성장이 종종 성능 향상과 실제 사용 능력으로 이어진다고 언급하며 엄격하게 부정적인 상관관계라는 개념과 모순됩니다. 그러나 특정 사용 사례 또는 잘못 설계된 컨텍스트에서는 성능 저하가 발생할 수 있음을 인정합니다.
도구의 압도적인 선택을 해결하기 위해 ‘분할 정복’ 접근 방식이 제안됩니다. 여기에는 특정 작업에 가장 적합한 도구를 선택하도록 특별히 설계된 도구를 추가하는 것이 포함됩니다. 이 ‘도구 선택 도구’는 사용 가능한 도구의 하위 집합을 ‘상위’ 에이전트로 반환하는 작업을 수행하는 또 다른 LLM 호출일 수 있습니다. 이 계층화된 접근 방식은 복잡성을 관리하기 위해 추가 수준의 간접성을 추가합니다.
그러나 컨텍스트에 도구를 가지고 있는 것만으로도 모델의 출력을 크게 변경할 수 있습니다. 컨텍스트와 관련된 도구(Retrieval-Augmented Generation 또는 RAG와 같은 기술을 통해 달성)는 유익하지만 ‘get_tools’ 요청 뒤에 모든 도구를 숨기는 것은 해로울 수 있습니다.
전송 및 권한 부여 계층으로서의 MCP
MCP는 주로 도구 수준 권한 부여에 초점을 맞춘 요청/응답 수명 주기를 갖는 전송 및 와이어 형식으로 작동합니다. 에세이는 MCP의 가장 큰 문제는 AI 에이전트가 도구를 기능적으로 구성할 수 있도록 지원하지 못한다는 것이라고 주장합니다.
저자는 LLM이 이미 OpenAPI 사양을 사용하여 문서화된 API와 상호 작용할 수 있는 기능을 갖추고 있기 때문에 MCP가 처음부터 불필요할 수 있다고 가정합니다. 누락된 요소는 권한 부여입니다. AI가 액세스할 수 있는 API를 제어하는 기능입니다. 저자는 MCP 대신 AI가 특정 엔드포인트에 권한 부여를 적용하면서 HTTP 요청을 할 수 있도록 제안합니다. 이 접근 방식은 기존 API를 얇은 MCP 도구로 래핑하는 현재 추세와 일치합니다.
MCP의 특히 짜증나는 측면은 스트리밍 도구 호출 결과에 대한 지원이 부족하다는 것입니다. 단일 요청/응답 쌍은 클라이언트가 페이지 매김을 위해 도구를 반복적으로 호출하도록 강제하여 장기 실행 프로세스를 방해합니다. gRPC를 사용하여 스트리밍 기능을 구현하면 MCP의 효율성을 크게 향상시킬 수 있습니다.
민감한 데이터 노출의 용이성
MCP의 중요한 문제는 민감한 데이터가 쉽게 노출될 수 있다는 것입니다. 또한 MCP는 본질적으로 AI 에이전트의 신뢰성을 높이지 않습니다. 단순히 더 많은 도구에 액세스할 수 있도록 허용하여 특정 상황에서 신뢰성을 역설적으로 감소시킬 수 있습니다.
저자는 MCP가 이러한 모든 문제를 해결하거나 책임져야 한다고 기대하지 않습니다. 오히려 MCP는 이러한 문제에 대한 더 큰 표면적을 만들어 앱 개발자와 사용자가 경계해야 합니다.
비유와 도시 계획
저자는 도시 계획의 비유를 사용하여 문제를 설명합니다. MCP를 시속 25마일의 제한 속도가 있는 6차선 도시 도로에 비유하는 것은 설계와 의도된 용도 간의 단절을 강조합니다. 단순히 벌금을 부과하거나 피상적인 ‘수정’을 추가하는 것은 근본적인 설계 문제를 해결하지 못합니다.
효과적인 도시 계획에는 속도 제한 준수를 자연스럽게 장려하는 도로를 설계하는 것이 포함됩니다. 마찬가지로 MCP는 외부 제어에만 의존하기보다는 잠재적 위험을 본질적으로 완화하도록 설계되어야 합니다.
LLM이 원치 않는 작업을 수행함
이 기사는 LLM이 서비스에서 작업을 실행하도록 허용하는 프로토콜에 대한 더 광범위한 비판으로 전환됩니다. 저자는 핵심 문제를 식별합니다. LLM이 사용자가 수행하기를 원하지 않는 작업을 수행할 수 있습니다. LLM이 독립적으로 수행할 수 있는 작업과 사용자 프롬프트가 필요한 작업을 구별합니다.
궁극적인 목표는 LLM이 전체 비즈니스를 관리하도록 하는 것이지만 기술은 아직 그러한 자율성을 가질 준비가 되지 않았습니다. 현재 사용자는 AI가 사전 검토 없이 이메일을 보내는 것을 원하지 않을 수도 있습니다.
저자는 사용자에게 확인을 요청하는 해결책을 거부하고, 대부분의 도구가 무해해 보일 때 사용자가 자동 확인 패턴(“YOLO 모드”)에 빠질 위험을 인용합니다. 이는 사람들이 현금보다 카드로 더 많이 쓰는 심리적 현상과 유사합니다. 기술이 아닌 인간 행동에 뿌리를 둔 문제입니다.
근본적인 질문: API를 사용하지 않는 이유는 무엇입니까?
MCP에 대한 논의에서 반복되는 질문은 API를 직접 사용하지 않는 이유입니다.
MCP를 사용하면 사용자가 직접 제어하지 않는 LLM 클라이언트(예: Claude, ChatGPT, Cursor, VSCode)가 API와 상호 작용할 수 있습니다. MCP가 없으면 개발자는 LLM API를 사용하여 사용자 지정 클라이언트를 구축해야 하며, 이는 기존 클라이언트를 구독과 함께 사용하고 특정 도구를 사용하는 방법을 가르치는 것보다 훨씬 비용이 많이 드는 작업입니다.
한 개발자는 USB를 통해 FM 하드웨어 신디사이저에 연결하기 위해 MCP 서버를 구축하여 AI 기반 사운드 디자인을 가능하게 한 경험을 공유합니다.
LLM 클라이언트 통합 및 표준화
핵심 문제는 ChatGPT 사용자 지정 GPT 작업이 주목할 만한 예외로 모든 LLM 클라이언트가 기본적으로 직접 API 상호 작용을 지원하지 않는다는 것입니다. Anthropic, Google 및 OpenAI는 Claude, ChatGPT 및 Cursor와 같은 LLM 기반 클라이언트에 대한 프로세스를 간소화하기 위해 MCP를 공유 프로토콜로 채택하기로 합의했습니다.
MCP는 LLM 클라이언트를 구축하는 사람들을 위해 프로세스를 단순화합니다. LLM이 API와 상호 작용하기를 원하는 경우 API 키를 제공하고 작동할 것으로 기대할 수는 없습니다. 에이전트를 만들어야 합니다.
MCP는 API를 문서화하고 호출 방법을 설명하는 방법과 해당 문서를 노출하고 호출을 용이하게 하는 표준화된 도구로 볼 수 있습니다. 불필요한 복잡성 없이 API를 래핑할 수 있을 만큼 충분한 추상화를 제공하지만 이러한 단순성으로 인해 사용자가 “자신의 발을 쏠” 수도 있습니다.
MCP의 효율성 및 재사용성
MCP가 없으면 개발자는 도구를 호출할 때마다 LLM에 도구 사용 방법을 반복해서 설명해야 합니다. 정보가 잊혀지거나 비표준 API 동작으로 인해 LLM이 도구를 올바르게 사용하지 못할 위험이 있습니다.
이러한 지속적인 설명 및 복제는 컨텍스트에서 토큰을 낭비하여 비용과 시간을 늘립니다. MCP는 필요한 모든 정보를 묶어 도구 사용을 보다 효율적으로 만들고 도구 공유를 용이하게 하여 이 프로세스를 간소화합니다.
LLM 제공업체에 API 문서와 함께 “여기에 사용할 수 있는 도구가 있습니다”라고 말함으로써 사용자는 반복적인 알림 없이 여러 채팅에서 해당 도구를 재사용할 수 있습니다. 또한 데스크톱 LLM 클라이언트가 로컬에서 실행되는 프로그램에 연결하여 OS 특정 실행 프로세스 문제를 해결할 수 있습니다.
MCP 및 로컬 리소스 액세스
MCP는 LLM에 대한 파일, 환경 변수 및 네트워크 액세스와 같은 로컬 리소스에 대한 액세스를 용이하게 합니다. 로컬에서 실행되도록 설계되어 LLM에 이러한 리소스에 대한 제어된 액세스 권한을 부여합니다.
표준 LLM 도구 호출 ‘모양’은 MCP 도구 호출 ‘모양’을 밀접하게 반영하여 도구를 에이전트에 연결하기 위한 간단한 표준이 됩니다.
MCP는 AI 모델에 노출된 함수 호출 스키마와 기본 API 간의 다리 역할을 합니다. 함수 호출을 도구로 변환하여 원활한 통신을 가능하게 합니다.
도구 제공업체인 경우 MCP는 AI 에이전트 프런트 엔드가 도구에 연결하기 위한 표준화된 프로토콜을 제공합니다. 이는 표준 프로토콜이 HTTP 및 OpenAPI일 수 없는 이유에 대한 질문에 답합니다.
MCP는 엔드포인트와 해당 운영 세부 정보를 사양에 통합하는 메타 API로, LLM이 보다 효과적으로 상호 작용할 수 있도록 합니다.
특정 시나리오의 MCP
MCP는 사용자가 질문을 하거나 어떤 API를 사용해야 할지 모를 때 문제를 해결할 수 있습니다. 또한 이전 메시지를 기반으로 요청을 처리할 수 있습니다.
한 사용자는 사용자의 “X”를 검색하여 엔드포인트로 보내고 싶었던 경험을 공유합니다. 그들은 MCP가 너무 간단한 작업에 비해 과도하다고 생각했으며 이는 기본 API 상호 작용에 항상 필요한 것은 아님을 나타냅니다.
MCP는 특히 에이전트 경험을 위해 설계된 네트워크를 통해 통신할 수 있는 소프트웨어를 구축하기 위한 FastAPI 웹 앱 프레임워크에 비유됩니다. AI 에이전트 개발을 위한 표준화된 프레임워크를 제공하여 “Rails-for-Skynet”으로 볼 수 있습니다.
공급자 제어에 대한 우려
MCP가 시스템에 대한 공급자 측 제어를 늘리기 위해 추진되고 있다는 우려가 있습니다. LLM 공급자는 결국 Google이 Gmail에서 IMAP/SMTP를 사용하기 어렵게 만든 것과 유사하게 API 액세스를 제한할 수 있습니다.
OpenAPI를 사용하면 에이전트가 /openapi.json에서 API 사양을 검색할 수 있습니다.
MCP는 빠른 상호 작용을 가능하게 하여 사용자가 입력 데이터를 준비하고 API로 보내고 출력을 구문 분석하고 각 메시지에 대해 프로세스를 반복하는 데 시간을 보내는 대신 몇 초 만에 작업을 완료할 수 있습니다.
샌드박싱 및 보안 위험
가장 큰 문제 중 하나는 하나의 MCP 서버 도구의 출력이 동일한 메시지 스레드의 다른 도구에 미치는 영향입니다. 이렇게 하면 의도치 않은 결과를 방지하기 위해 도구 간에 샌드박싱이 필요합니다. Invariant Labs는 도구 설명으로 이를 해결했고 다른 사람들은 MCP 리소스 첨부 파일을 사용했습니다. 샌드박싱 부족은 프롬프트 주입 위험을 악화시킵니다.
이는 SQL 주입에 비유됩니다. 취약점이 최소한의 관찰 가능성으로 어느 시점에서든 악용될 수 있는 시스템이 함께 짜여져 있습니다.
모델이 프롬프트의 신뢰할 수 있는 부분과 사용자 손상된 입력을 구별할 수 없으므로 프롬프트 인터페이스도 SQL 주입의 형태에 취약합니다. 이를 해결하려면 인코딩, 디코딩 및 모델 학습에 대한 근본적인 변경이 필요합니다.
이렇게 하면 프롬프트 주입과 도구 주입이 모두 가능하여 신뢰할 수 없는 코드가 실행될 수 있습니다.
컨테이너화 및 제어된 액세스
한 개발자는 프로젝트 코드가 마운트된 Docker 컨테이너를 시작하는 MCP 서버를 만들었습니다. 이 접근 방식을 사용하면 LLM이 샌드박스 환경 내에서 전체 Unix 도구 세트 및 프로젝트 특정 도구에 액세스할 수 있습니다.
채팅 기반 인터페이스를 통해 구동되는 이 에이전트 워크플로는 기존 방법보다 더 효과적인 것으로 입증되었습니다.
핵심은 MCP 에이전트에 필요한 것 이상으로 액세스 권한을 부여하는 것입니다. 컨테이너화 및 투명한 도구 UX는 보안 위험을 완화하는 데 매우 중요합니다.
가상 머신 및 인터넷 액세스
에이전트에 최소한의 Linux 설치(VM 또는 컨테이너로)가 있는 컴퓨터를 제공하면 인터넷에서 정보를 가져올 수 있어 더 나은 결과를 얻을 수 있습니다. 그러나 이는 악성 지침 및 데이터 유출과 관련된 보안 문제를 야기합니다.
신뢰할 수 있는 웹사이트에 대한 액세스를 제한하면 일부 위험을 완화할 수 있지만 신뢰할 수 있는 소스도 악성 콘텐츠를 호스팅할 수 있습니다. 악성 지침을 접할 가능성과 생산성 이점 간의 절충안을 신중하게 고려해야 합니다.
직원과 AI 에이전트 간의 차이는 중요합니다. 직원은 법률 및 계약의 적용을 받는 법적 개인으로 책임감을 제공합니다. AI 에이전트에는 이러한 법적 프레임워크가 없으므로 신뢰가 더 어려워집니다.
MCP 개발의 초기 단계
MCP는 2024년 11월에 발표되었으며 RFC는 활발하게 진화하고 있습니다.
일부 사람들은 MCP를 포함한 전체 AI 개인 비서 개념이 근본적으로 결함이 있다고 생각합니다.
1990년대 후반과 2000년대 초반의 AI 비서에 대한 초기 추진은 수직적 통합 및 대량 구매력을 갖춘 콘텐츠 애그리게이터가 더 효과적인 것으로 입증되었기 때문에 실패했습니다. 이는 Expedia 및 eBay와 같은 플랫폼의 부상으로 이어졌습니다.
다중 에이전트 시스템은 프로그래머가 에이전트의 상태에 영향을 미치도록 요구하며 이는 어려운 프로그래밍 작업입니다.
무료 가치의 한계
“주차 가능성으로 결과를 순위 매기기”에 대한 욕구는 유료 API 또는 광고 지원 프런트 엔드 뒤에 있는 데이터에 액세스하는 문제를 강조합니다. 기업은 API를 통해 전체 데이터 세트에 대한 액세스를 자유롭게 제공할 가능성이 낮습니다.
모든 회사가 데이터를 AI 에이전트에 통합하는 것은 아니지만 다양한 도구를 결합하여 워크플로를 강화할 수 있는 잠재력은 여전히 큽니다.
데이터 해자를 유지하는 것을 우선시하는 회사는 해당 해자를 위협하는 새로운 기술에 저항할 가능성이 높습니다.
booking.com에 API가 있는 경우 웹사이트와 동일한 결과를 반환할 가능성이 높으며 JSON 또는 XML 형식이 될 수 있습니다.
중개자 우회
booking.com과 같은 중개자가 사용자가 서비스를 완전히 우회하도록 허용하는 것은 의미가 없습니다.
그러나 개별 호텔은 종종 싫어하는 중개인인 booking.com을 우회하는 것이 유리하다고 생각할 수 있습니다.
Deep Research AI는 특정 기준에 따라 호텔을 검색하고 개별 호텔에서 운영하는 호텔 검색 MCP 서버와 상호 작용하여 booking.com의 인터페이스 및 광고를 탐색할 필요가 없습니다.
실제 사용 사례
MCP는 Elasticsearch에서 로그를 가져오거나 데이터베이스를 보다 구조화된 방식으로 쿼리하는 것과 같은 작업을 용이하게 할 수 있습니다.
새 서버를 사용하려면 .json 파일을 편집하고 앱을 다시 시작해야 하는 MCP 서버 구성의 정적 특성은 제한적일 수 있습니다.
미세 조정된 모델
MCP는 수많은 MCP 도구를 이해하고 각 대화에 적합한 도구를 선택하는 작은 미세 조정된 모델로 볼 수 있습니다.
특정 시나리오에서는 컨텍스트에 따라 도구를 동적으로 조정해야 할 수 있습니다.
개방형 대화 및 비즈니스 문제
MCP는 미리 정의된 흐름이 없는 일반적인 개방형 대화 시스템에 적합합니다. 그러나 모든 비즈니스 문제에 대한 만병통치약은 아닙니다. LangChain과 같은 프레임워크를 대체하기 위한 것이 아닙니다.
MCP의 대안인 개방형 커뮤니티 주도 표준은 분열되고 독점적이며 공급업체에 종속된 프로토콜입니다. 결함이 있지만 진화하는 표준은 전혀 없는 표준보다 낫습니다.
MCP를 보는 가장 좋은 방법은 API 주변에 클라이언트 래퍼를 구축하는 개별 개발자에서 API 제공업체 또는 커뮤니티 유지 관리 래퍼를 구축하는 것으로 전환하는 것입니다. 이는 NPM 또는 PyPi와 유사한 큰 도구 상자를 제공합니다. 그러나 오케스트레이션, 보안 및 사용법 정의는 여전히 필요합니다.
차세대 Langchain은 이 더 큰 도구 상자로부터 혜택을 받겠지만 여전히 혁신이 필요합니다.
사용자별 도구
어떤 경우에는 도구가 업로드된 CSV 파일을 슬라이스하고 조작하기 위한 도구와 같이 사용자 데이터에 따라 다를 수 있습니다.
종종 간과되는 한 가지 문제는 MCP가 모델 컨텍스트를 너무 많은 옵션으로 채울 수 있다는 것입니다. 낭비적인 토큰 사용과 불규칙한 모델 동작을 피하려면 우선 순위 지정 및 메타데이터 노출이 중요합니다.
표준 및 진화하는 기술
새로운 표준은 시간이 지남에 따라 나타나며 표준이 실제로 중요한 이후로 너무 오래되어 사람들은 표준이 어떻게 개발되는지 잊었습니다.
임의 개발자로부터 작은 서버 프로그램을 다운로드하여 LLM 클라이언트에 “도구”를 추가하는 것은 위험할 수 있습니다.
제기된 문제는 MCP 생태계가 해결해야 할 정당한 문제입니다. 일부 솔루션은 MCP 사양 내에 있고 다른 솔루션은 외부에 있습니다.
Claude 코드 및 실제 사용
MCP의 성공에 대한 상반된 의견이 있습니다. 일부는 MCP와 통합하는 회사에 대한 이야기를 들었고 다른 일부는 실망한 사용자로부터 이야기를 들었습니다.
이는 과대 광고 및 조기 채택의 단점을 강조합니다.
일부 개발자는 대부분의 사용 사례에서 HTTP API가 MCP보다 우수하다고 생각합니다. 그들은 “도구” 사용이 기능 및 기능에 대한 API 엔드포인트로 귀결된다고 주장합니다.
API는 기본적으로 자체 설명이 아니며 REST 및 HATEOAS 지지자가 접근 방식을 선보일 수 있는 기회를 놓쳤습니다.
LangChain 대안으로서의 MCP?
MCP는 “LangChain 냄새”가 나는 것으로 묘사되었습니다. 긴급한 문제를 해결하지 못하고 지나치게 추상적이며 장점을 설명하는 데 어려움이 있습니다.
아마도 “END OF LINE”이라고 말하고 해킹하려는 사람들을 게임 그리드로 추방해야 할 것입니다!
핵심 질문은 “일반” 챗봇 패러다임이 지속될 것인지입니다. 자체 도구가 있는 특수 앱은 MCP가 필요하지 않을 수 있습니다.
반대로 LLM이 더욱 강력해짐에 따라 외부 도구는 덜 필요할 수 있습니다. LLM이 이미 이미지를 직접 편집할 수 있는데 왜 Photoshop을 구동하기 위해 MCP를 원하겠습니까?
공상 과학 로봇 비서 꿈이 실현되지 않을 수 있으며 특수 언어 조작 도구가 더 유용할 수 있습니다.
사용자 기반 및 보안 인식
MCP의 사용자 기반에는 기술에 익숙하지 않은 개인도 포함되므로 보안 문제가 특히 중요합니다. 보안 모범 사례에 대한 인식을 높이는 것이 중요합니다.
결과 스키마를 정의해야 하는 OpenRPC를 기반으로 Xops를 사용하면 출력이 입력에 연결되는 방식을 계획하는 데 도움이 되어 복잡한 워크플로의 신뢰성이 향상됩니다.
이 기술은 시간이 지남에 따라 진화하고 정착될 가능성이 높습니다.
중복성 및 클라우드 인프라
일부는 MCP를 사용하는 것이 OpenAPI 표준에 비해 얻는 이점에 대해 의문을 제기하며 이를 중복으로 간주합니다.
LLM은 OpenAPI 시스템을 호출하는 데 무엇을 사용합니까? 셸에 어떻게 바인딩됩니까? LLM의 호스트는 어떻게 오케스트레이션합니까?
MCP는 LLM이 도구 호출을 수행할 수 있는 구조화된 방법을 제공합니다.
MCP 서버는 이미 HTTP 서버입니다.
MCP의 가장 큰 장점은 애플리케이션 개발자가 아닌 OpenAI와 같은 LLM 제공업체를 위한 것입니다.
LLM은 도구가 없는 두뇌이며 도구 호출은 LLM에 권한을 부여합니다. 그러나 일반 API를 사용하면 LLM 제공업체가 해당 도구에 액세스할 수 없습니다. MCP는 LLM에 액세스 권한을 부여하여 AI의 관문으로 자리매김합니다.
CLI 대 API
LLM이 자연어에 대해 훈련되고 CLI가 일반적인 사람이 읽고 쓸 수 있는 솔루션인 점을 감안할 때 CLI를 직접 사용하지 않는 이유는 무엇입니까?
MCP는 너무 빨리 등장하여 성숙할 시간이 필요합니다. 기존 표준 기관의 검토가 부족하고 과대 광고에 의해 주도됩니다.
실제 응용 프로그램이 부족합니다.
MCP의 주요 응용 프로그램
MCP는 Claude Desktop 및 틈새 AI 채팅 앱, 코드 자동화 도구 및 에이전트/LLM 자동화 프레임워크에서 사용됩니다.
다음 과대 광고 가능한 약어가 도착하면 폐기될 가능성이 높은 또 다른 서두른 기술입니다.
두 가지 종류의 언어 모델 도구 호출 프로토콜이 있습니다. 사람들이 불평하는 프로토콜과 아무도 사용하지 않는 프로토콜입니다.
Anthropic은 보안 문제로 이어지는 진공 상태에서 이 “표준”을 개발했습니다.
JSON-RPC 2.0
MCP는 JSON을 사용하여 클라이언트와 서버 간 통신을 가능하게 하는 경량 프로토콜인 JSON-RPC 2.0을 기반으로 구축되었습니다.
보편성을 얻지 못하고 보편성을 주장하면서 특정 생태계를 위해 설계된 중앙 집중식 사양처럼 느껴집니다.
MCP는 유용한 작업을 수행할 수 있을 만큼 강력하여 보안 문제가 발생합니다.
성숙한 표준이 아니며 안전하게 설계되지 않았습니다.
권장 사항은 존재하지만 시행되거나 구현되지 않습니다.
Langchain 및 도구 호출
Langchain은 “도구 호출” 패턴을 구현하는 많은 프레임워크 중 하나입니다.
MCP는 도구 호출, 템플릿 입력, 취소, 진행 상황 추적 및 도구 서버의 상태 유지를 포함하여 외부 정보가 언어 모델의 컨텍스트 창에 들어가는 방식에 대한 사양입니다.
모든 어시스턴트/통합 콤보가 호환되도록 세부 사항을 표준화하는 데 도움이 됩니다.
MCP에 정당한 문제가 있지만 비평가들은 논거를 개선해야 합니다.
인증은 중요하며 초기 버전에서 생략되어서는 안 됩니다.
너무 많은 복잡성이 있습니다.