우리는 Mattrx MCP 서버를 C#으로 구축하고 Azure에서 실행했습니다. 하지만 우리가 이 시리즈 전체를 통해 구축해 온 조용한 초능력이 여기 있습니다. 이 중 그 어떤 것도 서버를 단일 모델에 종속시키지 않는다는 점입니다. 동일한 mattrx-analytics 서버를 OpenAI, Anthropic, Gemini 또는 모든 에이전트 프레임워크(agent framework)가 구동할 수 있습니다. MCP에서 선언된 도구는 모두를 위해 선언된 도구이기 때문입니다.

이것은 Model Context Protocol (MCP)에 대한 15부작 심층 분석 중 파트 14입니다. 서버는 .NET 상태를 유지하지만, 이를 구동하는 클라이언트는 대개 Python(OpenAI SDK의 주 무대)입니다. 우리는 두 가지 방식으로 OpenAI에 MCP를 연결하고, 에이전트 프레임워크에 플러그인하며, 무엇보다도 여러분이 제어할 수 없는 플랫폼이 여러분의 도구를 호출하기 시작할 때 파트 6~8에서 다루었던 거버넌스(governance)를 온전하게 유지하는 방법을 알아볼 것입니다.

요약 (TL;DR)

두 가지 통합 모드

MODE A — 클라이언트 측 (사용자가 루프를 실행)
  호스트: MCP 클라이언트  <->  MCP 서버
                 |
...

1. 보편적인 도구 계층으로서의 MCP

MCP가 없다면 각 제공자마다 도구 스키마(tool schemas)를 직접 작성해야 합니다. OpenAI 함수는 여기, Anthropic 도구는 저기, Gemini 선언은 다른 곳에 위치하게 됩니다. N개의 제공자 × M개의 도구가 모두 서로 따로 놀게 됩니다. MCP를 사용하면 하나의 서버가 도구를 한 번만 선언하며, 어떤 제공자든 동일하게 발견된 JSON Schema를 소비합니다.

# 이전: 모든 제공자의 함수 호출(function-calling) 형식에 맞춰 모든 도구를 재선언합니다.
openai_tools    = [{"name": "get_campaign_kpis", "parameters": {...}}]   # 직접 작성한 JSON Schema
anthropic_tools = [{"name": "get_campaign_kpis", "input_schema": {...}}] # 다시 한 번, 약간 다름
...

이것은 백엔드가 아닌 **모델(models)**에 적용된, 파트 1의 N×M → N+M 원리입니다.

2. 클라이언트 측: MCP 도구 → OpenAI 도구 호출 (tool-calling)

MCP 도구를 발견하고, 이를 OpenAI의 tools 파라미터로 변환한 뒤(두 쪽 모두 JSON Schema이므로 거의 동일한 매핑임), 표준 도구 호출(tool-calling) 루프를 실행합니다.

# MCP 도구를 탐색하고 OpenAI의 tools 파라미터로 변환합니다 — 둘 다 JSON Schema입니다.
mcp_tools = await mcp.list_tools()
openai_tools = [{
...

번역 내용이 적은 이유는 MCP 도구 정의 자체가 JSON Schema이며, OpenAI의 parameters 필드 또한 JSON Schema이기 때문입니다. 루프는 직접 실행하며, 이를 통해 루프, 서버에 대한 접근 권한, 그리고 거버넌스(호스트의 게이트웨이가 바로 여기에 위치함)를 완전히 제어할 수 있습니다.

3. 호스팅 방식: OpenAI Responses API의 mcp 도구

Responses API의 호스팅된 mcp 도구를 사용자의 서버 URL로 지정하세요. OpenAI 플랫폼이 해당 서버에 연결하여 모델의 턴(turn) 동안 도구를 호출하므로, 루프 코드를 거의 작성할 필요가 없습니다.

# 호스팅 방식: OpenAI가 사용자의 MCP 서버에 연결하여 서버 측에서 도구를 호출합니다. (API는 계속 진화하므로 문서를 확인하세요.)
resp = client.responses.create(
    model="gpt-...",
...

호스팅된 도구는 코드가 가장 적게 드는 경로입니다. 하지만 변화된 점에 주목하세요: 이제 OpenAI의 인프라가 사용자의 서버에 직접 접근합니다. 따라서 사용자의 서버는 공개적으로 접근 가능해야 하며, 인증(auth) 및 거버넌스는 사용자가 직접 실행하지 않는 호출자(caller)에 대해서도 견고하게 유지되어야 합니다. 이는 편의성을 위해 신뢰를 일부 양보하는 것이며, 섹션 5에서는 이러한 거래를 안전하게 수행하는 방법을 다룹니다.

4. 에이전트 프레임워크도 MCP를 지원합니다

프레임워크를 MCP 서버로 지정하기만 하면 됩니다. OpenAI Agents SDK는 mcp_servers를 수용하며, Semantic Kernel(.NET 환경에 적합)은 MCP 도구를 커널 함수(kernel functions)로 가져오고, LangGraph는 MCP 어댑터를 갖추고 있습니다.

# OpenAI Agents SDK: 에이전트에 MCP 서버를 전달하면, 에이전트가 도구를 탐색하고 구동합니다.
from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp
...

모든 진지한 에이전트 프레임워크는 이제 MCP를 소비하므로, 프레임워크마다 도구를 일일이 연결할 필요가 없습니다. 대신 프레임워크를 서버로 지정하기만 하면 됩니다. MCP 서버가 계약(contract)이고, 프레임워크는 소비자(consumer)입니다.

5. 플랫폼이 도구를 구동할 때 거버넌스를 유지하는 방법

호스팅된 도구(hosted tool)를 사용할 때, OpenAI는 여러분의 서버를 직접 호출하며 — 기존에 호스트 내부에 위치했던 게이트웨이를 우회합니다. 거버넌스(governance)를 서버(server) 단계로 내려보내세요: OpenAI에 좁은 범위의 최소 권한 토큰(least-privilege token, 파트 7)을 전달하고, 호출 가능한 도구들을 허용 목록(allow-list)으로 관리하며, 민감한 도구는 승인 절차를 거치게 하고, 주입/유출 방어(injection/exfil defenses, 파트 8)를 서버 경계에서 유지하십시오.

# 호스팅된 도구는 제3자(THIRD PARTY)가 여러분의 서버에 접근함을 의미합니다. 호스트가 아닌 서버(SERVER)에서 거버넌스를 수행하세요.
tools=[{
    "type": "mcp",
...

호스팅된 플랫폼에 도구를 전달할 때, 모델 런타임(model runtime)은 더 이상 여러분의 호스트 내부에 있지 않습니다. 따라서 호스트 측 게이트웨이는 이를 제어할 수 없습니다. 거버넌스는 반드시 **서버(server)**에 존재해야 합니다: 읽기 전용의 최소 권한 토큰, 호출 가능한 도구의 허용 목록(allow-list), 부수 효과(side effect)가 있는 모든 작업에 대한 승인 게이트, 그리고 파트 6과 8에서 다룬 도구 결과 스크리닝(tool-result screening) 및 오디언스 바인딩(audience-binding)이 필요합니다. OpenAI의 플랫폼을 있는 그대로 — 즉, 신뢰할 수 없는 클라이언트(untrusted client) — 로 취급한다면, 그 편리함은 위험 없이 누릴 수 있습니다.

6. 하나의 서버, 어떤 모델이든

이전: 제공자별로 도구를 재선언함
  OpenAI functions  +  Anthropic tools  +  Gemini declarations  =  N x M

...

서버가 MCP의 제공자 중립적인 JSON 스키마(JSON Schema)로 도구를 선언하기 때문에, 모델을 교체하는 것은 클라이언트/설정(config)의 변경일 뿐입니다. 서버, 인증(auth), 범위(scopes), 그리고 거버넌스는 전혀 이동하지 않습니다. 여러분은 특정 벤더의 도구 형식에 종속되지 않습니다. 여러분이 도구를 소유하며, 모델은 교체 가능한 부품일 뿐입니다. 새로운 모델을 평가하는 것은 일정을 잡아야 하는 마이그레이션(migration)이 아니라, 오후 한나절 만에 수행할 수 있는 실험이 됩니다.

지속적으로 가져가야 할 모델 관점

MCP는 모델을 교체 가능한 부품으로 만듭니다. 여러분의 서버는 JSON 스키마로 도구를 한 번만 선언합니다. OpenAI는 이를 클라이언트 측에서 또는 호스팅된 방식으로 소비하며, 모든 에이전트 프레임워크(agent framework) 또한 이를 소비합니다. 도구를 소유하고 거버넌스를 서버에 유지하십시오. 그러면 제공자를 전환하는 것은 두려워해야 할 마이그레이션이 아니라, 점심 식사 전에 수행하는 실험이 됩니다. 이것이 바로 벤더가 아닌 프로토콜을 기반으로 구축하는 핵심 이유입니다.

MCP를 모델 불가지론(model-agnostic) 상태로 유지하는 세 가지 습관:

1. MCP 서버를 단일 도구 계약(tool contract)으로 유지하세요. 각 제공자(provider)에 맞춰 번역하되, 도구를 절대 재선언하지 마세요.
2. 서버에서 관리하세요 — 특히 호스팅된 도구(hosted tools)의 경우 더욱 그렇습니다. 최소 권한(least privilege), 허용 목록(allow-list), 승인(approval), 인젝션 방어(injection defense)를 적용하세요. 플랫폼은 클라이언트입니다.
3. 모델을 교체 가능한 것으로 취급하세요. 제공자를 변경하는 것이 클라이언트 또는 설정(config)의 변경만으로 이루어지도록 설계하고, 실제 교체를 통해 이를 증명하세요.

원문은 prepstack.co.in에 게시되었습니다. 파트 15는 시리즈를 마무리하며, Mattrx에서 MCP를 운영하며 얻은 교훈 — 무엇이 유지되었고, 무엇이 깨졌으며, 우리가 다르게 했을 일들에 대해 다룹니다.