Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
MCP(Model Context Protocol)는 AI 에이전트가 다양한 외부 툴과 표준화된 방식으로 연결할 수 있도록 하는 공통 프로토콜입니다. 이 프로토콜은 각기 다른 API와 인증 방식을 가진 툴들을 통합하여, 개발자가 새로운 툴을 쉽게 추가하고 에이전트의 재사용성을 높일 수 있게 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기지난 글에서는 Tool Use와 Dynamic Tool Selection에 대해 다루었습니다.
AI 에이전트는 Tool Registry에 등록된 다양한 툴 중에서 현재 작업에 적합한 툴을 Tool Selection을 통해 선택하고, Tool Calling을 거쳐 실행함으로써 실제 작업을 수행할 수 있습니다.
하지만 사용 가능한 툴의 수가 늘어날수록,
와 같은 새로운 문제가 발생합니다. 이 문제를 해결하기 위해 등장한 것이 '에이전트와 외부 툴을 표준화된 방식으로 연결하기 위한 공통 프로토콜'인 MCP(Model Context Protocol)입니다. 본 글에서는,
에 대해 살펴보겠습니다.
MCP는 Model Context Protocol의 약자입니다. MCP는
에이전트와 외부 툴을 표준화된 방식으로 연결하기 위한 공통 프로토콜입니다.
MCP는 에이전트와 툴 사이에 공통 레이어를 제공합니다.
예를 들어, MCP를 이용하면 AI 에이전트는 다음과 같은 툴과 연동할 수 있습니다.
일반 사용자용
비즈니스/개발용
이러한 툴들은 각각 다른 API와 인증 방식을 가지고 있습니다. MCP는 그 차이를 흡수하는 공통 인터페이스를 제공합니다.
Tool Use와 어떤 관계가 있는가? 현재로서는,
을 지원하는 기반 기술 중 하나로서 MCP가 주목받고 있습니다. 따라서 현재의 Agent Engineering에서 MCP는 필수적인 기반 기술 중 하나가 되어가고 있습니다.
툴은 각각 다른 API와 인증 방식을 가지고 있습니다.
기존에는,
는 문제가 있었습니다.
MCP가 이를 완전히 없애는 것은 아니지만, 에이전트와 툴의 연동을 대폭 간소화했습니다. 그 결과,
와 같은 이점을 얻을 수 있습니다. 즉,
툴마다 다른 구현을 반복하는 것이 아니라,
공통의 메커니즘을 통해 다양한 툴을 이용할 수 있게 되는 것
이 MCP의 큰 가치 중 하나입니다.
여기서 한 가지 주의해야 할 점이 있습니다.
MCP의 본질은 API를 알 필요가 없는 것이 아니라,
툴마다 다른 연결 방식을 표준화하는 것에 있습니다.
MCP는 크게 다음 3가지 요소로 구성됩니다.
이들은 각각 다른 역할을 가지면서도 연계하여 동작합니다.
MCP Host는 MCP를 이용하는 애플리케이션입니다. 예를 들면,
등이 MCP Host에 해당합니다. 사용자는 Host를 통해 에이전트와 대화합니다.
MCP Client는 Host와 MCP Server 사이를 중개하는 컴포넌트입니다. MCP Client는,
와 같은 처리를 담당합니다. 즉, MCP Client는 에이전트와 MCP Server를 연결하는 역할을 가집니다.
MCP Server는 툴에 대한 연결 처리를 제공합니다. 예를 들어,
Gmail 서버
Google Calendar 서버
Google Drive 서버
Notion 서버
Slack 서버
GitHub 서버
Salesforce 서버
등입니다. MCP 서버는,
사용 가능한 도구 목록
파라미터
실행 방법
을 Agent에게 공개합니다. Agent는 이 정보를 활용하여 Tool Selection 및 Tool Calling을 수행합니다.
이전 섹션에서는,
이라는 관계를 살펴보았습니다. 그러나 MCP를 좀 더 자세히 들여다보면,
Agent는 어디에 있고
Tool은 어디에 있는가
라는 의문이 생깁니다. MCP의 공식적인 구성은 일반적으로 다음과 같이 표현됩니다.
Tool의 위치는 명확해졌지만, 아직
Agent는 어디에 있는가
는 알 수 없습니다. 실제 Agent 애플리케이션에서는 MCP Host와 Agent가 일체화되어 작동하는 경우가 많습니다. 예를 들어,
등의 MCP Host에는 Agent와 MCP Client가 공존합니다. 따라서 다음과 같이 생각하면 이해하기 쉽습니다.
이렇게 생각하면,
Agent → MCP → Tool
이라는 단순한 관계와,
Host → Client → Server
라는 MCP의 내부 구조를 자연스럽게 연결하여 이해할 수 있습니다.
여기까지 살펴본 것처럼, Agent는 MCP Client를 통해 MCP Server와 통신합니다. 하지만 여기서 한 가지 의문이 생깁니다.
Agent는 사용 가능한 도구를 어떻게 알까요?
Agent가 처음부터 Gmail이나 Google Calendar, GitHub 같은 도구를 알고 있는 것은 아닙니다. 그래서 필요한 것이 Tool Discovery입니다.
Tool Discovery는,
사용 가능한 Tool을 발견하는 메커니즘
을 의미합니다.
(Image created by Author with Nano Banana)
Agent가 처음부터 사용 가능한 도구를 알지 못하기 때문에, Tool Discovery가 필요합니다. MCP 환경에서는 MCP Client가 MCP Server에 문의함으로써, 사용 가능한 도구나 그 정보를 얻을 수 있습니다.
(Image created by Author with Nano Banana)
Tool Discovery를 통해 발견된 도구 정보는 Tool Registry에 등록됩니다. 다시 말해,
이라는 역할의 차이가 있습니다. 그 후,
Tool Registry → Tool Selection → Tool Calling
이라는 흐름으로 Agent는 도구를 이용합니다. 즉,
Tool Discovery → Tool Registry → Tool Selection → Tool Calling
이라는 일련의 흐름을 통해, Agent는 적절한 도구를 찾고 사용할 수 있게 되는 것입니다.
이번에는 AI 에이전트를 지탱하는 기반 기술 중 하나인 MCP에 대해 살펴보았습니다. 사용 가능한 도구가 늘어나는 문제를 해결하기 위해 MCP가 등장하여, Agent와 Tool을 연결하는 기반으로서 기능하는 것을 보았습니다.
지난 기사에서는, Agent가
Tool Registry → Tool Selection → Tool Calling
이라는 흐름으로 도구를 이용하는 것을 설명했습니다.
이라는 구성의 MCP 환경에서는, MCP Client가 MCP Server에 문의함으로써, 사용 가능한 도구나 그 정보를 얻을 수 있습니다. 따라서,
Tool Discovery → Tool Registry → Tool Selection → Tool Calling
이러한 일련의 흐름을 통해, Agent는 Gmail, Google Calendar, Google Drive, GitHub, Slack 등 다양한 도구 중에서 적절한 도구를 찾아 통일적인 방식으로 사용할 수 있게 됩니다.
MCP 덕분에, Agent는 다양한 도구를 통일적인 방식으로 활용할 수 있게 되었습니다. 이는 Tool Use를 확장하는 데 매우 중요한 진전입니다. 하지만 실제 업무 작업이 복잡해짐에 따라, 이번에는 또 다른 과제가 나타납니다.
하나의 Agent만으로 모든 작업을 처리해야 하는가?
최근의 Agent Architecture에서는 단일하고 거대한 Agent에게 모든 것을 맡기기보다는, 여러 전문 Agent들에게 역할을 분담시키는 구성이 늘어나고 있습니다. 그러면 이번에는,
여러 Agent를 어떻게 안전하게 협조시킬 것인가
라는 새로운 문제가 생겨납니다. 다음 시간에는 Agent Engineering에서 또 하나의 중요한 주제인 Multi-Agent Coordination을 다루며, 여러 Agent를 어떻게 분리하고 어떻게 연계해야 하는지에 대해 살펴보겠습니다.