사내 에이전트에 주문 조회, 로그 검색, 실험 분석을 붙이다 보면 팀마다 연동을 따로 만든다. 도구가 늘면 같은 인증과 연결 코드를 반복해서 관리해야 하고, 에이전트에게 어떤 기능을 알려 줄지도 복잡해진다. 우버가 2026년 10월 1일 공개한 MCP Gateway는 에이전트와 사내 서비스를 연결하는 공통 창구다. 기존 사내 API를 재사용해 팀마다 연동을 따로 만드는 일을 줄였다. 공개 시점에 이 플랫폼은 MCP 서버 800개 초과, 도구 5,000개 초과를 관리하고 있었다.
우버는 API를 자동으로 찾아 목록에 올리되 소유 팀이 승인하기 전에는 켜지 않는다. 에이전트는 업무에 맞는 서버와 도구를 찾은 뒤 필요한 정의만 읽는다. PM과 창업자는 기존 API를 연결하는 작업과 실제 사용을 허용하는 결정을 따로 관리하는 방식에 주목할 만하다.
기존 API를 다시 만들지 않고 연결하려면
MCP(Model Context Protocol)는 에이전트가 외부 데이터와 기능을 도구로 호출하도록 연결하는 규약이다. 우버에는 이미 HTTP, gRPC, TChannel 방식으로 통신하는 내부 서비스가 많았다. 각 팀이 이 서비스를 에이전트용으로 새로 만드는 대신, 게이트웨이가 호출 형식을 변환하고 기존 서비스에 요청을 전달한다. 기존 서비스 코드를 바꾸지 않고 같은 API를 여러 에이전트가 사용할 수 있게 한 것이다.
도구 목록을 관리하는 레지스트리와 요청을 실제로 실행하는 게이트웨이도 분리했다. 자동 탐색기 AutoCrawler는 API 정의와 주석을 읽어 도구의 입력·출력 형식을 옮기고, 언어 모델로 설명을 보강한다. 처음부터 MCP로 만든 서버도 목록에 등록할 수 있다. 아래 레지스트리 화면은 서버별 도구 수, 이용 에이전트 수, 서비스 등급을 한곳에 모아 보여 준다.
이 방식을 검토할 때는 이미 운영 중인 API 중 어느 업무를 먼저 연결할지 정해야 한다. API 명세가 정리돼 있는지, 서비스 소유자가 누구인지도 도입 범위에 영향을 준다. 자동 수집기를 만든다고 업무에 맞는 도구 설명과 승인 책임까지 저절로 생기지는 않는다.
목록에 올라왔다는 이유로 실행 권한을 주지 않는다
우버는 발견한 서버와 도구를 기본 비활성(disabled-by-default) 상태로 등록한다. 소유 팀이 생성된 설명을 검토하고 수정한 뒤 명시적으로 활성화해야 한다. 도구 설명을 바꿀 때마다 설정 변경 내역이 생기며, 서버 소유자가 이를 승인하고 배포한다. 필요하면 이전 설정으로 되돌릴 수 있다.
도구 편집 화면에는 서버 선택, 도구 목록, 요청·응답 설정이 함께 있다. 공개 화면의 Enabled·Disabled 탭은 도구 상태를 구분한다. 별도로 표시된 Authorization Disabled는 권한 제어 상태를 가리킨다.
실행 단계에서는 사람·서비스·에이전트 등 호출 주체에 맞는 접근 정책을 적용하고, 응답의 개인정보와 민감 데이터를 가린다. 소유자의 활성화 승인은 어떤 도구를 제공할지 결정하는 절차이고, 호출자의 권한 검사는 누가 그 도구를 사용할지 판단하는 절차다. 사내 도구를 도입하는 팀도 이 두 결정을 구분해야 한다. 특히 조회 기능을 붙인 뒤 수정·삭제 기능으로 넓힐 때는 같은 승인 범위를 그대로 쓰기 어렵다. DoorDash의 게이트웨이 사례는 호출자 인증과 권한 철회까지 포함한 운영 경계를 설명한다.
5천 개 설명 대신 필요한 도구를 찾게 한다
서버마다 주소와 인증 정보, 도구 목록을 미리 연결하면 설정이 늘어난다. 모든 설명을 모델이 읽는 입력 공간에 넣는 방식도 한계가 있다. 우버의 Omni MCP는 하나의 프록시 서버를 통해 업무 의도에 맞는 서버를 찾고(discover_server), 그 서버의 도구를 조회한 다음(discover_tools), 고른 도구의 입력 형식을 읽고(get_tool_schema) 실행한다(invoke_tool).
Response Projection은 호출할 때 필요한 응답 필드의 경로를 지정하게 한다. 게이트웨이는 돌아온 응답에서 지정한 필드만 남긴다. 작동 방식을 주문 조회에 빗대면, 주문 상태만 필요한 업무에 긴 주문 객체 전체 대신 상태 필드를 전달하는 식이다. 응답 필드를 줄이는 기능은 호출 권한을 대신하지 않는다.
코딩 에이전트에는 코드 모드도 쓴다. 우버의 명령줄 도구 aifx로 서버를 나열하고, 도구를 검색하고, 게이트웨이를 거쳐 호출한다. 결과를 파일에 기록하면 에이전트가 필요한 부분만 검색해서 읽을 수 있다. 우버가 회사 기본 방식으로 채택했다고 밝힌 범위는 코딩 에이전트의 MCP 도구 사용이다.
도입 계획에는 연결 수보다 승인과 입력량을 적는다
사내 에이전트를 처음 붙이는 조직이라면 우버 규모의 플랫폼 전체를 만들 필요는 없다. 기존 API를 재사용할 수 있는 업무 하나를 고르고, 그 도구의 소유자와 활성화 조건부터 정하는 편이 실용적이다. 도구가 늘어날 때 목록 전체를 미리 읽힐지, 검색해서 필요한 정의만 읽힐지 선택하면 된다. 결과가 긴 업무는 반환 필드를 제한하거나 파일에 저장한 뒤 필요한 부분을 읽게 하는 경로도 검토할 수 있다.
도입 시험에서는 연동에 걸린 시간과 승인 대기 시간을 구분해 기록할 만하다. 입력에 들어간 도구 설명과 응답의 양, 잘못 고른 도구를 다시 검색한 횟수도 함께 보면 어디에 비용이 쌓이는지 알 수 있다. 우버 원문은 비용 절감률을 제시하지 않는다. 도구를 단계적으로 찾는 방식이 우리 업무에서도 이득인지 판단하려면, 같은 업무를 기존 방식과 새 방식으로 실행한 기록이 필요하다.
출처: Uber Engineering, Designing MCP Gateway: Uber's MCP Management Platform