🦈 MCP 심층 분석과 AI 툴링의 미래

2023년 OpenAI가 펑션 콜링(function calling)을 출시한 이후, 저는 에이전트와 툴 사용 생태계를 활성화하려면 무엇이 필요할지 고민해왔습니다. 기반 모델이 점점 더 지능화되면서, 에이전트가 외부 툴, 데이터, API와 상호작용하는 능력은 점점 더 파편화되고 있습니다. 개발자들은 에이전트가 작동하고 통합하는 모든 개별 시스템에 맞춰 특별한 비즈니스 로직을 갖춘 에이전트를 구현해야 합니다.

실행, 데이터 가져오기, 툴 호출을 위한 표준 인터페이스가 필요하다는 것은 분명합니다. API는 소프트웨어가 소통할 수 있는 공통 언어를 만들어 인터넷 최초의 위대한 통합자 역할을 했지만, AI 모델에는 그에 상응하는 것이 부족합니다.

2024년 11월에 소개된 MCP(Model Context Protocol)는 개발자 및 AI 커뮤니티 내에서 잠재적인 해결책으로 상당한 주목을 받고 있습니다. 이 글에서는 MCP가 무엇인지, AI가 툴과 상호작용하는 방식을 어떻게 바꾸는지, 개발자들이 이미 MCP로 무엇을 구축하고 있는지, 그리고 아직 해결해야 할 과제는 무엇인지 살펴보겠습니다.

시작해 보겠습니다.

MCP란 무엇인가?

MCP는 시스템이 여러 통합에 걸쳐 일반화할 수 있는 방식으로 AI 모델에 컨텍스트를 제공할 수 있도록 하는 오픈 프로토콜입니다. 이 프로토콜은 AI 모델이 외부 툴을 호출하고, 데이터를 가져오며, 서비스와 상호작용하는 방법을 정의합니다. 구체적인 예로, 아래는 Resend MCP 서버가 여러 MCP 클라이언트와 작동하는 방식입니다.

이 아이디어는 새로운 것이 아니며, MCP는 LSP(Language Server Protocol)에서 영감을 받았습니다. LSP에서는 사용자가 편집기에서 입력할 때 클라이언트가 언어 서버에 질의하여 자동 완성 제안이나 진단 정보를 얻습니다.

MCP가 LSP를 넘어 확장되는 지점은 에이전트 중심의 실행 모델에 있습니다. LSP는 대부분 반응적(사용자 입력에 기반한 IDE 요청에 응답)인 반면, MCP는 자율적인 AI 워크플로우를 지원하도록 설계되었습니다. 컨텍스트에 따라 AI 에이전트는 어떤 툴을 사용할지, 어떤 순서로 사용할지, 그리고 작업을 완료하기 위해 어떻게 연결할지를 결정할 수 있습니다. MCP는 또한 사람이 추가 데이터를 제공하고 실행을 승인할 수 있는 인간 개입(human-in-the-loop) 기능을 도입했습니다.

오늘날의 주요 사용 사례

적절한 MCP 서버 세트를 갖추면 사용자는 모든 MCP 클라이언트를 "만능 앱(everything app)"으로 바꿀 수 있습니다.

Cursor를 예로 들어보겠습니다. Cursor는 코드 편집기이지만, 잘 구현된 MCP 클라이언트이기도 합니다. 최종 사용자는 Slack MCP 서버를 사용하여 Slack 클라이언트로, Resend MCP 서버를 사용하여 이메일 발신기로, Replicate MCP 서버를 사용하여 이미지 생성기로 만들 수 있습니다. MCP를 활용하는 더 강력한 방법은 하나의 클라이언트에 여러 서버를 설치하여 새로운 플로우를 만드는 것입니다. 사용자는 Cursor에서 프론트엔드 UI를 생성하는 서버를 설치할 수 있을 뿐만 아니라, 에이전트에게 이미지 생성 MCP 서버를 사용하여 사이트의 히어로 이미지를 생성하도록 요청할 수도 있습니다.

Cursor 외에도 오늘날 대부분의 사용 사례는 개발 중심의 로컬 우선 워크플로우 또는 LLM 클라이언트를 사용하는 완전히 새로운 경험으로 요약될 수 있습니다.

개발 중심 워크플로우

매일 코드 속에서 사는 개발자들에게 "x 작업을 하기 위해 IDE를 벗어나고 싶지 않다"는 흔한 감정입니다. MCP 서버는 이 꿈을 현실로 만드는 훌륭한 방법입니다.

데이터베이스 상태를 확인하기 위해 Supabase로 전환하는 대신, 개발자는 이제 Postgres MCP 서버를 사용하여 읽기 전용 SQL 명령을 실행하고 Upstash MCP 서버를 사용하여 IDE에서 바로 캐시 인덱스를 생성하고 관리할 수 있습니다. 코드를 반복 작업할 때 개발자는 Browsertools MCP를 활용하여 코딩 에이전트가 실시간 환경에 접근하여 피드백과 디버깅을 할 수도 있습니다.

개발자 도구와 상호작용하는 워크플로우 외에도, MCP 서버가 가능하게 하는 새로운 용도는 웹 페이지를 크롤링하거나 문서를 기반으로 MCP 서버를 자동 생성하여 코딩 에이전트에 매우 정확한 컨텍스트를 추가할 수 있다는 것입니다. 통합을 수동으로 연결하는 대신, 개발자는 기존 문서나 API에서 직접 MCP 서버를 구동하여 툴을 AI 에이전트가 즉시 사용할 수 있도록 만들 수 있습니다. 이는 상용구 코드(boilerplate) 작성에 드는 시간을 줄이고, 실시간 컨텍스트를 가져오거나, 명령을 실행하거나, AI 어시스턴트의 기능을 즉석에서 확장하는 등 실제로 툴을 사용하는 데 더 많은 시간을 할애할 수 있음을 의미합니다.

완전히 새로운 경험

Cursor와 같은 IDE가 유일한 MCP 클라이언트는 아니지만, MCP가 기술 사용자에게 강력하게 어필하기 때문에 가장 많은 주목을 받았습니다. 비기술 사용자의 경우, Claude Desktop은 훌륭한 진입점 역할을 하여 MCP 기반 툴을 일반 대중이 더 쉽게 접근하고 사용자 친화적으로 사용할 수 있게 합니다. 곧 고객 지원, 마케팅 카피라이팅, 디자인, 이미지 편집과 같은 비즈니스 중심 작업을 위한 전문 MCP 클라이언트가 등장할 가능성이 높습니다. 이러한 분야는 패턴 인식 및 창의적 작업에서 AI의 강점과 밀접하게 연관되어 있기 때문입니다.

MCP 클라이언트의 디자인과 지원하는 특정 상호작용은 그 기능을 형성하는 데 중요한 역할을 합니다. 예를 들어, 채팅 애플리케이션은 벡터 렌더링 캔버스를 포함할 가능성이 낮고, 디자인 툴이 원격 시스템에서 코드를 실행하는 기능을 제공할 가능성은 낮습니다. 궁극적으로 MCP 클라이언트 경험이 전체 MCP 사용자 경험을 정의하며, MCP 클라이언트 경험에 관해서는 아직 우리가 발휘할 수 있는 잠재력이 훨씬 더 많습니다.

이에 대한 한 예는 Highlight가 클라이언트에서 모든 MCP 서버를 호출하기 위해 @ 커맨드를 구현한 방식입니다. 그 결과, MCP 클라이언트가 생성된 콘텐츠를 원하는 모든 다운스트림 앱으로 파이프할 수 있는 새로운 UX 패턴이 탄생했습니다.

또 다른 예는 Blender MCP 서버 사용 사례입니다. 이제 Blender를 거의 모르는 아마추어 사용자도 자연어를 사용하여 만들고 싶은 모델을 설명할 수 있습니다. 커뮤니티가 Unity 및 Unreal engine과 같은 다른 툴을 위한 서버를 구현함에 따라 텍스트-3D 워크플로우가 실시간으로 구현되는 것을 보고 있습니다.

우리는 주로 서버와 클라이언트를 생각하지만, MCP 생태계는 프로토콜이 발전함에 따라 점차 구체화되고 있습니다. 이 시장 지도는 오늘날 가장 활발한 영역을 다루고 있지만, 여전히 많은 공백이 있습니다. MCP가 아직 초기 단계라는 것을 알고 있기에, 시장이 발전하고 성숙함에 따라 지도에 더 많은 플레이어를 추가하게 되어 기쁩니다. (그리고 다음 섹션에서 이러한 미래 가능성 중 일부를 탐색할 것입니다.)

MCP 클라이언트 측면에서는 오늘날 우리가 보는 고품질 클라이언트 대부분이 코딩 중심입니다. 개발자가 일반적으로 신기술의 얼리 어답터이기 때문에 이는 놀라운 일이 아니지만, 프로토콜이 성숙해짐에 따라 더 많은 비즈니스 중심 클라이언트가 등장할 것으로 예상합니다.

우리가 보는 대부분의 MCP 서버는 로컬 우선이며 단일 플레이어에 초점을 맞춥니다. 이는 현재 MCP가 SSE 및 명령 기반 연결만 지원하는 증상입니다. 그러나 생태계가 원격 MCP를 최우선으로 만들고 MCP가 Streamable HTTP 전송을 채택함에 따라 더 많은 MCP 서버 도입을 기대합니다.

또한 MCP 서버 발견을 가능하게 하기 위해 새로운 MCP 마켓플레이스 및 서버 호스팅 솔루션의 물결이 나타나고 있습니다. Mintlify의 mcpt, Smithery, OpenTools와 같은 마켓플레이스는 개발자가 새로운 MCP 서버를 더 쉽게 발견하고, 공유하고, 기여할 수 있도록 만들고 있습니다. 이는 마치 npm이 JavaScript의 패키지 관리를 변화시켰거나 RapidAPI가 API 검색을 확장한 방식과 유사합니다. 이 계층은 고품질 MCP 서버에 대한 접근을 표준화하여 AI 에이전트가 필요에 따라 툴을 동적으로 선택하고 통합할 수 있도록 하는 데 중요할 것입니다.

MCP 채택이 증가함에 따라 인프라 및 툴링은 생태계를 더 확장 가능하고, 신뢰할 수 있으며, 접근 가능하게 만드는 데 중요한 역할을 할 것입니다. Mintlify, Stainless, Speakeasy와 같은 서버 생성 도구는 MCP 호환 서비스를 만드는 데 따르는 마찰을 줄이고 있으며, Cloudflare 및 Smithery와 같은 호스팅 솔루션은 배포 및 확장 문제를 해결하고 있습니다. 동시에 Toolbase와 같은 연결 관리 플랫폼은 로컬 우선 MCP 키 관리 및 프록시를 간소화하기 시작했습니다.

미래의 가능성

그러나 우리는 에이전트 네이티브 아키텍처 진화의 초기 단계에 있을 뿐입니다. 그리고 오늘날 MCP에 대한 많은 기대가 있지만, MCP를 구축하고 배포할 때 아직 해결되지 않은 문제도 많습니다.

프로토콜의 다음 반복에서 해결해야 할 몇 가지 사항은 다음과 같습니다.

호스팅 및 멀티테넌시

MCP는 AI 에이전트와 해당 툴 간의 일대다 관계를 지원하지만, 멀티테넌트 아키텍처(예: SaaS 제품)는 많은 사용자가 공유 MCP 서버에 동시에 액세스하는 것을 지원해야 합니다. 원격 서버를 기본으로 갖는 것이 MCP 서버의 접근성을 높이는 단기적인 해결책이 될 수 있지만, 많은 기업에서는 자체 MCP 서버를 호스팅하고 데이터 및 제어 플레인을 분리하기를 원할 것입니다.

대규모 MCP 서버 배포 및 유지 관리를 지원하는 간소화된 툴체인은 더 넓은 채택을 가능하게 할 수 있는 다음 조각입니다.

인증

MCP는 현재 클라이언트가 서버와 인증하는 방법에 대한 표준 인증 메커니즘을 정의하지 않으며, MCP 서버가 타사 API와 상호작용할 때 인증을 안전하게 관리하고 위임하는 방법에 대한 프레임워크도 제공하지 않습니다. 인증은 현재 개별 구현 및 배포 시나리오에 맡겨져 있습니다. 실제로 MCP의 채택은 지금까지 명시적인 인증이 항상 필요하지 않은 로컬 통합에 집중된 것으로 보입니다.

더 나은 인증 패러다임은 원격 MCP 채택에 있어 큰 돌파구 중 하나가 될 수 있습니다. 개발자 관점에서 통합된 접근 방식은 다음을 포함해야 합니다.

• 클라이언트 인증: 클라이언트-서버 상호작용을 위한 OAuth 또는 API 토큰과 같은 표준 방법
• 툴 인증: 타사 API 인증을 위한 헬퍼 함수 또는 래퍼
• 다중 사용자 인증: 엔터프라이즈 배포를 위한 테넌트 인식 인증

인가

툴이 인증되었더라도 누가 사용하도록 허용되어야 하며 권한은 얼마나 세분화되어야 할까요? MCP에는 내장된 권한 모델이 없으므로 접근 제어는 세션 수준입니다. 즉, 툴은 접근 가능하거나 완전히 제한됩니다. 향후 인가 메커니즘이 더 세분화된 제어를 형성할 수 있지만, 현재 접근 방식은 인증되면 세션 전체 액세스 권한을 부여하는 OAuth 2.1 기반 인가 흐름에 의존합니다. 이는 더 많은 에이전트와 툴이 도입됨에 따라 추가적인 복잡성을 야기합니다. 각 에이전트는 일반적으로 고유한 인가 자격 증명이 있는 자체 세션이 필요하며, 이는 세션 기반 접근 관리의 복잡한 망으로 이어집니다.

게이트웨이

MCP 채택이 확장됨에 따라 게이트웨이는 인증, 인가, 트래픽 관리 및 툴 선택을 위한 중앙 집중식 계층 역할을 할 수 있습니다. API 게이트웨이와 유사하게 접근 제어를 시행하고, 요청을 올바른 MCP 서버로 라우팅하며, 로드 밸런싱을 처리하고, 응답을 캐시하여 효율성을 개선할 것입니다. 이는 서로 다른 사용자와 에이전트가 별도의 권한을 요구하는 멀티테넌트 환경에서 특히 중요합니다. 표준화된 게이트웨이는 클라이언트-서버 상호작용을 단순화하고, 보안을 개선하며, 더 나은 관찰 가능성을 제공하여 MCP 배포를 더 확장 가능하고 관리하기 쉽게 만들 것입니다.

MCP 서버 검색 가능성 및 사용성

현재 MCP 서버를 찾고 설정하는 것은 수동 프로세스로, 개발자가 엔드포인트나 스크립트를 찾고, 인증을 구성하고, 서버와 클라이언트 간의 호환성을 확인해야 합니다. 새로운 서버를 통합하는 것은 시간이 많이 걸리며, AI 에이전트는 사용 가능한 서버를 동적으로 검색하거나 적응할 수 없습니다.

하지만 지난달 AI 엔지니어 컨퍼런스에서 있었던 Anthropic의 발표에 따르면, MCP 서버 레지스트리 및 검색 프로토콜이 곧 나올 것으로 보입니다. 이는 MCP 서버 채택의 다음 단계를 열 수 있습니다.

실행 환경

대부분의 AI 워크플로우는 순서대로 여러 툴 호출이 필요하지만, MCP에는 이러한 단계를 관리하기 위한 내장된 워크플로우 개념이 부족합니다. 모든 클라이언트에게 재개 가능성(resumability)과 재시도 가능성(retryability)을 구현하도록 요구하는 것은 이상적이지 않습니다. 오늘날 개발자들이 이를 작동시키기 위해 Inngest와 같은 솔루션을 탐색하는 것을 보지만, 상태 저장 실행(stateful execution)을 일급 개념으로 승격하면 대부분의 개발자를 위한 실행 모델이 명확해질 것입니다.

표준 클라이언트 경험

개발자 커뮤니티에서 자주 듣는 질문 중 하나는 MCP 클라이언트를 구축할 때 툴 선택을 어떻게 생각해야 하는가입니다. 모든 사람이 툴을 위해 자체 RAG를 구현해야 하는가, 아니면 표준화되기를 기다리는 계층이 있는가?

툴 선택 외에도 툴을 호출하는 통일된 UI/UX 패턴도 없습니다(슬래시 커맨드부터 순수 자연어까지 모든 것을 보았습니다). 툴 검색, 순위 지정 및 실행을 위한 표준 클라이언트 측 레이어는 보다 예측 가능한 개발자 및 사용자 경험을 만드는 데 도움이 될 수 있습니다.

디버깅

MCP 서버 개발자들은 종종 동일한 MCP 서버가 여러 클라이언트에서 쉽게 작동하도록 만드는 것이 어렵다는 것을 발견합니다. 대부분의 경우 각 MCP 클라이언트에는 고유한 특이점이 있으며, 클라이언트 측 트레이스는 없거나 찾기 어려워 MCP 서버 디버깅을 매우 어려운 작업으로 만듭니다. 세상이 더 많은 원격 우선 MCP 서버를 구축하기 시작함에 따라 로컬 및 원격 환경 전반에 걸쳐 개발 경험을 더욱 간소화하기 위한 새로운 툴 세트가 필요합니다.

AI 툴링의 시사점

MCP의 개발 경험은 2010년대의 API 개발을 떠올리게 합니다. 패러다임은 새롭고 흥미롭지만, 툴체인은 초기 단계에 있습니다. 지금으로부터 몇 년 후로 빨리 감기를 하여 MCP가 AI 기반 워크플로우의 사실상 표준이 된다면 어떤 일이 일어날까요? 몇 가지 예측입니다:

• 개발 우선 기업의 경쟁 우위는 최고의 API 디자인을 제공하는 것에서 에이전트가 사용할 최고의 툴 컬렉션을 제공하는 것으로 진화할 것입니다. MCP가 자율적으로 툴을 검색할 수 있는 능력을 갖게 된다면, API 및 SDK 제공업체는 자사의 툴링이 검색에서 쉽게 발견될 수 있도록 하고 특정 작업에 대해 에이전트가 선택할 만큼 충분히 차별화되도록 해야 합니다. 이는 인간 개발자가 찾는 것보다 훨씬 더 세분화되고 구체적일 수 있습니다.
• 모든 앱이 MCP 클라이언트가 되고 모든 API가 MCP 서버가 된다면 새로운 가격 모델이 등장할 수 있습니다. 에이전트는 속도, 비용, 관련성의 조합에 따라 툴을 더 동적으로 선택할 수 있습니다. 이는 가장 널리 채택된 툴 대신 성능이 가장 좋고 가장 모듈화된 툴을 선택하는 보다 시장 주도적인 툴 채택 프로세스로 이어질 수 있습니다.
• 기업은 명확하고 기계 판독 가능한 형식(예: llms.txt)으로 툴과 API를 설계하고 기존 문서를 기반으로 MCP 서버를 사실상의 결과물로 만들어야 하므로 문서화는 MCP 인프라의 중요한 부분이 될 것입니다.
• API만으로는 더 이상 충분하지 않지만 훌륭한 출발점이 될 수 있습니다. 개발자들은 API에서 툴로의 매핑이 거의 1:1이 아니라는 것을 발견할 것입니다. 툴은 작업 실행 시점에 에이전트에게 가장 의미 있는 더 높은 추상화입니다. 단순히 send_email()을 호출하는 대신, 에이전트는 지연 시간을 최소화하기 위해 여러 API 호출을 포함하는 draft_email_and_send() 함수를 선택할 수 있습니다. MCP 서버 설계는 API 중심이 아닌 시나리오 및 사용 사례 중심이 될 것입니다.
• 모든 소프트웨어가 기본적으로 MCP 클라이언트가 된다면 새로운 호스팅 모드가 필요할 것입니다. 워크로드 특성이 기존 웹사이트 호스팅과 다를 것이기 때문입니다. 모든 클라이언트는 본질적으로 다단계이며 재개 가능성, 재시도, 장기 실행 작업 관리와 같은 실행 보장이 필요합니다. 호스팅 제공업체는 또한 비용, 지연 시간 및 성능을 최적화하기 위해 서로 다른 MCP 서버 간의 실시간 로드 밸런싱이 필요하며, 이를 통해 AI 에이전트가 특정 순간에 가장 효율적인 툴을 선택할 수 있도록 합니다.

MCP는 이미 AI-에이전트 생태계를 재편하고 있지만, 다음 단계의 진전은 우리가 근본적인 과제를 어떻게 해결하는지에 따라 정의될 것입니다. 제대로 수행된다면 MCP는 AI-툴 상호작용의 기본 인터페이스가 되어 차세대 자율적이고, 다중 모드이며, 깊이 통합된 AI 경험을 열 수 있습니다.

널리 채택된다면 MCP는 툴이 구축되고, 소비되며, 수익화되는 방식의 변화를 나타낼 수 있습니다. 시장이 MCP를 어디로 이끌지 기대됩니다. 올해는 중추적인 해가 될 것입니다. 통합된 MCP 마켓플레이스의 부상을 보게 될까요? AI 에이전트를 위한 인증이 원활해질까요? 다단계 실행이 프로토콜에 공식화될 수 있을까요?

A Deep Dive Into MCP and the Future of AI Tooling | Andreessen Horowitz

We explore what MCP is, how it changes the way AI interacts with tools, what developers are already building, and the challenges that still need solving.

Andreessen HorowitzYoko Li