Anthropic의 모델 컨텍스트 프로토콜(MCP): AI 통합을 위한 ‘USB-C’ 표준 (Part 1)
날짜
April 28th, 2025
소요 시간
7분
최신 소식
소개
AI 모델은 매우 강력하지만, 그동안 기업들이 매일 사용하는 방대한 데이터와 도구들로부터는 고립되어 있었습니다. 모델을 데이터베이스, 문서 저장소, 또는 API와 연결하는 모든 새로운 통합 작업은 각각 별도의 맞춤형 솔루션을 필요로 했습니다. 이러한 단절은 다양한 환경에서 AI 시스템을 확장하는 데 큰 걸림돌이 되어왔습니다.
이 문제를 해결하기 위해 Anthropic은 2024년 말, AI 어시스턴트와 실제 데이터가 존재하는 시스템 간의 연결을 위한 개방형 표준으로 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 을 도입했습니다. Anthropic은 MCP를 _“AI 애플리케이션을 위한 USB-C 포트”_라고 설명하며, 이는 다양한 데이터 소스와 도구에 언어 모델을 표준화된 방식으로 연결할 수 있도록 해주는 단일한 통합 방식입니다.
이 글에서는 MCP가 무엇인지, 어떻게 작동하는지, 그리고 차세대 AI 기반 애플리케이션을 개발하는 개발자들에게 왜 중요한지를 살펴보겠습니다.
모델 컨텍스트 프로토콜(MCP)이란 무엇인가요?
MCP는 본질적으로 애플리케이션이 대형 언어 모델(LLM)에게 컨텍스트를 제공하는 방식을 표준화하는 오픈 프로토콜입니다. MCP의 목표는 현재의 일회성 통합 방식을 대체하여, 모든 AI 어시스턴트와 데이터 소스가 공유할 수 있는 _일반적인 인터페이스_를 만드는 것입니다. 실질적으로 MCP를 통해 개발자는 AI 모델과 데이터베이스, 파일 시스템, API, 비즈니스 애플리케이션과 같은 외부 리소스 간에 안전한 양방향 연결을 구축할 수 있습니다.
개발자는 AI가 접근해야 하는 각 데이터 소스나 API마다 별도의 맞춤형 코드를 작성하는 대신, MCP를 한 번 구현함으로써 일관된 "플러그 앤 플레이" 방식의 연결을 구축할 수 있습니다.
즉, AI 어시스턴트는 MCP 인터페이스를 통해 다른 시스템의 관련 정보를 손쉽게 참조하거나 필요한 작업을 매끄럽게 실행할 수 있다는 의미입니다.
왜 MCP가 필요했을까요?
AI 어시스턴트의 활용이 확산되면서, 가장 정교한 모델들조차도 정보 사일로에 "갇혀" 있는 경우가 많았습니다. 이들은 기업의 지식 베이스에서 데이터를 쉽게 가져오거나 업무용 소프트웨어에서 직접 작업을 수행하는 것이 쉽지 않았기 때문입니다. 개발자들은 데이터 소스와 AI 모델을 임시적으로 통합해왔지만, 이는 유지보수가 어렵고 확장성이 떨어졌습니다. MCP는 AI를 데이터에 연결하는 하나의 표준 프로토콜을 제공함으로써, 각 도구마다 별도의 맞춤형 커넥터를 개발할 필요 없이 통합을 단순화하고 일관되게 만들어줍니다. Anthropic의 설명에 따르면, "MCP는 AI 시스템과 데이터 소스를 연결하기 위한 일반적인 오픈 표준을 제공하여, 단편화된 통합 방식을 하나의 프로토콜로 대체한다."
또한, MCP는 오픈소스로 제공되어 누구나 MCP 호환 통합 기능을 개발할 수 있도록 열려 있으며, 이는 다양한 커넥터들이 지속적으로 늘어나는 생태계 형성으로 이어지고 있습니다.
MCP의 주요 이점은 다음과 같습니다.
| 주요 이점 | 설명 |
|---|---|
| 플러그인 통합 | Google Drive, Slack, GitHub, 각종 데이터베이스 등 인기 있는 시스템을 위한 사전 구축된 MCP 커넥터 라이브러리가 지속적으로 확대되고 있습니다. 개발자는 처음부터 새로 구축할 필요 없이 이러한 커넥터를 재사용할 수 있어 시간과 비용을 절감할 수 있습니다. |
| 벤더 유연성 | MCP는 특정 모델에 종속되지 않는 구조로, 애플리케이션과 LLM 사이의 중간 계층 역할을 합니다. 이를 통해 LLM 공급자나 모델을 변경하더라도 기존 통합을 재작성할 필요 없이 손쉽게 전환할 수 있습니다. |
| 보안 설계 | 안전한 데이터 접근을 위한 모범 사례를 장려하며, 데이터는 조직 내부 인프라에 안전하게 보관됩니다. MCP는 기능 협상 및 사용자 권한 제어를 포함하여 보안을 기본으로 설계되었습니다. |
요약하면, MCP의 목적은 컨텍스트 인식 AI 애플리케이션을 더 쉽게 구축할 수 있도록 지원하는 것입니다. Block과 Apollo와 같은 초기 도입자들은 이미 MCP를 자사 시스템에 통합했으며, Zed, Replit, Codium, Sourcegraph와 같은 개발자 도구 회사들도 MCP를 활용하여 자사 플랫폼을 강화하고 있다. 이를 통해 AI 에이전트가 관련 정보를 검색하고 시행착오를 줄이며 보다 적절하고 기능적인 결과물을 생성할 수 있습니다.
Anthropic은 Google Drive, Slack, Git, PostgreSQL 등 일반적인 엔터프라이즈 시스템을 위한 MCP 서버를 오픈소스로 공개하여 MCP 생태계 활성화에 기여하고 있습니다.
MCP 생태계가 성숙함에 따라 AI 시스템이 단일 애플리케이션에 국한되지 않고 다양한 도구와 데이터셋 간의 컨텍스트를 유연하게 유지하며 작동할 수 있게 되는 것입니다.
MCP 아키텍처: AI와 도구를 연결하는 방식
모델 컨텍스트 프로토콜(MCP)은 기본적으로 클라이언트–서버 아키텍처를 따르며, AI 애플리케이션과 외부 시스템(통합 대상)을 연결합니다.
다음은 MCP 아키텍처의 기본 구조입니다.
| 구성 요소 | 역할 |
|---|---|
| MCP 호스트 (LLM 애플리케이션) | 데이터/도구를 사용하고자 하는 AI 기반 애플리케이션 또는 어시스턴트이다. (예: Claude Desktop, AI 코딩 IDE, 맞춤형 채팅 인터페이스). 애플리케이션이 시작될 때 MCP 서버에 연결을 시작한다. |
| MCP 서버 (통합) | MCP 표준을 통해 특정 데이터 소스나 기능(예: 파일 접근을 위한 Google Drive, 데이터베이스 쿼리를 위한 Postgres 등)을 외부에 제공하는 경량 프로그램입니다. 각 서버는 하나의 도메인에 집중하며 독립적으로 실행됩니다. |
| MCP 클라이언트 (커넥터) | 호스트 애플리케이션 내에 상주하며, 각 MCP 서버와 1:1 연결을 유지합니다. MCP 프로토콜을 사용해 통신하며, 호스트와 서버 간의 데이터 및 결과를 중계합니다. |
이 설계는 역할을 명확하게 분리합니다.
AI 애플리케이션 개발자는 호스트 측(예: 데이터를 프롬프트나 도구 호출에 어떻게 활용할지)에 집중할 수 있고, 통합 개발자는 서버 측(예: Slack이나 Salesforce에서 데이터를 어떻게 가져올지)에 집중할 수 있습니다. 이 둘은 MCP 인터페이스에서 만납니다.
이러한 분리는 마치 마이크로서비스가 기업용 소프트웨어에서 다양한 기능을 분리하는 방식이나, LSP(Language Server Protocol)가 코드 에디터와 프로그래밍 언어의 구현을 분리하는 방식과 유사합니다.
실제로 MCP는 마이크로소프트의 LSP에서 영감을 받았습니다. LSP가 에디터와 언어 분석기 간의 통신을 표준화한 것처럼,
MCP는 AI 시스템과 컨텍스트 및 도구 제공자 간의 통신 방식을 표준화합니다.
JSON-RPC를 통한 통신
모든 MCP 연결은 상태를 유지하며 정의된 수명 주기를 따릅니다. 클라이언트가 서버에 연결하면, 먼저 초기화 핸드셰이크를 수행하여 서로의 프로토콜 버전과 홍보된 기능을 교환합니다. 이 핸드셰이크는 클라이언트와 서버가 서로 지원하는 기능에 대해 합의하도록 보장합니다. 예를 들어, 서버는 "리소스" 또는 "도구" 기능을 제공하는지 선언하고, 클라이언트는 "루트"와 같은 특정 선택적 동작(서버의 접근 범위를 특정 하위 리소스로 제한하는 방식)을 지원하는지를 선언합니다.
초기화가 완료되면, 연결은 메시지 교환 단계로 넘어가며, 호스트와 서버는 요청이나 단방향 알림을 자유롭게 주고받을 수 있습니다. 양측 모두 작업이 완료되면 연결을 정상적으로 종료할 수 있지만(또는 예기치 않은 연결 종료를 처리할 수 있음), 일반적으로 MCP 서버는 지속적으로 실행되며 AI 어시스턴트가 활성화되어 호스트는 연결을 유지합니다.
MCP 프로토콜은 전송 수단에 구애받지 않고 즉, 다양한 통신 채널 위에서 작동할 수 있다. MCP가 지원하는 주요 전송 방식은 두 가지입니다.
- Stdio(표준 입출력) 전송:
프로세스의 표준 입력/출력 스트림을 사용하여 통신합니다.
로컬 통합에 이상적이며, 예를 들어 MCP 호스트가 같은 머신에서 서버 프로세스를 생성하고 파이프를 통해 통신할 수 있다. 같은 머신이나 같은 컨테이너 환경에서 단순하고 효율적인 접근 방식입니다. (이는 LSP 서버가 Stdio을 통해 통신 하위 프로세스로 실행되는 방식과 유사합니다.)
- HTTP + SSE 전송:
원격 또는 클라우드 기반 서버에 적합한 방식입니다. 클라이언트에서 서버로의 방향을 위한 HTTP POST 요청, 서버에서 클라이언트로의 스트리밍 메시지를 위한 서버 전송 이벤트를 사용합니다. 실제, 호스트는 MCP 서버가 호스팅된 HTTP 엔드포인트로 요청을 POST하고, 서버는 SSE 스트림을 통해 응답이나 알림을 푸시합니다. 이 방식을 통해 MCP를 웹 환경에서도 적절한 인증을 거쳐 사용할 수 있으며, 기업 방화벽이나 클라우드 함수 환경 뒤에서도 운영할 수 있습니다.
전송 방식과 무관하게, 모든 메시지는 내부적으로 JSON-RPC 페이로드이다. JSON-RPC는 MCP가 활용하는 몇 가지 기본 메시지 유형을 정의합니다.
- 요청: 응답을 기대하는 메시지
- 응답: 결과 또는 오류를 포함하는 메시지
- 알림: 응답을 기대하지 않는 일방향 메시지.
예를 들어, 호스트가 파일 시스템 서버로부터 사용 가능한 파일 목록을 가져오고 싶을 때, 다음과 같은 요청 메시지를 보냅니다.
json{ "jsonrpc": "2.0", "id": 42, "method": "resources/list", "params": {} }
그리고 서버가 요청을 처리할 수 있다면, 다음과 같은 결과 메시지로 응답합니다.
json{ "jsonrpc": "2.0", "id": 42, "result": { "resources": \[ { "uri": "[file:///path/to/file1.txt](file:///\\path\to\file1.txt)", "name": "file1.txt" }, { "uri": "[file:///path/to/file2.txt](file:///\\path\to\file2.txt)", "name": "file2.txt" } \] } }
이 가상의 JSON 교환에서 "method": "resources/list"는 사용 가능한 리소스를 나열하는 MCP 작업에 해당합니다. 서버는 각 리소스가 URI(및 사람이 읽을 수 있는 이름을 포함할 수 있음)로 식별된 리소스 설명자 목록을 포함하는 JSON 객체를 반환합니다. id 필드는 응답을 원래 요청과 연결하는 역할을 합니다. 이 JSON-RPC 구조 덕분에 MCP를 준수하는 클라이언트와 서버는 서로를 쉽게 이해할 수 있습니다. 새로운 유형의 서버가 등장하더라도, MCP에서 정의한 표준 메서드 이름과 스키마를 사용하기만 하면 기존 호스트와 별도의 맞춤형 코드 없이 상호 작용할 수 있습니다.
기능 및 특징
MCP의 강력한 측면 중 하나는 서버가 호스트에(또는 그 반대로) 제공할 수 있는 기능 세트를 확장할 수 있다는 점입니다. MCP 명세서는 통합 방식에 따라 조합할 수 있는 몇 가지 기능 범주를 정의하고 있습니다.
| 기능 | 설명 |
|---|---|
| 리소스 | 모델이 사용할 수 있는 읽기 전용 컨텍스트로 데이터 또는 콘텐츠(예: 문서, 파일, DB 레코드 등)를 제공합니다. 각 리소스는 고유한 URI를 가지며, 텍스트 형식일 수도 있고 바이너리 형식일 수도 있습니다. 예시: 파일을 제공하는 Google Drive MCP 서버 이 구성 요소는 "모델이 활용할 수 있는 정보에는 무엇이 있는가?" 라는 질문에 답하는 데 도움을 줍니다. |
| 프롬프트 | 서버가 템플릿화된 프롬프트나 대화 흐름을 제공할 수 있도록 합니다. 사전 정의된 워크플로우나 도메인 특화 구조로 모델을 안내하는 데 유용합니다. 예시: 문의를 처리하기 위한 고객 지원 템플릿. |
| 도구 | 서버를 통해 외부에 공개된 호출 가능한 동작/함수(callable actions/functions)를 나타냅니다 (플러그인 또는 함수 호출 방식과 유사). AI는 도구 이름과 매개변수(parameters)를 전달하고, 서버는 이를 실행합니다. 예시: 캘린더 서버에서 이벤트 생성, Slack 서버에서 메시지 전송 등. 이를 통해 AI가 제어 가능한 방식으로 작업을 수행할 수 있도록 합니다. |
| 샘플링 | 서버가 호스트에게 모델 출력을 생성해 달라고 요청할 수 있도록 합니다. 이는 복잡한 워크플로우(예: 리서치 에이전트)에서 유용하며, 중간 작업을 다시 LLM으로 위임함으로써 반복적이거나 다중 에이전트 기반의 추론을 가능하게 합니다. |
이러한 기능들은 연결 핸드셰이크 과정에서 협상됩니다. MCP 서버는 자신이 지원하는 기능들을 홍보합니다. 예를 들어, 순수 읽기 전용 데이터 서버는 "리소스"만 선언할 수 있고, 인터랙티브 서비스는 "리소스"와 "도구" 모두를 선언할 수 있습니다. 클라이언트도 자신이 처리할 수 있는 기능을 홍보합니다 (일부 경량 클라이언트는 모든 기능을 구현하지 않을 수 있습니다). 이러한 협상 과정을 통해 양측은 서로 무엇을 기대할 수 있는지 명확히 알게 됩니다.
그 후 프로토콜은 각 기능 유형에 대해 구체적인 메서드를 정의합니다. 예를 들어, 서버가 리소스를 지원한다면 "사용 가능한 리소스 리스트" 또는 "리소스 콘텐츠 읽기" 같은 메서드를 구현해야 합니다. 서버가 도구를 지원한다면 "사용 가능한 도구 리스트" 및 "도구 호출하기" 메서드를 구현해야 합니다. 이 모든 메서드는 MCP 명세서에 따라 표준화되어 있어, 호스트가 서로 다른 서버에서도 일관되게 호출할 수 있도록 되어 있습니다.
파이썬에서 모델 컨텍스트 프로토콜(MCP)
아래는 텍스트 기반 리소스(짧은 문서)를 제공하는 MCP 서버와 STDIO를 통해 연결하여 해당 리소스를 가져오고, 그 콘텐츠를 OpenAI API에 프롬프트로 사용하는 클라이언트 파이썬을 사용한 포괄적인 예제입니다. 공식 MCP 파이썬 SDK(MCP 서버/클라이언트 및 STDIO 전송을 지원)를 사용하고, 모델 호출을 위해 OpenAI 파이썬 SDK를 사용합니다. 예제는 서버 코드와 클라이언트 코드를 별도로 구성하고, 주석을 포함하며, 오류 처리와 로깅에 대한 최고 모범 사례를 따릅니다.
예제 개요
- MCP 서버 (server.py) – 하나 이상의 텍스트 문서를 제공함으로써 MCP '리소스' 기능을 구현합니다. MCP SDK의 FastMCP를 사용하여 리소스 URI와 검색 로직을 정의합니다.
- MCP 클라이언트 (client.py) – MCP SDK를 사용하여 서버를 (STDIO를 통해) 실행하고 상호작용합니다. 클라이언트는 사용 가능한 리소스를 나열하고, 리소스의 내용을 읽은 후 해당 내용을 컨텍스트로 하여 프롬프트를 생성합니다. 이 프롬프트는 OpenAI SDK를 사용해 OpenAI API(예: GPT-4)로 전송되며, 모델의 응답이 출력됩니다.
- OpenAI API 통합 – 검색된 리소스 내용을 포함하는 채팅 완료 요청(chat completion request)을 생성하여 RAG 흐름을 구현합니다. OpenAI API 키는 로컬 사용을 위해 환경 변수에 설정되어 있다고 가정합니다.
Newsletter
더 보기
![[Recap] UPP Global Technology JSC Establishing Anniversary](/homepage/news-section/new-4.webp)
대화하기
원하신 정보를 이메일로 보내드립니다
이메일을 입력해 주세요
원하시는 내용을 입력해 주세요
Hanoi, Vietnam
Web3 Tower, No. 15, Alley 4, Duy Tan, Cau Giay, Hanoi, Vietnam