Model Context Protocol (MCP)이란? AI와 도구 및 데이터를 연결하는 표준

Model Context Protocol (MCP)은 AI 애플리케이션이 외부 도구, 데이터, 프롬프트 및 기타 기능을 일관된 인터페이스를 통해 연결할 수 있게 하는 개방형 표준입니다. 모든 모델‑시스템 조합마다 맞춤형 통합을 구축하는 대신, 개발자는 AI 호스트와 MCP 서버 간에 공유 프로토콜을 구현할 수 있습니다.

MCP는 종종 AI를 위한 범용 커넥터로 설명되지만, 그 비유는 완전하지 않습니다. 프로토콜은 단순히 데이터를 이동시키는 것이 아니라, 참여자들이 기능을 설정하고, 리소스와 동작을 공개하며, 구조화된 메시지를 교환하고, 보안 경계를 유지하는 방식을 정의합니다. 이는 AI 어시스턴트와 에이전트를 위한 신흥 인프라의 중요한 부분이 됩니다.

MCP가 존재하는 이유

모델 자체만으로는 기업의 비공개 문서를 확인하거나, 로컬 저장소를 검사하거나, 실시간 데이터베이스에 질의하거나, 내부 서비스를 호출할 수 없습니다. 개발자들은 과거에 이러한 기능을 일회성 플러그인 및 애플리케이션 전용 API를 통해 연결했습니다.

이러한 접근 방식은 통합 문제를 야기합니다. 10개의 AI 애플리케이션이 각각 10개의 시스템에 연결해야 한다면, 팀은 수십 개의 맞춤형 어댑터를 유지하게 될 수 있습니다. 각 어댑터는 도구, 컨텍스트, 인증, 오류 및 업데이트를 서로 다르게 표현할 수 있습니다.

MCP는 공통 계약을 만듭니다. MCP와 호환되는 애플리케이션은 알려진 형식으로 기능을 제공하는 MCP 서버와 통신할 수 있습니다. 공식 Model Context Protocol 사양이 프로토콜을 정의하고, 개별 호스트와 서버는 지원할 기능 및 보안 정책을 결정합니다.

MCP 아키텍처

MCP는 AI 애플리케이션의 대화 및 모델 로직을 각 데이터 소스나 서비스에 필요한 통합 로직과 분리합니다. 호스트는 동시에 여러 클라이언트 연결을 유지할 수 있습니다—파일 시스템 서버용 하나, 데이터베이스 서버용 하나, 비즈니스 애플리케이션용 또 하나—그리고 일관된 인터페이스를 통해 그 기능들을 모델에 제공합니다.

서버는 반드시 원격 인터넷 서비스일 필요는 없습니다. 데스크톱 애플리케이션 옆에서 로컬로 실행되거나, 기업 네트워크 내부에서, 혹은 원격 서비스로 운영될 수 있습니다. 이러한 배포 선택은 전송 및 신뢰 경계를 바꾸지만, 핵심 관계는 변하지 않습니다: 클라이언트는 서버로부터 기능을 발견하고, 구조화된 메시지를 교환합니다.

MCP는 호스트‑클라이언트‑서버 아키텍처를 사용합니다.

• 호스트: 사용자가 상호작용하는 AI 애플리케이션으로, 예를 들어 어시스턴트, 코딩 환경, 또는 에이전트 플랫폼 등이 있습니다.
• 클라이언트: 호스트가 특정 MCP 서버와 연결을 유지하기 위해 만든 프로토콜 구성 요소입니다.
• 서버: 선택된 도구, 리소스 또는 프롬프트를 MCP 클라이언트에 제공하는 프로그램입니다.

호스트는 동시에 여러 서버에 연결할 수 있습니다. 한 서버는 파일 저장소에 대한 접근을 제공하고, 다른 서버는 프로젝트 관리 시스템에, 또 다른 서버는 내부 데이터베이스에 접근을 제공합니다. 호스트는 사용자 경험, 모델 오케스트레이션, 동의 및 모델 컨텍스트에 배치되는 정보를 책임집니다.

메시지는 JSON-RPC 규약을 사용해 구조화됩니다. 초기화 과정에서 참여자들은 프로토콜 버전과 기능을 협상합니다. 이 협상이 중요한 이유는 클라이언트와 서버가 모든 선택적 기능을 구현할 필요가 없기 때문입니다.

도구, 리소스 및 프롬프트

MCP는 서버가 제공하는 기능을 여러 기본 요소로 조직합니다. 가장 친숙한 세 가지는 도구, 리소스 및 프롬프트입니다.

도구

도구는 AI 애플리케이션이 호출할 수 있는 실행 가능한 함수입니다. 예시로는 고객 데이터베이스 검색, 이슈 생성, 쿼리 실행, 현재 재고 조회 등이 있습니다. 도구 정의에는 이름, 설명 및 입력 스키마가 포함되어 모델과 런타임이 어떤 인수가 필요한지 알 수 있습니다.

도구 사용은 외부 시스템을 변경할 수 있으므로 호스트는 의미 있는 설명을 표시하고, 입력을 검증하며, 권한을 적용하고, 중요한 작업에 대해서는 확인을 요구해야 합니다.

리소스

리소스는 애플리케이션이 읽을 수 있는 컨텍스트이며, 파일, 데이터베이스 레코드, 문서 페이지 또는 생성된 보고서가 해당됩니다. 리소스는 식별자를 사용하고 이름 및 미디어 유형과 같은 메타데이터를 노출할 수 있습니다. 이를 통해 호스트는 모든 읽기 작업을 동작으로 가장하지 않고도 정보를 발견하고 검색할 수 있는 표준화된 방법을 제공합니다.

프롬프트

프롬프트는 서버가 호스트에 제공하는 재사용 가능한 템플릿 또는 워크플로우입니다. 사용자가 기능을 올바르게 호출하도록 돕거나, 구조화된 인수를 제공하거나, 도메인 특화 지시와 관련 컨텍스트를 결합하는 데 활용될 수 있습니다.

MCP는 반대 방향의 기능도 지원합니다. 협상된 내용에 따라 서버가 호스트에게 모델 완성이나 사용자 입력을 요청할 수 있습니다. 중요한 설계 원칙은 모든 참가자가 모든 작업을 수행할 수 있다고 가정하지 않고 명시적인 기능 협상을 하는 것입니다.

MCP 도구 호출 시 어떤 일이 일어나나요?

리포지터리 분석 서버에 연결된 AI 코딩 어시스턴트를 생각해 보십시오.

1. 호스트가 MCP 서버에 연결하고 지원되는 기능을 협상합니다.
2. 클라이언트가 사용 가능한 도구 목록을 요청합니다.
3. 서버가 입력 스키마를 포함한 구조화된 도구 정의를 반환합니다.
4. 호스트가 선택된 도구 설명을 모델에 제공할 수 있게 합니다.
5. 모델이 함수 호출을 제안합니다(예: 특정 함수에 대한 참조 검색).
6. 호스트가 정책을 확인하고 필요 시 사용자에게 승인을 요청합니다.
7. 클라이언트가 검증된 요청을 서버에 전송합니다.
8. 서버가 작업을 수행하고 구조화된 콘텐츠 또는 오류를 반환합니다.
9. 호스트가 다음 단계에서 모델에 제공할 결과의 일부를 결정합니다.

MCP는 교환을 표준화하지만 모델이 도구를 호출할 수 있는지 여부를 결정하지는 않습니다. 그 결정은 호스트와 그 정책 계층에 달려 있습니다.

MCP는 API를 대체하지 않습니다

MCP 서버는 종종 기존 API, 소프트웨어 개발 키트, 명령줄 도구 또는 데이터베이스 드라이버를 래핑합니다. 이러한 기본 인터페이스가 실제 작업을 수행합니다. MCP는 그 위에 AI 중심의 발견 및 상호작용 계층을 추가합니다.

이 차이는 MCP가 REST, GraphQL 및 기타 애플리케이션 인터페이스와 보완적임을 설명합니다. 결제 서비스는 성숙한 API를 유지하면서 MCP 서버는 모델 친화적인 설명과 스키마를 가진 제한된 작업 하위 집합을 노출할 수 있습니다.

MCP vs. Function Calling

함수 또는 도구 호출은 모델 능력입니다: 모델이 함수를 호출하기 위한 구조화된 요청을 반환할 수 있습니다. MCP는 도구와 컨텍스트 제공자를 발견하고 통신하기 위한 프로토콜입니다.

두 개념은 자주 함께 작동합니다. MCP 서버가 호스트에 어떤 도구가 존재하는지 알려줍니다. 호스트는 선택된 정의를 모델에 제시합니다. 모델이 도구 호출을 내보냅니다. 호스트는 MCP를 사용해 해당 요청을 적절한 서버에 보냅니다.

MCP vs. Agent2Agent

MCP는 AI 애플리케이션을 기능 및 컨텍스트에 연결합니다. Agent2Agent(A2A)는 서로 다른 시스템이나 조직이 소유할 수 있는 자율 에이전트 간의 통신에 초점을 맞춥니다.

실제 시스템은 두 방식을 모두 사용할 수 있습니다. 에이전트가 MCP를 통해 도구와 데이터를 접근한 뒤, A2A를 사용해 더 큰 작업을 다른 에이전트에 위임할 수 있습니다. MCP는 “이 애플리케이션이 해당 기능을 어떻게 사용할 수 있나요?”에 답하고, A2A는 “이들 에이전트가 작업을 어떻게 조정하나요?”에 답합니다.

보안 위험 및 제어

보안 호스트는 서버와 도구에 대한 명시적인 허용 목록을 유지하고, 접근이 허가될 때 의미 있는 동의를 표시하며, 모든 호출을 이를 승인한 사용자 또는 워크로드 ID와 연결합니다. 도구 스키마는 예상치 못한 인수를 거부할 수 있을 정도로 좁게 설계되어야 하며, 감사 로그에는 서버, 기능, 입력값, 결과 상태 및 승인 경로가 기록되어야 합니다.

반환된 리소스와 도구 결과 역시 프롬프트 주입 공격의 표면이 될 수 있습니다. MCP를 통해 읽힌 문서에 모델에게 지시를 무시하거나 데이터를 유출하도록 요구하는 텍스트가 포함될 수 있습니다. 호스트는 신뢰할 수 없는 콘텐츠와 시스템 정책을 명확히 구분해야 하며, 한 서버의 출력이 다른 서버의 권한을 조용히 확대하지 않도록 방지해야 합니다.

표준화는 상호 운용성을 향상시키지만 서버를 신뢰할 수 있게 만들지는 않습니다. MCP 서버는 민감한 데이터, 오해를 일으키는 도구 설명, 위험한 동작 또는 손상된 종속성을 노출할 수 있습니다. 리소스를 통해 가져온 신뢰할 수 없는 콘텐츠에도 모델을 조작하려는 프롬프트 주입 명령이 포함될 수 있습니다.

중요한 제어 항목은 다음과 같습니다:

• 최소 권한: 각 서버에 목적에 필요한 자격 증명과 범위만 부여합니다.
• 서버 신뢰: 서버를 연결하기 전에 소스, 코드, 소유권 및 업데이트 경로를 검증합니다.
• 사용자 가시성: 어떤 서버가 데이터를 받으며 어떤 작업을 수행할지 명확히 표시합니다.
• 입력 검증: 모델 외부에서 스키마와 비즈니스 규칙을 적용합니다.
• 승인 경계: 민감하거나 외부, 재무, 파괴적인 작업을 확인합니다.
• 데이터 최소화: 필요한 작은 부분만 전송하고 전체 문서나 대화를 보내는 것을 피합니다.
• 로그 및 폐기: 호출을 기록하고 이상 징후를 모니터링하며, 자격 증명과 연결을 쉽게 비활성화할 수 있도록 합니다.

MCP 프로젝트는 아키텍처와 보안 지침을 지속적으로 다듬고 있습니다. 프로젝트의 2026 specification update는 표준이 보다 단순한 인프라, 권한 부여 및 프로덕션 배포를 중심으로 진화하고 있음을 보여줍니다.

개발자는 언제 MCP를 사용해야 할까요?

MCP는 여러 AI 클라이언트가 동일한 기능에 일관된 연결이 필요하거나, 도구를 런타임에 검색 가능해야 하거나, 팀이 AI 오케스트레이션을 시스템별 통합 코드와 분리하고자 할 때 강력한 선택입니다.

단일 백엔드가 엄격히 제어되는 작은 애플리케이션의 경우 직접 함수 호출이 더 간단할 수 있습니다. 프로토콜을 도입하면 서버 수명 주기 관리, 호환성 테스트, 인증, 가시성 및 거버넌스 등 자체적인 운영 작업이 필요합니다.

Model Context Protocol (MCP)에 대해 기억해야 할 사항

MCP는 AI 애플리케이션과 그 주변 도구 및 컨텍스트 사이의 공통 언어입니다. 그 가치는 고립된 통합 관행을 검색 가능하고 구조화되며 확장 가능한 프로토콜로 대체함으로써 얻어집니다.

표준이 신중한 엔지니어링의 필요성을 없애지는 않습니다. 호스트는 여전히 어떤 서버를 신뢰할지, 어떤 기능을 노출할지, 어떤 데이터를 공유할지, 그리고 언제 사람이 행동을 승인해야 할지를 결정해야 합니다. MCP는 연결을 이식 가능하게 만들고, 거버넌스는 이를 안전하고 유용하게 합니다.