저자: FounderPark
Anthropic이 작년에 출시한 MCP 프로토콜은 올해 Manus와 Agent의 인기로 인해 갑자기 AI 분야에서 이슈 프로토콜이 되었습니다. OpenAI, Microsoft, Google 등 주요 기업도 이 프로토콜을 지원했습니다. 국내 알리바바 클라우드 바이리안과 텐센트 클라우드도 이에 발맞춰 신속한 구축 플랫폼을 출시했습니다.
하지만 많은 논란도 있습니다. 많은 사람들은 MCP와 API 사이에 큰 차이가 없다는 점, Anthropic의 엔지니어들이 인터넷 프로토콜에 능숙하지 않다는 점, 그리고 프로토콜이 너무 단순해서 보안 문제가 있다는 점에 의문을 제기합니다.
MCP 프로토콜의 발명자가 이러한 질문에 답하는 것은 당연한 일입니다.
최근 Latent Space에서 진행한 팟캐스트에서 Anthropic 팀의 MCP 프로토콜 발명가인 Justin Spahr-Summers와 David Soria Parra를 초대하여 MCP의 기원과 MCP에 대한 그들의 다양한 생각에 대해 자세히 이야기했습니다. MCP가 출시된 이유, MCP가 기존 API와 다른 점, MCP를 사용하여 도구를 보다 효과적으로 활용하는 방법 등이 포함됩니다. 정보의 양이 방대하므로 읽어볼 것을 권장합니다.
게스트 소개:
Alessio Fanelli(진행자): Decibel의 파트너 겸 CTO
swyx(호스트): Small AI의 창립자
데이비드 소리아 파라: 인류 엔지니어
저스틴 스파르-서머스: 인류 엔지니어
요약:
MCP 컨셉에 대한 "영감의 섬광"은 Anthropic의 내부 프로젝트인 LSP(언어 서버 프로토콜)에서 나왔습니다. LSP에서 영감을 받은 두 엔지니어는 "AI 애플리케이션과 확장 기능 간의 통신"을 표준화하기 위해 LSP와 비슷한 것을 만들 수 있을지 궁금해했습니다.
MCP의 핵심 설계 원칙은 도구 개념이 도구 자체뿐만 아니라 클라이언트 애플리케이션과 사용자와도 긴밀하게 관련되어 있다는 것입니다. 사용자는 MCP 작동을 완벽하게 제어할 수 있어야 합니다. 도구는 모델에 의해 제어됩니다. 즉, 사용자가 도구 사용을 적극적으로 지정하지 않고도 모델에 의해서만 도구가 호출됩니다(프롬프트 목적의 경우 제외).
오픈 API와 MCP는 상호 배타적이지 않고 매우 상호 보완적입니다. 중요한 것은 특정 작업에 가장 적합한 도구를 선택하는 것입니다. AI 애플리케이션 간의 풍부한 상호작용을 구현하는 것이 목표라면 MCP가 더 적합합니다. 모델이 API 사양을 쉽게 읽고 해석할 수 있게 하려면 개방형 API가 더 나은 선택이 될 것입니다.
MCP 서버를 빠르게 구축하려면 AI 지원 코딩을 사용하는 것이 매우 좋은 방법입니다. 개발 초기 단계에서는 MCP SDK 코드 조각을 LLM 컨텍스트 창에 넣고 LLM이 서버를 빌드하도록 돕습니다. 결과는 대개 매우 좋으며, 나중에 세부 사항을 더욱 최적화할 수 있습니다. 이는 기본 기능을 빠르게 구현하고 반복하는 좋은 방법입니다. 동시에 Anthropic의 MCP 팀은 LLM이 참여할 수 있도록 서버 구축 프로세스를 단순화하는 데 주력하고 있습니다.
AI 애플리케이션, 생태계, 에이전트의 미래 개발 방향은 상태 유지(Statefulness)가 될 경향이 있는데, 이는 Anthropic의 MCP 핵심 팀 내에서 가장 논란이 많은 주제 중 하나이기도 합니다. 많은 논의와 반복 끝에 우리는 Statefulness의 미래에 대해 낙관적이기는 하지만 기존 패러다임에서 벗어날 수는 없으며 Statefulness의 개념과 실제 운영의 복잡성 사이에서 균형을 찾아야 한다는 결론에 도달했습니다.
파운더 파크는 개발자 커뮤니티 구축하고, 새로운 모델과 기술을 적극적으로 시도하고 테스트하는 개발자와 기업가를 초대하고 있습니다. QR 코드를 스캔하여 제품/프로젝트 정보를 자세히 입력하세요. 심사를 통과하시면 직원이 그룹에 추가해 드립니다~
그룹에 가입하면 다음과 같은 혜택을 누릴 수 있습니다.
주류 모델(DeepSeek 등) 개발 및 커뮤니케이션이 집중되어 있음
리소스 도킹, API, 클라우드 공급업체, 모델 공급업체와의 직접적인 커뮤니케이션 및 피드백 기회
창업자 박씨는 유용하고 흥미로운 제품/사례를 적극적으로 홍보할 예정입니다.
01 MCP는 어떻게 탄생했나요?
swyx(호스트): 우선, MCP가 무엇인가요?
저스틴: 모델 컨텍스트 프로토콜, 줄여서 MCP는 기본적으로 AI 애플리케이션이 스스로를 확장하거나 플러그인 생태계에 통합하는 데 도움이 되도록 만든 디자인입니다. 구체적으로, MCP는 AI 애플리케이션(당사에서 "클라이언트"라고 부름)과 다양한 외부 확장(당사에서 "MCP 서버"라고 부름)이 서로 협업할 수 있도록 하는 일련의 통신 프로토콜을 제공합니다. 여기서 "확장"은 플러그인, 도구 또는 기타 리소스가 될 수 있습니다.
MCP의 목적은 모든 사람이 외부 서비스와 기능을 쉽게 도입하거나 AI 애플리케이션을 구축할 때 더 많은 데이터를 검색하여 애플리케이션의 기능을 더욱 풍부하게 만들 수 있도록 하는 것입니다. "클라이언트-서버"라는 개념은 주로 상호작용 모드를 강조하기 위해 우리의 이름에 포함되었지만, 본질은 "AI 애플리케이션을 더 쉽게 확장할 수 있는" 보편적인 인터페이스를 만드는 것입니다.
하지만 MCP는 모델 자체보다는 AI 애플리케이션에 초점을 맞춘다는 점을 강조하는 것이 중요한데, 이는 흔히 오해되는 부분입니다. 또한, MCP는 AI 애플리케이션을 위한 USB-C 포트와 같으며, 전체 생태계를 연결하는 범용 인터페이스라는 점에 동의합니다.
swyx(호스트): 클라이언트와 서버의 특성상 USB-C 인터페이스처럼 양방향이라는 점이 흥미롭습니다. 많은 사람들이 관련 연구를 수행하고 오픈 소스 프로젝트를 구축하려고 노력합니다. 저는 Anthropic이 다른 연구소보다 개발자를 유치하는 데 더 적극적이라고 생각합니다. 이런 일이 일어나게 된 데에는 외부적인 영향이 있었는지, 아니면 두 분이 같은 방에 있을 때 갑자기 떠오른 생각인지 궁금합니다.
데이비드 : 사실 대부분은 우리 두 사람이 방에 있을 때 즉흥적으로 생각해 낸 것들이었습니다. 이것은 대전략의 일부가 아닙니다. 저는 2024년 7월에 Anthropic에 입사하여 주로 내부 개발자 도구 부문을 담당했습니다. 이 기간 동안 저는 더 많은 직원이 기존 모델을 심층적으로 통합할 수 있는 방법에 대해 생각했습니다. 결국, 이 모델들은 훌륭하고 더 나은 전망을 가지고 있습니다. 당연히 저는 모든 사람이 우리의 모델을 더 많이 활용하기를 바랍니다.
직장에서 저는 개발 도구 분야에서 쌓은 경험에 금방 좌절감을 느꼈습니다. Claude Desktop은 제한적이고 확장이 불가능했고, IDE에는 Claude Desktop의 유용한 기능이 없었기 때문입니다. 그래서 두 IDE 사이에서 콘텐츠를 복사해서 사용해야 했는데, 이는 번거로운 일이었습니다. 시간이 지나면서. 저는 이것이 MxN 문제, 즉 여러 애플리케이션과 여러 통합이라는 것을 깨달았고, 이를 해결하는 가장 좋은 방법은 단일 프로토콜을 사용하는 것이라는 것을 깨달았습니다. 당시 저는 아직 LSP(Language Server Protocol)와 관련된 내부 프로젝트를 진행하고 있었고, 별다른 진전이 없었습니다. 이러한 아이디어를 결합하고 몇 주 동안 고민한 끝에 일종의 프로토콜을 구축하는 아이디어가 떠올랐습니다. LSP와 비슷한 것을 만들 수 있을까요? " AI 애플리케이션과 확장 프로그램 간의 통신 "을 표준화합니다.
그래서 저는 저스틴을 찾아서 아이디어를 공유했고, 다행히도 그는 관심을 보였어요. 그래서 우리는 함께 만들기 시작했죠.
이 아이디어가 떠오른 때부터 프로토콜을 구축하고 첫 번째 통합을 완료하는 데 약 한 달 반이 걸렸습니다. 저스틴은 첫 번째 클로드 데스크톱 통합 작업에 대량 노력을 기울였고, 저는 IDE에서 프로토콜을 어떻게 사용할 수 있는지 보여주기 위해 IDE에서 많은 개념 증명을 수행했습니다. 공식 출시 전에 관련 코드베이스를 살펴보니 많은 세부 정보가 드러났습니다. 이것이 MCP의 기원에 대한 대략적인 이야기입니다.
알레시오(진행자): 타임라인은 어떻게 되나요? 공식 출시일이 11월 25일인 건 알고 있어요. 이 프로젝트를 언제부터 시작했나요?
저스틴 : 7월경, 데이비드가 아이디어를 제안한 후, 저는 곧바로 그와 함께 MCP를 구축하는 작업에 흥미를 느꼈습니다. 처음 몇 달 동안은 클라이언트, 서버, SDK 등 통신 프로토콜을 구축하는 기반 작업 대량 진행 속도가 느렸습니다. 하지만 프로토콜을 통해 통신이 가능해지면 흥미진진해지고 온갖 환상적인 애플리케이션을 구축할 수 있게 됩니다.
나중에 우리는 내부적으로 해커톤을 개최했고, 몇몇 동료들은 MCP를 사용하여 3D 프린터를 제어할 수 있는 서버를 프로그래밍하고 "메모리 기능"과 같은 확장 기능을 구현했습니다. 프로토타입은 호평을 받았고, 이를 통해 우리는 이 아이디어가 큰 잠재력을 가지고 있다는 확신을 갖게 되었습니다.
swyx(조정자): MCP를 다시 만들어 보면, 우리가 보는 건 최종 제품뿐입니다. 두 분 모두 인정하시듯, 이는 LSP에서 영감을 받은 것이 분명합니다. 건축할 때 작업량은 어느 정도인지 궁금합니다. 빌드 프로세스는 대부분 코딩 대량 인가요, 아니면 대량 디자인 집약적인가요? 저는 디자인 작업이 큰 비중을 점유비율 생각합니다. 예를 들어, JSON-RPC를 선택할 때 LSP를 어느 정도 활용합니까? 어떤 부분이 더 어렵나요?
저스틴 : 저희는 LSP로부터 많은 영감을 얻습니다. 데이비드는 개발 도구 측면에서 LSP에 대한 많은 경험이 있고, 저는 주로 제품이나 인프라 분야에서 일하고 있으며, LSP는 저에게는 새로운 분야입니다.
설계 원칙의 관점에서 볼 때 LSP는 데이비드가 언급한 M x N 문제를 해결합니다. 이전에는 다양한 IDE, 편집기, 프로그래밍 언어가 별개의 개체였습니다. JetBrains의 뛰어난 Java 지원 기능을 Vim에서 사용할 수 없었고, JetBrains의 뛰어난 C 언어 지원 기능도 사용할 수 없었습니다. LSP는 모든 당사자가 공통 언어를 만들어 "소통"할 수 있도록 해줍니다. LSP는 프로토콜을 통합하므로 "편집자 언어"를 한 번만 구현하면 됩니다. 우리의 목표는 비슷하지만, 시나리오는 "AI 애플리케이션-확장" 간의 연결로 바뀌었습니다.
구체적인 세부 사항 측면에서는 JSON-RPC와 양방향 통신의 개념을 채택하여 다른 방향으로 나아갔습니다. LSP는 의미적 원칙보다는 기능적 표현, 사고, 다양한 기본 요소 제공에 초점을 맞추는데, 이는 MCP에도 적용됩니다. 그런 다음 MCP의 각 기본 요소에 대해 대량 시간을 들여 고민하고 그 차이점을 파악하는 데 많은 시간을 투자했습니다. 이는 대량 디자인 작업이었습니다. 처음에는 TypeScript, Python, Rust를 Zed 통합에 지원하고, 클라이언트와 서버가 있는 SDK를 구축하고, 내부 실험 생태계를 육성하고, 기본 MCP 개념(하위 프로세스 실행 등 포함)을 안정화하고자 했습니다.
우리는 LSP에 대한 많은 비판을 고려했고 MCP에서 이를 개선하려고 노력했습니다. 예를 들어, JSON-RPC의 일부 LSP 접근 방식은 너무 복잡했기 때문에 우리는 좀 더 직접적인 구현을 만들었습니다. MCP를 구축할 때 특정 분야에서는 혁신을 추구하고 다른 측면에서는 성숙한 모델을 차용하기로 했습니다 . 예를 들어, JSON-RPC를 선택하는 것은 중요하지 않지만 기본 요소와 같은 혁신에 초점을 맞추는 것이 중요합니다. 이런 측면에서 선배들의 업적으로부터 배우는 것은 우리에게 많은 도움이 됩니다.
swyx(호스트): 저는 프로토콜 설계에 관심이 있고, 여기서 논의할 내용이 많습니다. M x N 문제를 언급하셨습니다. 사실, 개발자 도구를 사용하는 사람이라면 누구나 이 문제를 겪어보았을 텐데요, 이것이 바로 "Universal Box" 문제입니다.
인프라 엔지니어링의 기본적인 문제와 해결책은 많은 것들을 N개의 서로 다른 것들에 연결하여, "범용 상자"를 만드는 것입니다. Uber, GraphQL, 제가 일했던 Temporal, 그리고 React와 같은 회사는 모두 이런 문제를 겪고 있습니다. 궁금한데, 페이스북에 있을 때 N 곱하기 N 문제를 풀어본 적이 있나요?
데이비드: 어느 정도는 그렇습니다. 이것은 좋은 예입니다. 저는 버전 제어 시스템 등에서 이런 종류의 문제를 많이 다루어 왔습니다. 모든 문제를 모든 사람이 읽고 쓸 수 있는 무언가로 통합하고, 이를 해결할 수 있는 "보편적 상자"를 만드는 것입니다. 개발자 도구의 세계에서는 이런 종류의 문제가 어디에나 있습니다.
swyx(진행자): 흥미로운 점은 "범용 박스"를 만드는 사람들이 동일한 문제, 즉 구성 가능성, 원격 및 지역적 문제 등에 직면하게 된다는 것입니다. 저스틴은 기능적 표현의 문제를 언급했습니다. 본질적으로 동일한 것도 있지만, 개념을 명확히 하기 위해 다르게 표현해야 할 필요가 있습니다.
02 MCP의 핵심 개념: 도구, 리소스 및 팁은 필수적입니다.
swyx(호스트): MCP 문서를 읽으면서 이런 의문이 들었습니다. 왜 이 두 가지 사이에 차이가 있어야 할까요? 많은 사람들은 도구 호출을 보편적인 해결책으로 여깁니다. 사실, 도구 호출의 종류에 따라 의미가 다릅니다. 때로는 자원이고, 때로는 운영이고, 때로는 다른 목적을 위한 것입니다. 어떤 개념을 유사한 범주로 묶는지 알고 싶습니다. 왜 그 중요성을 강조하는가?
저스틴 : 저희는 모든 기본 개념을 애플리케이션 개발자의 관점에서 생각해봅니다. IDE, Claude Desktop 또는 Agent 인터페이스 등 애플리케이션을 개발할 때 사용자가 통합을 통해 얻고자 하는 기능은 훨씬 더 명확해질 것입니다. 동시에 도구 호출이 필요하고, 다양한 기능을 구별해야 합니다.
따라서 MCP의 원래 핵심 기본 개념은 나중에 확장되었습니다.
도구 : 핵심입니다. 즉, 모델에 도구를 직접 추가하고 모델이 언제 도구를 호출할지 결정하게 하는 것입니다. 애플리케이션 개발자에게 이는 "함수 호출"과 유사하지만 모델에 의해 시작됩니다.
리소스 : 기본적으로 모델의 컨텍스트에 추가할 수 있고 애플리케이션에서 제어할 수 있는 데이터나 배경 정보를 말합니다. 예를 들어, 모델이 자동으로 관련 리소스를 검색하고 찾아 컨텍스트에 맞게 배치하도록 할 수 있습니다. 또한 드롭다운 메뉴, 종이 클립 메뉴 등을 통해 사용자가 이를 LLM에 전송되는 정보의 일부로 만들 수 있도록 애플리케이션에 명시적인 사용자 인터페이스 기능을 설정할 수도 있습니다. 이는 모두 리소스에 대한 애플리케이션 시나리오입니다.
프롬프트 : 사용자가 의도적으로 시작하거나 대체하는 텍스트나 메시지. 예를 들어, 편집기 환경에 있는 경우 슬래시 명령이나 이와 유사한 자동 완성 기능, 즉 직접 삽입하려는 매크로와 같습니다.
MCP를 통해 우리는 콘텐츠를 표현하는 다양한 방법에 대한 통찰력을 얻었지만, 궁극적으로 결정은 앱 개발자에게 달려 있습니다. 애플리케이션 개발자의 경우, 이러한 개념을 다양한 방식으로 표현하는 것이 매우 유용합니다. 이를 통해 적절한 경험을 결정하고 이를 기반으로 차별화를 만들 수 있습니다. 애플리케이션 개발자의 관점에서 볼 때, 그들은 자신의 애플리케이션이 똑같기를 원하지 않으며, 개방적이고 통합된 생태계에 연결할 때 최상의 경험을 만들기 위한 고유한 관행이 필요합니다.
저는 두 가지 측면이 있다고 생각합니다. 첫 번째 측면은 현재 도구 호출이 통합의 95% 이상을 점유비율 것입니다. 더 많은 고객이 리소스 콜과 프롬프트 콜을 이용하기를 바랍니다. 구현된 첫 번째 기능은 매우 실용적이며 추적 가능한 MCP 서버를 구축할 수 있는 프롬프트 기능입니다. 이는 사용자 중심의 상호작용이며, 사용자는 언제 정보를 가져올지 결정하는데, 이는 모델이 처리될 때까지 기다리는 것보다 낫습니다. 또한 더 많은 MCP 서버에서 도구 사용법을 보여주기 위해 프롬프트를 사용하기를 바랍니다.
반면, 리소스 부분도 큰 잠재력을 가지고 있습니다. 문서, 데이터베이스 및 기타 리소스를 공개하는 MCP 서버와 이를 중심으로 완전한 인덱스를 구축하는 클라이언트를 상상해 보세요. 리소스 콘텐츠가 풍부하기 때문에 모델 기반에서는 노출되지 않으며, 컨텍스트 창에서 실제로 사용할 수 있는 것보다 훨씬 많은 리소스 콘텐츠가 있을 수 있습니다. 앞으로 몇 달 안에 앱들이 이러한 기본 개념을 더 잘 활용하여 더욱 풍부한 경험을 만들어낼 것으로 기대됩니다.
알레시오(진행자): 망치를 들고 있으면 모든 것을 못처럼 여기고 도구를 사용해 모든 문제를 해결하고 싶어합니다. 예를 들어, 많은 사람들이 리소스 호출보다는 데이터베이스 쿼리에 이를 사용합니다. API 인터페이스(예: 데이터베이스)가 있는 경우 도구와 리소스를 사용하는 데 장단점이 무엇인지 궁금합니다 . SQL 쿼리를 수행하기 위해 도구를 사용해야 하는 경우는 언제인가요? 데이터 처리에 리소스를 사용해야 하는 경우는 언제인가요?
저스틴: 도구와 리소스를 구분하는 방법은 도구는 모델에 의해 호출되고, 모델은 적절한 도구를 찾아 적용할지 여부를 스스로 결정한다는 것입니다. LLM이 SQL 쿼리를 실행할 수 있게 하려면 이를 도구로 설정하는 것이 합리적입니다.
리소스 사용은 더 유연하지만, 현재 많은 클라이언트가 이를 지원하지 않기 때문에 상황이 복잡합니다. 이상적으로는 데이터베이스 테이블 구조와 기타 콘텐츠를 리소스를 통해 호출할 수 있습니다. 사용자는 이를 통해 대화를 시작하기 위해 애플리케이션에 관련 정보를 알려주거나, AI 애플리케이션이 자동으로 리소스를 찾도록 할 수 있습니다. 엔터티를 나열하고 읽어야 하는 요구 사항이 있는 한, 이를 리소스로 모델링하는 것이 합리적입니다. 리소스는 URI로 고유하게 식별되며, URI는 사용자가 입력한 URI를 해석하기 위해 MCP 서버를 사용하는 것과 같은 범용 변환기로 간주될 수 있습니다. 예를 들어 Zed 편집기를 살펴보겠습니다. MCP 서버와 상호 작용하여 힌트를 채우는 힌트 라이브러리가 있습니다. 양측 모두 URI와 데이터 형식에 동의해야 합니다. 이는 리소스 적용의 멋진 교차 사례입니다.
애플리케이션 개발자의 관점으로 돌아가서 요구 사항을 생각해 보고 이 아이디어를 실제에 적용해 보겠습니다. 예를 들어, 기존 애플리케이션 기능을 살펴보고 이 접근 방식을 채택할 경우 어떤 기능을 분리하여 MCP 서버에서 구현할 수 있는지 확인하세요. 기본적으로 추가 메뉴가 있는 모든 IDE는 자연스럽게 리소스로 모델링될 수 있습니다. 하지만 이러한 구현은 이미 존재합니다.
swyx(조정자): 네, Claude Desktop에서 @ 기호를 본 순간 이것이 커서와 동일한 기능이라고 생각했고, 이제 다른 사용자도 이 기능을 활용할 수 있게 됐습니다. 이 디자인 목표는 기능 자체가 이미 존재하고 사람들이 쉽게 이해하고 사용할 수 있기 때문에 좋습니다. 저는 그 차트를 보여드렸고 여러분도 그 가치에 동의하셨을 거라고 확신합니다. 저는 그것이 매우 도움이 된다고 생각하고 문서의 첫 페이지에 올려야 한다고 생각합니다. 좋은 제안입니다.
저스틴 : 이에 대해 PR(풀 리퀘스트)을 제출할 의향이 있으신가요? 우리는 이 제안을 정말 좋아해요.
swyx(호스트): 알겠습니다. 제출하겠습니다.
개발자 관계 담당자로서 저는 항상 사람들에게 명확한 지침을 제공하려고 노력합니다. 먼저 핵심 요점을 설명한 다음, 두 시간에 걸쳐 자세히 설명하는 식으로요. 그러니 핵심 내용을 다루는 그림이 있는 게 매우 도움이 됩니다. 프롬프트에 대한 강조에 감사드립니다. ChatGPT와 Claude의 초창기에는 많은 사람들이 GitHub와 비슷한 프롬프트 라이브러리와 프롬프트 관리자 라이브러리를 만들려고 했지만, 실제로 인기를 얻은 사람은 없었습니다.
실제로 이 분야에서는 더 많은 혁신이 필요합니다. 사람들은 프롬프트가 역동적이기를 기대하고, 당신은 그러한 가능성을 제공합니다. 저는 당신이 언급한 다단계 프롬프트의 개념에 전적으로 동의합니다. 이는 때로는 모델을 제대로 실행하기 위해 다단계 프롬프트를 채택하거나 일부 제한을 극복해야 한다는 것을 보여줍니다. 프롬프트는 단순히 단일 대화 입력이 아니라, 때로는 일련의 대화 과정입니다.
swyx(조정자): 리소스와 도구의 개념이 어느 정도 융합되는 지점이 있다고 생각합니다. 때로는 어느 정도 사용자 제어나 애플리케이션 제어가 필요하고, 때로는 모델이 제어하기를 원한다는 점을 언급하셨기 때문입니다. 그렇다면 우리는 단지 도구의 하위 집합을 선택하고 있는 것일까요?
데이비드: 그렇죠. 그럴 만한 우려라고 생각해요. 궁극적으로 이는 MCP의 핵심 설계 원칙이며, 도구 개념은 실제로 도구 자체 그 이상의 것이며 클라이언트 애플리케이션과 긴밀하게 연결되어 있고 나아가 사용자와도 긴밀하게 연결되어 있다는 것입니다. 사용자는 MCP 작동을 완벽하게 제어할 수 있어야 합니다. 도구가 모델에 의해 제어된다는 것은 사용자가 도구 사용을 적극적으로 지정하는 것이 아니라 모델에 의해서만 호출된다는 것을 의미합니다 (물론, 프롬프트 목적의 경우는 예외이지만 이는 일반적인 사용자 인터페이스 기능이 되어서는 안 됩니다).
하지만 저는 클라이언트 애플리케이션이나 사용자가 MCP 서버에서 제공하는 콘텐츠를 필터링하고 최적화하기로 결정하는 것은 완전히 합리적이라고 생각합니다. 예를 들어, 클라이언트 애플리케이션은 MCP 서버에서 도구 설명을 얻고 디스플레이를 최적화할 수 있습니다. MCP 패러다임에 따라 클라이언트 애플리케이션은 모든 것을 완벽하게 제어할 수 있어야 합니다. 또한, 서버 개발자가 팁, 리소스, 도구와 같은 기본 요소를 논리적으로 그룹화할 수 있도록 프로토콜에 기능을 추가하는 초기 아이디어가 있습니다. 이러한 그룹은 서로 다른 MCP 서버로 간주될 수 있으며, 사용자는 필요에 따라 이를 결합할 수 있습니다.
03 MCP와 OpenAPI: 경쟁인가 보완인가?
swyx(호스트): MCP와 Open API를 비교해서 말씀드리고 싶습니다 . 결국, 이는 모든 사람이 매우 우려하는 문제 중 하나임이 분명합니다.
저스틴 /데이비드: 근본적으로 오픈 API 사양은 제가 API와 클라이언트를 개발할 때 자주 사용하는 매우 강력한 도구입니다. 그러나 대규모 언어 모델(LLM)의 적용 시나리오에 대한 오픈 API 사양은 너무 자세하여 방금 언급한 MCP의 기본 개념과 애플리케이션 개발자의 사고 방식과 같은 상위 수준의 AI 특정 개념을 완전히 반영하지 못합니다. 모델은 단순히 REST API를 제공하고 마음껏 실행하기보다는, 모델에 맞게 특별히 설계된 도구, 리소스, 팁 및 기타 기본 개념을 통해 더 많은 이점을 얻습니다.
반면에 MCP 프로토콜을 설계할 때 우리는 의도적으로 그것을 상태 저장형으로 만들었습니다. 이는 AI 애플리케이션과 상호작용이 본질적으로 더 상태 저장적이기 때문입니다. 무상태 방식은 어느 정도 항상 자리를 차지하겠지만, 상호작용 모드(예: 비디오, 오디오 등)가 계속 증가함에 따라 상태 저장 방식이 점점 더 대중화될 것이므로 상태 저장 프로토콜이 특히 유용해질 것입니다.
사실, 오픈 API와 MCP는 모순되는 것이 아니라 상호 보완적입니다. 그들은 각자 고유한 장점을 가지고 있으며 서로 매우 상호 보완적입니다. 저는 특정 작업에 가장 적합한 도구를 선택하는 것이 중요하다고 생각합니다. AI 애플리케이션 간의 풍부한 상호작용을 구현하는 것이 목표 라면 MCP가 더 적합합니다. 모델이 API 사양을 쉽게 읽고 해석할 수 있게 하려면 개방형 API가 더 나은 선택이 될 것입니다. 두 가지 사양을 연결하는 초기 단계의 노력이 진행 중이며, 공개 API 사양을 MCP로 변환하여 공개하고, 반대로 MCP 사양을 공개 API 사양으로 변환하여 공개하는 도구를 통해 두 사양을 연결하는 작업이 진행 중인데, 이는 매우 좋은 일입니다.
알레시오(호스트): 저는 AGI 스튜디오에서 해커톤을 공동 주최했습니다. 개인 에이전트 개발자로서, 저는 누군가가 MCP 서버를 생성할 수 있는 개인 에이전트를 만드는 것을 봤습니다. API 사양의 URL만 입력하면 해당 MCP 서버를 생성할 수 있습니다. 이런 현상에 대해 어떻게 생각하시나요? 이는 대부분의 MCP 서버가 별다른 독특한 설계 없이 기존 API 위에 계층을 하나 더 추가한 것일 뿐이라는 뜻인가요? 미래는 항상 지금과 같이 AI를 주로 사용하여 기존 API에 연결하는 방식이 될까요 ? 아니면 완전히 새롭고 전례 없는 MCP 경험이 될까요?
저스틴 /데이비드: 둘 다라고 생각해요. 한편, "커넥터를 통해 애플리케이션으로 데이터를 가져온다"와 같은 요구 사항은 항상 가치가 있습니다. 현재는 도구 호출이 기본에 가깝지만, 앞으로는 다른 기본 개념이 이런 유형의 문제를 해결하는 데 더 적합할 수도 있습니다. 여전히 커넥터나 어댑터 계층이라 할지라도, 다양한 개념을 적용하면 가치를 높일 수 있습니다.
반면, 어댑터 이상의 역할을 하는 MCP 서버를 구축하면 흥미로운 사용 사례에 대한 실질적인 기회가 있습니다. 예를 들어, 메모리 MCP 서버를 사용하면 LLM이 여러 대화에서 정보를 기억할 수 있습니다. 순차적 사고를 하는 MCP 서버는 모델의 추론 능력을 향상시킬 수 있습니다. 이러한 서버는 외부 시스템과 통합하는 대신, 모델에 대한 완전히 새로운 사고방식을 제공합니다.
그럼에도 불구하고 AI를 사용하여 서버를 구축하는 것은 완전히 가능합니다. 구현해야 할 기능이 다른 API를 적용한 것이 아니라 독창적인 것이라 하더라도, 일반적으로 모델은 이를 구현할 방법을 찾을 수 있습니다. 실제로 많은 MCP 서버는 API 래퍼가 될 것입니다. 이는 합리적이고 효과적이며 많은 진전을 이루는 데 도움이 될 수 있습니다. 하지만 우리는 아직 탐색 단계에 있으며 끊임없이 무엇이 가능한지 탐구하고 있습니다.
이러한 기본 개념에 대한 고객 지원이 향상됨에 따라 더욱 풍부한 경험이 제공될 것입니다. 예를 들어, "Reddit 섹션의 내용을 요약"할 수 있는 MCP 서버는 아직 구축되지 않았지만 프로토콜 자체는 완전히 실행 가능합니다. 사람들의 요구가 "저는 제가 관심 있는 것들을 LLM에 연결하고 싶을 뿐입니다"에서 "저는 모델과 깊이 상호작용할 수 있는 더욱 풍부한 경험과 실제 워크플로를 원합니다"로 바뀌면 이러한 혁신적인 애플리케이션이 등장하게 될 것이라고 생각합니다. 하지만 현재 클라이언트가 지원하는 기능과 서버 개발자가 구현하려는 기능 사이에 "닭과 달걀" 문제가 있습니다.
04 AI 프로그래밍을 활용한 MCP 서버 빠른 구축 방법
알레시오(진행자): 사람들이 덜 논의하는 MCP의 또 다른 측면이 있다고 생각하는데, 바로 서버 구성입니다. MCP 서버 구축을 시작하려는 개발자에게 어떤 조언을 해주시겠습니까? 서버 개발자로서, 모델이 이해할 수 있도록 자세한 설명을 제공하는 것과 모델이 자동으로 처리할 수 있도록 원시 데이터를 직접 얻는 것 사이에서 가장 적절한 균형을 어떻게 찾으시나요?
저스틴 /데이비드: 몇 가지 제안이 있어요. MCP의 장점 중 하나는 약 30분 정도면 구축할 수 있는 간단한 기능을 매우 쉽게 만들 수 있다는 점입니다. 완벽하지는 않지만 기본적인 요구 사항을 충족시키기에 충분합니다. 시작하는 가장 좋은 방법은 원하는 프로그래밍 언어를 선택하고 SDK가 있다면 사용하는 것입니다. 모델이 상호작용할 수 있는 도구를 만드세요. MCP 서버를 설정합니다. 서버에 도구를 추가합니다. 도구에 대한 간략한 설명을 작성하세요. 표준 입력 및 출력 프로토콜을 통해 원하는 애플리케이션에 연결합니다. 그리고 모델이 그것을 어떻게 활용할 수 있는지 살펴보겠습니다.
개발자에게 자신이 관심 있는 분야에서 모델이 작동하는 모습을 빠르게 볼 수 있다는 것은 매우 매력적이며 열정을 불러일으켜 다른 도구, 리소스, 팁이 무엇인지, 성능을 평가하고 팁을 최적화하는 방법에 대해 깊이 생각하게 만듭니다. 이는 시간이 지남에 따라 탐구할 수 있는 과정이지만, 간단한 것부터 시작해서 모델이 관심 있는 것과 어떻게 상호 작용하는지 보는 것도 재미있습니다. MCP는 개발을 즐겁게 만들고 모델을 빠르게 유용하게 만들어줍니다.
저는 또한 AI 지원 코딩을 활용하는 데 관심이 있습니다. 개발 초기 단계에서 우리는 MCP SDK의 코드 조각을 LLM의 컨텍스트 창에 넣고 LLM이 서버를 빌드하는 데 도움을 줄 수 있다는 것을 발견했습니다. 결과는 대개 매우 좋았고, 세부 사항은 나중에 더욱 최적화될 수 있었습니다. 이는 기본 기능을 빠르게 구현하고 반복하는 좋은 방법입니다. 처음부터 우리는 LLM이 참여할 수 있도록 서버 구축 프로세스를 단순화하는 데 중점을 두었습니다. 지난 몇 년 동안 MCP 서버를 시작하는 데에는 100~200줄의 코드만 필요했는데, 정말 쉬웠습니다. 기성 SDK가 없는 경우 모델에 관련 사양이나 다른 SDK를 제공하여 일부 기능을 구축하는 데 도움을 받을 수도 있습니다. 일반적으로 자신이 좋아하는 언어로 도구 호출을 하는 것도 꽤 간단합니다.
알레시오(조정자): 제가 보기에 서버 빌더는 최종적으로 반환되는 데이터의 형식과 내용을 크게 결정합니다. 예를 들어, Google Maps와 같은 도구 호출의 경우 어떤 속성이 반환되는지는 빌더에 의해 결정됩니다. 속성이 누락되면 사용자는 해당 속성을 재정의하거나 수정할 수 없습니다. 이는 일부 SDK에 대한 저의 불만 중 하나와 비슷합니다. 사람들이 API를 래핑하는 SDK를 빌드할 때 API가 추가하는 매개변수를 생략하면 해당 새로운 기능을 사용할 수 없습니다. 이 문제에 대해 어떻게 생각하시나요? 사용자는 얼마나 개입해야 할까요, 아니면 전적으로 서버 설계자에게 달려 있을까요?
저스틴 /데이비드: 구글 맵 예시와 관련해서는, 우리가 출시한 참조 서버이기 때문에 어느 정도 책임이 있을 겁니다. 일반적으로, 적어도 현재로서는 도구 호출 결과를 구조화된 JSON 데이터가 아니거나 특정 패턴과 일치하지 않도록 의도적으로 설계하고 있으며, LLM에 직접 입력할 수 있는 텍스트나 이미지와 같은 메시지 형태로 표시되도록 설계하고 있습니다. 즉, 우리는 대량 의 데이터를 반환하고 LLM이 이를 걸러내고 관심 있는 정보를 클레임 신뢰하는 경향이 있습니다. 우리는 모델이 필요한 정보를 얻을 수 있는 유연성을 제공하기 위해 많은 노력을 기울였습니다. 그것이 이 모델의 장점이기 때문입니다. 우리는 모델이 개선됨에 따라 확장이 어려워지는 것을 피하면서 지나치게 제한적이거나 규범적이지 않으면서도 LLM의 잠재력을 최대한 활용하는 방법에 대해 생각합니다. 따라서 예시 서버에서 이상적인 상태는 모든 결과 유형이 호출된 API에서 그대로 직접 전달되고, API가 자동으로 데이터를 전달하는 것입니다.
알레시오(진행자): 선을 어디에 그을지 결정하는 건 정말 어려운 결정이에요.
데이비드: 여기서 AI의 역할을 강조해야 할 것 같습니다. 놀랍지 않게도, 예시 서버 중 대부분은 클로드가 작성했습니다. 현재 사람들은 문제를 해결하기 위해 전통적인 소프트웨어 엔지니어링 방법을 사용하는 데 익숙해져 있지만, 실제로는 LLM을 위한 시스템을 구축하는 방법을 다시 배우고 그 역량을 신뢰해야 합니다. LLM이 매년 상당한 진전을 이루고 있으므로, 이제는 데이터 처리 작업을 해당 분야에 능숙한 모델에 맡기는 것이 현명한 선택입니다. 이는 우리가 지난 20년, 30년, 심지어 40년 동안의 전통적인 소프트웨어 엔지니어링 관행을 폐기해야 할 수도 있다는 것을 의미합니다.
다른 관점에서 MCP를 살펴보면, AI의 발전 속도는 놀랍습니다. 흥미롭기도 하고 조금은 걱정스럽기도 합니다. 모델 기능 향상의 다음 단계에선 가장 큰 병목 현상이 외부 데이터 소스를 읽고 상태 저장 작업을 수행하는 등 외부 세계와 상호 작용하는 기능일 수 있습니다 . Anthropic에서 일할 때 우리는 안전한 상호작용을 매우 중요하게 여기며 그에 따라 통제와 보정을 시행합니다. AI가 발전함에 따라 사람들은 모델이 이러한 기능을 갖기를 기대하게 될 것이며, 모델을 외부 세계에 연결하는 것은 AI 생산성을 개선하는 데 중요합니다. MCP는 또한 미래의 방향과 그 중요성에 대한 우리의 베팅입니다.
알레시오(조정자): 맞습니다. "포맷됨"이라는 단어가 포함된 모든 API 속성을 제거해야 한다고 생각합니다. 모든 인터페이스에서 원시 데이터를 얻어야 합니다. 왜 미리 포맷해야 하나요? 이 모델은 주소와 같은 정보를 스스로 형식화할 만큼 충분히 똑똑합니다. 그러므로 이 부분은 최종 사용자가 결정해야 합니다.
05 MCP가 더 많은 도구를 호출하도록 개선하려면 어떻게 해야 하나요?
swyx(호스트): 또 다른 질문을 하고 싶습니다. MCP 구현은 몇 개의 관련 기능을 지원할 수 있습니까? 여기에는 폭과 깊이의 문제가 포함되며, 방금 논의한 MCP 중첩과 직접적인 관련이 있습니다.
클로드가 2024년 4월에 최초로 백만 개의 토큰 컨텍스트 사례를 출시했을 때 250개의 도구를 지원할 수 있다고 밝혔지만, 많은 실제 상황에서 이 모델은 그렇게 많은 도구를 효과적으로 사용할 수 없습니다. 어떤 의미에서 이것은 폭의 문제입니다. 도구를 호출하는 도구가 없고, 모델과 도구의 평평한 계층 구조만 있기 때문에 도구에 대해 혼란스러워하기 쉽습니다. 여러 도구가 비슷한 기능을 가지고 있는 경우, 모델이 잘못된 도구를 호출하여 만족스럽지 못한 결과를 초래할 수 있습니다. 특정 시점에 활성화할 수 있는 MCP 서버의 최대 수에 대한 권장 사항이 있습니까?
저스틴: 솔직히 말해서, 이 질문에 대한 절대적인 답변은 없습니다. 한편으로는 사용하는 모델에 따라 달라지고, 다른 한편으로는 모델을 정확하게 이해하고 혼란을 피할 수 있을 만큼 도구의 이름과 설명이 충분히 명확한지 여부에 따라 달라집니다. 가장 이상적인 상황은 모든 정보를 LLM에 제공하는 것입니다. 그러면 LLM에서 모든 것을 완벽하게 처리해 줄 것입니다. 이는 또한 MCP가 구상하는 미래 청사진입니다. 하지만 실제 애플리케이션에서는 클라이언트 애플리케이션(즉, AI 애플리케이션)이 도구 세트를 필터링하거나, 규모가 작고 빠른 LLM을 사용하여 가장 관련성 있는 도구를 필터링한 후 대규모 모델에 전달하는 등의 보충 작업을 수행해야 할 수도 있습니다. 또는 일부 MCP 서버를 다른 MCP 서버의 프록시로 설정하여 필터링할 수 있습니다.
적어도 클로드에게는 수백 개의 도구를 지원하는 것이 안전한 선택입니다. 그러나 다른 모델의 상황은 아직 불확실합니다. 시간이 지나면서 상황은 나아질 것이므로, 이러한 진전을 방해하지 않도록 제한 조치를 신중하게 취해야 합니다. 지원할 수 있는 도구의 수는 설명의 중복 정도에 따라 크게 달라집니다. 서버의 기능이 뚜렷하고 도구 이름과 설명이 명확하고 고유한 경우, 유사한 기능을 갖춘 서버(예: GitLab과 GitHub 서버에 모두 연결하는 서버)보다 지원되는 도구 수가 더 많을 수 있습니다.
또한 이는 AI 응용 프로그램의 유형에 따라서도 달라집니다. 고도로 지능적인 애플리케이션을 구축하는 경우 사용자에게 묻는 질문의 양과 인터페이스의 구성 가능성을 줄이는 것이 좋습니다. 하지만 IDE나 채팅 앱 같은 것을 만들 때 사용자가 항상 모든 기능을 활성화하기보다는 원하는 기능 세트를 원하는 대로 선택할 수 있도록 하는 것이 매우 합리적입니다.
swyx(호스트): 마지막으로 Sequential Thinking MCP Server 에 대해 살펴보겠습니다 . 이 플러그인은 분기 기능과 "더 많은 쓰기 공간"을 제공하는 기능을 가지고 있는데, 매우 흥미롭습니다. 또한, Anthropic은 지난주 Thinking Tool을 소개하는 새로운 엔지니어링 블로그를 게시했고, 커뮤니티에서는 Sequential Thinking Server와 이 Thinking Tool 사이에 중복이 있는지에 대한 혼란이 있었습니다. 실제로는 서로 다른 팀이 서로 다른 방식으로 비슷한 일을 하는 것일 뿐이며, 결국 이를 구현하는 방법도 다양합니다.
저스틴/데이비드: 제가 아는 한, 순차적 사고 서버는 Anthropic의 사고 도구와 직접적으로 공통된 기원을 가지고 있지 않습니다. 하지만 이는 일반적인 현상을 반영합니다. LLM이 더 신중하게 생각하고, 환상을 줄이며, 다른 목표를 달성하기 위해 여러 차원에서 효과를 보다 완전하고 신뢰할 수 있게 입증할 수 있는 다양한 전략이 있습니다. MCP의 힘은 바로 이것입니다. 다양한 기능을 달성하기 위해 서로 다른 서버를 구축하거나, 동일한 서버에 서로 다른 제품이나 도구를 설정할 수 있으며, 이를 통해 LLM은 특정한 사고 패턴을 적용하여 다양한 결과를 얻을 수 있습니다.
따라서 LLM에 대한 이상적이고 규정된 사고방식은 존재하지 않습니다.
swyx(호스트): 제 생각에는 애플리케이션마다 용도가 다르고, MCP를 사용하면 이런 다양성을 구현할 수 있지 않나요?
저스틴/데이비드: 정확히 그거죠. 저는 일부 MCP 서버가 취하는 접근 방식이 단지 당시 모델 자체의 성능에 부족한 부분을 메우는 것일 뿐이라고 생각합니다. 모델의 학습, 준비, 연구에는 점진적으로 모델의 성능을 개선하는 데 대량 시간이 걸립니다. 예를 들어 Sequential Thinking Server를 살펴보겠습니다. 간단해 보일지 몰라도, 그렇지 않고 며칠 만에 만들 수도 있습니다. 하지만 이런 복잡한 사고 기능을 모델에 직접 구현하려면 며칠 만에 완료할 수 있는 일은 절대 아닙니다.
예를 들어, 제가 사용하는 모델이 그다지 신뢰할 만하지 않거나, 누군가 현재 모델에서 생성된 결과가 전반적으로 신뢰할 만하지 않다고 느낀다면, 모델이 쿼리에 대해 세 가지 결과를 생성한 다음 가장 좋은 결과를 선택하도록 하는 MCP 서버를 구축하는 것을 상상할 수 있습니다. MCP를 사용하면 이러한 재귀적이고 구성 가능한 LLM 상호작용을 구현할 수 있습니다.
06 복합 MCP와 Agent의 차이점은 무엇인가요?
알레시오(호스트): 다음으로 구성 가능성에 대한 질문을 드리고 싶습니다. 한 MCP를 다른 MCP에 도입하는 개념에 대해 어떻게 생각하시나요? 이에 대한 계획이 있나요? 예를 들어, Reddit 스레드의 내용을 요약하는 MCP를 빌드하려면 Reddit API 에 응답하는 MCP 와 요약 기능을 제공하는 MCP를 호출해야 할 수 있습니다. 그렇다면, 어떻게 그런 "슈퍼 MCP"를 만들 수 있을까?
저스틴 /데이비드: 이건 매우 흥미로운 주제이고 두 가지 측면에서 볼 수 있습니다.
한편, 요약 함수와 같은 구성 요소를 만드는 것을 고려해보세요 . LLM을 호출할 수는 있지만 특정 모델에 구애받지 않기를 바랍니다. 여기에는 MCP의 양방향 커뮤니케이션 기능이 포함됩니다. 예를 들어 Cursor는 LLM과의 상호작용 루프를 관리합니다. 서버 개발자는 커서를 사용하여 클라이언트(사용자가 있는 애플리케이션)에 특정 작업을 수행하도록 요청할 수 있습니다. 예를 들어, 클라이언트에게 사용자가 현재 선택한 모델을 사용하여 요약하고 결과를 반환하도록 요청하는 것입니다. 이런 방식으로 요약 모델의 선택은 커서에 따라 달라지며, 개발자는 서버 측에 추가적인 SDK나 API 키를 도입할 필요가 없어 특정 모델에 독립적인 구성을 얻을 수 있습니다.
반면, MCP를 사용하면 더욱 복잡한 시스템을 구축하는 것도 가능합니다 . Cursor나 Windsurf와 같은 서비스를 지원하고, 동시에 MCP 클라이언트 역할도 하면서 다른 MCP 서버를 호출하여 더욱 풍부한 경험을 만들어내는 MCP 서버를 상상해 보세요. 이는 재귀적 성격을 반영하며, 이 패턴은 사양 승인과 같은 측면에도 반영됩니다. 서버와 클라이언트 역할을 하는 이러한 애플리케이션을 직렬로 연결할 수 있으며, MCP 서버를 사용하여 DAG(Directed Acycle Graph)를 구축하여 복잡한 상호 작용 프로세스를 구현할 수도 있습니다. 스마트 MCP 서버는 전체 MCP 서버 생태계의 기능을 활용할 수도 있습니다. 사람들은 이미 이와 관련된 실험을 수행했습니다. 자동 선택 및 설치와 같은 기능을 고려한다면 실현 가능한 가능성은 매우 많습니다.
현재, 우리 SDK는 개발자가 클라이언트이자 재귀적 MCP 서버인 애플리케이션을 더 쉽게 구축하거나 여러 MCP 서버의 동작을 보다 편리하게 재사용할 수 있도록 더 많은 세부 정보를 추가해야 합니다. 이러한 사항은 향후 개선이 필요하지만, 현재 가능하지만 아직 널리 채택되지 않은 몇 가지 응용 시나리오를 이미 보여줄 수 있습니다.
swyx(진행자): 매우 흥미로운 내용인 것 같습니다. 많은 사람이 여기에서 많은 아이디어와 영감을 얻을 수 있을 거라고 믿습니다. 그렇다면 서버이자 클라이언트인 이 MCP를 에이전트로 볼 수 있을까요? 어떤 의미에서 에이전트란 요청을 보내면 사용자가 완전히 알지 못하는 저수준 작업을 수행하는 것을 말합니다. 원시 데이터의 최종 출처와 사용자 사이에는 추상화 계층이 있습니다. Agent에 대한 독특한 통찰력이 있나요?
저스틴 /데이비드: MCP 방식을 통해 에이전트를 구축하는 것이 실제로 가능하다고 생각합니다. 여기서 구별해야 할 점은 MCP 서버와 클라이언트가 단순한 에이전트인 경우와 실제 에이전트인 경우의 차이입니다. 예를 들어, MCP 서버 내에서 클라이언트가 제공한 샘플 루프를 사용하여 경험을 풍부하게 하고 모델이 도구를 호출하여 실제 에이전트를 빌드하도록 할 수 있습니다. 이 건설 방법은 비교적 간단합니다.
MCP와 Agent 간의 관계에 관해서는 여러 가지 생각 방식이 있습니다.
첫째, MCP는 에이전트의 역량을 표현하는 좋은 방법일 수 있지만, 현재 사용자 상호작용 경험을 향상시킬 수 있는 일부 기능이나 함수가 부족할 수 있습니다. 이는 MCP 프로토콜에 포함하는 것이 좋습니다.
두 번째로, MCP는 에이전트를 구축하거나 다양한 에이전트가 서로 결합할 수 있도록 하는 기본 통신 계층으로 사용될 수 있습니다. 물론, MCP가 Agent 개념 자체에 너무 집중하기보다는 AI 애플리케이션의 통합에 더 집중해야 한다고 믿는 것과 같은 다른 가능성도 있습니다. 이는 여전히 진행 중인 논의이며, 각 방향에는 장단점이 있습니다. "범용 상자" 비유로 돌아가서, 프로토콜을 설계하고 생태계를 관리할 때 지나치게 복잡한 기능을 피하고 프로토콜이 모든 것을 포함하려고 하지 않도록 특히 주의해야 합니다. 그렇지 않으면 모든 측면에서 성능이 저하될 수 있습니다. 핵심 질문은 에이전트가 기존 모델과 패러다임 프레임 에 어느 정도 자연스럽게 통합될 수 있는지, 아니면 어느 정도 독립적인 개체로 존재해야 하는지인데, 이는 여전히 해결되지 않은 문제입니다.
swyx(조정자): 양방향 통신이 이루어지면 클라이언트와 서버가 하나로 결합되고, 작업을 다른 MCP 서버로 위임할 수 있어 에이전트와 더욱 유사해진다고 생각합니다. 여러분이 단순함을 염두에 두고 모든 문제를 해결하려고 하지 않는다는 점에 감사드립니다.
07 MCP의 다음 단계 : 프로토콜을 더 안정적으로 만드는 방법?
swyx(호스트): 최근 상태 저장 서버에서 상태 비저장 서버로의 업데이트가 많은 사람들의 관심을 끌었습니다. 게시 프로토콜 및 전송 수단으로 SSE(Server-Sent Events)를 선택하고, 플러그형 전송 계층을 지원하게 된 이유는 무엇입니까? 이 작품은 제러드 팔머 의 트윗 에 영향을 받은 것인가요 , 아니면 이미 기획 중이었나요?
저스틴 /데이비드: 그렇지 않아요. 우리는 몇 달 전 GitHub에서 Statefulness와 Stateless의 딜레마에 대해 공개적으로 논의했으며 장단점 을 따져보았습니다. 우리는 AI 애플리케이션, 생태계, 에이전트의 미래 개발 방향이 Statefulness가 될 것이라고 믿습니다 . 이는 MCP 핵심 팀 내에서 가장 논란이 많은 주제 중 하나였으며 많은 논의와 반복을 거쳤습니다. 최종 결론은 우리가 Statefulness의 미래에 대해 낙관적이기는 하지만 기존 패러다임에서 벗어날 수 없으며 Statefulness의 개념과 실제 운영의 복잡성 사이에서 균형을 찾아야 한다는 것입니다. MCP 서버가 장기간 연속 연결을 유지해야 하는 경우 배포 및 운영이 매우 어려울 것입니다. 원래 SSE 전송 설계는 MCP 서버를 배포하고 클라이언트가 서버에 연결하여 거의 무한정으로 연결 상태를 유지할 수 있다는 아이디어를 기반으로 했습니다. 이는 대규모 운영이 필요한 모든 사람에게 높은 요구 사항이었고 이상적인 배포 또는 운영 모델이 아니었습니다.
따라서 우리는 상태 저장의 중요성과 운영 및 유지 관리의 용이성 사이의 균형을 맞추는 방법에 대해 고민합니다. SSE를 포함한 스트리밍 HTTP 전송의 도입은 점진적으로 이루어지도록 설계되었습니다. 서버는 일반 HTTP 서버가 될 수 있으며, 결과는 HTTP POST 요청을 통해 얻습니다. 그런 다음 기능을 점진적으로 향상시켜, 예를 들어 결과 스트리밍을 지원하거나 심지어 서버가 클라이언트에 사전에 요청을 할 수 있도록 할 수도 있습니다. 서버와 클라이언트가 세션 재개(즉, 연결이 끊긴 후 다시 연결하여 전송을 계속하는 것)를 지원하는 한, 상태 저장 상호작용을 고려하면서 편리하게 확장할 수 있으며, 네트워크 불안정성 및 기타 조건에 더 잘 대처할 수 있습니다.
Alessio(호스트): 네, 세션 ID도 포함됩니다. 신원 확인의 미래에 대한 계획은 무엇입니까? 현재 일부 MCP의 경우 명령줄에 API 키만 붙여넣으면 됩니다 . 미래의 개발 방향은 무엇이라고 생각하시나요? 인증 정보를 관리하기 위한 MCP 전용 구성 파일이 있을까요?
저스틴 /데이비드: 우리는 이미 프로토콜의 다음 초안 개정판에 인증 사양을 포함시켰습니다. 현재는 OAuth 2.1이나 최신 하위 집합을 이용한 사용자-서버 인증에 주로 중점을 두고 있습니다. 이런 접근 방식은 효과적이며, 사람들은 이를 바탕으로 발전해 나가고 있습니다. 이렇게 하면 많은 문제를 해결할 수 있습니다. 특히 앞으로 대부분의 서버가 원격 서버가 되고 서버 간에 보안 인증이 필요하다는 점을 고려하면, 사용자가 API 키를 무심코 붙여넣는 일은 원치 않을 것이기 때문입니다.
로컬 환경에서는 권한 정보가 전송 계층에서 정의되므로 데이터 프레임 캡슐화(요청 헤더 설정)가 필요하고 표준 입력 및 출력(stdin/stdout)을 직접 구현할 수 없습니다. 그러나 표준 입력 및 출력을 사용하는 프로그램을 로컬에서 실행하는 경우 매우 유연하며 브라우저를 열어서 인증 프로세스를 처리할 수도 있습니다. 로컬에서 권한 부여를 위해 HTTP를 사용할지 여부는 아직 완전히 결정되지 않았습니다. 저스틴은 이를 지지하는 경향이 있지만, 저는 개인적으로 이에 동의하지 않으며 논란의 여지가 있습니다.
권한 부여 설계와 관련하여, 저는 계약의 다른 내용과 마찬가지로, 우리는 매우 간결하게 작성하고, 실제적인 문제점을 해결하고, 기능을 최대한 단순화한 다음, 실제적인 요구와 문제점에 따라 점진적으로 확장하여 과도한 설계를 피하려고 노력한다고 생각합니다. 프로토콜을 설계할 때는 많은 주의가 필요합니다. 실수가 한 번 발생하면 기본적으로 되돌릴 수 없고 이전 버전과의 호환성도 손상되기 때문입니다. 따라서 신중하게 고려되고 검증된 기능만 수용하거나 추가하고, 특정 기능을 핵심 프로토콜에 추가해야 한다는 데 대한 광범위한 합의가 이루어질 때까지 확장 메커니즘을 통해 커뮤니티에서 일시적으로 해당 기능을 시험해 볼 수 있도록 하는 것이 더 쉽고 안정적입니다. 또한, 향후에도 지속적인 지원을 제공할 수 있습니다.
권한 부여와 API 키를 예로 들면서 우리는 대량 브레인스토밍을 했습니다. 현재의 인증 방식(OAuth 2.1 하위 집합)은 이미 API 키의 사용 시나리오를 충족할 수 있습니다. MCP 서버는 OAuth 인증 서버 역할을 하며 관련 기능을 추가할 수 있지만, "/authorize" 페이지를 방문하면 API 키를 입력할 수 있는 텍스트 상자만 제공될 수 있습니다. 이것이 가장 이상적인 접근 방식은 아닐지 몰라도, 기존 모델에 적합하고 현재로서는 실행 가능합니다. 우리는 추가 옵션을 너무 많이 추가하면 클라이언트와 서버 모두 더 많은 사례를 고려하고 구현해야 하며, 이로 인해 복잡성이 증가할 것이라는 점이 우려되었습니다.
알레시오(진행자): 범위의 개념에 대해 생각해 본 적이 있나요? 어제 우리는 Agent.ai의 창립자인 Dharmesh Shah 와 함께 에피소드를 진행했습니다 . 그는 이메일에 대한 예를 들었습니다. 그는 자신의 모든 이메일을 소유하고 있으며 "이 유형의 이메일에만 접근할 수 있습니다" 또는 "이 사람에게 보낸 이메일에만 접근할 수 있습니다"와 같이 더 세분화된 범위 제어를 원합니다. 오늘날 대부분의 범위는 일반적으로 REST API 디자인, 즉 액세스할 수 있는 특정 엔드포인트를 기반으로 합니다. 향후 모델에서 Scopes 계층을 이해하고 활용하여 전송되는 데이터를 동적으로 제한하는 것이 가능할 것이라고 생각하시나요?
저스틴 /데이비드: 우리는 스코프에 대한 잠재적 필요성이 있다는 것을 알고 있으며 이에 대해 논의했지만, 프로토콜에 추가하는 데는 매우 신중해야 합니다 . 우리의 기준은 먼저 현재 구현으로는 해결할 수 없는 실질적인 문제를 찾은 다음, MCP 구조의 확장성을 기반으로 프로토타입을 구축하고, 이것이 좋은 사용자 경험을 가져올 수 있다는 것을 증명한 후에야 공식적으로 프로토콜에 통합하는 것을 고려하는 것입니다. 인증의 경우는 다릅니다. 인증은 상향식으로 설계되었습니다.
우리는 범위에 대한 설명을 들을 때마다 그것이 합리적이라고 생각하지만, 현재 구현의 단점을 명확히 하기 위해서는 구체적인 엔드투엔드 사용자 사례가 필요하며, 이를 통해 더 자세히 논의할 수 있습니다. 구성 가능성과 논리적 그룹화의 설계 개념을 고려할 때 일반적으로 MCP 서버는 비교적 작게 설계하는 것이 좋습니다. 대량 기능을 독립적이고 분리된 서버에서 구현한 다음 애플리케이션 계층에서 결합하는 것이 가장 좋습니다. 일부 사람들은 이의를 제기하며, 단일 서버가 여러 서비스의 권한 부여 작업을 수행하는 것에 찬성하지 않았습니다. 그들은 이러한 서비스 자체가 자체의 독립된 서버에 대응해야 하며, 이후 애플리케이션 수준에서 결합되어야 한다고 믿었습니다.
08 MCP 서버 배포의 보안 이슈
알레시오(진행자): 저는 MCP의 훌륭한 디자인 중 하나가 프로그래밍 언어의 독립성이라고 생각합니다. 제가 아는 한, Anthropic에는 공식 Ruby SDK가 없고 OpenAI에도 마찬가지입니다. Alex Rudall과 같은 개발자가 이러한 툴킷을 만드는 데 훌륭한 일을 했지만 MCP를 사용하면 더 이상 각 프로그래밍 언어에 맞게 SDK를 조정할 필요가 없고 Anthropic에서 인식하는 표준 인터페이스만 만들 수 있다는 점이 더욱 훌륭합니다.
swyx(호스트): MCP 레지스트리에 관해서는 현재 5~6개의 레지스트리가 있으며, 당초 공식 발표에 따르면 레지스트리는 운영을 중단한 것으로 알려졌습니다. 다운로드, 좋아요, 리뷰, 신뢰 메커니즘 등을 제공하는 등록 센터의 서비스 모델은 기존 소프트웨어 패키지 저장소(예: npm 또는 PyPI)와 쉽게 비슷하지만, 이로 인해 신뢰할 수 없다는 느낌이 듭니다. 사회적 증거가 있더라도 다음 업데이트로 인해 이전에 신뢰했던 패키지가 보안 위협에 노출될 수 있습니다. 이런 종류의 신뢰 체계의 남용은 신뢰 체계 자체가 신뢰 체계 자체에 의해 손상되는 것처럼 느껴집니다. 따라서 저는 사람들에게 MCP Inspector를 사용하도록 권장하고 싶습니다. 왜냐하면 통신 트래픽만 확인하면 되고, 이런 방식으로 많은 보안 문제를 발견하고 해결할 수 있기 때문입니다. 레지스트리의 보안 문제와 공급망 리스크 어떻게 생각하시나요?
저스틴 /데이비드: 네, 정말 맞는 말씀이에요. 이는 모든 레지스트리가 직면할 가능성이 있는 전형적인 공급망 보안 문제입니다. 업계에서는 이 문제에 대한 다양한 해결책이 있습니다. 예를 들어, Apple의 App Store와 유사한 모델을 채택하여 소프트웨어를 엄격하게 검토하고, 자동화된 시스템과 수동 검토팀을 구성하여 이 작업을 완료할 수 있습니다. 이는 실제로 이러한 유형의 문제를 해결하는 방법이며 특정 시나리오에서는 실행 가능합니다. 하지만 저는 이 모델이 오픈소스 생태계에는 그다지 적용되지 않을 수 있다고 생각합니다. 오픈소스 생태계는 일반적으로 MCP 레지스트리, npm 패키지 관리자, PyPI(Python 패키지 인덱스)와 같은 탈중앙화 또는 커뮤니티 중심 접근 방식을 채택하기 때문입니다.
swyx(호스트): 이러한 창고는 본질적으로 공급망 공격 문제에 직면해 있습니다. 공식 코드 기반으로 출시된 몇몇 핵심 서버, 특히 메모리 서버와 추론/사고 서버와 같은 특수 서버. 이러한 기능은 기존 API를 감싸는 단순한 래퍼가 아닌, API를 직접 조작하는 것보다 사용하기 편리할 수 있습니다.
메모리 서버를 예로 들어 보겠습니다. 시장에는 메모리 기능에 초점을 맞춘 몇몇 스타트업이 있지만, 이 MCP 메모리 서버를 사용하면 코드 양이 약 200줄에 불과해 매우 간단합니다. 물론, 더 복잡한 확장이 필요한 경우, 더욱 성숙한 솔루션이 필요할 수 있습니다. 하지만 메모리 기능을 빠르게 도입하고 싶은 경우 이 제품은 매우 훌륭하게 구현되어 있으며 해당 회사의 제품에만 의존할 필요가 없을 수도 있습니다. 이러한 API 패키지가 아닌 특수 서버에 관해 공유하고 싶은 특별한 이야기가 있나요?
저스틴 /데이비드: 사실 특별한 이야기는 없어요. 이러한 서버 중 다수는 앞서 언급한 해커톤에서 유래되었습니다. 그 당시 사람들은 MCP라는 아이디어에 큰 관심을 가졌습니다. Anthropic 내의 일부 엔지니어는 메모리 기능을 구현하거나 관련 개념을 시도하고 싶어했고, MCP를 사용하여 이전에는 구현하기 어려웠던 프로토타입을 빠르게 구축할 수 있었습니다. 더 이상 특정 분야의 전문가가 될 필요도 없고, 애플리케이션이나 서비스에 메모리와 같은 기능을 추가하기 위해 특정 리
