MCP Gateway - 기존 API를 MCP 도구로 통합하는 Uber의 플랫폼 설계
요약
Uber는 MCP Gateway라는 통합 플랫폼을 구축하여, 기존의 다양한 API와 네이티브 서버에 분산된 수많은 도구들을 일관된 방식으로 에이전트에게 제공합니다. 이 게이트웨이는 프로토콜 차이를 추상화하고 중앙에서 접근 제어 및 배포를 관리하며, AutoCrawler를 통해 서비스 변경을 자동으로 탐지하여 운영 복잡성을 크게 줄였습니다.
핵심 포인트
- MCP Gateway는 기존 API와 네이티브 서버의 도구를 통합하는 공통 오케스트레이션 계층입니다.
- Proxy Gateway가 데이터 평면 역할을 하며, 다양한 프로토콜(HTTP, gRPC 등)을 MCP 호환 인터페이스로 변환합니다.
- AutoCrawler는 IDL 레지스트리 및 내부 신호를 구독하여 서비스와 도구를 자동으로 발견하고 등록합니다.
- 도구 단위 접근 제어와 중앙 집중식 배포 관리를 통해 보안과 운영 안정성을 확보했습니다.
- Uber는 분산된 MCP 연동을
MCP Gateway로 통합해 기존 API와 네이티브 MCP 서버를 일관된 방식으로 제공하며, 현재 800개 이상의 서버와 5,000개 이상의 도구를 운영함
MCP Registry가 검색, 소유권, 활성화 설정을 관리하고, Proxy Gateway가 MCP 요청을 HTTP, gRPC, TChannel 호출로 변환해 기존 백엔드 수정 없이 실행
AutoCrawler가 API 정의와 네이티브 서버에서 도구를 자동 발견하고, 소유 팀의 검토와 활성화 후 공개 - 게이트웨이는
도구 단위 접근 제어와 응답의 개인정보 및 민감정보 제거를 공통 적용하고, 도구 변경 승인과 배포, 롤백을 중앙에서 관리함 - Omni MCP의 단계적 도구 탐색, 필요한 응답 필드만 남기는 Response Projection, 결과를 파일로 처리하는 Code Mode로 컨텍스트 사용량과 비용을 줄임
개별 MCP 연동에서 공통 플랫폼으로
- 초기
MCP(Model Context Protocol) 연동은 에이전트가 실시간 비즈니스 맥락에 접근하고 내부 서비스를 조회하며 사용자를 대신해 작업하도록 해 효용을 입증함 - 수백 개 팀이 에이전트 워크플로를 탐색하면서
도구 파편화와 인프라 중복이 발생함 - 도구를 발견하기 어렵고 안정적으로 운영하기 힘들었으며, 특정 서비스나 에이전트 구현에 강하게 결합돼 있었음
- 통합 아키텍처 없이 확장하면 운영 복잡성, 보안 위험, 개발 마찰이 커지는 문제가 있었음
MCP Gateway는 에이전트와 기존 백엔드 및 네이티브 MCP 서버 사이의 공통 오케스트레이션 및 라우팅 계층임
- HTTP, gRPC, TChannel의 프로토콜 차이를 추상화하고 일관된 보안과 관측 가능성을 제공함
- 기존 API를 MCP 도구로 노출하고 여러 에이전트가 같은 방식으로 재사용하도록 하며, 현재 800개 이상의 서버와 5,000개 이상의 도구를 호스팅함
MCP Registry와 Proxy Gateway의 역할 분리
MCP Registry는 제어 평면으로서 서버와 도구의 카탈로그를 유지하고, 검색, 소유권, 활성화 상태의 단일 기준점 역할을 함
- 기존 API를 노코드로 노출한 도구부터 MCP 명세에 맞춰 직접 구현한 네이티브 도구까지 관리함
Proxy Gateway는 데이터 평면으로서 런타임 MCP 요청을 실행함
- 요청을 HTTP, gRPC, TChannel로 변환해 적절한 백엔드에 전달하고, 응답을 MCP 호환 결과로 바꿈
- 기반 서비스를 변경하지 않고도 에이전트에 일관된 MCP 인터페이스를 제공함
AutoCrawler를 통한 서버와 도구 자동 발견
AutoCrawler는 Cadence 기반 분산 워크플로 시스템으로, Uber의 IDL 레지스트리와 내부 서비스 신호를 구독함
- 정기 cron 작업이 워크플로를 실행해 신규 서비스, API, 스키마 변경을 검색함
- MCP 서버 표현을 생성하거나 갱신하고, 도구 정의와 스키마를 생성하거나 가져와
기본 비활성 상태로 등록함 - 서비스 팀의 직접 작업에 의존하지 않고 수천 개 서비스로 탐색을 확장함
IDL 기반 서비스는 Protobuf 또는 Thrift 정의에서 서버와 도구를 도출함
- 서비스/API 그룹마다 가상 MCP 서버를 생성하거나 갱신함
- IDL에서 메서드 이름, 요청 및 응답 스키마, 문서화 주석을 추출함
- LLM이 추출된 스키마와 주석을 바탕으로 에이전트 친화적인 도구 설명을 생성함
- 스키마를 MCP 호환 JSON-RPC 2.0 스키마로 변환하고 도구를 등록하거나 갱신함
네이티브 MCP 서버는 Uber의 서버 개발 프레임워크인 MCPFx를 사용하며, 존재 여부와 준비 상태를 알리는 하트비트 지표를 내보냄
- AutoCrawler가 하트비트를 지속적으로 감시해 새 서버를 발견함
- 서버의
listTools
를 호출해 공개한 도구와 스키마를 가져옴
- 발견한 도구를 포함하는 가상 프록시 MCP 서버를 레지스트리에 비활성 상태로 생성함
서드파티 연동과 소유 팀의 승인
서드파티 MCP 서버도 중앙 게이트웨이를 통해 연결하며, Jira와 Google 등의 연동을 지원함
- MCP Gateway는 호출자의 사용자 토큰을 하위 서비스에 전달하면서 인가, 요청 속도 제한, 민감정보 제거를 적용함
- Third-Party MCP Service는 내부 사용자 토큰을 해당 외부 서비스의 인증 토큰으로 교환한 뒤 외부 MCP 서버에 요청함
발견이 곧 노출을 뜻하지 않음을 기본 원칙으로 삼으며, 자동 생성한 서버도 서비스 팀이 소유하고 통제함
- 모든 서버와 도구는 소유 팀이 생성된 정의를 검토하고 필요에 따라 수정한 뒤 명시적으로 활성화해야 함
- 도구 설명을 변경할 때마다 설정 변경 차이가 생성되며
서버 소유자의 승인이 필요함 - 소유자는 변경을 승인하고 배포하거나, 필요하면 이전의 검증된 버전으로 롤백할 수 있음
런타임 구성과 프로토콜 변환
- 데이터 평면은 제어 평면의 서버 및 도구 설정을 지속적으로 받아
메모리 내 상태를 주기적으로 갱신함 - 도구 수정과 활성화 변경을 서비스 재시작이나 재배포 없이 반영함
- 설정에 따라 가상 MCP 서버를 동적으로 구성하고, 서버마다
/<service-name>/mcp
엔드포인트를 노출함
- 내장 프록시 서버가 요청에 맞는 서버 핸들러를 선택함
서버 핸들러는 도구와 하위 서비스 정보를 바탕으로 라우팅과 실행을 담당함
-
IDL 기반 도구에서는 HTTP 엔드포인트 설정이나 gRPC/TChannel 프로시저 등 목적지 매핑을 메모리에 유지함
-
입력 JSON을 적절한 전송 형식으로 변환하고 Protobuf 또는 Thrift 바이트로 직렬화한 뒤 하위 서비스에 전달함
-
응답 바이트를 MCP 호환 JSON으로 변환해 호출 에이전트에 반환함
-
실제 하위 서비스 요청은 모든 백엔드 서비스와 함께 실행되는 서비스 메시 사이드카
Muttley를 통함
네이티브 MCP 서버도 레지스트리에 가상 서버로 등록하며, 런타임에는 원래 서버로 요청을 투명하게 프록시하고 응답을 호출자에게 돌려줌
공통 보안과 운영 효과
-
게이트웨이는 모든 서버에
도구 단위 인가와 민감정보 제거를 내장함 -
Uber의 Access Control System을 사용해 사람, 서비스, 에이전트 등 감지한 호출 주체에 맞는 charter 정책을 적용함
-
정책은 서버 수준에서 생성하며, 필요하면 도구별로 재정의할 수 있음
-
도구 응답에서 개인정보와 민감정보를 기본적으로 제거함
-
플랫폼 통합으로
쉬운 발견과 설치, 기존 API의 노코드 도구화, 내장 관측 가능성과 보안, 중앙화된 소유권 및 거버넌스를 확보함
Omni MCP의 단계적 런타임 탐색
- MCP에는
서버 간 검색 기능이 기본 제공되지 않아, 에이전트가 도구 목록을 요청하려면 먼저 어느 서버에 연결할지 알아야 함 - 서버 URL, 자격 증명, 도구 목록을 명시적으로 연결해야 하므로 수백 개 서버를 미리 구성하면 모델 컨텍스트 한도를 소모함
Omni MCP는 단일 프록시 서버를 통해 게이트웨이의 모든 서버에 단계적으로 접근하도록 함
discover_server
: 질의 의도에 맞는 MCP 서버를 탐색함
discover_tools
: 특정 서버의 도구를 조회함
get_tool_schema
: 도구의 JSON 스키마를 가져옴
invoke_tool
: 도구를 호출함
- 필요한 정보를 점진적으로 발견해
컨텍스트와 토큰 사용을 최적화하면서 접근 제어를 비롯한 게이트웨이 기능을 그대로 사용함
Response Projection과 Code Mode
Response Projection은 GraphQL과 유사하게 필요한 응답 필드만 선택하는 호출 방식임
- 도구 요청 스키마에 새 필드를 추가하고, LLM이 필요한 필드의 중첩 경로 배열을 작성함
- 게이트웨이는 런타임에 지정된 필드만 남기도록 응답을 잘라냄
- 이 방식으로 기업 규모에서 API 스키마의 MCP 호환성을 확장함
Code Mode는 셸 환경의 코딩 에이전트가 전체 응답을 모델 컨텍스트에 넣는 대신 도구 출력을 파일에 직접 쓰는 패턴을 지원함
- Uber의 에이전트 작업용 CLI인
aifx를 통해 MCP 서버 설치 없이 게이트웨이로 호출을 전달함 - 컨텍스트에 MCP 정의가 없어도 작업에 맞는 도구를 발견하도록 지원함
aifx mcp list
: 사용 가능한 MCP 서버를 나열함
aifx mcp search
: 모든 MCP 서버에서 도구를 검색함
aifx mcp call
: 게이트웨이를 통해 MCP 도구를 호출함
- 에이전트는 명령을 연결해 실행하고 출력을 파일에 저장한 뒤,
grep
으로 필요한 부분만 골라 컨텍스트에 적재할 수 있음
Code Mode는 현재 Uber 코딩 에이전트의 기본 MCP 도구 사용 방식임
기존 API를 활용하는 확장 전략
기존 API가 에이전트에 도구를 제공하는 가장 빠른 경로라는 설계 원칙에 따라, 서비스 재작성 대신 게이트웨이의 프로토콜 변환을 선택함
-
Muttley를 통해 기존 HTTP, gRPC, TChannel 서비스를 연결하므로 하위 서비스 변경이 필요 없음
-
개별 팀의 중복 연동에서 벗어나 어느 팀이든 수분 내 연결할 수 있는 통합 플랫폼을 구축함
-
대규모 에이전트 시스템의 어려움은 AI 자체보다
발견, 보안, 신뢰성을 뒷받침하는 연결 기반을 구축하는 데 있음 -
프로덕션에서 실제 사용자를 대신해 행동할 만큼 신뢰할 수 있는 에이전트를 만들기 위해 MCP Gateway를 공통 기반으로 사용함
댓글과 토론
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기