AI에서 MCP는 무엇을 의미하나요? 모델 컨텍스트 프로토콜 설명

AI에서 MCP는 무엇을 의미하나요?

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

이는 AI 애플리케이션을 파일, 데이터베이스, 검색 도구, 캘린더, 코드 저장소 및 비즈니스 소프트웨어와 같은 외부 시스템에 연결하기 위한 오픈 소스 표준입니다. 공식 MCP 문서에서는 이를 USB-C 포트에 비유합니다. 모든 조합마다 새 케이블이 필요한 대신, 서로 다른 장치가 동일한 연결 표준을 사용할 수 있다는 의미입니다.

이러한 비유는 유용하지만 MCP를 실제보다 단순하게 느끼게 할 수도 있습니다.

MCP는 AI 모델이나 애플리케이션이 아니며 API를 대체하지도 않습니다. 이는 호환되는 AI 애플리케이션과 서버가 사용하는 통신 표준입니다. 애플리케이션이 사용자의 요청을 이해하려면 여전히 언어 모델이 필요하며, 연결된 서비스도 대개 내부적으로 기존 API에 의존합니다.

보다 정확히 정의하면 다음과 같습니다.

MCP는 AI 애플리케이션이 외부 도구와 데이터 소스를 탐색하고 연결하며 정보를 교환하는 방식을 표준화합니다.

여기서 context라는 단어가 중요합니다. 언어 모델은 학습 데이터에 포함되어 있거나 현재 상호작용 중 제공된 정보만 알고 있습니다. MCP를 사용하면 현재 데이터베이스 레코드, 로컬 파일 또는 실시간 API 요청의 결과와 같은 추가 컨텍스트에 AI 애플리케이션이 접근할 수 있습니다. 필요한 경우에 한해서 말입니다.

Model Context Protocol은 왜 만들어졌나요?

MCP가 등장하기 전에는 개발자가 AI 애플리케이션과 외부 서비스의 각 조합마다 별도의 통합을 구축하는 것이 일반적이었습니다.

Google Calendar, GitHub, 고객 데이터베이스 및 내부 결제 시스템을 사용해야 하는 AI 어시스턴트를 생각해 보세요. 각 통합에는 고유한 API 형식, 인증 절차, 함수 정의 및 오류 처리 규칙이 있을 수 있습니다.

이제 다른 AI 어시스턴트를 위해 동일한 연결을 다시 구축한다고 생각해 보세요.

MCP는 이러한 반복적인 통합 작업을 줄이려고 합니다. 서비스는 MCP 서버를 통해 기능을 제공할 수 있고, 호환되는 AI 애플리케이션은 공유 프로토콜을 통해 연결할 수 있습니다.

그렇다고 개발자가 통합 구축을 중단할 수 있다는 뜻은 아닙니다. 여전히 누군가는 MCP 서버를 구현하고, 기본 서비스에 연결하며, 자격 증명을 관리하고, 요청을 검증하고, 시스템을 유지 관리해야 합니다. 이점은 재사용입니다. 어떤 기능이 프로토콜을 따르면 여러 호환 AI 호스트에 더 쉽게 연결할 수 있습니다.

도구, 데이터 소스 및 AI 클라이언트의 수가 늘어나기 시작할 때 MCP의 가치가 가장 커집니다. 하나의 안정적인 서비스에 연결된 단일 애플리케이션이라면 직접 API 통합이 여전히 더 간단한 선택일 수 있습니다.

MCP 작동 방식: 호스트, 클라이언트 및 서버

MCP는 클라이언트-서버 아키텍처를 사용하지만 세 가지 구성 요소가 관여하기 때문에 용어가 혼동될 수 있습니다.

MCP 호스트

호스트는 사용자가 상호작용하는 AI 애플리케이션입니다. 채팅 어시스턴트, 코딩 환경, 데스크톱 애플리케이션 또는 맞춤형 AI 에이전트일 수 있습니다.

호스트는 대화를 조정하고, 언어 모델과 통신하며, 권한을 관리하고, 사용할 수 있는 MCP 연결을 결정합니다.

MCP 클라이언트

MCP 클라이언트는 호스트 내부에서 MCP 서버와의 연결을 유지하는 구성 요소입니다.

공식 MCP 아키텍처에 따르면 호스트는 일반적으로 서버마다 별도의 클라이언트 연결을 생성합니다. 애플리케이션이 파일 시스템 서버와 캘린더 서버에 연결되면 두 개의 MCP 클라이언트를 관리합니다.

MCP 서버

MCP 서버는 MCP 클라이언트가 특정 기능을 사용할 수 있도록 제공하는 프로그램입니다. 사용자 장치에서 로컬로 실행되거나 다른 서버에서 원격으로 실행될 수 있습니다.

MCP 서버는 세 가지 핵심 유형의 기능을 제공할 수 있습니다.

• 도구: 데이터베이스 조회, 캘린더 일정 생성 또는 메시지 전송과 같은 실행 가능한 함수입니다.
• 리소스: 파일, 데이터베이스 레코드 또는 API 응답처럼 애플리케이션이 읽을 수 있는 정보입니다.
• 프롬프트: 모델 상호작용을 구성하는 데 도움이 되는 재사용 가능한 템플릿입니다.

호스트와 서버는 먼저 서로 지원하는 프로토콜 기능을 협상합니다. 그런 다음 클라이언트가 사용 가능한 기능 목록을 요청할 수 있습니다. 모델이 특정 도구가 관련 있다고 판단하면 호스트는 구조화된 요청을 MCP 클라이언트를 통해 올바른 서버로 전달합니다.

결과는 AI 애플리케이션으로 돌아가 모델의 다음 응답을 위한 추가 컨텍스트가 됩니다.

요청부터 도구 결과까지: 실제 MCP 예시

개발자가 내부 AI 어시스턴트에 다음과 같이 요청한다고 가정해 보겠습니다.

“이번 달 API 지출을 확인하세요. 예산보다 20% 이상 많으면 엔지니어링 팀에 알림을 생성하세요.”

간소화한 MCP 워크플로는 다음과 같을 수 있습니다.

1. AI 애플리케이션이 요청을 받아 언어 모델로 보냅니다.
2. MCP 클라이언트는 연결된 금융 서버가 get_api_usage 및 get_budget_limit을 제공한다는 사실을 확인합니다.
3. 모델은 해당 도구를 선택하고 필요한 날짜 범위를 제공합니다.
4. MCP 서버는 회사의 결제 API를 호출하고 현재 지출액과 예산을 반환합니다.
5. 모델은 지출액이 한도를 20% 이상 초과하는지 계산합니다.
6. 알림이 필요하면 애플리케이션은 create_alert와 같은 연결된 메시징 도구를 식별합니다.
7. 이 작업은 외부 시스템을 변경하므로 애플리케이션은 사용자에게 확인을 요청할 수 있습니다.
8. 승인 후 메시징 서버가 기본 메시징 API를 호출합니다.
9. 모델은 사용자에게 확인한 내용과 수행한 작업을 알려 줍니다.

MCP는 이 과정의 중간 단계, 즉 도구 탐색, 입력 요구 사항 설명, 도구 호출 및 구조화된 결과 반환을 표준화합니다.

MCP가 직접 계산을 수행하거나 언어 모델을 제공하거나 결제 및 메시징 API를 대체하는 것은 아닙니다.

MCP vs API vs 함수 호출 vs RAG

이 용어들은 종종 서로 경쟁하는 기술로 소개됩니다. 실제로는 서로 다른 계층에서 작동하며 하나의 애플리케이션에 함께 사용되는 경우가 많습니다.

MCP는 API를 대체하나요?

아니요. MCP와 API는 서로 관련 있지만 다른 문제를 해결합니다.

API는 특정 서비스를 호출하는 방법을 정의합니다. 예를 들어 결제 API는 계정 사용량을 반환하는 엔드포인트를 정의할 수 있습니다.

MCP는 AI 애플리케이션이 호환 서버가 제공하는 기능을 탐색하고 사용하는 방법을 정의합니다. 해당 서버는 실제 데이터를 가져오기 위해 결제 API를 호출할 수 있습니다.

다시 말해 다음과 같습니다.

API는 소프트웨어를 서비스에 연결합니다. MCP는 AI 애플리케이션이 공통 프로토콜을 통해 여러 서비스와 연동하도록 돕습니다.

애플리케이션에 하나의 고정된 기능만 필요하다면 직접 API 통합이 더 빠르고 쉬울 수 있습니다. 개발자가 여러 AI 클라이언트에서 도구를 재사용하거나 사용 가능한 기능을 동적으로 변경하려는 경우에는 MCP가 더 매력적인 선택이 됩니다.

MCP는 함수 호출과 같은 것인가요?

아니요. 함수 호출은 일반적으로 모델의 기능입니다. 개발자가 하나 이상의 함수를 설명하면 모델은 해당 함수를 사용해야 한다고 판단할 때 구조화된 인수를 생성합니다.

MCP는 이 과정 주변에서 작동합니다. 모든 도구를 애플리케이션에 하드코딩하지 않고 연결된 서버에서 도구 정의를 탐색하도록 애플리케이션을 지원할 수 있습니다.

모델은 여전히 함수 호출 또는 도구 호출을 사용해 MCP가 제공하는 도구를 선택할 수 있습니다.

MCP는 RAG의 한 유형인가요?

아니요. 검색 증강 생성, 즉 RAG는 관련 정보를 검색해 모델이 답변하기 전에 모델의 컨텍스트에 추가하는 방법입니다.

MCP 서버는 RAG 시스템의 일부가 되는 문서 검색 도구를 제공할 수 있습니다. 그러나 MCP는 문서 색인 방식, 결과 순위 지정 방식 또는 검색된 텍스트를 프롬프트에 추가하는 방식을 결정하지 않습니다.

MCP는 요청과 결과를 전달할 수 있습니다. 검색 작업은 검색 시스템이 수행합니다.

MCP가 할 수 있는 일과 할 수 없는 일

MCP는 호환 애플리케이션 간에 도구를 더 쉽게 재사용하도록 합니다. 또한 애플리케이션이 하드코딩된 연결에 전적으로 의존하지 않고 사용 가능한 도구와 필수 입력을 탐색하도록 할 수 있습니다.

하지만 흔히 제기되는 몇 가지 주장은 과장되어 있습니다.

MCP는 다음을 수행하지 않습니다.

• MCP 클라이언트 지원이 없는 애플리케이션을 호환 가능하게 만들지 않습니다.
• 기본 API나 비즈니스 로직의 필요성을 없애지 않습니다.
• 모든 인증 및 권한 요구 사항을 자동으로 처리하지 않습니다.
• 모델이 올바른 도구를 선택한다고 보장하지 않습니다.
• 도구가 정확한 데이터를 반환한다고 보장하지 않습니다.
• 타사 서버를 기본적으로 안전하게 만들지 않습니다.
• 통합을 모니터링하고 업데이트하며 유지 관리할 필요를 없애지 않습니다.
• 연결된 시스템 간에 모든 데이터를 자동으로 공유하지 않습니다.

또한 모델에 연결된 모든 서비스에 대한 제한 없는 접근 권한을 부여하지도 않습니다. 호스트는 연결할 서버를 제어하며, 서버 기능과 사용자 권한에 따라 무엇을 읽거나 변경할 수 있는지가 결정됩니다.

개발자는 언제 MCP를 사용해야 하나요?

애플리케이션이 여러 도구나 데이터 소스에 연결해야 할 때, 특히 이러한 기능을 서로 다른 AI 호스트에서 재사용할 수 있어야 할 때 MCP를 고려할 가치가 있습니다.

일반적인 상황은 다음과 같습니다.

• 문서, 데이터베이스 및 지원 티켓을 검색하는 내부 어시스턴트.
• 저장소, 이슈 트래커 및 모니터링 시스템을 사용하는 코딩 에이전트.
• 여러 실시간 데이터 소스를 조회하는 연구 애플리케이션.
• 레코드를 읽고 다른 소프트웨어에서 승인된 작업을 수행하는 비즈니스 에이전트.
• 여러 MCP 호환 클라이언트에서 서비스가 작동하기를 원하는 도구 제공업체.

애플리케이션에 하나의 좁은 워크플로만 있거나, 하나의 서비스만 사용하거나, 모든 요청을 정밀하게 저수준 제어해야 한다면 직접 API 통합이 더 나은 선택일 수 있습니다. MCP 서버를 추가하면 배포, 보안 설정, 테스트 및 관찰이 필요한 구성 요소가 하나 더 생깁니다.

MCP는 일부 통합 작업의 반복을 줄여 줍니다. 그러나 아키텍처상의 절충점을 없애지는 않습니다.

MCP는 안전한가요?

MCP는 자동으로 안전하거나 위험해지지 않습니다. 보안은 호스트, 서버, 기본 서비스, 인증 흐름 및 각 작업에 부여된 권한에 따라 달라집니다.

연결된 서버는 AI 애플리케이션으로부터 민감한 정보를 받을 수 있습니다. 쓰기 권한이 있는 도구는 파일 변경, 메시지 전송, 레코드 생성 또는 기타 외부 작업을 수행할 수도 있습니다.

공식 MCP 보안 가이드에서는 토큰 전달, 서버 측 요청 위조, 세션 탈취, 손상된 로컬 서버 및 혼동된 대리인 공격 등의 위험을 다룹니다. 이는 구현상의 위험이며, 시스템이 표준 프로토콜을 사용한다는 이유만으로 사라지는 이론적 문제가 아닙니다.

개발자는 다음과 같은 기본 통제 장치를 적용해야 합니다.

• 신뢰하고 검증할 수 있는 서버에만 연결합니다.
• 각 서버에 필요한 최소 권한만 부여합니다.
• 읽기 전용 도구와 데이터를 변경하는 도구를 분리합니다.
• 민감하거나 파괴적인 작업에는 확인을 요구합니다.
• 도구 입력과 출력을 검증합니다.
• 자격 증명을 프롬프트와 도구 설명에 포함하지 않습니다.
• 조사와 감사를 위해 도구 호출을 기록합니다.
• 원격 서버로 전송될 수 있는 정보를 검토합니다.

OpenAI 역시 맞춤형 MCP 서버가 데이터를 수신하고 외부 작업을 수행할 수 있다고 경고하며, 신뢰할 수 있는 서버에만 연결할 것을 권장합니다. 현재 구현에서는 ChatGPT 대화에서 쓰기 작업 전에 확인이 필요하지만, 모든 MCP 클라이언트가 동일한 정책을 적용한다고 가정해서는 안 됩니다. OpenAI의 MCP 문서

2026년에 MCP에 어떤 변화가 있었나요?

2026년 7월 기준으로 최신 안정 MCP 사양은 2025년 11월 25일에 공개된 버전입니다. 공식 프로젝트는 그 이후 다른 사양 버전을 발표하지 않았다고 밝혔습니다. 2026 MCP 로드맵은 이미 안정 프로토콜에서 보장되는 기능이 아니라 계획된 작업을 설명합니다.

현재 사양은 두 가지 표준 전송 방식을 정의합니다.

• stdio: 로컬 프로세스와 통신하는 데 사용됩니다.
• Streamable HTTP: 원격 MCP 서버에 사용됩니다.

Streamable HTTP는 이전 HTTP+SSE 전송 방식을 대체했지만, 클라이언트와 서버는 하위 호환성을 유지할 수 있습니다. 현재 전송 사양에는 인증, 오리진 검증, 로컬 네트워크 바인딩 및 세션 처리에 관한 요구 사항과 권장 사항도 포함되어 있습니다.

MCP의 거버넌스도 변경되었습니다. 2025년 12월 프로토콜은 Linux Foundation의 Agentic AI Foundation 설립 프로젝트가 되었습니다. 재단은 10,000개가 넘는 MCP 서버가 공개되었으며 ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor 및 Visual Studio Code를 비롯한 제품 전반에서 채택되었다고 보고했습니다. Linux Foundation 발표

2026년 로드맵은 전송 확장성, 에이전트 통신, 거버넌스 및 엔터프라이즈 준비라는 네 가지 영역에 집중합니다. 감사 추적, SSO 통합 인증, 구성 이식성 및 게이트웨이 동작은 여전히 해결 중인 엔터프라이즈 과제에 포함됩니다.

마지막 요점이 중요합니다. MCP는 로컬 개발자 도구를 위한 실험 단계를 넘어섰지만, 엔터프라이즈 보안 및 운영 모델의 일부는 여전히 성숙해지는 과정에 있습니다.

MCP 애플리케이션에서 GPT Proto의 역할

GPT Proto와 MCP는 AI 애플리케이션의 서로 다른 계층에 속합니다.

MCP는 애플리케이션을 외부 도구와 컨텍스트에 연결합니다. 애플리케이션이 요청을 이해하고, 작업을 선택하고, 최종 응답을 생성하려면 여전히 모델이 필요합니다.

이 모델은 모델 API 제공업체를 통해 이용할 수 있습니다. GPT Proto 모델 카탈로그를 사용하는 개발자는 추론 계층에서 텍스트 모델과 추론 모델 중 선택할 수 있으며, MCP 서버는 외부 시스템 연결을 처리합니다.

간소화된 설정에는 다음이 포함될 수 있습니다.

• MCP 호스트 역할을 하는 AI 애플리케이션.
• 추론과 생성을 위해 GPT Proto를 통해 액세스하는 언어 모델.
• 호스트가 관리하는 하나 이상의 MCP 클라이언트.
• 외부 도구와 데이터를 제공하는 MCP 서버.
• 이러한 서버가 내부에서 사용하는 기존 API.

두 계층은 상호 보완적입니다. 공통 모델 API를 사용하면 애플리케이션의 모델을 테스트하거나 변경하기가 쉬워지고, MCP는 해당 애플리케이션을 여러 도구에 연결할 때 반복 작업을 줄일 수 있습니다.