MCP란 무엇인가요? 모델 컨텍스트 프로토콜이 AI 에이전트를 도구 및 데이터에 연결하는 방법

AI 어시스턴트들은 추론(reasoning), 코딩, 리서치, 다단계 작업 완료 능력 면에서 점점 더 좋아지고 있습니다. 하지만 모델이 똑똑해진다고 해서 사라지지 않는 기본적인 문제가 하나 있습니다.

AI 모델은 사용자의 유용한 정보와 실제 행동이 존재하는 시스템에 자동으로 접근할 수 없습니다.

회사는 GitHub, Slack, Google Drive, 데이터베이스, CRM, 내부 API, 프로젝트 관리 도구 등 수십 개의 다른 시스템에 데이터를 가지고 있을 수 있습니다. 전통적으로 개발자들은 각각의 시스템마다 맞춤형 통합(custom integrations)을 구축해야 했습니다.

바로 이 지점에서 MCP, 즉 Model Context Protocol이 등장합니다.

MCP는 AI 애플리케이션이 외부 도구 및 데이터와 연결되는 방식을 표준화하기 위해 설계된 개방형 프로토콜입니다. Anthropic은 AI 시스템과 외부 데이터 소스 간의 단편적이고 일회성 통합을 줄이는 방법으로 2024년 11월에 MCP를 도입했습니다.

MCP는 **AI 애플리케이션을 위한 표준 연결 계층(standard connection layer)**이라고 생각할 수 있습니다.

모든 AI 애플리케이션과 모든 도구마다 완전히 다른 통합을 구축하는 대신, 개발자들은 공통 프로토콜을 기반으로 구축할 수 있습니다.

그리고 이 구분이 중요합니다.

MCP는 단순히 또 다른 AI 모델이거나, 또 다른 챗봇이 아니며, 모든 API를 대체하는 것도 아닙니다. 이는 AI 애플리케이션과 외부 기능 간의 연결을 더 표준화하는 방식입니다.

MCP란 무엇인가요?

MCP는 Model Context Protocol의 약자입니다.

간단히 말해, MCP는 AI 애플리케이션이 외부 도구, 리소스 및 프롬프트를 발견하고 상호 작용할 수 있도록 하는 표준화된 프로토콜입니다.

Anthropic은 MCP를 USB-C 비유를 들어 설명합니다. USB-C가 기기들이 주변 장치에 연결할 수 있는 표준화된 방법을 제공하듯이, MCP는 AI 애플리케이션이 도구 및 데이터에 연결할 수 있는 표준화된 방법을 제공합니다.

간소화된 MCP 아키텍처는 다음과 같습니다:

AI 애플리케이션 → MCP 클라이언트 → MCP 서버 → 외부 시스템

예를 들어:

AI 코딩 어시스턴트 → MCP → GitHub

또는:

AI 에이전트 → MCP → PostgreSQL 데이터베이스

또는:

AI 어시스턴트 → MCP → 회사 지식 기반

중요한 점은 AI 애플리케이션이 모든 개별 시스템에 대해 반드시 완전히 맞춤화된 통합(custom integration)을 필요로 하지는 않는다는 것입니다.

MCP 서버는 AI 애플리케이션이 상호 작용할 수 있는 표준화된 인터페이스를 제공합니다.

MCP는 왜 만들어졌을까요?

MCP와 같은 프로토콜이 인기를 얻기 전에는, 개발자들이 AI 애플리케이션과 외부 서비스 사이에 맞춤형 통합(custom integrations)을 자주 만들었습니다.

다음 기능에 접근해야 하는 AI 어시스턴트를 구축한다고 상상해 보세요:

• GitHub
• Slack
• Google Drive
• PostgreSQL
• Jira
• 내부 회사 API

공통 통합 계층(common integration layer)이 없다면, 각 연결마다 자체 구현, 인증 로직, 스키마, 오류 처리 및 유지 관리가 필요할 수 있습니다.

이제 또 다른 AI 애플리케이션이 동일한 서비스에 접근해야 한다고 상상해 보세요.

동일한 통합 문제가 다시 발생합니다.

이것이 바로 MCP가 해결하도록 설계된 문제 중 하나입니다.

다음과 같이 생각하는 대신:

AI [앱 → 맞춤형 GitHub] 통합

AI 앱 → 맞춤형 Slack 통합

AI 앱 → 맞춤형 데이터베이스 통합

개발자들은 더욱 표준화된 패턴을 목표로 작업할 수 있습니다:

AI 앱 → MCP → GitHub

AI 앱 → MCP → Slack

AI 앱 → MCP → 데이터베이스(database)

이것이 모든 엔지니어링 작업을 없애는 것은 아닙니다. 인증(Authentication), 권한(permissions), 배포(deployment), 모니터링(monitoring), 그리고 애플리케이션별 로직은 여전히 중요합니다.

하지만 이는 AI와 도구 간의 연결을 위한 공통 프로토콜을 만듭니다.

MCP는 어떻게 작동하나요?

개괄적으로, MCP 워크플로우에는 MCP 호스트(host), MCP 클라이언트(client), 그리고 하나 이상의 **MCP 서버(server)**가 포함됩니다.

간소화된 흐름은 다음과 같습니다:

1. 사용자가 AI 애플리케이션에 작업을 부여합니다.
2. AI 애플리케이션이 외부 정보나 동작이 필요하다고 판단합니다.
3. MCP 클라이언트가 MCP 서버와 통신합니다.
4. 서버는 사용 가능한 기능을 노출합니다.
5. AI 애플리케이션이 적절한 도구나 리소스를 선택합니다.
6. MCP 서버가 요청된 작업을 수행합니다.
7. 결과가 AI 애플리케이션으로 반환됩니다.
8. 모델은 그 결과를 사용하여 작업을 계속 진행합니다.

예를 들어, AI 코딩 어시스턴트에게 다음과 같이 질문한다고 상상해 보세요:

“우리의 공개 GitHub 이슈를 확인하고 가장 시급한 버그 세 가지를 요약해 줘.”

AI는 다음을 수행해야 할 수 있습니다:

요청 이해 → GitHub 접근 → 이슈 검색 → 분석 → 요약 생성

MCP 서버가 GitHub에 대한 연결을 제공할 수 있습니다.

AI는 GitHub의 전체 내부 아키텍처를 컨텍스트 내에 가질 필요가 없습니다. MCP 서버를 통해 노출된 기능과 상호작용합니다.

MCP 호스트, 클라이언트 및 서버 설명

이 세 가지 용어는 혼동하기 쉽습니다.

MCP 호스트란 무엇인가요?
호스트는 MCP 기능을 사용하려는 AI 애플리케이션입니다.

예시로는 AI 비서, 코딩 환경 또는 에이전트 애플리케이션 등이 포함될 수 있습니다.

호스트는 전체적인 AI 경험을 관리하며 서버에 MCP 클라이언트 연결을 생성할 수 있습니다.

MCP 클라이언트는 무엇인가요?
MCP 클라이언트는 MCP 서버와 통신하는 역할을 하는 구성 요소입니다.

이는 호스트 애플리케이션 내부의 커넥터라고 생각할 수 있습니다.

호스트는 MCP 클라이언트를 통해 여러 개의 MCP 서버에 연결할 수 있습니다.

MCP 서버란 무엇인가요?
The MCP 서버는 AI 애플리케이션이 사용할 수 있는 기능을 노출합니다.

그러한 기능에는 다음이 포함될 수 있습니다:

• 외부 API 호출
• 문서 검색
• 데이터 읽기
• 데이터베이스 질의(Querying)
• 파일 접근
• 액션 수행
• 재사용 가능한 프롬프트 제공

MCP 서버가 반드시 거대한 클라우드 플랫폼일 필요는 없습니다. 유용한 기능 세트를 노출하는 비교적 작은 프로그램일 수도 있습니다.

Anthropic의 초기 MCP 생태계에는 GitHub, Google Drive, Slack, Postgres, Git, Puppeteer와 같은 시스템에 대한 예시가 포함되었습니다.

MCP 도구, 리소스 및 프롬프트

MCP를 이해하는 데 가장 중요한 부분 중 하나는 MCP 서버가 무엇을 노출할 수 있는지 아는 것입니다.

MCP 도구(Tools)
도구란 AI 애플리케이션이 호출할 수 있는 액션입니다.

예를 들어:

• GitHub 이슈 검색
• 캘린더 이벤트 생성
• 데이터베이스 질의
• 지식 기반 검색
• 메시지 전송
• 티켓 생성

도구는 특히 에이전트 워크플로우(agentic workflows)에서 중요합니다. 왜냐하면 AI 시스템이 텍스트를 생성하는 것을 넘어 실제로 외부 시스템과 상호 작용할 수 있게 해주기 때문입니다.

예를 들어, OpenAI의 현재 문서에서는 에이전트를 원격 MCP 서버에 연결하고 해당 서버가 에이전트가 호출할 수 있는 도구 정의(tool definitions)를 게시하도록 지원합니다.

MCP 리소스 (MCP Resources)

리소스는 AI 애플리케이션에 정보나 컨텍스트를 제공합니다.

이는 애플리케이션이 프로토콜을 통해 접근할 수 있는 데이터라고 생각하시면 됩니다.

리소스는 문서화 시스템, 데이터베이스, 파일 시스템 또는 다른 출처의 정보를 나타낼 수 있습니다.

핵심적인 차이점은 간단합니다:

도구(Tools)는 일반적으로 에이전트가 무언가를 하도록 합니다.

리소스(Resources)는 일반적으로 에이전트가 정보에 접근하도록 합니다.

MCP 프롬프트 (MCP Prompts)

MCP는 재사용 가능한 **프롬프트(prompts)**도 노출할 수 있습니다.

이는 AI 애플리케이션이 특정 작업을 처리하는 방식의 표준화를 돕습니다. 예를 들어, 한 조직은 다음을 위해 재사용 가능한 프롬프트를 만들 수 있습니다:

• 코드 검토 (Reviewing code)
• 고객 피드백 요약 (Summarizing customer feedback)
• 지원 티켓 분석 (Analyzing support tickets)
• 문서화 검토 (Reviewing documentation)

이는 특정 워크플로우를 애플리케이션 전반에 걸쳐 재사용하기 쉽게 만듭니다.

MCP 전송 및 통신 (MCP Transport and Communication)

개발자가 이해해야 할 또 다른 계층이 있습니다: 클라이언트와 서버가 어떻게 통신하는지입니다.

MCP 구현은 서버 배포 방식과 클라이언트 연결 방식에 따라 로컬 또는 원격 환경에서 작동할 수 있습니다. 예를 들어, OpenAI의 현재 MCP 문서는 애플리케이션 환경에서 실행되는 프로세스에 대해 HTTP뿐만 아니라 stdio를 사용하여 연결을 설명합니다.

로컬 개발 워크플로우의 경우, MCP 서버는 사용자의 컴퓨터에서 프로세스로 실행될 수 있습니다.

프로덕션 애플리케이션의 경우, MCP 서버가 원격으로 호스팅되고 네트워크를 통해 접근될 수 있습니다. 이러한 구분은 다음을 고려하기 시작할 때 중요해집니다:

• 인증 (Authentication)
• 인가 (Authorization)
• 네트워크 보안 (Network security)
• 배포 (Deployment)
• 모니터링 (Monitoring)
• 확장성 (Scaling)
• 지연 시간 (Latency)
• 신뢰성 (Reliability)

따라서 MCP는 단순히 서버를 작성하는 것에 관한 것이 아닙니다. 그 서버가 어떻게 호스팅되느냐가 주변 아키텍처에 극적인 영향을 미칠 수 있습니다.

MCP가 API와 같은가요?

아닙니다.

이것은 가장 흔한 MCP 오해 중 하나입니다.

API는 소프트웨어 시스템들이 통신할 수 있도록 하는 일반적인 메커니즘입니다.

반면, MCP는 AI 애플리케이션과 외부 컨텍스트/기능(capabilities) 간의 표준화된 상호작용을 중심으로 특별히 설계된 프로토콜입니다.

전통적인 API가 다음과 같은 엔드포인트를 노출할 수 있습니다:

GET /users

POST /orders

GET /products

반면에 MCP 서버는 도구(tools), 리소스, 프롬프트와 같이 AI 지향적인 기능들을 노출할 수 있습니다.

이 둘은 함께 작동할 수도 있습니다.

예를 들어:

AI 에이전트 → MCP 서버 → REST API → CRM

이 아키텍처에서, MCP 서버는 AI가 접하는 인터페이스 역할을 하며 기존의 API는 그 아래에 남아있습니다. 따라서 MCP를 채택한다고 해서 반드시 기존 API를 버려야 함을 의미하지 않습니다.

많은 경우, MCP는 기존 서비스 위에 놓일 수 있습니다.