03 2026년 클라우드 솔루션 리포트: API 관리

│정채상 KAIST

들어가며: MCP는 표준이 되기 전에 섀도우 IT가 됐다

20여 년 전 회사 PC를 운영하던 IT 부서의 풍경은 어수선했다. 직원들은 검색 한 번으로 찾은 사이트에서 화면보호기, 무료 코덱, 출처 모를 유틸리티의 실행 파일(.exe)을 받아 설치했고, 그 안에 무엇이 들어 있는지를 회사가 추적할 방법은 거의 없었다. 사태가 정리된 것은 백신이 좋아져서가 아니라, "어떤 실행 파일이 어떤 경로로, 어떤 권한을 가지고 회사 안에 들어오는지"를 한 점에서 통제하는 엔드포인트 관리·그룹 정책·소프트웨어 카탈로그라는 통제점(Control Plane)이 자리 잡았기 때문이었다.

2026년 5월의 풍경은 그 시절과 닮았다. 개발자는 깃허브와 npm 레지스트리에서 별점이 높은 순으로 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 서버를 골라 회사 데이터에 연결한다. 그러나 별점은 인기의 신호일 뿐 안전의 보증이 아니고, 부풀리기도 어렵지 않다. 정작 AI 에이전트는 자기가 호출한 도구가 어디서 왔는지조차 알지 못한다. 퀄리스(Qualys)는 2026년 3월 보고서에서 MCP 서버를 "AI 시대의 새로운 섀도우 IT(Shadow IT)"라고 표현했다. 비유처럼 들리지만 실은 정확한 진단이었다.¹⁾ MCP는 2024년 말 앤트로픽이 공개한 이후 1년 반 만에 활성 공개 서버가 1만 개를 넘겼고, 오픈AI, 구글 딥마인드, 마이크로소프트가 이 표준을 채택하며 사실상의 산업 표준으로 자리 잡았다. 동시에 받아쓰기가 너무 쉬운 탓에 IT 부서는 누가 무엇에 어떻게 연결하는지 더는 추적하지 못한다.

추적하지 못하는 이 사각지대가 얼마나 넓은지는 수치가 말해 준다. 노스틱(Knostic)의 공개 인터넷 스캔에 따르면 1,800개 이상의 MCP 서버가 인증 없이 동작했고,²⁾ 애스트릭스(Astrix) 분석에 따르면 MCP 서버의 53%가 정적 시크릿(Static Secrets, 코드나 환경 변수에 고정된 장기 토큰)에 의존했다. 인증 없이 노출된 서버, 장기 토큰에 의존하는 연결, 정식 승인 없이 운영에 자리 잡은 의존성. 모두 '누가 무엇에 연결돼 있는지'를 통제하지 못해 생기는 문제이고, 통제점이 들어서야 비로소 드러나고 막을 수 있다.

성격이 다른 위협도 있다. 패키지 자체가 공급망 경로로 들어와 승인된 서버 안에서 작동하는 사고다. 한 번 승인한 서버라도 업데이트가 일어날 때마다 다시 점검하지는 않기 때문에, 신뢰하던 패키지의 업데이트 한 번이 그대로 위협으로 바뀐다. mcp-remote 패키지의 원격 코드 실행 취약점(CVE-2025-6514)은 43만 7,000건의 다운로드 환경에 영향을 미쳤고, 주간 다운로드 1,500건에 이르던 인기 패키지 포스트마크(Postmark) MCP 서버는 사용자가 발송하는 모든 이메일을 공격자에게 BCC로 조용히 전달했다. 마이크로소프트 365 코파일럿의 CVE-2025-32711은 숨겨진 프롬프트로 데이터 유출을 가능하게 했고, 아사나(Asana) MCP의 버그는 서로 다른 고객 인스턴스 사이에 데이터를 노출시켰다. 이 부류는 승인된 서버 내부에서 일어나기 때문에, 뒤에서 보듯 게이트웨이를 통과시키는 것만으로는 막히지 않는다.

MCP를 정의한 앤트로픽 2026년 4월 로드맵도 같은 공백을 자기 고백처럼 적었다. 엔터프라이즈 준비 상태를 4가지 우선순위 중 하나로 꼽으면서도, 그것이 '아직 정의가 가장 덜 된 영역'이라고 인정했다. 무엇이 부족한지는 감사 추적, SSO(Single Sign-On) 통합, 게이트웨이 동작, 설정 휴대성이라는 항목으로 정리했다.³⁾ 표준의 세부가 정해지기도 전에 광범위한 채택이 먼저 일어난 것이다.

20여 년 전과 다른 점은 통제점이 어디에 들어설지가 비교적 분명하다는 점이다. 그 자리에 들어서고 있는 것이 API 게이트웨이다. 4월호에서 다룬 코드형 인프라(IaC)가 인프라를 코드로 정의하는 계층이었고 5월호의 쿠버네티스가 워크로드의 운영체제였다면, API 게이트웨이는 그 위에서 움직이는 AI 트래픽이 반드시 통과하는 관문이다. 이 관문을 두고 6개 벤더가 경쟁한다. 이번 글에서 다룰 벤더는 Kong, 아피지(Apigee, 구글 클라우드), 아마존 베드락 에이전트코어(AgentCore), 뮬소프트(MuleSoft, 세일즈포스), 타이크(Tyk), 포스트맨(Postman)이다. 모두가 "MCP 지원"을 발표한 2026년에 정작 중요한 기준은 지원 여부가 아니라, 이미 퍼진 섀도우 MCP를 어떻게 게이트웨이의 통제 아래로 들이는가에 있다.

2026년 API 관리의 세 가지 큰 흐름

섀도우 MCP의 실상

MCP 서버는 깃허브와 npm에서 받아 즉시 실행할 수 있는 가벼운 자바스크립트, 파이썬 프로세스인데, 이 가벼움이 폭발적 성장의 동력이면서, IT 부서가 연결 관계를 파악하지 못하는 원인이기도 하다. 퀄리스 보고서는 회피 패턴을 세 가지로 정리한다. 감시가 닿지 않는 높은 번호의 포트를 무작위로 잡아 로컬에서 도는 사례, IDE 플러그인과 개발자 도구에 내장돼 IT의 시야 밖에 머무는 사례, 테스트로 시작했다가 정식 승인 없이 프로덕션 의존성이 된 사례이다. 노스틱이 발견한 1,800개 이상의 무인증 서버는 공개 인터넷에 노출된 것만 집계한 숫자이며, 사내망에 머무는 무관리 서버는 여기에 포함되지 않는다. mcp-remote와 포스트마크의 사례는 패키지 공급망 자체가 위협 요소가 됐음을 보여 주는데, 인기 패키지의 업데이트 한 번이 수십만 개의 설치 환경을 동시에 위험에 빠뜨린다.

거버넌스는 본질적으로 프로토콜 계층이 아니라 조직 계층의 문제다. DX 히어로즈의 2026년 초 분석은 "프로토콜 개선이 조직의 정책을 대신할 수는 없다"고 정리하면서, 도구 단위로 통제하는 방법은 표준화되지 않은 채 프로토콜이 기본으로 제공하는 것은 서버 단위의 차단과 허용에 그친다는 점, 로컬 MCP 설정이 중앙 레지스트리의 통제를 우회한다는 점을 짚는다.⁴⁾ 정책으로서의 거버넌스가 실제로 작동하려면, 그것을 강제하는 운영 차원의 통제점이 있어야 한다. 그 통제점은 프로토콜이 아니라 운영의 단일 출입구에서 만들어진다.

통제점의 귀환 — API 게이트웨이가 AI 통제점이 되다

API 게이트웨이는 새로운 발명이 아니다. 인증, 속도 제한(Rate Limiting), 로깅, 트래픽 라우팅, 정책 적용은 지난 20년간 게이트웨이의 표준 기능이었다. 2026년 들어 달라진 것은 이 기능들이 새로운 대상에 적용된다는 데 있다. 인증의 대상은 사람과 앱에서 AI 에이전트로 옮겨 가고, 속도 제한의 단위는 초당 요청에서 분당 토큰으로 확장되며, 감사의 단위는 호출당 페이로드에서 에이전트의 의사결정 추적으로 넓어진다.

여기서 한 가지 분명히 해 두고 싶은 것은, 게이트웨이가 보안 도구를 대체하지 않는다는 점이다. 위협을 탐지하고 권한을 판별하는 일은 보안 계층의 몫으로, 3월호에서 다룬 CNAPP(Cloud-Native Application Protection Platform, 클라우드 네이티브 애플리케이션 보호 플랫폼), 제로 트러스트, 비인간 ID의 영역이다. 게이트웨이의 고유한 역할은 모든 AI 트래픽이 반드시 한 점을 통과하도록 강제하는 인라인 통제(Inline Enforcement)다. 보안 도구가 무엇이 위험한지를 판정한다면, 게이트웨이는 그 판정이 적용될 단일 경로를 만든다. 그래서 앞 챕터의 무인증이나 미승인 부류는 게이트웨이로 가시화되고 차단되지만, 포스트마크 BCC처럼 승인된 서버 내부에서 벌어지는 행위는 게이트웨이가 아니라 보안 계층이 잡아야 한다. 이후 연재 글에서 다룰 ID와 접근 관리가 '누가'를 판정한다면, 게이트웨이는 '어느 경로로'를 강제한다.

이 역할을 두고 6개 벤더가 저마다 뛰어들고 있는데, 다음 챕터의 벤더 분석에서 평가축별로 비교한다. 다만 모든 조직이 지금 이 통제점을 새로 만들어서 관리해야 하는 것은 아니다. MCP가 이미 운영에 들어와 있거나 에이전트가 사내 데이터에 닿고 있다면 그 시점이 앞당겨지고, 그렇지 않다면 인벤토리부터 시작해도 늦지 않다(도입 시점을 가르는 기준은 맺으며에서 구체화한다). 기존 API 게이트웨이가 있다면 이를 교체할 일은 아니지만, 그 게이트웨이가 MCP와 A2A(Agent-to-Agent, 에이전트 간 통신) 트래픽을 같은 평면에서 다룰 수 있는지, LLM 토큰 비용을 정책으로 제한할 수 있는지, 에이전트별 권한 분리를 지원하는지를 로드맵에서 확인해야 한다. 5월호에서 쿠버네티스가 AI 워크로드의 운영체제 자리에 올랐다고 짚었는데, 그 위에는 통제점이 따로 들어서야 한다.

"MCP-ify"의 올바른 방법

"MCP-ify"는 기존에 쓰던 API를 AI 에이전트가 호출할 수 있는 MCP 도구 형태로 바꿔 내놓는 과정이다. 단순한 변환으로 보일 수 있으나, 게이트웨이를 거치지 않은 MCP-ify는 회사 데이터로 직접 이어지는 새 출입구를 내는 일이며, 들어가며에서 본 .exe를 직접 받아 설치하던 시절과 다를 바 없다.

다음의 세 단계를 따르는 게 올바른 순서이다.

• 1.발견(Discovery) 단계: 사내 API 인벤토리를 정비한다.

• 2.통제 노출(Controlled Exposure) 단계: 게이트웨이를 단일 경로로 강제하되, 노출하려는 MCP 서버의 출처와 무결성을 함께 검증한다.

• 3.감사 가능 운영(Auditable Operation) 단계: 에이전트 호출 추적과 토큰 비용 추적을 함께 운영한다.

이 순서를 건너뛰어 발견 단계 없이 노출부터 시작하면 섀도우 MCP가 오히려 자라난다. Kong 컨텍스트 메시, 에이전트코어 게이트웨이, 아피지 API 허브의 스펙 부스트(Spec Boost) 같은 벤더 자동화가 통제 노출 단계의 마찰을 줄여 주지만, 발견과 감사 가능 운영의 책임은 여전히 도입 조직의 몫이다. 4월호에서 "AI가 인프라 코드를 쓸 때 정책형 코드(Policy as Code)로 가드레일을 설정하라"고 제언한 것과 같은 원칙이 여기에도 그대로 적용된다. 에이전트가 API를 호출할 때에도 게이트웨이 정책이 같은 가드레일 역할을 한다.

벤더 심층 분석: 통제점 역량의 비교

벤더들은 아래 표 1과 같이 다섯 가지 축으로 비교한다. 1) 발견 자동화(섀도우 MCP를 가시화하는가), 2) 인증과 권한 분리(에이전트별 권한을 분리하는가), 3) 비용 통제(LLM 토큰 비용을 사전 정책으로 제한하는가), 4) 감사 추적(에이전트 호출을 추적 가능한가), 5) 다중 환경 적용성(특정 클라우드 서비스 제공사나 생태계에 종속되지 않는가)이다.

다만 여섯 벤더가 모두 같은 비교 선상에 서는 것은 아닌데, 포스트맨은 런타임 통제점이라기보다 발견과 카탈로그 단계를 보강하는 보완재에 가까워, 권한 분리와 비용 통제 비교 항목에서는 빠지고, 나머지 다섯이 통제점 자체를 두고 경쟁하는 구도이다.

그림 1 2026년 API 게이트웨이 6개 벤더의 통제점 역량 비교

Kong — API 게이트웨이에서 AI 연결성 플랫폼으로

Kong은 2026년 2월 "AI 연결성"이라는 새 카테고리를 선언했다. 그 한가운데에 컨텍스트 메시(Context Mesh)가 있다. 사내 API를 자동 발견해 MCP 도구로 변환하고 런타임 거버넌스와 함께 배포하는, Kong이 업계 최초로 내세우는 시도다.⁵⁾ MCP 레지스트리는 Kong의 통합 API 관리 플랫폼인 Kong Konnect의 API 서비스 카탈로그에 통합돼 MCP 서버·도구의 등록, 발견, 거버넌스를 한 곳에 모은다. 사내에 흩어진 기존 API를 스캔하고, 인증을 포함한 MCP 도구 정의를 자동 생성한 뒤, Kong AI 게이트웨이에 배포하며 기존 접근 제어와 정책을 상속시키는 흐름은 발견 → 통제 노출 → 감사 가능 운영의 세 단계를 한 제품 안에서 처리하려는 접근이다. 솔레이스(Solace, 실시간 이벤트 스트리밍 업체)와의 파트너십으로 API·이벤트 스트리밍·AI 서비스를 단일 통제점으로 묶기로 했다.⁶⁾

그림 2 Kong 컨텍스트 메시 — 사내 API를 자동 발견해 MCP 도구로 변환·배포하는 흐름

다만 도입 전에 살펴야 할 점들이 있는데, 먼저 컨텍스트 메시와 MCP 레지스트리가 모두 테크 프리뷰 단계여서 프로덕션 검증이 아직 부족하다. 다음으로 "AI 연결성"이라는 새 카테고리의 시장은 아직 형성 중이어서 도입하려 해도 예산 확보의 근거가 약해진다. 마지막으로 API 트래픽 기반 과금에 AI 에이전트 트래픽이 더해지면 비용 예측이 어려워지는 점이 있다.

아피지(Apigee, 구글 클라우드) — 검증된 API 관리에 LLM 비용 통제를 더하다

아피지는 2025년 가트너 API 관리 매직 쿼드런트 리더에 10년 연속으로 자리 잡았고 평가 부문 중 '실행 능력'에서 가장 높은 자리에 올랐다.⁷⁾ 빅쿼리, 컴퓨트 엔진을 포함한 구글 클라우드 전체 서비스에 MCP 지원이 통합된 생태계의 일부로 운영되며, 관리형 API를 커스텀 MCP 서버로 변환하는 기능이 있어 기존 아피지 고객은 자사 API를 즉시 AI 에이전트에게 노출할 수 있다. 그리고 GKE용 APIM 오퍼레이터는 정식 출시되어 쿠버네티스 환경에 경량 API 관리를 제공한다.⁸⁾

다른 솔루션들과의 차별점은 LLM 워크로드 정책 2종이 정식 출시되어 토큰 사용량 모니터링과 속도 제한으로 AI 호출의 비용과 리소스를 통제할 수 있게 되었는데, 이는 "AI 시대의 API 핀옵스(FinOps)"에 해당하는 기능이다. API 허브의 스펙 부스트는 AI가 기존 API 스펙을 분석해 예시·설명·에러 문서를 자동 보강하며, 에이전트가 API를 더 잘 이해하도록 돕는 발견 단계의 자동화를 이루어 낸다.

그림 3 아피지가 AI 에이전트 트래픽을 중개하며 인증·속도 제한·분석을 적용하는 구조⁹⁾

약점도 분명하다. 가격이 경쟁 대비 높아 소규모 트래픽에서 진입 비용이 부담으로 작용한다. 구글 클라우드에 종속돼 멀티 클라우드 환경에서 단독으로 운영하기 어렵다. 아피지 X(차세대)와 아피지 엣지(레거시) 사이의 마이그레이션이 복잡하다는 점이 고객 불만으로 남아 있다.

아마존 베드락 에이전트코어 — API에서 에이전트 게이트웨이로

아마존 베드락 에이전트코어 게이트웨이는 API 게이트웨이 엔드포인트, 람다 함수, 기존 서비스를 몇 줄의 코드로 MCP 호환 도구로 변환해 에이전트에게 제공한다. AWS 워크로드를 가진 조직에는 마찰이 가장 적은 통제 노출 경로인 셈이다.

통제 역량의 핵심은 2026년 3월 3일 정식 출시된 정책이다. 에이전트의 게이트웨이 도구 호출을 사전에 가로채 세밀한 권한을 적용하는 기능으로, 에이전트 거버넌스를 처음으로 프로덕션 수준에서 구현한 것으로 꼽힌다.¹⁰⁾ 평가는 에이전트의 실제 행동에 기반한 품질 평가를 제공하며, 에피소딕 메모리는 에이전트가 경험에서 학습해 유사 상황에 적응하는 장기 메모리이고, 양방향 스트리밍은 음성 에이전트의 자연스러운 대화를 지원한다.

그림 4 에이전트코어 게이트웨이의 정책(Policy) 설정 — 도구 호출 전 권한 적용

다만 살펴야 할 점이 두 가지 있다. 먼저 에이전트코어 게이트웨이가 베드락 생태계 안에서만 완전한 기능을 발휘해, 앤트로픽 API 직접 호출이나 애저 오픈AI같은 다른 LLM 제공사와의 통합이 제한적이다. 다음으로 기존 API 게이트웨이와 에이전트코어 게이트웨이의 관계가 불명확해 둘을 동시에 운영해야 하는 상황이 발생할 수 있다.

뮬소프트(MuleSoft, 세일즈포스) — 통합 플랫폼에서 에이전트 오케스트레이터로

뮬소프트 에이전트 패브릭(Agent Fabric)은 에이전트 시대의 통합 허브를 지향한다. 에이전트 레지스트리(에이전트·AI 자산 카탈로그), 에이전트 브로커(에이전트 간 지능형 라우팅), 플렉스 게이트웨이(MCP·A2A 보안·관리), 그리고 에이전트 비주얼라이저(에이전트 상호작용 가시화)의 네 기둥으로 구성된다.¹¹⁾ MCP와 A2A를 함께 다루는 드문 구성이며, 세일즈포스 에이전트포스 3의 네이티브 MCP 지원과 결합돼 CRM 데이터에서 AI 에이전트 동작까지 끊김 없는 흐름을 제공한다. 애니포인트 코드 빌더(Anypoint Code Builder)는 커서와 윈드서프 같은 MCP 지원 IDE에서 뮬소프트 개발을 가능하게 하며, 애니포인트용 아인슈타인이 API 스펙과 데이터위브(Dataweave) 변환을 자동 생성한다. 뮬소프트는 2026년 가트너 iPaaS(통합 플랫폼 서비스) 매직 쿼드런트에서도 줄곧 리더로 평가받아 왔다.

그림 5 뮬소프트 에이전트 패브릭의 네 기둥 — Discover·Orchestrate·Govern·Observ

약점도 짚어 보면, 세일즈포스 생태계에 종속돼 세일즈포스를 쓰지 않는 조직에는 과잉 투자로 작용한다. 이 도구들을 아우르는 핵심 제품인 애니포인트 플랫폼의 가격이 엔터프라이즈 전용 수준이어서 중소 규모 조직에 진입 장벽이 된다. 통합 플랫폼의 복잡성 때문에 API 관리만 필요한 조직에는 전체 스택이 과하다는 점을 이야기한다.

타이크(Tyk) — 오픈소스 AI 게이트웨이의 대안

타이크는 REST, 그래프QL(GraphQL), TCP, gRPC를 지원하는 오픈소스 API 게이트웨이로, 기능 잠금 없는 '배터리 포함(Batteries-included)' 철학이 차별점이다. CNCF(클라우드 네이티브 컴퓨팅 재단), 리눅스 재단, OpenAPI 스펙 멤버로 오픈소스에 진정성 있게 참여한다. 타이크 AI 스튜디오는 오픈코어 AI 게이트웨이로, LLM·에이전트·MCP 툴체인·RAG 워크로드의 라우팅, 거버넌스, 보안을 단일 통제점에서 처리한다. 4월호에서 다룬 오픈토푸(OpenTofu)가 테라폼의 오픈소스 대안이었던 것과 같은 맥락에서, 타이크는 Kong의 상용 전략에 대한 오픈소스 대안이고, 속도 제한 같은 핵심 통제는 커뮤니티 에디션에서도 문제없이 제공된다. 따라서 데이터 주권이 중요한 규제 산업 등 자체 호스팅을 선호하는 조직에게 가장 자연스러운 옵션으로 고려된다.

그림 6 타이크의 거버넌스 게이트웨이를 통한 MCP 도구 발견·통제 흐름¹²⁾

반대로 살펴야 할 점도 몇 가지 있는데, 먼저 Kong, 아피지, AWS 대비 시장 인지도가 낮아 엔터프라이즈 도입을 설득하기 어렵다. 다음으로는 AI 스튜디오가 오픈코어(핵심 오픈소스에 상용 확장이 더해진 형태)여서 오픈소스 부분에서 AI 기능의 경계가 어디까지인지 모호하다. 그리고 글로벌 PoP(Point of Presence, 접속 거점) 수와 인프라가 클라우드 서비스 제공사(CSP) 게이트웨이 대비 한정적이다.

포스트맨(Postman) — API 테스팅 도구에서 AI 네이티브 API 플랫폼으로

포스트맨은 2026년 3월 "AI 네이티브 API 개발의 새 시대"를 선언하며 플랫폼을 전면 개편했다.¹³⁾ 에이전트 모드는 AI가 포스트맨과 연결된 리포지터리 전반에서 컬렉션·테스트·목(Mock)을 편집하고 생성하는 에이전틱 기능이며, MCP 프로토콜의 네이티브 지원으로 아틀라시안, 클라우드워치, 깃허브 같은 MCP 서버와 통합된다. API 카탈로그는 스펙·컬렉션·테스트 실행·CI/CD 활동·프로덕션 관측성(Observability)을 단일 뷰로 제공하는 'API의 단일 출처'를 지향한다. AI 테스트 생성 기능은 API에 대한 계약·부하·단위·통합·E2E(종단 간) 테스트를 자동으로 만들어 주며, 에이전트 모드는 MCP 서버에서 컨텍스트를 받아 다단계 변경을 자동화한다.

그림 7 포스트맨 API 카탈로그 — 스펙·테스트·관측성을 단일 뷰로 모은 'API 단일 출처'

반면에 약점으로는 포스트맨의 전통적 강점이 API 테스팅에 있고 API 관리에는 있지 않아 Kong, 아피지, AWS 같은 런타임 게이트웨이 기능을 제공하지 않는다는 점이다. 그리고 AI 네이티브 기능은 2026년 3월에 출시돼 대규모 엔터프라이즈 레퍼런스가 아직 쌓이지 않았다는 평이고, 유료 플랜의 가격이 팀 규모에 따라 빠르게 오르는 점도 자주 지적된다.

맺으며: CIO·CTO를 위한 API 전략 제언

2026년의 API 전략은 새 표준의 도입이 아니라 통제점의 복원에서 시작한다. 다만 모든 조직이 지금 당장 게이트웨이를 새로 들여야 하는 것은 아니다. 사내에서 MCP 서버가 이미 실제 운영에 깊이 자리 잡았거나, AI 에이전트가 사내 데이터에 접근하고 있거나, LLM 토큰 비용이 무시할 수 없는 수준에 이르렀다면 통제점의 복원은 미룰 수 없는 과제다. 셋 중 어디에도 해당하지 않는다면 지금은 도입을 서두르기보다 인벤토리와 모니터링으로 도입 시점을 가늠하기를 추천한다. 통제점의 복원이 필요한 조직에게 할 질문은 "이미 사내에 퍼진 섀도우 MCP를 어떻게 게이트웨이 뒤로 끌어들이고, 감사 가능한 운영으로 정착시킬 것인가"가 될 것인데, 아래의 네 가지를 권한다.

• 1.섀도우 MCP의 인벤토리를 먼저 수행한다: 통제점을 세우기 전에 회사 안에 어떤 MCP 서버가 어디에 연결돼 있는지를 파악하는 것이 우선이다. 깃허브와 npm 사용 분석, 사내 네트워크 트래픽 분석, 개발자 인터뷰의 세 경로로 인벤토리를 작성할 것을 권한다. 이 작업 없이 게이트웨이를 도입하면 통제 대상이 무엇인지 모르는 상태로 시작한다.

• 2.게이트웨이를 단일 출입구로 강제한다: 인벤토리가 확보되면 모든 MCP 트래픽이 게이트웨이를 거치도록 네트워크 정책을 설정한다. 이는 .exe 시대에 그룹 정책으로 미승인 실행 파일의 설치를 차단했던 것과 같은 원리다. 기존 API 게이트웨이가 MCP와 A2A를 지원하지 않으면 단기적으로는 어댑터를 두고, 중기적으로는 게이트웨이 교체 또는 추가 도입을 검토할 것을 권한다.

• 3.LLM 토큰 비용을 API 핀옵스의 일부로 설계한다: 에이전트가 API를 호출할 때 발생하는 LLM 토큰 비용은 기존 API 비용 구조와 다른 변동성을 갖는다. 아피지의 LLM 워크로드 정책이나 Kong AI 게이트웨이의 토큰 한도 같은 게이트웨이 레벨 통제를 핀옵스의 일부로 설계할 것을 권한다. 사후 청구서 분석이 아니라 사전 정책 통제가 필요한 영역이다.

• 4.API 팀과 AI 팀의 거버넌스를 통합한다: API 팀과 AI 팀이 분리된 거버넌스로 움직이면, API는 에이전트가 안전하게 쓰기 어려운 상태로 남고, 에이전트는 통제 없이 API를 호출한다. 두 전략을 하나의 거버넌스 프레임워크 안에서 운영할 것을 권한다. 앞에서 인용한 DX 히어로즈의 진단처럼 거버넌스의 실패는 프로토콜 계층이 아니라 조직 계층에서 일어나며, 통제점의 복원은 결국 조직의 일이다.

반대로 피해야 할 것도 분명하다. 인벤토리 없이 게이트웨이부터 들이는 일, 발견을 건너뛰고 노출부터 여는 일, "MCP 지원" 발표만 보고 게이트웨이가 사고까지 막아 준다고 기대하는 일이다. 셋 다 통제점을 세우는 대신 새 출입구를 늘린다.

20여 년 전 .exe 시대의 끝을 만든 것은 더 좋은 백신이 아니라 통제점의 등장이었다. 2026년 AI 인프라에서 같은 일이 다시 일어나고 있으며, API 게이트웨이가 그 통제점 자리에 들어서고 있다.

Appendix

참고문헌

1) Qualys. "MCP Servers: The New Shadow IT for AI in 2026." Qualys Blog, 2026.03.19. 
https://blog.qualys.com/product-tech/2026/03/19/mcp-servers-shadow-it-ai-qualys-totalai-2026 

2) Hou, J., et al. "Securing the Model Context Protocol (MCP): Risks, Controls, and Governance." arXiv:2511.20920, 2026. 
https://arxiv.org/html/2511.20920v1 

3) Model Context Protocol. "The 2026 MCP Roadmap." Model Context Protocol Blog, 2026.04. 
https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/ 

4) DX Heroes. "MCP Governance in the Enterprise: What the Landscape Looks Like in Early 2026." 2026. 
https://dxheroes.io/insights/mcp-governance-landscape-early-2026 

5) Kong. "Kong Launches Context Mesh to Connect Enterprise Data to AI Agents." PRNewswire, 2026.02.10. 
https://www.prnewswire.com/news-releases/kong-launches-context-mesh-to-connect-enterprise-data-to-ai-agents-302683492.html 

6) Kong. "Kong and Solace Announce Partnership to Unify API and Real-Time Data and Event Streaming." PRNewswire, 2026.02.18. 
https://www.prnewswire.com/news-releases/kong-and-solace-announce-partnership-to-unify-api-and-real-time-data-and-event-streaming-302691193.html 

7) Google Cloud. "Apigee, a Leader in 2025 Gartner Magic Quadrant for API Management." Google Cloud Blog, 2025.
https://cloud.google.com/blog/products/ai-machine-learning/apigee-a-leader-in-2025-gartner-api-management-magic-quadrant 

8) Google Developers. "Google Cloud Announces APIM Operator for Apigee General Availability." Google Developers Blog, 2025.05.12. 
https://developers.googleblog.com/google-cloud-announces-apim-operator-for-apigee-general-availability/ 

9) https://cloud.google.com/blog/products/api-management/using-apigee-api-management-for-ai 

10) AWS. "Amazon Bedrock AgentCore adds Quality Evaluations and Policy Controls for Deploying Trusted AI Agents." AWS Blog, 2026.03.03. 
https://aws.amazon.com/blogs/aws/amazon-bedrock-agentcore-adds-quality-evaluations-and-policy-controls-for-deploying-trusted-ai-agents/ 

11) Salesforce. "Salesforce Launches MuleSoft Agent Fabric to Orchestrate and Govern Any AI Agent Across the Agentic Enterprise." Salesforce News, 2026.
https://www.salesforce.com/news/stories/mulesoft-agent-fabric-announcement/ 

12) https://tyk.io/learning-center/mcp-gateway-architecture-technical-guide/ 

13) Postman. "New Postman is Here." Postman Blog, 2026.03.02. https://blog.postman.com/new-postman-is-here/