소개
Uber 에서 AI 에이전트가 빠르게 도입되면서, 팀이 코드, 데이터, 운영 시스템과 상호작용하는 방식에 근본적인 변화가 일어났습니다. MCP(Model Context Protocol) 를 활용한 초기의 임시 통합만으로도 그 가치는 분명했습니다. 에이전트가 실시간 비즈니스 컨텍스트에 접근하고, 내부 서비스를 쿼리하며, 사용자를 대신해 의미 있는 작업을 수행할 수 있게 되면서 역량이 비약적으로 향상되었습니다. 이러한 초기 성과는 MCP 가 Uber 내부에서 에이전트 시스템을 구축하기 위한 강력한 추상화 계층임을 증명했습니다.
하지만 도입 속도가 빨라지면서 중대한 과제도 함께 드러났습니다. 각 팀이 개별적으로 통합을 구축하다 보니 도구 파편화와 인프라 중복이 발생했습니다. MCP 도구는 찾기 어렵고 안정적으로 운영하기 까다로웠으며, 특정 서비스나 에이전트 구현에 강하게 결합되어 있었습니다. 소규모에서는 이런 방식이 통했지만, 수백 개의 팀이 에이전트 워크플로를 탐색하기 시작하면서 Uber 의 요구사항을 충족하지 못했습니다. 통합 아키텍처 없이는 MCP 확장이 운영 복잡성, 보안 위험, 개발자 마찰을 증가시켜 결국 그 영향력을 제한할 수밖에 없었습니다.
Uber 규모에서 MCP 의 잠재력을 온전히 끌어내려면, 팀의 유연성은 유지하면서도 AI 에이전트가 기존 백엔드 시스템과 상호작용하는 방식을 표준화할 중앙 집중형 확장 가능 솔루션이 필요했습니다. 이 솔루션은 프로토콜 차이(HTTP, gRPC™, TChannel) 를 추상화하고, 일관된 보안 및 관측 가능성 보장을 강제하며, 회사 전체에서 MCP 도구를 쉽게 생성·검색·재사용할 수 있도록 해야 했습니다.
우리는 이러한 요구를 해결하기 위해 MCP Gateway 를 구축했습니다. 이는 Uber 의 모든 MCP 상호작용을 지원하는 기반 마이크로서비스로, AI 에이전트와 기존 백엔드 서비스 및 네이티브 MCP 서버 사이에서 오케스트레이션 및 라우팅 계층 역할을 합니다. MCP 로직을 단일 게이트웨이로 중앙 집중화함으로써, 에이전트-서비스 간 상호작용에 일관된 실행 모델을 제공하고 팀이 핵심 인프라를 다시 만들 필요가 없도록 했습니다. 기존 API 는 MCP 도구로 매끄럽게 노출되고, 한 곳에서 관리·운영되며, 여러 에이전트가 동일한 방식으로 사용할 수 있습니다. MCP Gateway 는 Uber 내에서 AI 에이전트를 구축할 수 있는 확장 가능하고 빠르며 일관된 경로를 열어주었으며, 현재 800 개 이상의 MCP 서버와 5,000 개 이상의 도구를 호스팅하고 있습니다.
그림 1: MCP Gateway(API 를 도구로 활용).
이 블로그 글에서는 MCP Gateway 의 설계를 살펴보며, 프록시 계층(MCP 와 기존 프로토콜 간의 양방향 변환), 검색 계층(MCP Registry 및 API 크롤링), 그리고 컨트롤 플레인(작성)을 다룹니다.
게이트웨이
MCP Gateway 는 마이크로서비스 기반 아키텍처를 따르며, 게이트웨이가 AI 지원 시스템과 Uber 백엔드 서비스 사이의 중앙 통합 지점 역할을 합니다. 플랫폼은 컨트롤 플레인으로 작동하는 MCP Registry 와 데이터 플레인을 구성하는 Proxy Gateway 라는 두 가지 주요 컴포넌트로 이루어져 있습니다.
MCP Registry 는 내부 서비스로 지원되는 수백 개의 MCP 서버와 수천 개의 MCP 도구 카탈로그를 관리합니다. 이러한 도구는 기존 API 를 MCP 도구로 노출하는 노코드 정의부터 MCP 사양에 맞춰 명시적으로 구축된 완전한 네이티브 구현까지 다양합니다. 레지스트리는 생태계 전반에서 검색, 소유권, 활성화를 위한 단일 진실 공급원(Single Source of Truth) 을 제공합니다.
Proxy Gateway 는 런타임에서 MCP 요청을 실행하는 역할을 담당합니다. MCP 프로토콜 호출을 HTTP, gRPC 또는 TChannel 요청으로 변환하여 적절한 백엔드 서비스로 전달하고, 응답을 다시 MCP 호환 결과로 변환합니다. 이 변환 계층 덕분에 AI 에이전트는 기본 서비스를 변경하지 않고도 일관된 MCP 인터페이스를 통해 기존 시스템과 상호작용할 수 있습니다.
컨트롤 플레인
Uber 는 마이크로서비스 아키텍처를 사용하며, HTTP, gRPC, TChannel 을 통해 API 를 노출하는 수천 개의 내부 서비스를 운영합니다. 이러한 API 는 AI 시스템에 유용한 컨텍스트를 제공하지만, 각 팀에 MCP 서버를 수동으로 작성하도록 요구하는 것은 느리고 고통스러운 과정입니다. 이 문제를 해결하기 위해 우리는 AutoCrawler 를 구축했습니다. AutoCrawler 는 Uber 의 IDL 레지스트리를 지속적으로 스캔하여 API 를 찾고, 이를 변환한 뒤 레지스트리에 업데이트합니다. 또한 네이티브 MCP 서버를 쿼리하여 레지스트리에 추가합니다.
AutoCrawler: 검색 엔진
Autocrawler 는 Cadence 기반 분산 워크플로 시스템으로, Uber 의 IDL 레지스트리 및 내부 서비스 시그널을 구독합니다. 고정된 일정에 따라 cron 작업이 Cadence 워크플로를 트리거하여 새로 추가된 서비스, API, 스키마 변경 사항을 스캔합니다.
발견된 모든 엔터티에 대해 AutoCrawler 는 다음을 담당합니다.
- MCP 서버 표현 생성 또는 업데이트
- 도구 정의 및 스키마 생성 또는 가져오기
- MCP Registry 에 도구를 기본적으로 비활성화된 상태로 등록
이러한 공유 기반 덕분에 MCP 검색이 수천 개의 서비스로 확장될 수 있으며, 동시에 서비스 팀이 크리티컬 패스에서 제외됩니다.
그림 2: Auto Crawler.
IDL 기반 서비스 검색
Protobuf 또는 Thrift IDL 로 정의된 전통적인 백엔드 서비스의 경우, AutoCrawler 는 IDL Registry 에서 직접 MCP 서버와 도구를 도출합니다. 각 서비스:API 그룹에 대해 AutoCrawler 는 다음 단계를 수행합니다.
- MCP 서버 업서트: 발견된 서비스에 해당하는 가상 MCP 서버를 생성하거나 업데이트합니다.
- IDL 정의 파싱: 연결된 protobuf 또는 Thrift 파일을 파싱하여 메서드 이름, 요청 및 응답 스키마, 문서 주석을 추출합니다.
- 도구 설명 생성: LLM 을 사용하여 추출된 스키마와 주석을 기반으로 에이전트에 친화적인 풍부한 MCP 도구 설명을 생성합니다.
- 스키마 변환: protobuf 또는 Thrift 스키마를 MCP 호환 JSON-RPC 2.0 스키마로 변환합니다.
- MCP 도구 업서트: 생성된 MCP 도구를 MCP Registry 에 기본적으로 비활성화된 상태로 등록하거나 업데이트합니다.
네이티브 서버 검색
IDL 기반 서비스 외에도 MCP Gateway 는 MCP 프로토콜을 직접 구현하고 에이전트에 최적화된 도구를 노출하는 네이티브 MCP 서버도 지원합니다.
MCPFx 는 Uber 가 네이티브 MCP 서버를 구축하는 데 사용하는 프레임워크입니다. 각 네이티브 MCP 서버는 자신의 존재와 준비 상태를 알리는 하트비트 메트릭을 방출합니다. AutoCrawler 는 이러한 하트비트 신호를 지속적으로 모니터링하여 새로운 네이티브 MCP 서버를 자동으로 검색합니다. 네이티브 MCP 서버가 발견되면 AutoCrawler 는 다른 검색 경로를 따릅니다.
- 네이티브 MCP 서버에 listTools 호출을 수행하여 명시적으로 노출된 도구와 해당 스키마를 가져옵니다.
- MCP Registry 에 발견된 모든 도구와 스키마를 포함하는 가상 프록시 MCP 서버를 기본적으로 비활성화된 상태로 생성합니다.
3P MCP 서버
MCP Gateway 는 Uber 전역의 모든 MCP 상호작용을 위한 중앙 오케스트레이션 계층 역할을 하며, Jira 및 Google 과 같은 서드파티 통합에도 매끄러운 지원을 제공합니다.
서드파티 MCP 서버 프로비저닝은 두 가지 핵심 컴포넌트의 협력에 의존합니다.
- MCP Gateway: 권한 부여, 속도 제한, 민감한 데이터 삭제 등 필수 게이트웨이 기능을 적용하면서 호출자의 사용자 토큰을 다운스트림으로 전달합니다.
- 서드파티 MCP 서비스: 외부 MCP 서버로 요청을 발송하기 전에 내부 사용자 토큰을 해당하는 서드파티 인증 토큰으로 교환합니다.
작성 및 활성화
서비스 팀의 참여 없이 MCP 서버를 생성할 수도 있지만, MCP 서버의 소유권과 제어권은 반드시 서비스 팀에 있어야 합니다. MCP Gateway 의 핵심 설계 원칙 중 하나는 '검색되었다고 해서 바로 노출되는 것은 아니다'라는 점입니다. 모든 MCP 서버와 도구는 비활성화된 상태에서 시작하며, 소유 팀이 명시적으로 검토하고 활성화해야 합니다. 서비스 소유자는 활성화하기 전에 생성된 도구 정의를 검토하고 개선할 수 있습니다.
도구 설명이 변경될 때마다 설정 변경 diff 가 트리거되며, 이는 서버 소유자의 승인이 필요합니다. 소유자는 설정 변경을 승인하고 배포할 수 있으며, 필요한 경우 이전 버전으로 롤백할 수도 있습니다.
그림 3: MCP Registry UI.
그림 4: MCP 도구 UI.
데이터 플레인
MCP Gateway 데이터 플레인은 MCP 요청 실행을 담당하는 핵심 런타임 서비스입니다. 컨트롤 플레인에서 서버 및 도구 설정을 지속적으로 소비하고 고정된 주기로 인메모리 상태를 갱신하여, 도구 업데이트나 활성화 변경과 같은 설정 변경 사항이 서비스 재시작이나 재배포 없이 실시간으로 반영되도록 합니다.
이 설정을 바탕으로 데이터 플레인은 가상 MCP 서버를 동적으로 구체화합니다. 각 가상 서버에 대해 게이트웨이는 AI 에이전트 실행의 진입점 역할을 하는 단일 /<service-name>/mcp 엔드포인트를 노출합니다. 수신된 요청은 내장된 프록시 서버를 통해 해당 서버 핸들러로 해석됩니다.
그림 5: MCP Gateway 데이터 플레인.
프로토콜 변환 및 실행
MCP Gateway 의 프로토콜 변환은 Proxy Gateway 내의 서버 핸들러가 처리합니다. 각 서버 핸들러는 도구와 다운스트림을 모두 인식하므로 런타임에서 MCP 요청을 올바르게 라우팅하고 실행할 수 있습니다.
보안
MCP Gateway 는 모든 서버에 대해 도구 수준의 세분화된 권한 부여 및 데이터 삭제 기능을 기본 제공합니다. MCP Gateway 는 Uber 의 내부 Access Control System 을 사용하여 감지된 호출자 액터(사람, 서비스, 에이전트) 에 구성된 다양한 charter 정책을 적용합니다. Charter 정책은 서버 수준에서 생성되며, 필요한 경우 도구 수준 오버라이드를 선택적으로 적용할 수 있습니다.
또한 MCP Gateway 는 도구 응답에서 PII 또는 민감한 데이터를 즉시 삭제하는 기능을 기본 제공합니다.
IDL 기반 다운스트림 서비스
기존 백엔드 서비스로 지원되는 도구의 경우, 서버 핸들러는 HTTP 엔드포인트 설정이나 gRPC/TChannel 프로시저와 같은 다운스트림 대상을 설명하는 인메모리 매핑을 유지합니다.
MCP 요청이 도착하면 핸들러는 다음을 수행합니다.
- 수신된 JSON 페이로드를 적절한 와이어 포맷으로 변환합니다.
- 요청을 Protobuf 또는 Thrift 바이트로 직렬화합니다.
- 요청을 다운스트림 서비스로 전달합니다.
- Protobuf 또는 Thrift 바이트 응답을 다시 MCP 호환 JSON 으로 변환하여 호출 에이전트에 반환합니다.
실제 다운스트림 요청은 모든 백엔드 서비스와 함께 실행되는 Uber 의 서비스 메시 사이드카인 Muttley 를 통해 실행됩니다. 요청 실행을 Muttley 에 위임함으로써 MCP Gateway 는 기존 서비스 간 라우팅 기능을 자동으로 활용할 수 있습니다.
네이티브 MCP 서버
네이티브 MCP 서버 역시 MCP 레지스트리에 가상 서버로 등록되며, 레지스트리가 원본 서버로의 프록시 역할을 합니다. 런타임에서 네이티브 MCP 요청은 투명하게 다운스트림 서버로 프록시되고, 응답은 다시 호출자에게 프록시됩니다.
게이트웨이의 이점
MCP-Gateway 를 구축함으로써 Uber 는 에이전트 시스템을 구축하기 위한 확장 가능하고 통합된 접근 방식을 확보했으며, 가장 큰 영향을 준 이점은 다음과 같습니다.
- 쉬운 검색 및 설치
- 기존 API 에 대한 노코드 접근 방식
- 기본 제공되는 관측 가능성 및 보안
- 중앙 집중식 소유권 및 거버넌스
게이트웨이 확장
MCP Gateway 를 수백 개의 서버와 수천 개의 도구로 확장하는 과정에서 소규모에서는 발생하지 않는 문제들이 드러났습니다. 컨텍스트 비대화와 과도한 비용이 대표적입니다.
런타임 검색
MCP 에는 서버 간 검색이라는 네이티브 개념이 없습니다. 에이전트는 어떤 도구가 사용 가능한지 묻기 전에 이미 어떤 서버와 통신해야 하는지 알고 있어야 합니다. 에이전트가 MCP 서버를 사용하도록 설정하려면 서버 URL, 자격 증명, 도구 목록을 명시적으로 연결해야 합니다. 이를 수백 개의 서버에 적용하는 것은 확장성이 떨어지며, 이 모든 컨텍스트가 모델의 컨텍스트 한도를 소진해 버립니다. 우리는 다음을 통해 이 문제를 해결했습니다.
- Omni MCP - MCP 클라이언트가 점진적 검색 패턴으로 MCP Gateway 의 모든 서버에 접근할 수 있게 해주는 단일 프록시 서버로, 증분 검색을 통한 컨텍스트/토큰 최적화도 가능하게 합니다. Omni MCP 는 다음 도구들을 노출합니다.
- discover_server - 쿼리 의도에 기반하여 MCP 서버 검색
- discover_tools - 서버의 도구 조회
- get_tool_schema - 도구의 json 스키마 가져오기
- invoke_tool - 도구 호출
이러한 도구들은 기본 제공되는 접근 제어 및 기타 게이트웨이 기능과 함께 모든 MCP 서버에 대한 증분 검색 및 접근을 가능하게 합니다.
- Response Projection - MCP Gateway 는 MCP 도구를 위한 GraphQL 스타일의 호출 패턴인 Response Projection 도 제공합니다. 도구 요청 스키마에 새 필드를 삽입하여 게이트웨이가 모든 필드가 아닌 필요한 필드만 요청하도록 지시하는 방식으로 작동합니다. LLM 은 필수 필드만의 중첩 경로 배열을 읽고 주입합니다. 그러면 게이트웨이는 런타임에서 프로젝션된 필드만 유지하여 응답을 축소합니다. 이를 통해 기업 수준에서 MCP 용 API 스키마 호환성을 확장할 수 있었습니다.
- Code Mode - 코딩 에이전트는 종종 셸 환경에서 작동하는데, 이때 도구 출력을 파일에 직접 쓰는 것이 전체 응답을 모델 컨텍스트에 로드하는 것보다 효율적입니다. Code Mode 는 에이전트 작업을 위한 Uber 의 CLI 인 aifx 를 통해 이 패턴을 지원하며, MCP 서버를 설치할 필요 없이 게이트웨이를 통해 MCP 호출을 라우팅합니다. 이는 MCP 정의가 컨텍스트에 없어도 에이전트가 작업에 적합한 MCP 도구를 찾을 수 있도록 돕습니다. aifx 는 세 가지 명령을 노출합니다.
- aifx mcp list - 사용 가능한 MCP 서버 나열
- aifx mcp search - 모든 MCP 서버에서 도구 검색
- aifx mcp call - MCP Gateway 를 통해 MCP 도구 호출
에이전트는 단일 명령으로 이들을 체이닝하고 출력을 파일에 쓸 수 있으며, 파일 시스템 에이전트는 이를 선택적으로 grep 하여 필요한 것만 컨텍스트에 로드합니다. Code Mode 는 이제 코딩 에이전트에서 MCP 도구를 사용하기 위한 전사 기본값이 되었습니다.
결론
MCP Gateway 구축은 Uber 에서 AI 에이전트가 작동하는 방식을 근본적으로 바꾸어 놓았습니다. 수십 개의 팀이 일관되지 않은 도구, 공유된 보안 보장 부재, 중복된 인프라 속에서 개별적으로 MCP 통합을 연결하던 파편화 문제는 이제 어떤 팀이든 몇 분 만에 연동할 수 있는 통합되고 확장 가능한 플랫폼으로 탈바꿈했습니다.
우리의 설계를 이끈 핵심 통찰은 단순했습니다. 기존 API 가 에이전트에게 도구를 제공하는 가장 빠른 방법이라는 것입니다. 팀에게 에이전트 중심 세계를 위해 서비스를 다시 작성하라고 요구하는 대신, MCP Gateway 는 그들이 있는 그대로의 상태에서 만납니다. 즉, HTTP, gRPC, TChannel 호출을 Muttley 를 통해 다운스트림 서비스 변경 없이 투명하게 MCP 호환 상호작용으로 변환합니다.
대규모 에이전트 시스템을 구축하고 있다면, 가장 어려운 부분은 AI 자체가 아닙니다. 진정한 사용자가 있는 프로덕션 환경에서 에이전트가 신뢰받고 행동할 수 있도록 만드는 연결 조직, 즉 검색, 보안, 신뢰성을 구축하는 일이 가장 어렵습니다. MCP Gateway 는 그 과제에 대한 우리의 답변이며, 여기에 기록된 설계 결정이 같은 문제를 마주한 다른 분들께 도움이 되기를 바랍니다.
감사의 말
커버 사진 출처: OpenAI 의 ChatGPT 로 생성됨; 외부 이미지, 로고 또는 서드파티 자산은 사용되지 않았습니다.
gRPC 는 The Linux Foundation 의 상표입니다.
Uber Engineering 의 최신 소식을 계속 확인하려면 LinkedIn 에서 팔로우하여 최신 블로그 게시물과 인사이트를 받아보세요.
