MCP 아키텍처: 다이어그램으로 살펴보는 완벽한 기술 분석

MCP 아키텍처는 MCP(Model Context Protocol)를 가능하게 하는 기본 구성 요소와 통신 규칙의 집합입니다. MCP는 오픈 소스 표준이며, MCP 아키텍처는 MCP가 실행되는 기반 인프라입니다.

모든 MCP 아키텍처는 호스트, 클라이언트, 서버라는 세 가지 핵심 구성 요소를 포함하며 이를 중심으로 구축됩니다. MCP의 통신 프레임워크는 흔히 데이터 계층과 전송 계층으로 구성된다고 설명됩니다. 데이터 계층은 메시지 형식을 정하는 규칙의 집합입니다(MCP 요청은 JSON-RPC 2.0으로 전송됩니다). 전송 계층은 이러한 메시지를 전달하며, 외부 연결에는 Streaming HTTP를 사용합니다.

MCP 아키텍처는 Model Context Protocol을 구현하는 서버 프레임워크입니다. Model Context Protocol은 AI 모델을 도구에 연결하고, 데이터베이스 같은 리소스와 입력 컨텍스트를 확장하는 프롬프트에도 연결하는 개방형 표준입니다. 이러한 요소를 통틀어 “프리미티브”라고 합니다. 결과적으로 MCP 아키텍처를 사용하면 클라이언트 측을 정기적으로 업데이트하지 않아도 LLM이 사용 가능한 도구를 탐색하고 워크플로우를 실행할 수 있습니다.

MCP 아키텍처 다이어그램: AI 애플리케이션이 MCP 서버와 요청을 주고받으며, MCP 서버는 도구, 리소스, 프롬프트를 제공합니다.

Anthropic이 처음 선보인 이후 MCP 아키텍처는 AI 워크플로우에서 널리 사용되고 있습니다. 이는 주로 여러 API 연결을 기반으로 구축된 시스템처럼 유지 관리 부담이 큰 시스템을 성능 저하 없이 대체하기 때문입니다. 사용 가능한 모든 기능이 MCP 서버 뒤에 있으므로 연결은 하나만 있으면 되며, 업데이트와 추가 기능을 클라이언트 애플리케이션에서 즉시 사용할 수 있습니다.

MCP는 LLM이 호스트 애플리케이션의 로컬 시스템이나 외부 제공업체에서 사용할 수 있는 도구, 프롬프트, 리소스를 탐색하고 호출할 수 있는 수단을 제공합니다.

외부 기능에 대한 액세스를 제공하는 도구의 경우, 탐색은 호스트가 MCP 서버에 tools/list 호출을 보내 사용 가능한 도구를 찾는 과정입니다. 그런 다음 LLM(경우에 따라서는 호스트)이 사용 가능한 도구의 설명을 읽고 필요에 따라 해당 도구를 요청할 수 있습니다. 프롬프트와 리소스도 비슷한 과정을 거칩니다.

MCP 아키텍처 구성 요소 다이어그램: LLM, 오케스트레이터, 클라이언트를 포함하는 호스트가 탐색과 요청의 두 단계를 거쳐 MCP 서버에 연결하고, MCP 서버는 도구, 리소스, 프롬프트를 노출합니다.

이는 소프트웨어 개발에서 일반적이었던 맞춤형 API 기반 아키텍처와 대조됩니다. 이러한 아키텍처에서는 앱 외부의 기능을 호출하려면 정확한 형식의 요청을 담은 전용 연결을 사용해야 했습니다.

호스트 애플리케이션은 중앙 오케스트레이션 플랫폼으로, LLM에 연결됩니다. Perplexity, Claude Desktop 같은 잘 알려진 도구가 MCP 시스템에서 호스트 역할을 할 수 있습니다.

간단한 워크플로우에서는 사용자가 채팅 인터페이스를 통해 질문합니다. 그러면 호스트의 오케스트레이터 구성 요소가 질문에 컨텍스트를 추가하여, 사용 가능한 MCP 프리미티브와 그 기능에 대한 설명을 LLM에 알려줍니다.

클라이언트는 AI 애플리케이션 내의 소프트웨어 구성 요소입니다. MCP는 클라이언트가 호스트나 LLM의 지시에 따라 내부 및 외부 MCP 서버와 통신할 수 있도록 표준 인터페이스를 제공합니다. 클라이언트의 역할은 연결을 설정하고, JSON-RPC 메시지의 형식을 지정하고, 요청을 보내고, 응답을 받는 것입니다.

“MCP 호스트”와 “MCP 클라이언트”라는 용어는 때때로 같은 의미로 쓰입니다. 하지만 Perplexity 같은 호스트는 여러 MCP 클라이언트를 동시에 오케스트레이션할 수 있으므로 둘을 구분하는 것이 유용합니다. 복잡한 AI 워크플로우에서는 수십, 심지어 수백 개의 개별 MCP 서버에 액세스해야 할 수 있으며, 각 서버는 별도의 연결을 사용합니다.

Perplexity 같은 MCP 호스트가 세 개의 MCP 클라이언트를 오케스트레이션하는 다이어그램으로, 각 클라이언트는 데이터베이스, 파일, 외부 API 등 자체 MCP 서버에 연결되어 있습니다.

서버는 AI 기반 도구가 사용할 수 있는 모든 도구를 노출합니다. 아키텍처 관점에서 MCP 서버는 들어오는 요청을 해석하고, 필요한 경우 요청된 프리미티브에 연결합니다.

MCP 서버는 다음 세 가지 범주의 프리미티브에 대한 액세스를 제공할 수 있습니다:

도구: 본질적으로 외부 소프트웨어 기능입니다. 기존의 API 기반 방식을 생각해 보면, 웹 분석 애플리케이션은 형식이 지정된 요청을 외부 서버에 보내 데이터를 가져올 수 있습니다. MCP 아키텍처에서는 제공업체의 모든 서드파티 기능을 단일 연결로 사용할 수 있으며, 요청은 표준 형식 규칙에 따라 생성됩니다.
리소스: 리소스는 읽기 전용 컨텍스트를 제공하는 데이터 소스입니다. 데이터베이스 스키마가 좋은 예입니다. MCP 서버는 호스트가 사용할 수 있는 다양한 정보 소스를 노출합니다. LLM이 생성한 SQL 검색처럼 호스트가 데이터베이스를 쿼리하는 경우, 이는 도구 요청으로 간주됩니다.
프롬프트: LLM이 특정 작업을 수행하도록 돕는 재사용 가능한 프롬프트 템플릿입니다. 사용자나 호스트는 작업을 완료하는 데 미리 만들어진 지침이 필요할 때 도구 대신 프롬프트를 호출합니다. 호스트 애플리케이션에서 “코드 검토”나 “데이터 분석” 옵션처럼 미리 설정된 작업은 사용자가 선택할 수 있는 프롬프트로 저장되는 경우가 많습니다.

또한 MCP와 API는 상호 배타적인 기술이 아니라는 점도 주목할 만합니다. MCP 서버는 탐색 요청에 대한 응답으로 사용 가능한 API 호출을 노출할 수 있습니다. 핵심은 이를 유지 관리하는 주체가 클라이언트가 아니라 MCP 제공업체라는 점입니다.

MCP 아키텍처의 데이터 계층은 요청, 응답, 알림의 형식을 정의하는 규칙의 집합입니다. 메시지의 표준 언어는 JSON-RPC입니다.

모든 MCP 아키텍처는 (1) 호스트의 초기화 및 탐색, (2) MCP 서버의 응답, (3) 호스트의 호출(LLM이 결정하는 경우도 있음)이라는 기본 과정을 따르며, 각 단계는 별도의 JSON 메시지로 이루어집니다.

MCP 데이터 계층 다이어그램: 사용자가 호스트 애플리케이션에 프롬프트를 보내면 호스트 애플리케이션 안에서 LLM이 MCP 클라이언트와 함께 작동합니다. 클라이언트는 MCP 서버(도구, 리소스, 프롬프트)에 요청을 보내 결과를 받고, 호스트는 사용자에게 응답을 반환합니다.

두 가지 예시를 통해 도구 탐색이 어떻게 작동하는지 살펴보겠습니다(리소스나 프롬프트에도 적용될 수 있습니다):

LLM 생성 전 도구 탐색: 호스트가 MCP 클라이언트를 시작하면 클라이언트는 tools/list 요청(MCP 서버의 사용 가능한 도구 목록)을 보냅니다. LLM은 생성 과정에서 이를 검토하고 특정 도구, 리소스, 프롬프트가 필요한지 판단합니다.
LLM에 검색 실행 옵션 제공: 에이전틱 시스템에서는 호스트가 search-tools 같은 탐색 옵션을 컨텍스트 입력에 추가하고, LLM은 필요한 경우 검색을 요청할 수 있습니다.

대체로 외부 애플리케이션 기능인 도구는 일반적으로 LLM이나 호스트가 선택합니다. 리소스와 프롬프트는 보통 사용자의 요청에 따라 또는 호스트에 의해 요청됩니다.

다음은 가상의 메모 애플리케이션에서 MCP 서버로 보내는 tools/list 요청의 모습입니다:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

이 예시에서 “id”:101은 클라이언트가 응답을 매칭할 수 있도록 ID로 요청을 식별하며, “params” 필드에는 클라이언트 이름(notes-app-client), 기능 등 클라이언트에 대한 추가 정보가 포함됩니다.

이에 대한 응답으로 MCP 서버는 사용 가능한 도구의 이름과 관련 세부 정보를 포함한 도구 정의를 반환합니다. 예를 들어 목록에는 메모 애플리케이션이 연결된 작업 관리 또는 캘린더 애플리케이션에서 작업을 생성하고 각 작업에 제목과 우선순위를 지정할 수 있게 해 주는 add-task 도구가 포함될 수 있습니다.

요청은 다음과 같은 형태일 수 있습니다:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” 필드는 MCP 서버에 도구 호출임을 알리고, “name”은 호출할 도구를 지정하며, “arguments”는 필요한 입력값을 제공합니다.

데이터 계층이 클라이언트와 MCP 서버 간 연결의 무엇에 해당한다면, 전송 계층은 어떻게에 해당합니다. 전송 계층은 메시지가 이동하는 방식, 즉 구체적인 채널과 요청 및 응답이 전달되는 방식을 규정하는 규칙을 정의합니다.

MCP에는 두 가지 전송 경로가 있습니다:

표준 입출력: MCP 서버가 호스트 앱과 동일한 로컬 환경에서 실행될 때 사용됩니다. 클라이언트는 JSON 요청을 서버의 표준 입력에 씁니다. 서버는 이를 읽고 요청된 작업을 수행한 다음 응답을 표준 출력에 씁니다.
Streamable HTTP: MCP 서버가 호스트 애플리케이션 외부에서 실행되면 MCP 클라이언트는 HTTP POST를 사용해 서버에 요청을 보냅니다. 서버는 단일 JSON 메시지로 응답하거나, 지속적인 “수신 대기” 채널인 Server-Sent Events(SSE) 스트림으로 응답하여 시간에 걸쳐 여러 메시지를 반환할 수 있습니다.

MCP 멀티 테넌트 아키텍처는 여러 사용자(테넌트)에게 동시에 서비스를 제공할 수 있는 구현 방식입니다.

여기서 테넌트는 개인, 여러 개인으로 구성된 그룹 또는 조직일 수 있습니다. 구현 방식으로는 테넌트마다 별도의 MCP 서버를 실행하거나, 하나의 공유 서버에 대한 액세스를 제공하거나, 여러 서버를 중앙 게이트웨이 뒤에 배치하는 방법이 있습니다. 게이트웨이를 사용하는 경우 게이트웨이는 사용자의 ID나 요청의 성격에 따라 요청을 올바른 엔드포인트로 라우팅합니다.

기본 원리는 표준 MCP 아키텍처와 같지만, 개별 사용자 요청이 각자의 작업 공간에서 처리되고(공유 리소스를 사용하더라도) 별도로 인증됩니다. 엔터프라이즈 환경에서 흔히 사용되며, 여러 MCP 서버를 실행하면 불필요하게 비용이 많이 들기 때문에 공유 리소스를 선호하는 경우가 많습니다.

엔드투엔드 MCP 요청은 실제로 어떻게 이루어질까요? 여기에는 8가지 핵심 단계가 있으며, 각 단계에는 서로 다른 아키텍처 구성 요소가 관여합니다.

엔드투엔드 MCP 요청의 8단계 흐름도: 도구 탐색, 사용자 입력, 모델 처리, 도구 선택, 요청, 도구 실행, 결과, 답변 생성.

앞서 살펴본 작업 관리 서비스에 연결된 메모 애플리케이션 예시를 통해 MCP 도구 호출이 실제로 어떻게 이루어지는지 살펴보겠습니다:

도구 탐색: 메모 애플리케이션(호스트)은 MCP 클라이언트를 사용해 tools/list 요청으로 서버에서 사용 가능한 도구를 요청합니다. 서버는 add-task 도구를 포함한 도구들의 이름, 설명, 예상 입력값을 반환합니다. 이 단계는 프롬프트를 제출하기 전에 이루어질 수도 있습니다.
사용자 입력: 앱 내 챗봇을 통해 LLM 기반 메모 애플리케이션에 “새 초안을 검토하는 작업을 우선순위 보통으로 캘린더에 만들어 줘”와 같은 요청을 제출합니다.
모델 처리: 호스트가 사용자의 요청과 관련 도구 정의를 LLM에 보냅니다.
도구 선택: LLM은 도구와 입력값을 지정하는 구조화된 도구 요청을 생성합니다. 예를 들어 add-task 도구에 title: Review the draft와 priority: Medium을 지정합니다. 호스트는 해당 작업이 허용되는지 확인한 후 요청을 MCP 클라이언트에 전달하고, MCP 클라이언트는 JSON-RPC 메시지를 보냅니다.
요청: MCP 클라이언트가 MCP 서버에 tools/call 요청을 보냅니다.
도구 실행: MCP 서버가 작업 관리 애플리케이션의 API를 호출하여 지정된 제목과 우선순위로 새 작업을 생성합니다.
결과 반환: 서버가 결과를 MCP 클라이언트에 보내면, 클라이언트는 이를 호스트에 전달합니다. 호스트는 이 결과를 LLM에 제공하는 정보에 추가합니다.
답변 생성: LLM은 결과를 사용해 “초안 검토 작업을 우선순위 보통으로 만들었습니다.”와 같은 답변을 사용자에게 생성합니다.

MCP와 기존 API 아키텍처는 흔히 혼동되지만, 서로 보완적인 기술입니다. MCP는 AI 기반 애플리케이션을 위해 특별히 설계되었으며, 하드코딩된 여러 API 연결을 구현하고 관리하는 데 따르는 높은 유지 관리 부담을 해소합니다.

MCP는 호스트 애플리케이션에 기능 제공업체나 내부 리소스당 하나의 연결을 제공함으로써, 비대해진 컨텍스트 입력(모든 API 나열) 문제나 제한적인 API 기반 애플리케이션 스크립트 문제를 해결하는 데 도움이 됩니다.

대신 MCP는 도구 목록의 일부로 API(정확히는 API를 호출하는 기능)를 노출할 수 있습니다. 제공업체가 앱을 업데이트하여 새 API가 생기거나 문서가 변경되면 MCP 서버만 업데이트하면 됩니다. 호스트 앱 측에서는 코드를 변경할 필요가 없습니다.

MCP 보안은 도입 이후 많은 논쟁의 대상이 되어 왔습니다. 일반적으로 안전한 기술로 여겨지지만 몇 가지 보안 위험이 있으며, 그중 상당수는 복잡한 아키텍처 구현에서 더 두드러집니다.

MCP 아키텍처에는 다음과 같은 잠재적 취약점이 있습니다:

프롬프트 인젝션: 사용자가 외부 데이터에 악의적인 프롬프트를 삽입하고, AI 모델이 이를 지시로 잘못 해석합니다.
과도한 권한 부여: MCP 서버는 AI 모델에 많은 수의 도구를 노출할 수 있으며, 이로 인해 보안 문제의 잠재적 영향 범위(폭발 반경)가 커질 수 있습니다.
의도치 않은 데이터 유출: 잘못 구성된 구현으로 인해 API 키나 데이터베이스 자격 증명 같은 민감한 정보가 LLM에 전달될 수 있습니다.
로컬 시스템 조작: 로컬 MCP 서버는 다른 애플리케이션과 마찬가지로 악성 스크립트 같은 로컬 시스템 문제에 취약하며, 여기에 더해 에이전틱 AI 시스템에 연쇄적으로 해로운 영향을 미칠 수 있다는 문제도 있습니다.

이러한 문제는 모두 극복할 수 있습니다. 시스템 안전을 보장하는 데는 이미 확립된 조치만으로도 충분한 경우가 많습니다. 사람이 검토 과정에 참여하도록 하고(human-in-the-loop), 민감한 데이터를 엄격하게 통제하고, 서버 공격을 방어하는 등의 조치는 모두 일반적인 관행입니다.

MCP는 개발자에게 유용하고 인기 있는 개방형 표준으로 자리 잡았습니다. LLM 기반 애플리케이션에서 하드코딩된 API의 여러 문제를 해결하고 개발자의 코딩 부담을 크게 줄여 줍니다.

앞으로도 MCP의 기본 호스트 및 서버 아키텍처는 거의 확실히 그대로 유지될 것입니다. 향후 혁신은 다단계 워크플로우 전반에 걸친 고급 에이전틱 기능에 집중될 것입니다.

또한 이러한 에이전틱 기능이 구현됨에 따라 더 강력한 보안 안전장치가 필요하며, AI 시스템이 더욱 광범위하고 복잡해짐에 따라 특히 전송 계층에서 확장 가능한 아키텍처가 필요해질 것입니다.

MCP 아키텍처란 무엇인가요?

MCP 아키텍처 구성 요소: 호스트, 클라이언트, 서버

호스트

클라이언트

서버

MCP 아키텍처의 데이터 계층이란 무엇인가요?

MCP 아키텍처의 전송 계층이란 무엇인가요?

MCP 멀티 테넌트 아키텍처란 무엇인가요?

MCP 아키텍처 다이어그램: 단계별 안내

MCP 아키텍처는 기존 API 아키텍처와 어떻게 다른가요?

MCP 아키텍처는 안전한가요?

MCP 아키텍처의 다음 단계는 무엇일까요?