Uber가 MCP Gateway를 공개했습니다. 규모부터가 다릅니다. 800개 넘는 MCP server, 5,000개 넘는 tool을 운영합니다. Registry를 control plane, Proxy Gateway를 data plane으로 나누고, AutoCrawler가 기존 HTTP·gRPC·TChannel API를 자동 발견해 registry에 등록합니다.

그런데 규모가 커지자 새 문제가 나타났습니다. 수천 개 tool schema를 agent context에 넣을 수 없다는 것입니다. Uber의 해법 3종이 이번 글의 주제입니다.

구조: 발견은 자동으로, 등록은 꺼진 채로

AutoCrawler (Cadence 워크플로우, IDL registry 구독)
  → 새 서비스·API·스키마 변경 스캔
  → MCP server 표현 생성·업데이트
  → tool 정의·스키마 생성 (LLM이 설명 작성 보조)
  → registry에 disabled-by-default 등록
  → owner 리뷰 후 활성화

핵심이 "disabled-by-default"입니다. 자동 발견하되 기본은 꺼둡니다. 서비스 팀을 급한 길에서 빼면서도 규모는 맞추는 구조입니다. MCP 비교 글에서 "도구를 표준으로 내놓기"를 말했는데, Uber는 "표준으로 내놓는 과정" 자체를 자동화했습니다.

병목 3종과 해법 3종

병목 해법 내용
수천 schema를 context에 못 넣음 Omni MCP incremental discovery 필요할 때 찾는 구조
응답이 너무 큼 Response Projection 필요한 response field만 반환
결과가 context를 삼킴 Code Mode agent가 결과를 파일에 저장하고 필요한 부분만 grep

Code Mode가 특히 재미있습니다. 코딩 에이전트가 결과를 파일에 쓰고 필요한 부분만 읽는 방식인데, Uber coding agent의 기본 MCP 사용 방식이라고 합니다. 토큰 5배 글의 "다시 읽기" 문제에 대한 정면 해법입니다. 읽지 말고 저장해두라는 것입니다.

daily.dev가 전한 agentic SDLC 강연 numbers도 맥락을 줍니다. 모델 게이트웨이 800+ 프로젝트·일 1억+ 요청, MCP 게이트웨이의 Omni·CLI·code-mode로 fleet 전체 토큰 40%+ 절감, 에이전트 작성 PR 70%+. 규모에서 나온 최적화가 규모로 검증되는 구조입니다.

우리 규모로 줄이기: Registry 3단계

Uber 규모가 아니어도 패턴은 가져올 수 있습니다.

1단계 Registry (오늘):
- 쓰는 MCP server·tool 목록 1장 (이름·용도·owner)
- 안 쓰는 것은 registry에서 내린다 (좀비 도구 정리)

2단계 search (이번 주):
- 전체 schema 주입 중단
- search → schema-on-demand → invoke 순서로 바꾼다
- 필요한 것만 그때 가져오기

3단계 Projection + Code Mode (이번 달):
- 큰 응답은 field 지정 반환
- 긴 결과는 파일 저장 + grep (context에 직접 안 넣기)

MCP 하네스 글과 라우팅 글의 "필요한 것만" 원칙이 tool discovery에도 적용됩니다.

CodeBridge Mini Lab: tool 10개 다이어트

① 현재 주입 중인 tool schema를 센다 (개수·토큰)
② 안 쓴 지 2주 넘은 tool을 registry에서 내린다
③ 가장 큰 응답 1개를 고른다:
   [ ] 필요한 field만 받는가
   [ ] 파일 저장 + grep으로 바꿀 수 있는가
④ 1주일 후 비교:
   [ ] tokens/task 변화
   [ ] tool 선택 정확도 변화 (떨어지면 search 설명 보강)

속도 글의 작업 완료 시간과 같이 보면 효과가 더 잘 보입니다. context가 가벼워지면 끝나는 시간이 당겨집니다.

결론: 다음 병목을 먼저 치라

한 줄로 정리합니다.

MCP의 다음 병목은 연결이 아니라 발견 × 컨텍스트 × 거버넌스다.

800개가 되기 전에 구조를 잡으세요. Registry 1장, search 순서, 큰 응답 자르기의 3종이면 10개에서도 효과가 납니다. 도구가 늘어날수록 context는 비싸집니다. 비싸지기 전에 찾는 구조를 만드세요.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

도구 발견·호출·검증 구조를 설계해보고 싶다면, 하네스·루프·그래프를 순서대로 쌓는 과정이 이 글의 Registry→search→invoke와 바로 이어집니다.