당신의 AI 로드맵은 나쁜 모델 때문에 실패하지 않습니다. 그것은 통합용 글루 코드 (Integration Glue Code) — 즉, 당신이 구축할 모든 에이전트와 모든 백엔드에 대해 에이전트 4번을 백엔드 9번에 연결하는 수작업 어댑터 — 때문에 실패합니다. **Model Context Protocol (MCP)**은 바로 그 곱셈 연산을 멈추게 하는 기술입니다.

이 글은 15부작 심층 분석 중 파트 1입니다. 모든 파트는 동일한 실행 예제를 사용합니다: 우리의 멀티 테넌트 마케팅 분석 SaaS인 Mattrx (.NET 9 / Azure)이며, 여기에 등장하는 모든 지표는 해당 실제 시스템에서 추출되었습니다.

요약 (TL;DR)

차원	이전 (맞춤형 글루 코드)	이후 (MCP)
통합 모델	N 에이전트 × M 백엔드	N 에이전트 + M 서버
...

• 14개의 맞춤형 통합이 3개의 MCP 서버로 축소되었습니다.
• 약 9,000줄의 글루 코드가 삭제되었습니다 — 대략 40%의 절감 효과입니다.
• 새로운 기능 온보딩(Onboarding) 시간이 약 3일에서 약 2시간으로 단축되었습니다.
• 에이전트 도구 호출(Tool-call) 오류율이 6%에서 0.8%로 떨어졌습니다.
• 하루 약 85,000건의 MCP 도구 호출이 발생하며, 모두 동일한 경계(Boundary) 내에서 관리됩니다.
• 주당 약 40건의 도구 오용/인젝션(Injection) 시도가 MCP 경계에서 차단되었습니다.

단 하나의 사고방식 전환: 통합(Integration)을 구축하는 것을 멈추고 역량(Capability)을 게시(Publishing)하기 시작하십시오. 통합은 하나의 에이전트에게 하나의 백엔드를 호출하는 방법을 가르칩니다. 역량은 어떤 에이전트라도 자신의 스키마(Schema)만으로 발견하고 호출할 수 있는 도구입니다. MCP는 역량을 곱셈이 아닌 덧셈 방식으로 만듭니다.

N×M 문제

N개의 에이전트와 M개의 백엔드가 있을 때, 당신은 최대 N×M개의 통합 코드를 작성하게 되며, 각 코드는 인증(Auth), 재시도(Retries), 오류 매핑(Error mapping), 로깅(Logging)을 각자 약간씩 잘못된 방식으로 재구현합니다.

이전 — N 에이전트 x M 백엔드 = 최대 N*M개의 맞춤형 통합

Insights ---+--> Campaigns API (커스텀 클라이언트)
...

1. 통합의 폭발

이전에는 모든 에이전트가 모든 백엔드에 대한 맞춤형 클라이언트를 내장하고 있었습니다:

// 이전: 에이전트가 4개의 수작업 클라이언트에 고정되어 있음.
public sealed class InsightsAgent(
    CampaignsApiClient campaigns,   // 맞춤형 HTTP 클라이언트 #1
...

이후에는, 각 역량이 MCP 도구로서 단 한 번만 선언됩니다:

// AFTER: mattrx-analytics MCP 서버에 한 번만 선언된 역량.
[McpServerToolType]
public sealed class AnalyticsTools(ICampaignQueries campaigns, AiPrincipal principal)
...

에이전트 측은 모든 서버와 MCP로 통신하는 단 하나의 클라이언트로 축소됩니다:

var result = await mcp.CallToolAsync(
    "get_campaign_kpis",
    new { campaignId = "4821", range = "2026-06-01/2026-06-28" },
...

결과: 14개의 통합(integrations) → 3개의 서버, 약 9,000줄의 글루 코드(glue code) 삭제, 거의 모든 삭제가 이루어짐.

2. 역량 발견 (Capability discovery)

이전에는 도구 세트(toolset)가 에이전트와 함께 컴파일되는 상수(constant)였습니다. 즉, 목록과 실제 상태 사이에 괴리(drift)가 발생했습니다. 이후에는 서버가 자신의 도구들을 광고(advertise)하고, 클라이언트가 런타임(runtime)에 이를 발견합니다:

// AFTER: 에이전트가 매 세션마다 서버에 무엇을 할 수 있는지 묻습니다.
var tools = await mcp.ListToolsAsync(ct);
// 각 도구: 이름, 설명, 인자를 위한 JSON Schema — LLM이 사용하기에 충분함
...

발견(Discovery)은 조용한 초능력입니다. 서버에 새로운 도구를 배포하기만 하면, 모든 에이전트가 다음 세션부터 즉시 사용할 수 있습니다. 역량을 온보딩(Onboarding)하는 데 걸리는 시간이 약 3일에서 약 2시간으로 단축되었습니다.

3. 단일 인증 및 감사 경계 (One auth and audit boundary)

이전에는 모든 맞춤형(bespoke) 클라이언트가 인증(auth)을 새로 구현해야 했습니다 (하나의 정적 키, 하나의 OAuth 범위, 또는 인자로 전달된 테넌트 ID(tenant id)를 신뢰하는 방식 — 우리가 배포했던 바로 그 버그). 이후에는 모든 도구 호출이 단 하나의 MCP 경계를 통해 들어옵니다:

// AFTER: 하나의 경계가 모든 도구에 대해 인증(auth), 범위(scope), 테넌트 바인딩(tenant binding) 및 감사(audit)를 강제합니다.
public sealed class GovernedToolFilter(AiPrincipal principal, IAuthorizationService authz, IAiAuditLog audit)
{
...

단 하나의 OAuth 2.1 / Entra ID 경계가 N개의 맞춤형 인증 흐름을 대체했습니다. 도구 호출 오류율(Tool-call error rate)이 6%에서 0.8%로 감소했습니다. 이러한 오류의 대부분은 단순히 존재 자체가 사라진 인증 및 계약 불일치(contract mismatches) 문제였습니다.

4. 외부 AI를 위한 안전한 문 (A safe door for external AI)

이전에는 파트너사가 자신의 AI 어시스턴트가 귀사의 KPI를 가져오기를 원한다면, 이는 "그들을 위해 또 다른 클라이언트를 구축하라"는 의미였고, 따라서 답변은 "아니오"였습니다. 하지만 이제는 승인된 외부 어시스턴트가 Entra ID를 통해 인증을 받고, 해당 테넌트 및 campaigns:read 권한으로 범위가 지정된(scoped) 토큰을 획득하며, 내부 에이전트가 사용하는 것과 정확히 동일한 도구(tools)를 호출합니다. 이 과정은 동일하게 탐색되고, 범위가 지정되며, 감사(audited)됩니다. 이는 맞춤형 통합(bespoke integration) 방식에서는 존재하지 않았던 역량입니다.

MCP 호출은 실제로 어떻게 구성되는가

이 프로토콜은 매우 작습니다. 세 가지 메시지 유형(initialize, tools/list, tools/call)이 거의 모든 작업을 수행하며, 이들은 모두 전송 계층(운영 환경에서는 Streamable HTTP + SSE, 로컬 개발 시에는 stdio)을 통한 JSON-RPC 방식입니다. 이 작은 표면적이 핵심입니다. 어떤 클라이언트와 어떤 서버라도 구현할 수 있을 만큼 작으며, 바로 이 점이 역량을 가산적(additive)으로 만드는 요소입니다.

MCP를 도입하지 말아야 할 때

• 단일 에이전트, 단일 백엔드 (1×1). 직접적인 메서드 호출(direct method call)이 더 간단하고 빠릅니다.
• 외부 소비자가 없는 안정적인 내부 도구 세트. 가산적인 이점은 이론적인 수준에 그칩니다.
• 초저지연(Ultra-low-latency)이 필요한 핫 패스(hot paths). MCP는 홉(hop)과 JSON-RPC 프레이밍을 추가합니다.
• 인증(Auth) 체계가 여전히 혼란스러운 상태. MCP의 가치는 단일 ID 제공자(identity provider)와 결합될 때 복리로 증가합니다.
• 아직 v1을 출시하지 않은 경우. 먼저 단순한 통합 방식을 구축하십시오. N 또는 M이 실제로 증가할 때 MCP를 도입하십시오. 저희는 두 번째가 아니라 14번째 통합 단계에서 이를 도입했습니다.

앞으로 가져가야 할 모델

통합은 N×M으로 확장되지만, 프로토콜은 N+M으로 확장됩니다. 당신이 작성하는 모든 맞춤형 클라이언트는 다음 에이전트가 나타날 때마다 다시 지불해야 하는 곱셈입니다. 당신이 MCP 도구로 게시하는 모든 역량은 미래의 모든 에이전트가 무료로 얻게 되는 덧셈입니다.

• 엔드포인트(endpoints)가 아닌 역량(capabilities)을 게시하십시오. 각 도구를 낯선 에이전트가 스키마(schema)만으로 호출할 수 있는 계약(contract)으로 설계하십시오.
• 모든 도구 앞에 하나의 ID 경계(identity boundary)를 두십시오. 도구별로 범위가 지정되고 코드 내에서 테넌트에 귀속되는 단일 OAuth/Entra 관문을 만드십시오.
• 도구 스키마를 공개 API로 취급하십시오. 버전을 관리하고, 문서화하며, 신중하게 변경하십시오.

원문은 PrepStack에 게시되었습니다. MCP를 도입하면서 서버 경계(server boundaries)를 어디에 설정해야 할지 전문가의 조언이 필요하신가요? randhir.jassal[at]gmail.com으로 연락해 주세요.