MCP: 통일된 툴 호출 프로토콜의 베일 벗기기
MCP 정의
MCP(Model Context Protocol)는 대규모 언어 모델(LLM)이 외부 툴 및 서비스와 상호 작용하는 방식을 표준화하기 위해 설계된 개방형 기술 프로토콜입니다. AI 세계 내에서 AI 모델이 광범위한 외부 툴과 ‘대화’할 수 있도록 지원하는 범용 번역기라고 생각하면 됩니다. 다양한 애플리케이션 및 서비스에서 제공하는 기능을 LLM이 요청하고 활용할 수 있는 공통 언어와 구조를 제공합니다.
MCP의 필요성
MCP의 등장 이전에는 AI 툴 호출이 두 가지 주요 문제로 인해 어려움을 겪었습니다.
- 인터페이스 파편화: 각 LLM은 고유한 명령 형식을 사용했으며, 각 툴 API는 고유한 데이터 구조를 가졌습니다. 개발자는 모든 조합에 대해 사용자 정의 연결 코드를 작성해야 했으므로 복잡하고 비효율적인 개발 프로세스가 발생했습니다.
- 개발 비효율성: 이러한 ‘일대일 번역’ 방식은 비용이 많이 들고 확장하기 어려웠습니다. 마치 각 외국 고객에 대해 전담 번역가를 고용하는 것과 같아 생산성과 민첩성을 저해했습니다.
MCP는 LLM이 외부 툴과 상호 작용할 수 있는 표준화된 프레임워크를 제공하여 이러한 문제점을 해결하고 개발 프로세스를 간소화하며 더 큰 확장성을 가능하게 합니다.
MCP 기능 이해
MCP의 기술 아키텍처는 MCP 호스트, MCP 클라이언트 및 MCP 서버의 세 가지 핵심 구성 요소로 구성된 시스템으로 개념화할 수 있습니다. 이러한 요소는 시너지 효과를 발휘하여 AI 모델과 외부 세계 간의 원활한 통신을 촉진합니다.
MCP의 역할을 파악하기 위해 현대적인 엔터프라이즈 환경을 고려해 보겠습니다. 이 비유에서:
- 사용자는 사용자 요구 사항을 이해하고 최종 결정을 내리는 최고 경영진을 나타냅니다.
- **(Claude 또는 GPT와 같은) 대규모 언어 모델(LLM)**은 경영진의 지시를 이해하고, 작업 단계를 계획하고, 외부 서비스를 활용할 시기를 결정하고, 정보를 통합하여 답변을 제공합니다.
- 에이전트 시스템은 지시된 대로 작업을 수행하는 개인 비서 또는 비서실 역할을 합니다.
- MCP는 비서가 사용하는 표준화된 통신 플랫폼 또는 엔터프라이즈 서비스 액세스 시스템 역할을 합니다. 결정을 내리는 것이 아니라 지침에 따라 다양한 서비스 제공업체와 통합된 형식 및 프로토콜로 통신합니다.
MCP 이전에는 AI가 외부 툴과 상호 작용하는 것이 혼란스러운 통신 표준 시대와 같았습니다. 비서(에이전트)가 다른 부서나 외부 공급업체에 연락해야 할 때마다 다른 통신 장치나 소프트웨어를 사용해야 했습니다. 이로 인해 다양한 시스템에 대한 숙지가 필요하여 비효율성이 발생했습니다. 개발자는 각 툴에 대해 별도의 연결 코드를 작성해야 했으므로 시간 낭비와 제한된 확장성이 발생했습니다.
MCP는 통합된 통신 플랫폼을 제공하여 이 프로세스를 간소화하여 비서가 동일한 시스템과 통신 프로토콜을 사용하여 모든 부서나 서비스 제공업체에 연락할 수 있도록 합니다. 개발자는 MCP 인터페이스를 한 번만 구현하면 되므로 AI 시스템이 프로토콜을 지원하는 모든 툴과 상호 작용할 수 있습니다.
MCP: 함수 호출을 기반으로 구축된 툴박스
MCP는 기존 함수 호출을 대체하는 것이 아니라 오히려 기능을 향상시키는 보완적인 구성 요소라는 점을 이해하는 것이 중요합니다.
함수 호출은 LLM이 외부 툴 또는 API와 상호 작용하는 핵심 메커니즘입니다. 툴이 필요할 때와 필요한 툴 유형을 식별할 수 있도록 하는 LLM의 기본 기능입니다.
MCP는 다양한 툴을 구성하고 액세스하기 위한 구조화된 프레임워크를 제공하는 툴 분류 시스템 역할을 합니다. 따라서 MCP는 함수 호출을 대체하는 것이 아니라 에이전트와 함께 복잡한 작업을 수행합니다.
완전한 툴 호출 프로세스에는 ‘함수 호출 + 에이전트 + MCP 시스템’의 조합이 포함됩니다.
본질적으로 LLM은 함수 호출을 통해 특정 툴을 호출해야 할 필요성을 표현합니다. 에이전트는 지침에 따라 툴 호출을 실행하고, MCP는 표준화된 툴 호출 사양을 제공합니다.
다음 비유를 고려해 보겠습니다. 상사(사용자)가 커피를 원합니다. 사무실(MCP 호스트)에서 사무실 관리자(LLM)는 비서(에이전트)에게 아메리카노(함수 호출)를 사라고 지시합니다. 비서는 공급업체 목록을 확인하고 아메리카노 커피 공급업체가 Meituan 또는 회사의 통합 조달 시스템(구현된 MCP 서버)과 통합되었음을 확인합니다. 그런 다음 비서는 조달 시스템(MCP 클라이언트)에서 공급업체를 찾아 주문합니다.
이전에는 MCP가 없었을 때 LLM이 함수 호출을 실행하면 에이전트는 API에 직접 연결하여 툴을 호출합니다. 각 API에는 별도의 호출 모드가 필요했으며 에이전트가 해석할 수 있도록 정의된 툴 목록과 호출 모드가 필요했습니다. MCP를 사용하면 많은 API를 공급업체의 MCP 클라이언트를 통해 직접 주문할 수 있어 에이전트의 시간과 노력을 절약할 수 있습니다. 그러나 LLM의 함수 호출은 {tool: ‘buy coffee’, ‘type’: ‘Americano’} 형식으로 변경되지 않습니다.
함수 호출과 MCP를 구별함으로써 MCP가 어떤 툴을 사용할지 결정하지 않고 작업 계획이나 사용자 의도를 처리하지 않는다는 것이 분명해집니다. 이러한 측면은 에이전트 계층의 관할권에 속합니다. MCP는 통합된 툴 인터페이스를 제공하여 업계 내에서 인정받는 표준 프로토콜이 됩니다.
MCP의 개발 과제 및 시장 환경
개발 문제
2월 이후 AI 개발 커뮤니티는 ‘MCP 골드 러시’를 목격했습니다. 공식 앱 스토어가 없는 상황에서 수천 개의 툴이 자발적으로 3개월 이내에 MCP 프로토콜과 통합되었습니다.
이러한 빠른 성장은 MCP를 업계의 주목을 받게 했지만 열망과 현실 사이의 격차도 드러냈습니다. 개발자들은 처음에 MCP를 ‘만능 키’로 여겼지만 특정 시나리오에서는 탁월하지만 다른 시나리오에서는 효과가 떨어지는 ‘특수 렌치’에 더 가깝다는 것을 알게 되었습니다.
MCP 참여자는 로컬 클라이언트 애플리케이션, 클라우드 클라이언트 애플리케이션 및 MCP 서버 개발자로 분류할 수 있습니다. 로컬 애플리케이션은 로컬 AI 비서와 유사하고, 클라우드 클라이언트 애플리케이션은 웹 기반 버전의 ChatGPT와 유사합니다. MCP 서버 개발자는 MCP 규칙을 준수하도록 API를 다시 패키징해야 하는 툴의 실제 제공업체입니다.
MCP의 출현은 처음에는 로컬 클라이언트 애플리케이션에서 환영받았지만 클라우드 클라이언트 애플리케이션과 MCP 서버 개발자는 문제에 직면했습니다.
MCP는 원래 로컬 파일 및 함수를 호출하기 위한 인터페이스 프로토콜로 설계된 Anthropic의 Claude 데스크톱 애플리케이션에서 시작되었으며 클라이언트 측 요구 사항에 깊이 뿌리를 두고 있습니다.
로컬 클라이언트 사용자에게 MCP는 무한히 확장 가능한 툴박스를 제공하여 사용자가 AI 비서의 기능을 지속적으로 확장할 수 있도록 하는 혁신을 의미했습니다.
Cursor 및 Claude Desktop과 같은 로컬 클라이언트 애플리케이션은 MCP를 활용하여 사용자가 개별 요구 사항에 따라 툴을 동적으로 추가하여 AI 비서 기능을 무제한으로 확장할 수 있도록 했습니다.
MCP는 AI 애플리케이션이 각 툴에 대해 별도의 인터페이스를 개발하지 않고도 로컬 환경 및 외부 툴과 원활하게 상호 작용할 수 있도록 하는 방법에 대한 로컬 클라이언트 개발의 핵심 문제점을 해결합니다. 이 통합 프로토콜은 통합 비용을 크게 줄여 소규모 스타트업과 개별 개발자에게 제한된 리소스로 기능이 풍부한 AI 애플리케이션을 구축할 수 있는 지름길을 제공합니다.
그러나 서버 측 개발(MCP 서버) 및 클라우드 클라이언트를 고려할 때 MCP의 매력은 줄어듭니다. 초기 버전의 MCP는 클라우드 서버(원격)에 대한 이중 링크 메커니즘을 사용하여 서버에서 클라이언트로의 단방향 메시지 푸시를 위한 SSE 장기 연결과 메시지 전송을 위한 HTTP 단기 연결을 사용했습니다.
이 접근 방식은 적시에 사용자 피드백과 개입에 적합했지만 서버 측 환경에서 일련의 엔지니어링 문제를 야기했습니다.
첫째, MCP 인터페이스를 구현하는 것은 반드시 상응하는 이점을 제공하지 않고도 대규모 엔터프라이즈 서비스 제공업체에 대한 추가 작업량을 나타냅니다. 이러한 서비스는 종종 성숙한 API 시스템을 갖추고 있으며 추가 MCP 적응 계층을 제공하면 실질적인 가치를 창출하지 않고 유지 관리 비용만 증가할 수 있습니다. 많은 엔터프라이즈급 애플리케이션은 MCP의 개방형 에코시스템보다 폐쇄적이고 제어 가능한 툴 호출 메커니즘을 선호합니다.
또한 고동시성 호출을 처리하기 위해 MCP 서비스를 여러 서버 아키텍처로 확장해야 하는 경우가 많습니다. MCP의 이중 연결 모델은 컴퓨터 간 주소 지정의 복잡성을 야기합니다. 하나의 서버에 장기 연결이 설정되고 요청이 다른 서버로 라우팅되면 이러한 분산 연결을 조정하기 위해 추가 브로드캐스트 큐 메커니즘이 필요하여 구현 난이도와 유지 관리 비용이 크게 증가합니다.
둘째, MCP는 클라우드 애플리케이션 영역에 제한이 있습니다. 클라우드 AI 에이전트(서버 측 에이전트)는 일반적으로 수락 후 작업을 처리하고 완료 시 리소스를 해제하는 상태 비저장 서비스에서 실행됩니다. 서버 측에서 MCP 클라이언트를 사용하려면 SSE 링크를 임시로 생성하고, 툴 호출 요청을 보내고, SSE에서 결과를 수신한 다음 SSE 링크를 닫아야 하는데, 이는 비효율적인 접근 방식으로 복잡성을 증가시키고 성능을 저하시킵니다. 이 시나리오에서는 단일 RPC 요청으로 충분해야 합니다.
실제로 MCP를 사용하는 클라우드 애플리케이션은 미리 설정된 툴 세트에 의존하며 동적 툴 검색 및 유연한 로딩의 MCP 서명 기능을 활용하지 않습니다.
클라우드 환경의 데이터 상호 작용 모드는 MCP가 의도한 대로 툴을 자유롭게 사용할 수 있는 기능을 제한합니다. 특정 하드 코딩된 툴을 호출하기 위한 고도로 표준화된 프로세스가 필요하여 유연성이 저하됩니다.
MCP 팀은 사용자 피드백에 대한 대응성을 보여주었습니다. 서버 측 개발자로부터 피드백을 받은 후 MCP는 3월 26일에 프로토콜을 업데이트하여 원래 SSE 전송을 스트리밍 가능한 HTTP 전송으로 대체했습니다. 새로운 프로토콜은 단일 툴 호출 요청만 필요한 상태 비저장 서비스 시나리오와 HTTP + SSE 이중 링크를 통해 이전에 충족되었던 실시간 푸시 요구 사항을 모두 지원합니다.
이러한 개선 사항은 현재 MCP 문제가 초기 설계 제한 사항에서 비롯되지만 극복할 수 없다는 것을 시사합니다.
시장의 혼란
MCP가 직면한 또 다른 과제는 시장에서 많은 구현의 낮은 사용성입니다.
현재 MCP 시장은 전형적인 기술 과장 주기(technology hype cycle)를 겪고 있습니다. 초기 앱 스토어의 혼란과 마찬가지로 현재 사용 가능한 수천 개의 MCP 툴 중 20% 미만이 실질적인 가치를 가지고 있습니다. 많은 구현에 간단한 구성 오류에서부터 완전한 사용 불가능성에 이르기까지 심각한 문제가 있습니다. 일부는 적절한 테스트 없이 급하게 시장에 출시되고, 다른 일부는 실제 사용을 위한 것이 아닌 실험적인 제품입니다.
더 근본적인 문제는 많은 MCP 구현이 시장에서 필요하지 않을 수 있다는 것입니다. MCP를 통해 제공되는 많은 툴은 MCP가 등장하기 전에 이미 사용 가능했고 사용되었던 API를 다시 패키징한 것으로, 고유한 가치를 거의 추가하지 않습니다.
예를 들어 수십 개의 검색 서비스가 MCP를 통해 제공되지만 품질이 크게 다릅니다. 일부 서비스는 부정확하거나 느려서 기존 솔루션보다 바람직하지 않을 수 있습니다.
또한 MCP에는 강력한 평가 시스템이 없어 에이전트가 신뢰할 수 있는 메트릭을 기반으로 가장 적합한 툴을 선택하기가 어렵습니다. 이 비효율적인 선택 프로세스는 컴퓨팅 리소스를 낭비하고 작업 완료 시간을 연장하며 사용자 경험을 저하시킵니다.
평가 시스템이 없으면 에이전트가 가장 적합한 툴을 선택하기가 어렵습니다. 여러 MCP 서비스가 유사한 이름과 설명을 가진 툴을 제공하는 경우 에이전트는 최상의 옵션을 선택하는 데 어려움을 겪을 수 있으며 토큰 낭비와 효율성 저하로 이어집니다.
가장 성공적인 AI 애플리케이션은 종종 반대 접근 방식을 취하여 더 많은 양의 툴보다 더 정확한 툴을 제공합니다. 예를 들어 Manus는 존재에도 불구하고 MCP 프로토콜을 채택하는 대신 내부 애플리케이션을 구축하기로 결정했습니다. Manus는 MCP 에코시스템과 통합하는 것보다 호출 정확도와 안정성을 우선시했습니다.
Cursor와 같은 코드 편집기에는 개발 기능이 내장되어 있어 대부분의 외부 MCP 툴이 중복됩니다.
현재 MCP 시장의 혼란스러운 상태는 반드시 실패의 징조는 아니지만 모든 신흥 기술 에코시스템의 성장에 필요한 단계입니다. 역사적 선례는 이러한 초기 과잉 확장이 시장 선택 메커니즘을 통해 점차 수렴되어 가장 가치 있는 요소만 남게 될 것임을 시사합니다.
이 프로세스를 통해 업계는 현재의 과제로부터 배우고 더 강력하고 신뢰할 수 있는 MCP 프레임워크를 만들 수 있습니다. 닷컴 버블이 전자 상거래 및 소셜 미디어에서 획기적인 혁신으로 이어진 것과 마찬가지로 MCP 트렌드는 보다 간소화되고 가치 있는 툴 에코시스템으로 이어질 수 있습니다.
사용자 피드백에 대한 MCP 팀의 개방적인 태도는 고무적이며 업계는 에코시스템을 더욱 유용하게 만들 수 있는 MCP 서비스의 품질을 평가하고 보장하는 더 나은 툴이 필요합니다.
MCP는 좋지만 만병통치약은 아니다
위에 언급된 문제는 MCP의 한계와 단점에서 비롯되어 현실적으로 달성할 수 있는 것을 강조합니다. 그러나 다른 비판은 비현실적인 기대에서 비롯됩니다.
최근의 한 비판에서는 MCP가 LLM과 MCP 간의 상호 작용 패턴을 규정하지 않기 때문에 결함이 있는 프로토콜이라고 합니다.
일부는 MCP가 AI 시스템 의사 결정을 자동으로 개선하거나 작업 계획 효율성을 향상시킬 것이라고 기대합니다. 이러한 기대는 도구를 장인과 혼동합니다.
문제는 인지 불일치에서 비롯됩니다. 통신 프로토콜이 지능형 시스템의 작업을 수행할 것이라고 기대하는 것입니다. 이는 USB가 사진을 편집하지 않거나 5G 표준이 코드를 작성하지 않는다고 비난하는 것과 같습니다. MCP는 주로 어떤 가전제품을 사용할지 또는 사용하는 방법을 규정하는 것이 아니라 플러그 호환성을 보장하는 표준화된 ‘툴 소켓’입니다.
에이전트-툴 호출의 효과는 툴 선택 숙련도, 작업 계획 기술 및 컨텍스트 이해와 같은 요소에 달려 있으며, 이러한 요소는 MCP의 범위에 속하지 않습니다. MCP는 표준화된 툴 인터페이스만 보장하며 이러한 툴이 선택되고 결합되는 방법은 보장하지 않습니다.
우리는 종종 기술에서 은탄환, 즉 보편적으로 적용 가능한 솔루션을 찾습니다. 소프트웨어 엔지니어링의 ‘은탄환은 없다’는 공리와 마찬가지로 AI 툴 사용에는 마법 같은 솔루션이 없습니다. 강력한 AI 시스템에는 이해 및 생성을 위한 LLM, 계획 및 실행을 위한 에이전트 프레임워크, 통합된 툴 인터페이스에 초점을 맞춘 MCP와 같이 설계된 구성 요소가 필요합니다.
MCP는 하나의 문제를 집중적으로 해결하고 모든 문제를 해결하는 것이 아니라 잘 해결하는 좋은 프로토콜 설계를 보여줍니다. 이러한 자제력은 클라이언트 측 툴 통합에서 발전을 돕습니다.
Alibaba의 Qwen, Baidu의 ‘Xinxiang’ 및 ByteDance의 Kouzi Space와 같은 엔터티는 MCP 프로토콜을 수용하여 보다 효율적인 내부 MCP 에코시스템을 구축하려고 시도합니다.
그러나 배포에는 주요 차이점이 있습니다. Baidu와 ByteDance는 더 공격적입니다. Baidu는 모바일 장치를 위한 ‘Xinxiang’(Kokone)을 통해 여러 AI 모델과 외부 툴을 통합하고 MCP 프로토콜을 활용하여 사용자 일상 생활에 통합하고 채택을 장려하는 C-end 접근 방식을 시도합니다.
ByteDance의 Kouzi Space에는 60개 이상의 MCP 확장 플러그인이 있습니다. 웹페이지를 통해 액세스할 수 있으며 생산성 시나리오를 주로 대상으로 하는 MCP를 지원하는 AI 기본 IDE인 Trae도 출시했습니다.
Alibaba는 MCP 프로토콜을 Alipay와 같은 제품에 통합하여 원클릭 AI 툴 호출을 가능하게 하고 MCP 프로토콜을 지원하는 Qwen3 모델을 오픈 소스로 공개하여 에이전트 기능을 향상시켰습니다.
Tencent Cloud 개발자는 MCP 플러그인 호스팅 서비스를 지원하는 AI 개발 스위트를 출시했습니다. Tencent Cloud의 대규모 모델 지식 엔진을 통해 사용자는 MCP 플러그인을 호출할 수 있습니다. Tencent Cloud의 CodeBuddy에서 출시한 Craft 소프트웨어 개발 지능형 에이전트는 MCP 개방형 에코시스템과 호환됩니다. 또한 Tencent Maps와 Tencent Cloud Storage는 자체 MCP SERVER를 출시했습니다.
AI 툴 사용은 프로그래밍 스타일이 어셈블리 언어에서 객체 지향으로 진화한 것처럼 직접적인 단일 툴 작동에서 전문 에이전트 협업으로 진화할 수 있습니다.
이 패러다임에서 MCP는 단순히 사용자 또는 개발자 대면 인터페이스 대신 기본 인프라의 일부가 될 수 있습니다. 보다 완전한 계획에는 추상화 수준을 높여 작업 계획 및 툴 선택 효율성을 향상시키는 에이전트 간(A2A)과 같은 아키텍처가 필요할 수 있습니다.
MCP를 ‘프로토콜’ 역할로 되돌림으로써 업계 표준화를 추진하는 진정한 힘을 인식할 수 있습니다. 이는 기술 진화에서 가장 소중한 ‘탈신비화’ 순간일 수 있습니다.