사내 API와 도구가 늘어날수록 AI 에이전트가 쓸 수 있는 기능을 찾고, 권한을 확인하고, 응답을 다루는 일도 복잡해집니다. Uber는 이 문제를 MCP 서버 몇 개를 연결하는 방식으로 풀지 않고, 800개가 넘는 서버와 5,000개가 넘는 도구를 한곳에서 관리하는 MCP Gateway로 다룹니다.
Uber Engineering의 MCP Gateway 설계 원문을 바탕으로, 등록과 실행을 어떻게 나누고 도구 노출을 통제하는지 살펴보겠습니다.
등록과 실행을 나눈 MCP Gateway
Uber의 구조는 두 부분으로 나뉩니다. MCP Registry는 control plane으로 서버와 도구를 발견하고 소유권 및 활성화 상태를 관리합니다. Proxy Gateway는 data plane으로 에이전트의 MCP 요청을 받아 실제 백엔드 서비스에 전달합니다. 등록 정보를 관리하는 일과 요청을 실행하는 일을 분리한 설계입니다.
이 구분은 규모가 커질수록 의미가 있습니다. 도구 목록을 찾고 승인 상태를 바꾸는 관리 경로와, 실제 서비스 호출이 오가는 실행 경로를 서로 다른 책임으로 운영할 수 있기 때문입니다.
AutoCrawler가 발견해도 바로 공개하지 않습니다
Registry의 AutoCrawler는 Cadence 기반 분산 워크플로로 기존 서비스 신호와 IDL Registry를 주기적으로 확인합니다. Protobuf와 Thrift 정의에서 서버와 도구 스키마를 만들고 MCP 호환 JSON-RPC 2.0 형식으로 변환합니다. Native MCP 서버는 heartbeat를 통해 발견하고 listTools를 호출해 도구 정보를 가져옵니다.
자동 발견은 자동 공개와 다릅니다. 새로 등록된 서버와 도구는 기본적으로 비활성화되어 있으며, 해당 소유 팀이 검토하고 승인한 뒤에 활성화됩니다. 변경 사항도 diff 검토와 배포, 롤백 절차를 거칩니다. 도구를 찾았다는 사실만으로 에이전트에 노출하지 않는 통제 단계가 Registry 안에 들어 있습니다.
기존 서비스 API를 에이전트 호출에 연결
Proxy Gateway는 MCP 요청을 기존 서비스가 사용하는 HTTP, gRPC, TChannel 등의 프로토콜에 맞춰 변환하고, 응답을 다시 MCP 형식으로 돌려줍니다. 기존 호출 경로에서는 Muttley 서비스 메시 사이드카를 사용합니다. 서비스 팀이 모든 API를 새 MCP 서버로 다시 구현하지 않아도, 게이트웨이가 프로토콜 사이를 연결하는 방식입니다.
이때 호출 주체가 누구인지 식별해 서버 단위 권한 정책을 적용하고, 필요하면 도구별 정책도 설정합니다. 요청 제한(rate limiting)과 응답의 PII 및 민감정보 redaction도 게이트웨이 책임에 포함됩니다. 도구 연결뿐 아니라 누가 호출할 수 있는지와 어떤 데이터가 돌아오는지도 함께 관리합니다.
Omni MCP는 필요한 도구 정보부터 찾아갑니다
도구가 수천 개라면 모든 설명과 스키마를 매 요청의 컨텍스트에 넣기 어렵습니다. Omni MCP는 검색과 호출을 네 단계로 나눕니다.
discover_server: 사용할 서버를 찾습니다.discover_tools: 해당 서버에서 관련 도구를 찾습니다.get_tool_schema: 선택한 도구의 상세 입력 스키마를 가져옵니다.invoke_tool: 필요한 도구를 실행합니다.
에이전트는 필요한 단계에서 필요한 정보만 가져오므로, 처음부터 전체 도구 카탈로그를 읽고 보관할 필요가 없습니다. 대규모 도구 집합에서 검색 범위를 점차 좁히는 방식입니다.
응답도 필요한 필드만 남깁니다
도구 실행 결과가 크면 에이전트가 실제로 사용할 정보보다 많은 데이터가 컨텍스트에 들어갈 수 있습니다. Response Projection은 요청 스키마에 중첩 경로 배열을 지정해 응답에서 필요한 필드만 남기는 기능입니다. Uber는 이를 GraphQL과 유사한 호출 방식으로 설명합니다.
검색 단계에서 도구 정보를 줄이고, 실행 뒤에는 결과 필드를 좁히는 셈입니다. 도구 카탈로그와 응답 양쪽에서 불필요한 컨텍스트를 줄일 수 있습니다.
aifx Code Mode로 검색하고 호출하기
Uber의 코딩 에이전트는 aifx CLI에서 MCP Gateway를 이용합니다. 원문에 소개된 명령은 aifx mcp list, aifx mcp search, aifx mcp call입니다. 에이전트마다 MCP 서버를 따로 설치하거나 수많은 도구 정의를 미리 컨텍스트에 불러오지 않고, 게이트웨이에서 필요한 도구를 찾아 호출합니다. 결과는 파일로 저장해 필요한 부분을 읽을 수 있습니다.
여기서 Code Mode는 단순히 도구 이름을 바꾸는 기능이 아닙니다. 내부 도구의 발견과 실행을 하나의 경로로 제공하고, 에이전트가 전체 도구 명세를 상시 보유하지 않도록 하는 사용 방식입니다.
대규모 MCP 운영에서 얻을 수 있는 설계 포인트
Uber 사례의 핵심은 MCP 연결 수를 늘리는 데만 있지 않습니다. Registry와 Proxy를 분리해 관리와 실행의 경계를 두고, 자동 발견 뒤에는 소유 팀 승인을 거치며, 실행 시 권한과 민감정보 처리를 적용합니다. Omni MCP와 Response Projection은 도구 설명과 응답을 필요한 만큼만 다루게 합니다.
따라서 MCP 도입을 검토하는 팀이라면 연결할 서버 목록뿐 아니라 발견 이후의 승인, 호출 주체별 정책, 기존 서비스와의 프로토콜 변환, 응답 데이터의 범위까지 함께 설계할 필요가 있습니다. Uber는 이 요소들을 MCP Gateway라는 공통 운영 경로에 모았습니다.
MCP가 처음이라면 MCP 용어 설명부터 확인할 수 있습니다. 개별 코딩 에이전트의 MCP 도구 호출 방식은 Pi의 MCP·Codemode 사례와 비교해 볼 수 있고, 호스팅 관점은 ChatGPT Sites의 MCP 서버 호스팅 글에서 이어집니다.
