안녕하세요, 오늘은 요즘 사람들이 많이 들어봤지만, 정작 제대로 알지는 못하는 MCP에 대해서 다루어보겠습니다.
이 글에서는 MCP란 무엇인지 이해할 수 있게 그 정의와 구조를 이해해보겠습니다.
목차
1. MCP가 뭐에요?
2. MCP의 구성요소
3. 예를 들자면
MCP가 무엇인지 먼저 살펴봅시다.
MCP란, Model Context Protocol의 약자로, 직역하자면 "(AI)모델 환경 표준"입니다.
즉, 인공지능 모델을 사용할 때에 어떠한 구조로 사용할지를 정의한 것이죠. 마치 웹의 표준처럼 사용되고 있는 RESTful API처럼요. MCP는 AI 모델이 외부 데이터와 도구에 접근하고 상호작용하는 모든 과정을 표준화하는 규약입니다. 따라서 이 MCP라는 프로토콜을 알아야 하는 사람은, AI 모델을 응용하여 특정한 서비스를 개발하려고 하는 사람으로 좁혀집니다. 모두가 알아야 하는 것은 아니라는 뜻이죠. 그저 하나의 프로토콜, 하나의 규칙 집합일 뿐입니다.
그렇다면 이 MCP는 왜 만들어진걸까요? 정말 필요한 것일까요?
네, MCP는 AI가 외부의 시스템과 연결되어야 하는 모든 상황에서 쓰입니다. 점점 더 많은 기능을 AI에게 맡기면서, AI를 사용하는 서비스들은 점점 더 복잡한 구조를 가지고 다양한 시스템을 연동하게 됩니다. 이 때, MCP는 모든 Tool이나 외부 시스템이 Agent와 소통할 때 동일한 방식으로 주고받도록 표준화해줍니다. 이로써 우리는 한번 만들어둔 특정 기능이나 서비스를 확장하거나 분리해내거나, 또는 재활용할 수도 있게 되는 것이죠. AI를 사용하는 시스템이 커지면 커질수록 MCP로 인한 표준화는 더 커다란 확장성과 효율성을 제공해줄 겁니다.
MCP는 크게 Host, Client, Server, Tool로 이루어져 있습니다.
기본적으로 모든 의사 결정은 Host에서 이루어지며, 다양한 외부 시스템이나 도구는 하나의 Tool로써 Server에 담겨 있습니다. Host는 Client를 통해 Server에 있는 Tool에게 요청하고, 결과를 반환받아서 내부의 기능 흐름에 사용합니다.
MCP Host란, MCP 환경에서 실제로 사용자가 상호작용하는 중심 애플리케이션입니다.
쉽게 말해, Claude Desktop이나 AI IDE처럼 사용자가 직접 명령을 내리고 결과를 확인하는 ‘AI의 얼굴’ 역할을 합니다.
Host는 여러 클라이언트 인스턴스를 관리하면서, 사용자의 권한을 통제하고, MCP 서버와의 연결을 초기화하며, 전체 LLM 처리 흐름을 조율합니다. 이렇게 실제 리소스를 사용하며 전체 흐름을 관리하기 때문에 흔히 쓰는 아키텍처 중 Orchesrator 패턴에 따라 설계되는 경우가 많습니다.
MCP Client는 Host가 Server와 통신할 때의 매개체 역할을 합니다.
각 클라이언트는 하나의 서버와 1:1로 연결되며, 실제로 프로토콜 수준에서 메시지를 주고받고, 연결 상태와 기능 협상을 처리합니다.
즉, Host가 여러 서버와 동시에 소통할 수 있도록 각각의 통신을 담당고 관리하는 역할을 하며, 보안 경계도 관리합니다.
MCP Server는 외부 데이터 소스나 도구의 기능을 실제로 제공하는 역할을 합니다. 각 서버는 파일 시스템, 데이터베이스, API, 클라우드 서비스 등 다양한 리소스를 표준화된 방식으로 노출하고, 클라이언트의 요청에 따라 작업을 수행합니다. 서버는 독립적으로 동작하며, 필요한 리소스와 프롬프트, 도구를 관리합니다.
4. Tool (도구)
Tool은 MCP 서버가 제공하는 실제 기능 단위입니다.
예를 들어, 파일 읽기, 번역, 데이터베이스 쿼리, 이메일 전송 등 구체적인 작업을 수행하는 ‘실행 단위’입니다. LLM이 어떤 작업이 필요하다고 판단하면, 클라이언트가 서버에 해당 도구 실행을 요청하고, 결과는 다시 LLM의 컨텍스트에 통합됩니다.
그러나 이 Tool이라는 구조가 MCP에서 가장 중요한 점인데요!
왜냐하면 OpenAI가 MCP를 위해 제공해주는 openai-agents 라이브러리에서는, Host가 각 Server에게 도구에 대한 정보를 요청하고 받아서 사용할지 여부를 직접 판단하기 때문이지요.(이에 대해서는 다음 글에서 자세하게 다루겠습니다.)
이렇게 설명만 보면 이해가 어려우실 수 있으니, 예시를 들어보겠습니다.
이제는 검색도, 첨부파일에 관한 질문도, 그림 그리기도 가능해진 챗 지피티를 예시로 살펴봅시다.
(Client는 항상 Host와 Server 사이에서 요청을 전달하니 생략하겠습니다)
만약 여러분이 챗지피티에게 "화성에서 춤추는 닐 암스트롱 그려줘"라는 채팅을 보내면,
1. Host인 llm은 여러분의 채팅을 보고 각 Server에게서 가지고 있는 도구의 정보를 받습니다.
만약 단일 서버라면 해당 서버는 Host에게 "웹 검색", "첨부파일 분석", "그림 그리기" 라는 각각의 Tool에 대해서 개발자가 써놓은 주석의 설명, 입력값, 반환값 등의 정보를 가져옵니다. 이번 경우에는 "이미지 그리기" 도구를 사용해야겠군요.
각 도구의 정보를 받은 Host는 어떤 도구를 사용할지 선택하여 요청을 보냅니다.
예를 들자면, OpenAI가 가지고 있는 DALL-E가 요구하는 규칙에 맞는 입력 형식으로 요청을 보내죠.
이 요청은 클라이언트, 서버를 거쳐 Tool에게 도착하여 해당 Tool의 기능을 수행합니다.
이번 경우, DALL-E가 사용자의 쿼리를 보고 이미지를 생성하겠네요!
Tool은 결과물로 생성된 이미지 혹은 이미지가 저장된 url을 반환합니다. 서버를 통해 클라이언트를 거쳐 Host에게 도달한 이 결과물은, Host의 llm 혹은 이에 맞는 프로세스를 거쳐서 사용자에게 보여집니다. 마침내 우리가 이미지와 그걸 읽은 llm의 코멘트를 읽게 되는 것이지요.
이렇게 정리해보았듯이, MCP는 그저 하나의 규칙으로, AI를 사용한 서비스를 개발할 때의 표준일 뿐입니다. 다만 앞으로 지대한 영향력을 끼칠 규칙이죠.
MCP에는 Tool과 Server라는 방식으로 기능을 세분화하여 분리해내고 표준화하였습니다. 이를 통해서 우리는 한번 만들어둔 Tool을 계속 재사용하고 쉽게 공유할 수 있게 되었죠. 앞으로 많은 사람들이 스스로 만든 다양한 Tool을 공유하고, 사람들은 공유받은 도구들을 조합해 풍부한 기능의 서비스를 개발할 수 있을테니, 점점 더 개발이 쉬워지겠다는 생각이 듭니다.
다음 글에서는, python으로 간단한 사칙 연산과 같은 동작을 하는 mcp server를 만들어서 동작하게 해보면서 체화하는 과정을 다루겠습니다. 감사합니다.