모델 컨텍스트 프로토콜(MCP)로 만드는 AI 에이전트 :1편

Last updated on 6월 19th, 2025 at 03:45 오후

오늘은 2025년 뉴욕 AI Engineer Summit 워크숍 데이의 현장 녹화 영상을 텍스트로 옮긴 콘텐츠를 준비해봤어요. 주로 MCP에 대한 이야기인데요. 잠깐, MCP가 아직 뭔지 모르신다고요? MCP는 Model Context Protocol의 약자입니다. AI 시스템과 데이터 소스를 연결하기 위한 범용 오픈 표준을 의미해요. 기존의 파편화된 통합 방식을 하나의 프로토콜로 대체하죠.

이 워크숍에서는 MCP를 만든 Anthropic이 직접 MCP의 철학과 MCP 출시 이후 생태계에 미친 영향, 그리고 개발자가 MCP를 활용해 맥락 중심의 AI 앱 및 에이전트 경험을 어떻게 만들 수 있는지에 대해 이야기합니다.

오늘의 연사인 Mahesh가 누구냐면요,
Anthropic의 Applied AI 팀에서 활동 중인 테크니컬 스태프(MTS, Member of Technical Staff)인데요. Model Context Protocol(MCP), AI 에이전트, 그리고 Claude를 기업 환경에서 더 유용하게 만들기 위한 작업에 집중하고 있는 인물입니다.이전에는 Scale AI와 Tecton에서 제품 관리자(Product Manager)로 일했으며, UC 버클리에서 자율주행차가 교통 시스템에 미치는 영향에 관한 연구를 수행한 이력이 있어요.

그럼, Mahesh의 뉴욕 AI Engineer Summit 워크숍이 궁금한 분들을 위해
현장감을 최대한 살려 강연 내용을 옮겨볼게요.

여러분, 안녕하세요. 와주셔서 감사합니다. 저는 Mahesh이고, Anthropic의 응용 AI 팀에서 일하고 있습니다. 이렇게 많은 분들이 와 주셔서 정말 기뻐요.

오늘은 MCP에 대해 이야기할 예정입니다. 워크숍보다는 발표 형식이지만, 최대한 소통하며 진행하도록 해보겠습니다. 질문이 있으시면 언제든지 해주세요. 제가 중간중간 답변드릴게요.

💡 왜 MCP가 필요했는가?

오늘 이야기할 내용은 MCP의 철학과, 왜 Anthropic이 이 MCP를 출시하고 구축하는 것이 중요하다고 생각했는지입니다. 또한 최근 몇 달간 MCP가 어떤 성과를 거뒀는지, 에이전트 및 AI 애플리케이션에 MCP를 어떻게 적용할 수 있는지, 마지막으로 앞으로의 로드맵에 대해서도 다룰 예정입니다.

MCP를 시작하게 된 동기는 아주 기본적인 개념, 즉 모델은 우리가 제공하는 컨텍스트만큼만 유용하다는 점이었습니다. 지금은 당연하지만, 1년 전만 해도 대부분의 AI 어시스턴트나 챗봇은 자료를 복사-붙여넣기하거나, 직접 입력하거나, 다른 시스템에서 붙여 넣는 방식이었죠. 하지만 지난 몇 개월, 1년 사이에, 모델이 실제로 여러분의 데이터나 컨텍스트에 훅(hook)을 걸 수 있는 시스템으로 진화하게 되었어요. 더 진화된 AI가 등장한 것이죠.

그 지점에서 우리는 MCP를 출범시킬 기회를 엿봤습니다. MCP는 AI 앱과 에이전트, 그리고 여러분이 사용하는 툴과 데이터 소스 사이를 매끄럽게 연결해주는 개방형 프로토콜이니까요.

MCP를 이해하려면, 먼저 MCP 이전에 존재했던 프로토콜과 시스템을 생각해봐야 합니다.

웹 앱의 프론트엔드와 백엔드가 상호작용하는 방식을 표준화하기 위해 API가 도입되었잖아요? 이것은 그 둘 사이에서 요청을 변환하는 일종의 프로토콜 또는 계층인데요. 그렇게 프론트엔드가 서버, 데이터베이스, 서비스 등에 접근할 수 있게 되었고요.

그 다음 등장한 것이 LSP, 즉 Language Server Protocol입니다. 이는 IDE가 언어별 도구와 상호작용하는 방식을 표준화합니다. LSP는 우리가 큰 영감을 받은 요소이며, 예를 들어 Go용 LSP 서버를 한 번 구축하면, LSP 호환 IDE는 모두 그 기능을 활용할 수 있게 되죠. 이 개념이 MCP의 기반이 되었습니다. MCP는 AI 애플리케이션이 외부 시스템과 상호작용하는 방식을 표준화하며, 세 가지 주요 방식, 즉 프롬프트, 툴, 리소스라는 인터페이스를 제공합니다.

🌐 MCP가 만든 생태계 변화

그렇다면 MCP 이전의 세계는 어떤 모습이었는가.
Anthropic은 수많은 고객과 API를 이용해 에이전트와 AI 애플리케이션을 구축하려는 사람들과 함께 애를 써왔어요. 업계 전반적으로, 심지어 하나의 회사 내부에서도 AI 시스템을 구축하는 방식이 완전히 제각각이었습니다. 한 팀은 커스텀 프롬프트 로직, 각기 다른 툴과 데이터 연결 방식, 권한 연동 방식 등을 갖춘 독자적인 구현체를 만들고 있었죠. 같은 회사 내 팀들끼리도 이렇게 다르면, 업계 전체는 말할 것도 없습니다.

그런데 MCP가 도입된 세계는 표준화된 AI 개발의 세계입니다. MCP 클라이언트 생태계를 설명해볼까요? 여기에는 저희의 1st-party 앱을 비롯해 최근 출시된 Parser, Windsurf, Block에서 나온 에이전트 Goose 등이 있습니다. 이들은 모두 MCP 클라이언트이며, 표준화된 인터페이스를 통해 어떤 MCP 서버와도 추가 작업 없이 연결이 가능합니다.

MCP 서버는, AI 애플리케이션에 관련된 다양한 시스템과 툴에 대한 접근을 연동하는 래퍼 또는 게이트웨이입니다. 데이터베이스, CRM (예: Salesforce), 혹은 로컬 시스템의 Git 같은 버전 관리 도구 등일 수 있습니다. 이 MCP 서버는 모델에게 데이터베이스나 레코드 접근을 가능하게 하고, 원격 서버에 있는 데이터를 읽고 쓰게 하며, 혹은 로컬 API에 연결하게 만들 수 있습니다.

결과적으로, MCP가 등장한 덕분에 생태계의 다양한 구성원들이 얻는 가치가 많아졌습니다. 애플리케이션 개발자는 클라이언트가 MCP 호환되기만 하면 어떤 MCP 서버와도 추가 작업 없이 연결할 수 있고요. 툴이나 API 제공자는 MCP 서버를 한 번만 구축하면 다양한 AI 앱에서 서버를 사용할 수 있어요. 이전에 비해 훨씬 편리하죠.

또 하나 덧붙이자면, MCP가 등장하기 전에는 다양한 클라이언트 앱이 다양한 서버와 상호작용하려고 할 때 수많은 조합이 필요했던 반면, MCP는 이 모든 것을 단일 계층으로 평탄화시킵니다. 이는 애플리케이션 개발자와 API 제공자 모두에게 더 강력하고 컨텍스트가 풍부한 AI 애플리케이션을 만들어주는 길을 열어줍니다.

기업 입장에서도 좋아요. MCP는 팀 간 역할 분리를 명확하게 해주니까요. 예를 들어, 어떤 팀이 인프라 계층을 담당하면서 벡터 DB나 RAG 시스템을 구축했다고 해보죠. 예전에는 각 팀이 제각기 이 벡터 DB에 접근하기 위한 자체 구현을 해야 했지만, MCP 세계에서는 한 팀이 MCP 서버를 만들어서 이 시스템을 관리하고 문서화하고, 다른 팀들은 이를 중심으로 빠르게 AI 앱을 개발할 수 있게 됩니다. 일종의 마이크로서비스 세계와도 유사하죠. 각 팀은 자신의 서비스를 담당하기만 하면, 회사 전체가 더 빠르게 움직일 수 있습니다.

그럼 이제 MCP 도입 사례에 대해 이야기해보겠습니다.
최근에는 IDE에서 코딩할 때, 사용자가 작업 중인 컨텍스트를 IDE에 제공하는 훌륭한 방식으로 MCP가 사용되고 있습니다. IDE 내의 에이전트는 GitHub나 문서 사이트 같은 외부 시스템과 통신하면서 작업을 지원할 수 있습니다.

서버 측에서도 많은 발전이 있었습니다. 지금까지 커뮤니티에서 만들어져 오픈소스로 공개된 서버만 1,100개 정도 되고요. 기업들이 직접 구축한 서버도 많습니다. 예시로 제가 직접 만든 서버도 있고요. 여러 회사들이 자신들의 시스템과 연동하기 위한 공식 통합 서버를 구축해 공개하고 있죠. 오픈소스 생태계 측면에서도, MCP 핵심 프로토콜이나 인프라 계층에 기여하는 사람들도 매우 많습니다.

⚙️ MCP의 3대 핵심 구성 요소

이제 MCP로 무엇을 만들 수 있는지, 그리고 프로토콜 내의 핵심 개념을 설명해볼게요.

첫 번째로 툴에 대해 이야기 해보죠.
툴은 아마도 가장 직관적인 요소이자, 지난 몇 달 동안 가장 많이 발전한 부분일겁니다. 툴은 모델 제어 요소입니다. 즉, 서버는 클라이언트 애플리케이션에 툴을 노출하고, 클라이언트 내의 모델, 즉 LLM이 툴을 언제 호출할지 결정하죠.

Cloud for Desktop 같은 MCP 호환 시스템에서는 일반적으로 툴이 프롬프트에 삽입되고, 툴 사용법이 서버 정의의 일부로 제공됩니다. 그리고 애플리케이션 내의 모델이 툴을 호출할 가장 적절한 시점을 선택하죠.툴이 할 수 있는 일의 범위는 사실상 무한합니다. 데이터를 읽어오는 툴, 데이터를 외부 애플리케이션에 보내는 쓰기 툴, 데이터베이스 업데이트 툴, 로컬 파일 시스템에 파일을 저장하는 툴 등 다양한 기능이 가능합니다.

이제 리소스(resources)에 대해 이야기해볼게요.
리소스는 애플리케이션에 노출된 데이터이며, 애플리케이션이 제어합니다. 서버는 이미지, 텍스트 파일, JSON 파일 등 다양한 형태로 리소스를 만들 수 있으며, 예를 들어 JSON 파일에는 서버와의 상호작용 기록이 담겨 있을 수도 있습니다. 이 리소스는 애플리케이션에 전달되고, 애플리케이션이 그 리소스를 어떻게 활용할지 결정합니다.

리소스를 통해 애플리케이션과 서버는 단순히 텍스트 챗봇 수준을 넘어서는 풍부한 인터페이스를 가질 수 있게 됩니다. 그동안 발견한 사용 예시 중 하나는 정적인 리소스를 제공하는 경우와 동적으로 생성된 리소스를 제공하는 경우입니다. 예를 들어 클라이언트 애플리케이션이 사용자 정보나 파일 시스템 정보를 서버에 보내면, 서버는 이를 기반으로 복잡한 데이터 구조를 생성해 클라이언트에 전달할 수 있습니다.

Cloud for Desktop에서는 리소스가 첨부파일 형태로 나타납니다. 사용자는 서버와 상호작용할 때 UI에서 리소스를 클릭해 대화에 첨부할 수 있고, 해당 리소스는 모델에 전달될 수 있습니다. 또한 리소스는 모델이 자동으로 첨부하도록 설정할 수도 있습니다. 예를 들어 모델이 현재 작업과 매우 관련 있는 리소스를 식별하고 자동으로 대화에 포함시킬 수도 있죠.

마지막으로 프롬프트에 대해 설명드릴게요. 프롬프트는 사용자 제어 요소로, 모델이 호출하는 것이 아닌 사용자가 호출하는 툴이라고 생각하시면 됩니다.

프롬프트는 특정 서버와 자주 수행되는 상호작용을 위한 사전 정의된 템플릿입니다. 좋은 사례로는 IDE인 Zed가 있습니다. Zed에서는 슬래시 명령어(slash command)를 통해 LLM과 상호작용할 수 있습니다. 예를 들어 “이 PR 작업 내용을 요약해줘”라는 요청을 하려면, SL GPR이라는 명령어와 함께 PR ID를 입력하면, Zed가 MCP 서버에 정의된 프롬프트를 기반으로 길고 구조화된 요청을 생성해서 LLM에 전달합니다. 그 결과, LLM은 아주 깔끔한 요약 정보를 생성하게 되죠.

우리가 본 다른 사용 사례로는 문서 기반 Q&A 같은 것들이 있습니다. 예를 들어 특정 형식의 문서가 있고, 화자 구분이나 포맷 규칙 등이 있다면, 이러한 규칙을 MCP 서버 내 프롬프트로 정의해두고, 사용자가 필요할 때 호출할 수 있도록 할 수 있습니다.

지금부터는 QnA 세션이 진행되는데요,
질문과 답변을 정리해볼게요.

자, 여기까지 각 구성 요소들이 어떻게 작동하는지 어떻게 함께 맞물리는지 설명해드렸습니다. 지금까지 설명드린 부분에 대해 질문해주시면 답변하겠습니다.

질문 “왜 리소스를 툴처럼 모델이 호출하는 방식으로 만들지 않았는가?”

MCP의 설계 철학 중 큰 부분은 단순히 모델을 더 똑똑하게 만드는 데 그치지 않고, 애플리케이션이 서버와 보다 풍부하게 상호작용할 수 있는 구조를 제공하는 것입니다. 툴은 일반적으로 모델이 제어하며 호출 시점을 결정합니다. 반면, 우리는 무엇이 모델이 제어해야 할 것인지, 무엇이 애플리케이션이 제어해야 할 것인지 명확히 구분하고자 했습니다. 예를 들어 MCP 호환 애플리케이션이 사전에 정의된 규칙에 따라, 혹은 LLM 호출 결과를 바탕으로 리소스를 컨텍스트에 포함시킬지 여부를 판단하게 될 수도 있죠. 그래서 클라이언트 개발자와 서버 개발자가 각자의 역할에서 혼란 없이 시스템을 구현할 수 있도록, 모델 제어 요소(툴)와 애플리케이션 제어 요소(리소스)를 명확히 나눈 것입니다.

질문 “모델이 벡터 데이터베이스에 접근할 수 있게 하려면 툴로 노출하는 것이 적절한가요?”

이건 사실 상황에 따라 다릅니다.
툴을 사용하는 가장 좋은 경우는 ‘언제 툴을 호출해야 하는지 애매한 상황’입니다. 예를 들어 LLM이 어떤 정보를 이미 컨텍스트 내에 가지고 있을 수도 있고, 어떤 경우에는 벡터 DB에 쿼리를 보내야 할 수도 있으며, 또 다른 경우에는 사용자로부터 추가 정보를 받아야 검색이 가능한 상황일 수도 있죠. 이런 경우 툴로 노출해두면 모델이 스스로 판단해서 필요한 순간에 호출할 수 있으니 이상적입니다. 반대로, 툴 호출 여부가 항상 명확하고 정해져 있는 경우라면 굳이 툴로 만들 필요 없이, 그냥 항상 호출하면 됩니다.

질문 “에이전트 프레임워크와 MCP의 관계는 어떻게 되나요? 함께 사용할 수 있나요?”

짧게 말하자면, ‘둘은 완벽히 서로를 보완하는 관계’라고 볼 수 있습니다.

실제로 이번 주에 LangGraph라는 프레임워크에서 MCP 서버와 연결할 수 있는 어댑터를 출시했어요. LangGraph 안에서 이미 구축해둔 에이전트 시스템이 있다면, MCP 서버를 이 어댑터를 통해 쉽게 노출시킬 수 있고, 시스템을 바꾸지 않고도 MCP 서버를 에이전트에 연결할 수 있습니다.

그래서 MCP는 에이전트 프레임워크를 대체하는 게 아니라, MCP 덕분에 툴, 프롬프트, 리소스들을 훨씬 더 표준화된 방식으로 에이전트 프레임워크에 연동할 수 있게 된 거죠.

질문 “MCP가 에이전트 프레임워크를 대체할 수 있느냐”

제 생각엔 완전히 대체하지는 않을 것 같습니다.
MCP가 대체할 수 있는 부분은 프롬프트 컨텍스트 관리나 툴 호출과 같은, 에이전트와 외부 시스템 간 연결 관련 로직입니다. 하지만 에이전트 프레임워크의 핵심 가치는 ‘에이전트 루프(Agentic Loop)’에 있습니다. 모델이 루프 안에서 어떻게 실행되는지, 툴 호출 결과에 어떻게 반응하는지, 컨텍스트나 메모리를 어떻게 다루는지 등을 정의하는 부분이죠.

MCP는 어디까지나 표준 레이어로서, 에이전트나 에이전트 프레임워크가 필요로 하는 컨텍스트를 외부 시스템에서 가져올 수 있게 해주는 역할입니다. 그래서 에이전트 프레임워크를 완전히 대체하는 게 아니라, 이것과과 함께 작동하는 구조로 보는 것이 더 정확합니다.

질문 “리소스나 프롬프트는 왜 굳이 툴로 통합하지 않았는가?”

아주 좋은 질문이에요.
물론 리소스와 프롬프트 대부분은 툴로도 처리할 수 있습니다. 하지만 MCP에서는 그것들을 따로 분리한 이유가 있습니다. 예를 들어 리소스와 프롬프트도 동적으로 사용자나 애플리케이션의 요청에 따라 변할 수 있습니다. 서버가 사용자의 요청을 기반으로 리소스를 들이거나, 특정 상황에 맞춰 맞춤형 프롬프트를 생성해서 클라이언트에 제공할 수도 있죠.

또한 리소스 알림 기능(resource notification)은 MCP의 중요한 기능 중 하나입니다. 클라이언트는 특정 리소스에 ‘구독’할 수 있고, 해당 리소스가 업데이트되면 서버는 클라이언트에 알림을 보내어 시스템 상태를 업데이트하거나 사용자에게 새로운 정보를 보여주도록 할 수 있습니다.

정리하자면, 물론 툴만으로도 많은 것을 할 수 있지만, MCP는 단순히 모델에 더 많은 정보를 주는 데 목적이 있는 것이 아니라, 애플리케이션이 서버의 기능을 더 풍부하게 활용할 수 있도록 구조를 제공하는 것입니다.

결국 중요한 건 제어권을 모델, 애플리케이션, 사용자 각각에게 명확히 부여하는 것이었습니다. 그래서 우리는 툴은 모델 제어, 리소스는 애플리케이션 제어, 프롬프트는 사용자 제어로 구분하고 있어요. 이것이 MCP가 단순한 모델 강화 수단을 넘어, 다양한 시스템 구성 요소들이 서로 명확히 협력할 수 있도록 설계된 이유입니다.

그럼, 실제 MCP를 활용한 사례는 어떻게 될까요?
다음 편에서는 해당 내용을 다뤄볼게요!