한눈에 보기
- 무엇: 우버가 사내 AI 에이전트와 수천 개 사내 서비스를 잇는 ‘MCP 게이트웨이’의 설계를 공개했어요. 에이전트의 모든 MCP 요청이 이 한 곳을 거쳐요.
- 누가: 우버 엔지니어링 팀(알록 스리바스타바, 디판슈 멘디라타, 가우라브 길 등)이 회사 기술 블로그에 썼어요.
- 언제: 2026년 10월 1일(미국 시간) 게시됐어요.
- 얼마: 게이트웨이에는 MCP 서버 800개 이상, 도구 5,000개 이상이 올라가 있어요. 우버 내부 시스템이라 판매하는 제품은 아니고, 비용은 공개되지 않았어요.
- 어디서: 우버 사내에서만 쓰는 인프라예요. 한국 이용자가 직접 쓸 수는 없고, 설계 방식이 참고 대상이에요.
결론부터 말하면, 우버는 “AI 에이전트에게 도구를 주는 가장 빠른 길은 이미 있는 사내 API”라고 보고, 그 API들을 한 관문에서 MCP 도구로 바꿔 주는 게이트웨이를 만들었어요. 핵심은 기술보다 관리예요. 자동으로 찾은 도구도 처음엔 꺼 둔 채 등록하고, 서비스 담당 팀이 검토해야 켜져요.
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구·데이터에 접속하는 방법을 정해 둔 공통 규격이에요. USB 단자처럼 모양을 맞춰 두면 어떤 에이전트든 같은 방식으로 도구를 꽂아 쓸 수 있다고 생각하면 쉬워요. AI 에이전트는 목표를 받으면 스스로 도구를 골라 쓰며 일을 처리하는 AI 프로그램이에요.
우버는 왜 게이트웨이를 만들었나요?
우버 글에 따르면 처음에는 팀마다 따로 MCP 연결을 만들었어요. 그러다 보니 도구가 흩어져 찾기 어렵고, 같은 기반 시설을 여러 팀이 중복으로 만들고, 보안 기준도 제각각이었다고 해요(공식, 우버 엔지니어링 블로그).
수백 개 팀이 에이전트를 시험하기 시작하면서 이 방식으로는 운영이 복잡해지고 보안 위험이 커진다고 판단했어요. 그래서 모든 MCP 요청을 한곳에서 처리하는 마이크로서비스, 즉 MCP 게이트웨이를 만들었다고 설명해요(공식, 같은 글). 게이트웨이는 여러 시스템 사이에서 요청을 받아 알맞은 곳으로 넘겨 주는 관문 서버예요.
숫자로 보면 어느 정도 규모인가요?
| 항목 | 우버가 밝힌 내용 | 근거 |
|---|---|---|
| 운영 중인 MCP 서버 | 800개 이상(“over 800 MCP servers”) | 공식, 우버 글 도입부 |
| 운영 중인 MCP 도구 | 5,000개 이상(“over 5000 tools”) | 공식, 우버 글 도입부 |
| 연결 대상 사내 서비스 | 수천 개(“thousands of internal services”), HTTP·gRPC·TChannel 방식 | 공식, 제어 영역 절 |
| 새 도구 등록 방식 | 자동 수집 후 꺼진 상태로 등록, 담당 팀 승인 뒤 사용 | 공식, 작성·활성화 절 |
| 코딩 에이전트 기본 방식 | ‘코드 모드'(aifx 명령줄 도구)가 회사 기본값 | 공식, 확장 절 |
800개와 5,000개라는 숫자는 우버 글 원문에서 그대로 확인했어요. 이 숫자에는 사내 API를 자동으로 바꾼 ‘가상’ 서버와 처음부터 MCP로 만든 서버가 함께 들어 있고, 그중 실제로 켜져 쓰이는 비율은 공개되지 않았어요.
게이트웨이는 어떻게 움직이나요?
게이트웨이는 크게 두 부분이에요. 레지스트리(제어 영역)는 어떤 서버와 도구가 있는지, 누가 주인인지, 켜져 있는지를 기록하는 목록이에요. 프록시(데이터 영역)는 실제 요청이 올 때 MCP 형식을 사내 서비스가 알아듣는 형식으로 바꿔 전달하고, 답을 다시 MCP 형식으로 돌려줘요(공식, 우버 글).
목록을 채우는 건 ‘AutoCrawler’라는 자동 수집기예요. 사내 API 정의 저장소를 정해진 주기로 훑어 새 서비스와 바뀐 API를 찾고, LLM으로 에이전트가 이해하기 쉬운 도구 설명을 만들어 레지스트리에 올려요. 이때 모든 도구는 꺼진 상태로 등록돼요(공식, 우버 글). API는 프로그램끼리 기능을 주고받는 약속된 창구예요.
우버는 이를 “발견했다고 노출하는 건 아니다(discovery doesn’t imply exposure)”라는 원칙으로 설명해요. 서비스 담당 팀이 자동 생성된 설명을 검토·수정한 뒤 켜야 하고, 설명을 바꿀 때마다 변경 내역을 승인받으며, 필요하면 이전 버전으로 되돌릴 수 있어요(공식, 우버 글).
보안은 게이트웨이에 모아 뒀어요. 도구 하나 단위로 권한을 검사하고, 호출한 쪽이 사람인지 서비스인지 에이전트인지에 따라 다른 정책을 적용해요. 도구가 돌려주는 답에서 개인정보 같은 민감한 정보는 자동으로 가린다고 밝혔어요(공식, 우버 글). 지라·구글 같은 외부 MCP는 사용자 토큰을 바꿔 끼운 뒤 호출해요.
도구가 수천 개면 에이전트가 헷갈리지 않나요?
우버도 같은 문제를 겪었어요. MCP에는 여러 서버를 가로질러 검색하는 기능이 없어서, 서버 수백 개를 다 연결하면 그 설명만으로 모델의 문맥 한도를 다 써 버린다고 적었어요(공식, 우버 글). 문맥 한도는 AI가 한 번에 읽고 기억할 수 있는 글자 양의 한계예요.
해결책은 세 가지예요. ‘Omni MCP’는 서버 찾기 → 도구 찾기 → 도구 설명 받기 → 실행하기 순서로 필요한 것만 조금씩 꺼내 보게 해요. ‘응답 골라 받기(Response Projection)’는 필요한 항목만 지정해 받게 해 답을 줄여요. ‘코드 모드’는 코딩 에이전트가 aifx 명령줄로 도구를 부르고 결과를 파일로 저장해, 필요한 부분만 읽게 해요(공식, 우버 글).
한국 이용자와 기업에는 어떤 의미가 있나요?
우버 시스템을 그대로 가져다 쓸 수는 없어요. 다만 사내에 API가 많은 국내 기업이 AI 에이전트를 붙이려 할 때 참고할 점이 분명해요. 서비스를 새로 짜지 않고 기존 API를 도구로 바꾸되, 켜기·권한·개인정보 가림을 한곳에서 관리하는 방식이에요(추정).
특히 “자동으로 찾되 기본은 꺼 둔다”는 원칙은 회사 규모와 상관없이 쓸 수 있어요. 개인정보 보호 규정이 엄격한 국내 금융·통신 기업이라면 응답 속 민감 정보 가림을 관문에서 일괄 처리하는 구조가 특히 참고가 될 거예요(추정). 에이전트에게 권한을 어디까지 줄지에 대한 기본 원칙은 AI 에이전트 권한 제한 기사에서 볼 수 있어요.
대단한 점과 아쉬운 점
| 대단한 점 | 아쉬운 점·모르는 점 |
|---|---|
| 서버 800개 이상·도구 5,000개 이상을 한 관문에서 운영한다는 실제 규모를 밝혔어요(공식, 우버 글). | 이 중 실제로 켜져 쓰이는 도구 비율, 하루 호출량, 오류율 같은 운영 지표는 없어요(공식 글에 없음). |
| 사내 서비스를 고치지 않고 기존 API를 도구로 바꿔, 팀들이 MCP 서버를 따로 만들 필요를 줄였어요(공식). | LLM이 만든 도구 설명이 얼마나 정확한지, 담당 팀 검토에서 얼마나 고쳐지는지는 공개되지 않았어요. |
| 자동 등록 도구를 꺼 둔 채 시작하고, 변경마다 승인·되돌리기를 둔 관리 구조가 구체적이에요(공식). | 회사가 스스로 쓴 사례 글이라 외부 검증 자료는 없어요. 장점 위주로 쓰였다는 점을 감안해야 해요(추정). |
| 도구가 많아질 때 생기는 문맥 낭비 문제를 점진 탐색·응답 골라 받기·코드 모드로 푼 방법을 공개했어요(공식). | 게이트웨이 코드는 공개되지 않았어요. 다른 회사가 쓰려면 설계만 참고해 직접 만들어야 해요. |
확장성: 이걸로 무엇을 해 볼 수 있나요?
규모가 작은 팀이라도 우버 방식의 일부는 바로 따라 할 수 있어요. 에이전트가 쓰는 도구 목록을 한 문서나 저장소에 모으고, 새 도구는 기본으로 꺼 둔 뒤 담당자가 켜게 하고, 도구 응답에서 개인정보를 가리는 단계를 한곳에 두는 거예요(추정).
운영체제 차원에서 에이전트가 쓸 수 있는 파일·네트워크를 제한하는 다른 접근은 윈도 MXC 정식 출시 기사에서 볼 수 있어요. 관문에서 막는 우버 방식과 기기에서 막는 방식은 서로 보완 관계예요(추정).
아직 모르는 것
- 5,000개 이상의 도구 가운데 실제로 켜진 도구가 몇 개인지 공개되지 않았어요.
- 게이트웨이를 거치면서 응답이 얼마나 느려지는지(지연 시간) 수치가 없어요.
- 자동 개인정보 가림이 어떤 기준으로 작동하고, 얼마나 놓치는지는 설명되지 않았어요.
- 우버가 이 게이트웨이를 외부에 공개하거나 오픈소스로 낼 계획이 있는지는 글에 없어요.
자주 묻는 질문
MCP란 무엇인가?
AI 에이전트가 외부 도구와 데이터에 접속하는 방식을 정해 둔 공통 규격이에요. 규격을 맞춰 두면 서로 다른 에이전트도 같은 도구를 같은 방법으로 쓸 수 있어요. 우버는 이 규격에 맞춰 사내 API를 도구로 바꿔 주는 관문을 만든 거예요.
MCP 서버란?
AI 에이전트에게 도구 목록을 알려 주고, 요청이 오면 그 도구를 실행해 결과를 돌려주는 프로그램이에요. 우버 게이트웨이에는 사내 API를 자동 변환한 ‘가상’ MCP 서버와, 처음부터 MCP로 만든 ‘네이티브’ MCP 서버가 함께 등록돼 있어요.
MCP 보안 취약점은 어떻게 막나요?
우버의 답은 ‘한곳에서 막기’예요. 모든 요청이 게이트웨이를 거치게 해 도구 단위 권한 검사와 응답 속 개인정보 가림을 일괄 적용하고, 자동으로 찾은 도구는 담당 팀이 검토하기 전까지 꺼 둬요. 다만 이 방식이 실제로 얼마나 막아 냈는지에 대한 수치는 공개되지 않았어요.
AI 에이전트와 MCP 차이는?
AI 에이전트는 일을 하는 주체이고, MCP는 그 에이전트가 도구에 연결할 때 쓰는 규격이에요. 사람으로 치면 에이전트가 일꾼이고, MCP는 공구를 꽂는 표준 콘센트에 가까워요.
출처
- Uber Engineering Blog, Alok Srivastava·Deepanshu Mehndiratta·Gaurav Gill, “Designing MCP Gateway: Uber’s MCP Management Platform” (게시 2026-10-01 미국 시간, 확인 2026-10-12) — 링크
- Model Context Protocol 공식 소개 (게시일 표기 없음, 확인 2026-10-12) — 링크
대표 이미지: 우버
구글 검색에서 AIMAG 소식을 먼저 보려면
AI 보조 초안 · 편집부 검수