MCP 제작자가 말하는 MCP의 탄생 배경, 아키텍처 장점 및 미래
작가: FounderPark
Anthropic가 작년에 발표한 MCP 프로토콜은 올해 Manus와 Agent 열풍으로 인해 갑자기 AI 분야에서 가장 핫한 프로토콜이 되었다. OpenAI, 마이크로소프트, Google 등 대형 기업들도 줄지어 이 프로토콜을 지원하고 있으며, 국내에서도 알리바바 클라우드 백련(百煉), 텐센트 클라우드 등이 신속히 뒤따라 플랫폼 구축을 시작했다.
하지만 논란도 적지 않다. 많은 사람들이 MCP와 API의 차이가 거의 없다고 의문을 제기하며, Anthropic의 엔지니어들이 인터넷 프로토콜에 능숙하지 않다는 점, 그리고 프로토콜이 너무 단순하여 발생하는 보안 문제 등을 지적한다.
이러한 질문들에 대해 MCP 프로토콜의 창시자가 답하기에는 더할 나위 없이 적합하다.
최근 Latent Space의 팟캐스트에서 그들은 Anthropic 팀의 MCP 프로토콜 개발자인 저스틴 스파르-섬머스(Justin Spahr-Summers)와 다비드 소리아 파라(David Soria Parra)를 초청해 MCP의 기원과 여러 아이디어들에 대해 자세히 이야기했다. 왜 MCP를 출시했는지, 기존 API와의 차이점은 무엇인지, 도구를 어떻게 더 잘 활용할 수 있는지 등 풍부한 정보를 담고 있다. 저장해서 읽는 것을 추천한다.
게스트 소개:
-
알레시오 파넬리(Alessio Fanelli, 진행자): 데시벨(Decibel) 파트너 겸 CTO
-
swyx(진행자): 스몰 AI(Small AI) 창립자
-
다비드 소리아 파라(David Soria Parra): Anthropic 엔지니어
-
저스틴 스파르-섬머스(Justin Spahr-Summers): Anthropic 엔지니어
TLDR:
-
MCP 개념의 '번뜩임'은 Anthropic의 내부 프로젝트 LSP(Language Server Protocol)에서 비롯되었다. 두 엔지니어는 LSP의 영감을 받아 AI 애플리케이션과 확장 간의 통신을 표준화할 수 있는 유사한 시스템을 만들 수 있을지 생각하게 되었다.
-
MCP의 핵심 설계 원칙은 도구라는 개념이 단지 도구 자체에 국한되지 않고 클라이언트 애플리케이션과 긴밀히 연결되어 사용자와도 밀접하게 관련된다는 것이다. MCP 작업을 통해 사용자는 완전한 제어권을 가져야 한다. 모델이 도구를 제어한다는 것은 사용자가 특정 도구를 명시적으로 지정하는 것이 아니라 모델이 호출을 결정한다는 의미이다 (단, 프롬프트 목적은 예외).
-
오픈 API와 MCP는 서로 대립되는 것이 아니라 매우 보완적인 관계이다. 중요한 것은 특정 작업에 가장 적합한 도구를 선택하는 것이다. AI 애플리케이션 간 풍부한 상호작용을 목표로 한다면 MCP가 더 적합하고, 모델이 API 사양을 쉽게 읽고 해석하길 원한다면 오픈 API가 더 낫다.
-
MCP 서버를 빠르게 구축하기 위해 AI 보조 코딩을 활용하는 것은 매우 좋은 방법이다. 초기 개발 단계에서 MCP SDK 코드 조각을 LLM의 컨텍스트 창에 넣어 LLM이 서버 구축을 도우도록 하면 종종 좋은 결과를 얻을 수 있으며, 세부 사항은 나중에 최적화할 수 있다. 이는 기본 기능을 빠르게 구현하고 반복하는 좋은 방법이다. 동시에 Anthropic의 MCP 팀은 LLM이 참여하기 쉬운 서버 구축 과정을 단순화하는 데 매우 주력하고 있다.
-
AI 애플리케이션, 생태계 및 에이전트의 미래 방향은 Statefulness(상태 유지성)를 향해 나아갈 것이며, 이는 Anthropic의 MCP 핵심 팀 내에서도 가장 논쟁적인 주제 중 하나이다. 여러 차례의 논의와 반복 끝에 현재는 Statefulness의 미래를 낙관하지만 기존 패러다임에서 벗어나서는 안 되며, Statefulness의 개념과 실제 운영의 복잡성 사이에서 균형을 찾아야 한다는 결론에 도달했다.
Founder Park는 새로운 모델과 기술을 적극적으로 시험하고 테스트하는 개발자, 창업가들을 위한 개발자 커뮤니티를 구성하고 있습니다. 아래 QR코드를 스캔하여 제품/프로젝트 정보를 상세히 작성하시면, 심사를 통과하신 후 담당자가 그룹에 초대합니다.
그룹에 입장하면 다음과 같은 혜택을 받을 수 있습니다:
-
딥시크(DeepSeek) 등 주요 모델에 대한 집중적인 개발 교류;
-
API, 클라우드 제공업체, 모델 공급업체와 직접 소통하고 피드백을 전달할 수 있는 리소스 연계 기회;
-
유용하고 재미있는 제품/사례에 대해 Founder Park가 적극적으로 홍보합니다.
01 MCP는 어떻게 탄생했나?
swyx(진행자): 우선, MCP란 무엇인가?
저스틴: 모델 컨텍스트 프로토콜(Model Context Protocol), 약칭 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의 유용한 기능이 부족해 내용을 복사하는 일이 번거로웠다. 시간이 지나면서 나는 이것이 M×N 문제, 즉 여러 애플리케이션과 다양한 통합의 어려움이라는 것을 깨달았다. 이런 문제는 하나의 프로토콜로 해결하는 것이 가장 적절했다. 당시 저는 LSP(Language Server Protocol)와 관련된 내부 프로젝트를 하고 있었는데, 진전이 없었다. 이러한 아이디어들을 종합해 몇 주간 고민한 끝에, 어떤 프로토콜을 구축하는 생각을 하게 되었다. 즉, LSP와 유사한 무언가를 만들어 ‘AI 애플리케이션과 확장 간의 통신’을 표준화할 수 없을까?
그래서 저는 저스틴에게 이 아이디어를 공유했고, 운좋게도 그는 매우 관심을 보였고, 함께 구축을 시작했다.
아이디어를 떠올린 후 약 1개월 반 정도 걸려 프로토콜을 구축하고 첫 통합을 완료했다. 저스틴은 Claude Desktop의 첫 통합에서 많은 작업을 수행했고, 저는 IDE에서 많은 개념 검증을 수행하며 프로토콜이 IDE에서 어떻게 사용될 수 있는지를 보여주었다. 정식 출시 전 코드베이스를 보면 많은 디테일을 발견할 수 있는데, 이것이 바로 MCP의 대략적인 탄생 이야기이다.
알레시오(진행자): 시간선은 어떻게 되나? 11월 25일이 정식 출시일이라는 것은 알고 있다. 이 프로젝트를 언제 시작했는가?
저스틴: 7월쯤, David가 아이디어를 낸 후 저는 금방 흥분되어 함께 MCP 구축을 시작했다. 처음 몇 달간은 클라이언트, 서버, SDK를 포함한 통신 프로토콜을 구축하는 데 많은 기초 작업이 필요했기 때문에 진척이 느렸다. 하지만 프로토콜을 통해 실제로 통신이 가능해지자 흥미로워졌고, 다양한 멋진 애플리케이션을 구축할 수 있었다.
이후 내부에서 해커톤을 개최했고, 동료들이 MCP를 이용해 3D 프린터를 제어할 수 있는 서버나 ‘기억 기능’ 등의 확장을 만들었다. 이러한 프로토타입은 큰 인기를 끌었고, 이 아이디어가 큰 잠재력을 가질 수 있음을 믿게 되었다.
swyx(진행자): MCP 구축으로 돌아가자면, 우리가 보는 것은 결국 성과물뿐인데, 분명히 LSP의 영향을 받은 것으로 보이고, 여러분도 인정하고 있다. 구축 과정에서의 작업량은 어땠는가? 주로 코드를 많이 작성하는 것이었는가, 아니면 설계 작업이 많았는가? 저는 설계 작업 비중이 크다고 느끼는데, JSON-RPC를 선택한 정도, LSP를 어느 정도 참고했는지, 그리고 어떤 부분이 특히 어려웠는가?
저스틴: 우리는 LSP로부터 많은 영감을 얻었다. David는 개발 도구 분야에서 LSP 경험을 풍부하게 가지고 있지만, 저는 주로 제품이나 인프라 작업을 해왔기 때문에 LSP는 나에게 새로운 것이었다.
설계 원칙 측면에서 LSP는 David가 언급한 M×N 문제를 해결했다. 이전에는 다른 IDE, 편집기, 프로그래밍 언어들이 각자 따로 노는 상태였다. Vim에서는 JetBrains의 우수한 Java 지원을 사용할 수 없었고, JetBrains에서는 Vim의 우수한 C 언어 지원을 사용할 수 없었다. LSP는 모든 당사자가 ‘대화’할 수 있는 보편적인 언어를 만들어내며 프로토콜을 통일했다. 이제 ‘편집기-언어’는 각각 한 번만 구현하면 되는 것이다. 우리의 목표도 유사하지만, 시나리오는 ‘AI 애플리케이션-확장’ 간의 연결이다.
구체적인 세부 사항에서는 JSON-RPC와 양방향 통신 개념을 채택한 이후 다른 방향으로 나아갔다. LSP는 기능 표현에 주목하며 다양한 기본 요소를 고려하고 제공하지만, 의미 중심의 원칙은 아니며, 이를 MCP에도 적용했다. 이후 우리는 MCP의 각 기본 요소와 그 차이점이 존재하는 이유에 대해 많은 시간을 들여 고민했고, 이는 상당한 설계 작업이었다. 초기에 우리는 TypeScript, Python, Zed 통합용 Rust 등 세 가지 언어를 지원하려 했고, 클라이언트와 서버를 포함한 SDK를 구축하고 내부 실험 생태계를 조성하며 로컬 MCP 개념(서브프로세스 시작 등)을 안정화시키려 했다.
우리는 LSP에 대한 많은 비판 의견을 참고해 MCP에서 개선하려 노력했다. 예를 들어 LSP가 JSON-RPC 위에서 하는 일부 작업은 너무 복잡하므로 우리는 좀 더 직접적인 구현 방식을 선택했다. MCP를 구축할 때 특정 분야에서는 혁신을 선택하고 다른 분야에서는 성숙한 패턴을 참조하는 것을 선택했다. JSON-RPC 같은 것은 중요하지 않지만 기본 요소 등 혁신적인 측면에 집중하는 것이며, 선배들의 성과를 참조하는 것이 우리에게 큰 도움이 되었다.
swyx(진행자): 저는 프로토콜 설계에 관심이 있다. 여기에는 펼쳐볼 수 있는 많은 내용이 있다. 이미 M×N 문제를 언급하셨고, 사실 개발자 도구 분야에서 일하는 사람이라면 누구나 겪는 ‘범용 박스(Universal Box)’ 문제이다.
인프라 엔지니어링의 기본 문제와 해결책은 많은 것을 N개의 다른 것에 연결하는 데 ‘범용 박스’를 만드는 것이다. 우버, GraphQL, 내가 일했던 Temporal, React 모두 이런 문제를 가지고 있다. 페이스북에서 N×N 문제를 해결한 적이 있는가?
David: 어느 정도 그렇다. 아주 좋은 예시이다. 나는 버전 제어 시스템 등에서 이런 문제를 많이 다뤘다. 문제를 모두 사람들이 읽고 쓸 수 있는 공통 장소에 통합하고 ‘범용 박스’를 만들어 해결하는 것이다. 개발자 도구 분야에서는 이런 문제가 곳곳에 존재한다.
swyx(진행자): 흥미로운 점은 ‘범용 박스’를 만드는 사람들이 모두 같은 문제에 직면한다는 것이다. 즉, 조합 가능성, 원격과 로컬 문제 등이다. 저스틴이 언급한 기능 표현 문제도 있고, 본질적으로 동일한 것이지만 표현 방식을 다르게 하기 위해 개념을 명확히 해야 한다.
02 MCP의 핵심 개념: 도구, 리소스, 프롬프트는 삼위일체
swyx(진행자): MCP 문서를 볼 때부터 궁금했는데, 왜 이 둘을 구분해야 하는가? 많은 사람들이 도구 호출을 모든 문제의 해결책으로 여긴다. 실제로 도구 호출의 유형은 다양하며, 때로는 리소스이고, 때로는 실행 작업이며, 다른 목적일 수도 있다. 여러분이 어떤 개념들을 유사한 범주로 묶었는지, 그리고 왜 그것들이 중요한지 강조하는지 알고 싶다.
저스틴: 우리는 각 기본 개념을 애플리케이션 개발자의 관점에서 생각한다. IDE, Claude Desktop 또는 에이전트 인터페이스와 같은 애플리케이션을 개발할 때, 사용자의 관점에서 통합에서 얻고자 하는 기능을 고려하면 훨씬 더 명확해진다. 동시에 도구 호출은 필수적이지만, 다른 기능들을 구분해야 한다.
따라서 MCP의 초기 핵심 기본 개념은 다음과 같으며, 이후에 추가되었다:
-
도구(Tool): 핵심이다. 즉, 모델에 직접 도구를 추가하여 모델이 언제 호출할지 스스로 결정하게 한다. 애플리케이션 개발자에게는 ‘함수 호출’과 유사하지만 모델이 발동한다는 점이 다르다.
-
리소스(Resource): 기본적으로 모델 컨텍스트에 추가할 수 있는 데이터나 배경 정보를 의미하며, 애플리케이션에 의해 제어될 수 있다. 예를 들어, 모델이 자동으로 관련 리소스를 검색하여 컨텍스트에 포함시키도록 할 수 있다. 또는 애플리케이션에서 명확한 UI 기능을 설정하여 사용자가 드롭다운 메뉴, 클립형 메뉴 등을 통해 LLM 정보의 일부로 만들 수 있다. 이러한 것들이 리소스의 활용 사례이다.
-
프롬프트(Prompt): 사용자가 발동하거나 사용자가 교체하는 텍스트 또는 메시지로 의도적으로 설계된다. 예를 들어, 편집기 환경에 있다면 슬래시 명령과 같거나, 자동 완성 기능과 유사하다. 사용하고자 하는 매크로를 직접 삽입하는 것과 같다.
MCP를 통해 우리는 이러한 내용의 다양한 표현 방식에 대한 견해를 갖고 있지만, 결국 애플리케이션 개발자가 결정한다. 애플리케이션 개발자로서 이러한 다양한 방식으로 표현된 개념들을 갖는 것은 유용하며, 이를 바탕으로 적절한 경험 방식을 결정하고 차별화를 형성할 수 있다. 애플리케이션 개발자의 관점에서 보면, 모든 애플리케이션이 동일하게 보이는 것을 원치 않으며, 오픈 통합 생태계에 연결할 때 최고의 경험을 창출하기 위해 독특한 접근이 필요하다.
두 가지 측면이 있다고 생각한다. 첫째, 현재 도구 호출은 통합에서 95% 이상을 차지하지만, 더 많은 클라이언트가 리소스 호출, 프롬프트 호출을 활용하기를 기대한다. 가장 먼저 구현된 것은 프롬프트 기능으로, 매우 실용적이며 추적 가능한 MCP 서버를 구축할 수 있다. 이는 사용자가 주도하는 상호작용으로, 정보를 언제 도입할지 사용자가 결정하며, 모델이 처리를 기다리는 것보다 우수하다. 또한 더 많은 MCP 서버가 도구 사용법을 프롬프트로 보여주기를 희망한다.
다른 한편으로 리소스도 잠재력이 크다. MCP 서버가 문서, 데이터베이스 등의 리소스를 공개하고, 클라이언트가 이를 기반으로 전체 인덱스를 구축하는 것을 상상해보자. 리소스는 풍부한 내용을 가지며, 모델이 공개를 주도하는 것이 아니다. 컨텍스트 창에서 실제로 사용 가능한 것보다 훨씬 더 많은 리소스 내용을 가질 수 있기 때문이다. 앞으로 몇 달 동안 애플리케이션이 이러한 기본 개념을 더 잘 활용해 더 풍부한 경험을 만들기를 기대한다.
Alessio(진행자): 망치를 들고 있으면 모든 것을 못처럼 보고 도구 호출로 모든 문제를 해결하려 한다. 예를 들어 많은 사람들이 데이터베이스 쿼리를 위해 도구를 사용하지만 리소스 호출은 사용하지 않는다. API 인터페이스(예: 데이터베이스)가 있는 경우, 도구와 리소스를 사용하는 각각의 장단점은 무엇인가? 언제 SQL 쿼리를 위해 도구를 사용해야 하며, 언제 데이터를 처리하기 위해 리소스를 사용해야 하는가?
저스틴: 우리는 도구와 리소스를 다음과 같이 구분한다. 도구는 모델이 호출을 발동하며, 모델이 적절한 도구를 찾아 적용하는 것으로 판단한다. LLM이 SQL 쿼리를 실행할 수 있도록 하려면 도구로 설정하는 것이 합리적이다.
리소스는 더 유연하지만, 현재 많은 클라이언트가 지원하지 않아 상황이 복잡하다. 이상적으로 데이터베이스 테이블 스키마 등의 내용은 리소스 호출을 통해 처리할 수 있다. 사용자는 이를 통해 관련 정보를 알려 대화를 시작하거나, AI 애플리케이션이 자동으로 리소스를 찾도록 할 수 있다. 엔티티를 나열하고 읽어야 하는 요구사항이 있다면 리소스로 모델링하는 것이 합리적이다. 리소스는 URI로 고유하게 식별되며, 일반 변환기로 간주할 수 있다. 예를 들어 Zed 편집기는 프롬프트 라이브러리와 MCP 서버가 상호작용하여 프롬프트를 채우며, URI 및 데이터 형식에 대해 합의해야 한다. 이는 리소스 활용의 매우 멋진 교차 예시이다.
다시 애플리케이션 개발자의 관점으로 돌아가 요구사항을 생각하고 이를 실제에 적용해보자. 기존 애플리케이션 기능을 살펴보고, 이 방식을 채택하면 어떤 기능을 분리하여 MCP 서버로 구현할 수 있는지 생각해보자. 기본적으로 첨부 메뉴를 가진 모든 IDE는 자연스럽게 리소스로 모델링할 수 있다. 다만 이러한 구현 방식은 이미 존재한다.
swyx(진행자): 네, 저는 Claude Desktop에서 @ 기호를 볼 때 Cursor의 기능과 동일하다는 것을 바로 알았다. 이제 다른 사용자들도 이 기능을 사용할 수 있게 되었다. 이 설계 목표는 훌륭하다. 왜냐하면 기능 자체가 이미 존재하고 사람들이 이해하고 사용하기 쉽기 때문이다. 제가 그 차트를 보여줬을 때, 여러분도 그 가치를 인정했을 것이라 생각한다. 매우 유용하며 문서 첫 페이지에 있어야 한다고 생각한다. 훌륭한 제안이다.
저스틴: PR(Pull Request)를 제출해주시겠습니까? 우리는 이 제안을 매우 좋아합니다.
swyx(진행자): 네, 제가 제출하겠습니다.
개발자 관계 담당자로서 저는 사람들에게 명확한 지침을 제공하는 데 항상 힘썼다. 예를 들어 핵심 요점을 먼저 나열한 후 두 시간 동안 자세히 설명하는 것이다. 따라서 핵심 내용을 하나의 그림으로 담는 것은 매우 유용하다. 프롬프트에 대한 여러분의 중시를 매우 높이 평가한다. ChatGPT와 Claude 초창기에는 많은 사람들이 GitHub에서 프롬프트 라이브러리, 프롬프트 관리자 라이브러리와 유사한 것을 만들려 했지만, 결국 크게 유행하지 않았다.
정말로 이 분야에는 더 많은 혁신이 필요하다. 사람들은 프롬프트가 동적이기를 원하며, 여러분은 그러한 가능성을 제공한다. 다단계 프롬프트(multi-step prompt) 개념에 대해 언급한 것을 매우 인정한다. 때때로 모델이 정상적으로 작동하려면 다단계 프롬프트 방식을 취하거나 일부 제한을 돌파해야 한다는 것이다. 프롬프트는 단순한 대화 입력이 아니라 때로는 일련의 대화 과정일 수 있다.
swyx(진행자): 저는 이것이 바로 리소스와 도구 개념이 어느 정도 융합되는 지점이라고 생각한다. 왜냐하면 지금 말씀하신 것처럼 때로는一定程度의 사용자 제어 또는 애플리케이션 제어가 필요하고, 다른 때는 모델이 제어하기를 원하기 때문이다. 그래서 지금 우리가 도구의 하위 집합을 선택하고 있는 것인가?
David: 네, 저는 이것이 합리적인 우려라고 생각한다. 궁극적으로 이것은 MCP의 핵심 설계 원칙으로, 도구라는 개념은 도구 자체에 국한되지 않고 클라이언트 애플리케이션과 밀접하게 연결되어 사용자와도 밀접하게 관련된다. MCP 작업을 통해 사용자는 완전한 제어권을 가져야 한다. 도구가 모델에 의해 제어된다는 것은 단지 모델이 호출을 결정한다는 의미이며, 사용자가 특정 도구를 명시적으로 지정하는 것은 아니다(물론 프롬프트 목적은 예외이지만, 이는 일반적인 사용자 인터페이스 기능이 되어서는 안 된다).
하지만 클라이언트 애플리케이션이나 사용자가 MCP 서버가 제공하는 내용을 필터링하고 최적화하기로 결정하는 것은 완전히 합리적이라고 생각한다. 예를 들어 클라이언트 애플리케이션은 MCP 서버에서 도구 설명을 가져와 최적화된 방식으로 표시할 수 있다. MCP 패러다임 하에서 클라이언트 애플리케이션은 완전한 제어권을 가져야 한다. 또한 우리는 초보적인 아이디어를 갖고 있다. 프로토콜에 기능을 추가하여 서버 개발자가 프롬프트, 리소스, 도구와 같은 기본 요소를 논리적으로 그룹화할 수 있도록 하는 것이다. 이러한 그룹은 서로 다른 MCP 서버로 간주될 수 있으며, 사용자가 자신의 필요에 따라 조합하여 사용할 수 있다.
03 MCP와 OpenAPI: 경쟁인가, 보완인가?
swyx(진행자):MCP와 오픈API(Open API) 비교에 대해 말하고 싶다.毕竟 이것은 분명히 모두가 매우 관심 있는 문제 중 하나이다.
저스틴/데이비드: 근본적으로 오픈 API 사양은 매우 강력한 도구이며, API 및 그 클라이언트를 개발할 때 자주 사용한다. 그러나 대규모 언어 모델(LLM)의 사용 사례를 고려하면, 오픈 API 사양은 지나치게 세부적이다. MCP에서 언급한 기본 개념과 애플리케이션 개발자의 사고 방식과 같은 더 고차원적이고 AI 특화된 개념을 충분히 반영하지 못한다. REST API를 제공하여 모델이 자유롭게 사용하도록 하는 것과 비교할 때, 모델은 도구, 리소스, 프롬프트 및 기타 기본 개념과 같이 전용으로 설계된 도구로부터 더 많은 이익을 얻을 수 있다.
반면, MCP 프로토콜을 설계할 때 우리는 의도적으로 일정 정도의 상태성을 갖도록 했다. 이는 AI 애플리케이션과 상호작용이 본질적으로 Statefulness(상태 유지성)를 선호하기 때문이다. Stateless(무상태)가 어느 정도 항상 쓸모 있지만, 상호작용 모드(예: 비디오, 오디오 등)가 증가함에 따라 Statefulness는 점점 더 인기를 끌게 될 것이며, 따라서 Statefulness 프로토콜도 특히 유용하다.
사실 오픈 API와 MCP는 서로 대립되는 것이 아니라 서로 보완한다. 각각 강력한 점이 있으며 매우 보완적이다. 핵심은 특정 작업에 가장 적합한 도구를 선택하는 것이다. AI 애플리케이션 간 풍부한 상호작용을 목표로 한다면 MCP가 더 적합하다. 모델이 API 사양을 쉽게 읽고 해석하기를 원한다면 오픈 API가 더 나은 선택이다. 초기부터 이미 두 사이를 연결하는 도구가 있었고, 오픈 API 사양을 MCP 형식으로 게시하거나 그 반대로 변환하는 도구도 있어 매우 좋다.
Alessio(진행자): 저는 AGI 스튜디오에서 공동 주최하는 해커톤에 참여했습니다. 개인 에이전트 개발자로서, 누군가 API 사양 URL만 입력하면 해당 MCP 서버를 생성할 수 있는 개인 에이전트를 구축한 사람을 보았습니다. 이 현상에 대해 어떻게 생각합니까? 대부분의 MCP 서버가 기존 API 위에 계층을 추가하는 것에 불과하고, 독특한 설계가 거의 없다는 것을 의미합니까? 미래에도 계속 기존 API에 AI를 연결하는 것이 주를 이루게 될까요, 아니면 전혀 새로운, 전에 없던 MCP 경험을 만들어낼 수 있을까요?
저스틴/데이비드: 저는 두 가지 모두 존재한다고 생각한다. 한편으로 '데이터를 애플리케이션에 연결하는 것'에 대한 수요는 항상 가치가 있다. 현재는 도구 호출을 기본적으로 사용하는 경우가 많지만, 미래에는 다른 기본 개념이 이러한 문제를 해결하는 데 더 적합할 수 있다. 비록 여전히 커넥터나 어댑터 계층일지라도, 다른 개념을 적응함으로써 가치를 추가할 수 있다.
다른 한편으로는 흥미로운 사용 사례가 존재할 가능성이 있으며, 단순히 어댑터 역할만 하는 MCP 서버를 구축할 수 있다. 예를 들어 메모리 MCP 서버는 LLM이 서로 다른 대화에서 정보를 기억할 수 있도록 한다. 순차적 사고 MCP 서버는 모델의 추론 능력을 향상시킬 수 있다. 이러한 서버는 외부 시스템과 통합되는 것이 아니라 모델에 새로운 사고 방식을 제공한다.
어쨌든 AI를 사용하여 서버를 구축하는 것은 완전히 가능하다. 구현하려는 기능이 다른 API를 적응하는 것이 아니라 독창적인 것이라 할지라도, 모델은 일반적으로 구현 방법을 찾을 수 있다. 실제로 많은 MCP 서버는 API 래퍼가 될 것이며, 이는 합리적이고 효과적이며 큰 진전을 이루는 데 도움이 된다. 그러나 우리는 여전히 탐색 단계에 있으며, 달성할 수 있는 가능성을 계속 탐색하고 있다.
클라이언트가 이러한 기본 개념에 대한 지원이 지속적으로 향상됨에 따라 풍부한 경험들이 나타날 것이다. 예를 들어 Reddit 섹션 내용 요약 MCP 서버는 아직 아무도 구축하지 않았지만, 프로토콜 자체는 완전히 이를 구현할 수 있다. 사람들이 '내가 관심 있는 것을 LLM에 연결하고 싶다'는 요구에서 '나는 진정한 워크플로우를 원하며, 더 풍부하고 모델이 깊이 상호작용할 수 있는 경험을 원한다'는 요구로 전환할 때 이러한 혁신적인 애플리케이션이 나타날 것이라고 생각한다. 그러나 현재 클라이언트의 지원 능력과 서버 개발자가 구현하고자 하는 기능 사이에는 확실히 '닭이 먼저냐 달걀이 먼저냐'의 문제가 존재한다.
04 어떻게 빠르게 MCP 서버를 구축할까: AI 프로그래밍 활용
Alessio(진행자): 저는 MCP에 대해 사람들이 상대적으로 덜 논의하는 또 다른 측면은 서버 구축이라고 생각합니다. MCP 서버를 구축하려는 개발자들에게 조언이 있습니까? 서버 개발자로서 모델이 이해할 수 있도록 상세한 설명을 제공하는 것과 원시 데이터를 직접 가져와 모델이 후속 자동 처리하도록 하는 것 사이에서 최적의 균형을 어떻게 찾을 수 있을까요?
저스틴/데이비드: 몇 가지 조언이 있다. MCP의 장점 중 하나는 간단한 기능을 구축하기가 매우 쉽다는 것이다. 약 30분 만에 구축할 수 있으며, 완벽하지 않을 수 있지만 기본적인 요구사항을 충족할 수 있다. 가장 좋은 입문 방법은 좋아하는 프로그래밍 언어를 선택하고, 해당 SDK가 있으면 바로 사용하는 것이다. 모델이 상호작용할 수 있도록 하고자 하는 도구를 구축한다. MCP 서버를 구축한다. 이 도구를 서버에 추가한다. 도구 설명을 간단히 작성한다. 표준 입력/출력 프로토콜을 통해 원하는 애플리케이션에 연결한다. 그런 다음 모델이 어떻게 사용하는지 관찰한다.
개발자에게는 모델이 자신이 관심 있는 것에 작용하는 것을 빠르게 볼 수 있다는 점이 매우 매력적이며, 열정을 불러일으키고, 더 필요한 도구, 리소스, 프롬프트를 깊이 생각하게 하며, 효과를 평가하고 프롬프트를 최적화하는 데 동기를 부여한다. 이는 계속 깊이 탐색할 수 있는 과정이지만, 먼저 간단한 것부터 시작하여 모델이 관심 있는 내용과 어떻게 상호작용하는지 보는 것만으로도 충분히 재미있다. MCP는 개발에 재미를 더하며 모델이 빠르게 작동하도록 한다.
또한 AI 보조 코딩을 활용하는 것을 선호한다. 개발 초기 단계에서 MCP SDK 코드 조각을 LLM의 컨텍스트 창에 넣어 LLM이 서버 구축을 도우도록 하면 종종 좋은 결과를 얻을 수 있으며, 세부 사항은 나중에 추가로 최적화할 수 있다. 이는 기본 기능을 빠르게 구현하고 반복하는 좋은 방법이다. 처음부터 우리는 LLM이 참여하기 쉬운 서버 구축 프로세스를 단순화하는 데 매우 주력했다. 지난 몇 년 동안 MCP 서버를 시작하는 데 100~200줄의 코드만 필요했으며, 정말로 간단하다. 기존 SDK가 없더라도 관련 사양이나 다른 SDK를 모델에 제공하여 일부 기능을 구축하도록 할 수 있다. 좋아하는 언어에서 도구 호출을 수행하는 것은 일반적으로 매우 직접적이다.
Alessio(진행자):서버 구축자가 최종 반환되는 데이터 형식과 내용을很大程度上 결정한다는 것을 발견했습니다. 예를 들어 도구 호출 예시에서 Google Maps는 반환할 속성을 구축자가 결정합니다. 특정 속성이 누락되면 사용자는 그것을 덮어쓰거나 수정할 수 없습니다. 이는 제가 일부 SDK에 대해 불만을 느끼는 것과 유사합니다. 사람들이 API 래퍼 SDK를 구축할 때 API가 추가한 새 매개변수를 누락하면 새 기능을 사용할 수 없습니다. 이 문제에 대해 어떻게 생각합니까? 사용자는 얼마나 큰 개입 권한을 가져야 하며, 완전히 서버 설계자가 결정해야 합니까?
저스틴/데이비드: Google Maps 예시에 대해 우리는 일정 부분 책임이 있을 수 있다. 왜냐하면 그것은 우리가 발표한 참조 서버이기 때문이다. 일반적으로 현재로서는 도구 호출 결과에 대해 구조화된 JSON 데이터일 필요도 없고, 특정 스키마와 일치할 필요도 없으며, 텍스트, 이미지와 같이 LLM에 직접 입력할 수 있는 메시지 형태로 제공하는 것을 의도적으로 설계했다. 즉, 우리는大量的 데이터를 반환하는 것을 선호하며, LLM이 관심 있는 정보를 자체적으로 필터링하고 추출할 수 있다고 믿는다. 우리는 이 방면에서 많은 노력을 기울였으며, 모델이 필요한 정보를 유연하게 얻을 수 있도록 하기 위함이며, 이것이 바로 모델의 강점이기 때문이다. 우리는 LLM의 잠재력을 최대한 발휘하도록 하기 위해 과도하게 제한하거나 지정하는 것을 피하고자 하며, 모델의 개선과 함께 확장하기 어려워지는 것을 방지하고자 한다. 따라서 예시 서버에서는 이상적으로 호출된 API에서 모든 결과 유형이 그대로 전달되어 API가 데이터를 자동으로 전달하는 상태가 되어야 한다.
Alessio(진행자): 어디에서 이 경계를 설정할 것인가는 정말로 어렵게 결정해야 하는 문제이다.
David: 여기서 AI의 역할을 조금 강조하고 싶다. 많은 예시 서버는 Claude가 작성한 것이다. 이는 놀라운 일이 아니다. 현재 사람들은 전통적인 소프트웨어 엔지니어링 방법으로 문제를 처리하는 데 익숙하지만, 실제로 우리는 LLM을 위한 시스템을 구축하는 방법을 다시 배우고 그 능력을 신뢰해야 한다. LLM이 매년 눈부신 발전을 이루고 있기 때문에, 이제 데이터 처리 작업을 이를 잘하는 모델에 맡기는 것이 현명한 선택이다. 이는 지난 20~30년, 혹은 40년간의 전통적인 소프트웨어 엔지니어링 실천 경험을 내려놓아야 할 수도 있다는 것을 의미한다.
MCP를 다른 각도에서 보면, AI의 발전 속도는 놀라우며, 흥분되기도 하고 약간의 걱정도 동반한다. 모델의 다음 능력 향상에서 가장 큰 병목 현상은 외부 세계와의 상호작용 능력일 수 있다. 예를 들어 외부 데이터 소스를 읽거나 Statefulness 행동을 취하는 것 등이다. Anthropic에서 일할 때 우리는 안전한 상호작용을 매우 중시하며, 이에 따라 통제 및 보정 조치를 취한다. AI가 발전함에 따라 사람들은 모델이 이러한 능력을 갖기를 기대할 것이며, 모델을 외부와 연결하는 것은 AI 생산성을 향상시키는 핵심이다. MCP는 또한 우리가 미래 방향성과 그 중요성에 걸고 있는 베팅이다.
Alessio(진행자): 맞다. '포맷팅(formatted)'이라는 단어가 붙은 API 속성은 모두 제거되어야 한다고 생각한다. 우리는 모든 인터페이스에서 원시 데이터를 가져와야 한다. 미리 포맷팅할 필요가 무엇인가? 모델은 충분히 똑똑해서 주소 등의 정보를 스스로 포맷팅할 수 있을 것이다. 따라서 이 부분은 최종 사용자가 결정해야 한다.
05 어떻게 MCP가 더 많은 도구를 효과적으로 호출하게 할 수 있을까?
swyx(진행자): 또 하나 질문하고 싶은 것은, MCP 구현이 얼마나 많은 관련 기능을 지원할 수 있는가? 이것은 범위와 깊이의 문제이며, 우리가 방금 논의한 MCP 중첩과도 직접 관련된다.
2024년 4월 클로드(Claude)가 첫 백만 토큰 컨텍스트 예시를 출시할 때, 250개의 도구를 지원할 수 있다고 밝혔다. 그러나 많은 실제 상황에서 모델은 이렇게 많은 도구를 실제로 효과적으로 사용하지 못한다. 일종의 범위 문제인데, 도구를 호출하는 도구가 없고, 모델과 일평면의 도구 계층 구조만 있기 때문에 도구 혼동이 쉽게 발생한다. 도구 기능이 유사할 때 모델은 잘못된 도구를 호출할 수 있으며, 결과가 좋지 않을 수 있다. 특정 시간에 활성화할 수 있는 MCP 서버의 최대 수에 대해 어떤 조언이 있습니까?
저스틴: 솔직히 말해 이 질문에는 절대적인 답이 없다. 한편으로는 사용하는 모델에 따라 달라지고, 다른 한편으로는 도구의 이름과 설명이 모델이 정확히 이해하고 혼동을 피할 수 있을 정도로 충분히 명확한지에 달려 있다. 이상적인 상태는 모든 정보를 LLM에 제공하고 완전히 모델이 모든 것을 처리하는 것이며, 이것이 MCP가 상상하는 미래 청사진이다. 그러나 현실적인 응용에서는 클라이언트 애플리케이션(AI 애플리케이션)이 필터링 도구 세트와 같은 보완 작업을 수행해야 할 수 있으며, 작은 고속 LLM을 사용하여 가장 관련성 있는 도구를 먼저 필터링한 후 대규모 모델에 전달할 수도 있다. 또한 일부 MCP 서버를 다른 MCP 서버의 프록시로 설정하여 필터링할 수도 있다.
C
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
