이론, 패턴, 그리고 코드에 대한 14개의 파트. 이 마지막 파트는 솔직한 사후 보고서(debrief)입니다. Mattrx에서 1년 동안 MCP를 프로덕션(production) 환경에서 운영한 후, 실제로 무엇이 버텨냈는지, 튜토리얼에서는 절대 언급하지 않는 어떤 점들이 우리를 괴롭혔는지, 그리고 만약 내일 다시 시작한다면 무엇을 다르게 할 것인지에 대해 다룹니다. MCP가 우리의 에이전트(agent)를 똑똑하게 만든 것은 아닙니다. 그것은 모델(model)이 한 일입니다. MCP는 에이전트를 '출시 가능한(shippable)' 상태로 만들어 준 것입니다.

이것은 Model Context Protocol (MCP)에 대한 15부작 딥다이브의 마지막인 파트 15입니다. 우리는 Mattrx의 사례를 되짚어 봅니다. 3개의 서버, 하루 85,000건의 도구 호출(tool calls), 백엔드 5명 + 프론트엔드 6명 + SRE 1명으로 구성된 팀을 운영하며, 해피 패스(happy-path) 튜토리얼에는 담기지 않는 부분들을 알려드립니다.

요약 (TL;DR)

• 프로덕션 환경에서 MCP의 역할은 지능이 아닙니다. 에이전트를 관리 가능하고(governable), 안전하며(secure), 관찰 가능하고(observable), 확장 가능하며(scalable), 모델 불가지론적(model-agnostic)으로 만드는 것입니다.
• 유지된 것: N+M 프로토콜에 대한 베팅, 하나의 관리형 게이트웨이(governed gateway), 최소 권한 원칙(least privilege) + 감사 로그(audit log), 하드코딩 대신 디스커버리(discovery-over-hardcoding).
• 깨진 것: 로드 밸런서(load balancer) 뒤의 SSE, 도구 결과 주입(tool-result injection), 무제한 결과(unbounded results), 너무 광범위한 도구 세트, 콜드 스타트(cold starts).
• 다르게 할 것: 첫날부터 보안 적용, 처음부터 의도(intents)를 중심으로 설계된 도구, 확장 전 관찰 가능성 확보, 더 이른 시점의 엔터프라이즈 관리형 인증(enterprise-managed auth).
• 통합 결과: 14개의 통합 → 3개의 서버, 약 9,000 LOC(코드 라인 수) 제거, 온보딩 3일 → 2시간, 도구 호출 오류 6% → 0.8%, 에이전틱(agentic) p95 4.2s → 1.8s, 주당 약 40건의 남용 시도 차단, 1년 동안 테넌트 간 유출(cross-tenant leaks) 제로.

우리가 실제로 여기에 도달한 과정

이 중 어느 것도 사전에 설계된 것이 없었습니다. 각각의 기능은 상처(scar)를 통해 얻은 결과물이었습니다.

Mattrx의 MCP로 가는 길 — 약 1년에 걸친 실제 순서:

통합 #14      -> N×M 글루(glue)가 마침내 감당 불가능해짐            (파트 1)
...

메타 레슨(meta-lesson): 당신은 이 기능들이 필요해진 바로 '다음 날'에 이 기능들을 추가하게 될 것입니다. 이 시리즈의 가치는 이러한 기능들을 필요하기 '전날'에 추가할 수 있도록 돕는 데 있습니다.

유지된 것 — 성과를 거둔 베팅들

1. N+M 프로토콜에 대한 베팅. 14개의 맞춤형 통합(bespoke integrations)을 3개의 MCP 서버로 압축함으로써 약 9,000줄의 글루 코드(glue code)를 삭제했고, 온보딩(onboarding) 기간을 며칠에서 몇 시간으로 단축했으며, 인증(auth), 거버넌스(governance), 관측성(observability)을 14곳이 아닌 단 한 곳에 연결할 수 있게 했습니다. 프로젝트 전체에서 가장 레버리지가 높았던 결정입니다. 이것부터 시작하세요.

2. 단일 거버넌스 게이트웨이 (One governed gateway). 모든 모델 및 도구 호출이 단일 경계(인증, 토큰 예산, PII(개인정보) 마스킹, 추가 전용(append-only) 감사)를 통과하도록 한 덕분에

2. 도구 결과 주입(Tool-result injection). 우리는 초기에 사용자 프롬프트 주입 공격에 대비했지만, 실제 공격이 _도구 결과_를 통해 들어왔을 때 허를 찔렸습니다. 그 내용은

사용자 / 에이전트 (User / agent)
   |
[ 게이트웨이: Front Door / APIM ]  인증(auth)(6) · 권한 범위(scopes)(7) · 속도 제한(rate-limit)(11) · 라우팅(route)
...

모든 수치를 한곳에 모아

앞으로 가져갈 모델

MCP가 우리의 에이전트를 지능적으로 만든 것이 아니라, 에이전트를 출시 가능하게 (shippable) 만들었습니다. 모델은 지능을 가져왔고, MCP는 정체성 (identity), 정책 (policy), 통제된 경계 (governed boundary), 관측 가능성 (observability), 확장성 (scale), 그리고 자율 에이전트를 프로덕션 데이터에 연결하고도 밤에 편히 잠들 수 있게 해주는 모델 독립성 (model-independence)을 가져왔습니다. 프로토콜은 쉬운 20%에 불과했습니다. 나머지 80% — 에이전트가 누구인지, 무엇을 할 수 있는지, 속았을 때 어떤 일이 발생하는지, 그리고 에이전트가 무엇을 했는지 어떻게 알 수 있는지 — 가 진짜 작업이며, 에이전트가 데모를 벗어나 실제로 출시될 수 있을지를 결정하는 것은 바로 이 작업입니다.

본 시리즈 전체를 관통하는 세 가지 습관:

1. 기능을 공개하고, 하나의 경계에서 통제하십시오 (Publish capabilities; govern at one boundary). 서버는 도구 (tools)를 선언하고, 단일 게이트웨이 (인증, 권한 범위, 감사)가 모든 호출을 통제합니다.
2. 에이전트가 속을 것이라고 가정하고, 할 수 있는 일을 제한하십시오 (Assume the agent will be tricked, and cap what it can do). 최소 권한 원칙 (Least privilege), 주입 방어 (injection defense), 그리고 관측 가능성 (observability)은 성공적인 공격을 통제 가능하고 가시적인 이벤트로 전환시킵니다.
3. 도구를 소유하고, 그 외의 모든 것은 교체 가능하게 만드십시오 (Own the tools; make everything else swappable). 모델, 프레임워크, 심지어 전송 계층 (transport)조차 변경할 수 있는 부분입니다. 당신이 유지해야 할 것은 당신의 도구와 거버넌스 (governance)입니다.

이것이 시리즈의 결론입니다. 15개의 파트, 하나의 시스템, 하나의 실행 예시, 그리고 모든 수치 뒤에 담긴 1년의 프로덕션 경험입니다. 이제 통합 (integration)이 아닌 기능 (capability)을 공개하십시오.

원문은 prepstack.co.in에 게시되었습니다. 이것은 15부작 MCP 딥다이브의 피날레입니다 — 전체 시리즈는 원문 포스트 끝에 링크되어 있습니다.