Model Context Protocol (MCP)이란? 엔지니어를 위한 쉬운 가이드

Source: Dev.to

위에 제공된 Source 라인만 포함되어 있어 번역할 본문이 없습니다. 번역을 원하는 텍스트(본문)를 제공해 주시면 한국어로 번역해 드리겠습니다.

MCP가 해결하는 문제

AI 모델은 추론에 뛰어나지만, 스스로는 완전히 고립되어 있습니다.

• 텍스트를 학습한 언어 모델은 많은 것을 알고 있지만, 데이터베이스에 무엇이 있는지, Slack 채널에 무엇이 있는지, 혹은 Jira에 현재 열려 있는 작업이 무엇인지는 모릅니다.
• 이메일을 보낼 수도 없고, CRM을 조회하거나, 배포를 트리거할 수도 없습니다.

AI 에이전트가 단순히 질문에 답하는 수준을 넘어 실제로 행동하려면 외부 도구와 데이터 소스에 연결되어야 합니다.

MCP가 등장하기 전에는 이러한 연결이 모두 맞춤형으로 구축되었습니다:

이러한 통합은 다른 팀으로 이전되지 않았으며, 서로 다른 LLM 간에 재사용되지도 않았습니다.

팀이 OpenAI에서 Claude로 전환하고 싶다면, 통합을 다시 작성해야 했습니다. 또 다른 팀이 비슷한 기능을 원한다면, 처음부터 다시 만들었습니다.

BCG는 이 문제에 수치를 붙였습니다: 표준 프로토콜이 없으면, 통합 복잡도가 조직 내 AI 에이전트가 늘어날수록 제곱으로 증가합니다. 새로운 에이전트마다 필요한 모든 도구에 대한 연결을 별도로 만들어야 하므로 복잡도가 급격히 커집니다.

MCP는 연결을 표준화함으로써 이 문제를 해결합니다. 각 팀이 맞춤형 통합을 구축하는 대신, 도구는 하나의 표준 인터페이스를 사용하는 MCP 서버로 자신을 노출합니다. MCP‑호환 에이전트라면 어떤 MCP 서버든 커스텀 코딩 없이 연결할 수 있습니다. 통합은 한 번만 구축하면 어디서든 작동합니다.

MCP가 실제로 무엇인가

Model Context Protocol은 오픈 표준이며 — 2024년 11월 Anthropic이 처음 발표하고, 2025년 12월 새로 설립된 Agentic AI Foundation의 일환으로 Linux Foundation에 기부되었습니다 — AI 에이전트가 외부 도구를 발견하고 호출하는 방식을 정의합니다.

핵심은 통신 프로토콜이라는 점입니다. MCP는 다음을 명시합니다:

1. 도구가 어떻게 설명되는가
   MCP 서버는 name, description, input schema, output schema와 같은 구조화된 정의를 포함한 도구 목록을 노출합니다. LLM은 이러한 정의를 읽어 어떤 도구가 사용 가능한지, 그리고 어떻게 사용할지를 이해합니다.

2. 도구가 어떻게 호출되는가
   에이전트가 도구를 사용하고자 할 때, 구조화된 요청을 MCP 서버에 보냅니다. 서버는 도구를 실행하고 구조화된 응답을 반환합니다. 모든 흐름은 JSON‑RPC 2.0 기반의 표준 메시지 형식으로 이루어집니다.

3. 발견이 어떻게 이루어지는가
   에이전트는 MCP 서버에 질의하여 해당 서버가 제공하는 도구를 파악합니다. 이는 에이전트가 사전에 하드코딩된 도구 정의에 의존하지 않고, 사용 가능한 도구에 맞춰 적응할 수 있음을 의미합니다.

비유: MCP는 AI 에이전트에게 USB‑C가 장치에 주는 역할과 같습니다. USB‑C가 나오기 전에는 각 장치마다 다른 커넥터—충전 케이블, 데이터 케이블, 디스플레이 케이블—가 있었고 모두 호환되지 않았습니다. USB‑C는 커넥터를 표준화했습니다. 어떤 장치든 어떤 케이블이든 연결하면 바로 동작합니다.
마찬가지로, MCP는 AI 에이전트와 도구 사이의 커넥터를 표준화합니다. MCP를 지원하는 에이전트는 어떤 LLM이 에이전트를 구동하든, 도구가 어떤 시스템에 연결되어 있든 관계없이 MCP를 지원하는 모든 도구와 연결할 수 있습니다.

3단계 작동 방식

1. 도구 소유자가 MCP 서버를 생성
   MCP 인터페이스를 사용해 하나 이상의 도구(예: 데이터베이스 조회 기능, Slack 메시징 기능, 코드 실행 환경)를 노출하는 경량 서비스입니다. 서버는 제공하는 도구와 호출 방법을 설명합니다.

2. 에이전트가 사용 가능한 도구를 발견
   에이전트가 초기화될 때 MCP 서버에 질의하여 도구 스키마가 포함된 구조화된 도구 목록을 받습니다. 이제 에이전트는 자신이 할 수 있는 일을 알게 됩니다.

3. 에이전트가 도구를 호출
   사용자의 요청과 사용 가능한 도구를 기반으로 LLM은 구조화된 도구 호출을 MCP 서버에 보냅니다. 서버는 도구를 실행하고 결과를 반환합니다. LLM은 그 결과를 추론에 반영하고 계속 진행합니다.

이것이 전체 루프입니다. LLM은 도구의 구현 세부 사항을 알 필요가 없으며, 도구도 LLM에 대해 알 필요가 없습니다. 프로토콜이 양자 간 대화를 처리합니다.

생태계가 이렇게 빠르게 성장한 이유

MCP는 2024년 11월에 출시되었습니다. 2025년 4월까지 MCP 서버 다운로드 수는 대략 100 k에서 월 8 M 이상으로 급증했습니다. 2025년 말에는 5,800개가 넘는 MCP 서버가 공개되어 Slack, Confluence, Sentry부터 데이터베이스, 코드‑실행 환경, 내부 엔터프라이즈 시스템에 이르기까지 모든 것을 포괄했습니다. SDK 다운로드는 월 97 M을 돌파했습니다.

이렇게 빠르게 채택을 촉진한 세 가지 요인:

1. 주요 LLM 제공업체들이 즉시 승인
   Anthropic이 직접 만들었지만 OpenAI, Google, Microsoft가 수개월 내에 채택했습니다. 이러한 벤더 간 지원 덕분에 개발자는 한 번 MCP 통합을 구축하면 어떤 LLM이든 사용할 수 있었습니다.

2. 툴 소유자를 위한 통합 비용이 거의 제로에 가까워짐
   기존 API를 MCP 서버로 노출하는 것은 소량의 래퍼 코드만 필요합니다. Slack, Datadog, Sentry와 같은 기업들은 증분 작업이 최소였기 때문에 빠르게 MCP 지원을 추가했습니다.

3. 개발자들이 정확히 이런 것을 갈망
   대안인 에이전트·팀·LLM 별 맞춤형 툴 통합을 구축하고 유지하는 일은 눈에 띄게 고통스러웠습니다. MCP는 즉각적인 안도감을 제공했습니다.

MCP에 포함되지 않는 내용

MCP는 연결을 정의합니다. 연결에 대한 규칙은 정의하지 않습니다.

• 프로토콜에는 어떤 에이전트가 어떤 도구를 호출할 수 있는지를 지정하는 내장 메커니즘이 없습니다.
• 감사 로그를 제공하지 않습니다.
• 도구 응답에 삽입된 지시문이나 악성 콘텐츠가 포함되어 있는지를 감지할 방법이 없습니다.

이러한 거버넌스 및 보안 문제는 주변 인프라스트럭처에서 처리하거나 핵심 MCP 사양 위에 구축된 확장 기능을 통해 해결해야 합니다.

MCP 게이트웨이가 필요한 이유

MCP는 LLM을 조작하도록 설계되었습니다. 팀별 접근 정책에 대한 개념이 없습니다.

Note: 이것은 결함이 아니라 의도적인 범위 결정입니다. 프로토콜은 최소한으로 유지하고, 거버넌스 계층은 그 위에 구축됩니다.

• 로컬 개발 / 소규모 실험:
  내장된 거버넌스가 없다는 점을 감당할 수 있습니다.

• 여러 팀, 민감한 데이터, 그리고 컴플라이언스 요구사항이 있는 프로덕션 배포:
  MCP가 기본 제공하는 기능과 기업 배포에 필요한 기능 사이의 격차가 크게 벌어집니다.

이 격차를 메우는 것이 바로 MCP 게이트웨이입니다. 이는 MCP 서버 앞에 위치하여 다음과 같은 거버넌스 및 보안 계층을 제공합니다:

• 인증
• 접근 제어 (RBAC)
• 감사 로그
• 도구 범위 지정

이 모든 작업은 게이트웨이를 통과하는 모든 에이전트에 대해 일관되게 수행됩니다.

TrueFoundry의 MCP 게이트웨이

TrueFoundry의 MCP 게이트웨이는 이 레이어를 위해 특별히 구축되었습니다. 그것은:

• 기존 아이덴티티 제공자에 연결합니다
• 도구 수준에서 RBAC를 적용합니다
• 전체 컨텍스트와 함께 모든 도구 호출을 기록합니다
• 귀사의 인프라 내에 완전히 배포되어 데이터가 환경을 떠나지 않도록 보장합니다

이미 상당한 AI 워크로드를 관리하고 있는 팀들은 이를 사용해 MCP를 데모 단계에서 신뢰할 수 있는 프로덕션 솔루션으로 전환합니다—팀 전반에 걸쳐, 엔터프라이즈 규모로.

TrueFoundry의 MCP 게이트웨이 탐색 →