DoorDash는 2026년 7월 30일, AI 에이전트가 내부 API와 외부 SaaS 도구를 호출하는 경로를 하나로 모은 Agent Gateway 구조를 공개했다. 이 회사가 짚은 문제는 MCP가 도구를 설명·탐색·호출하는 형식을 통일해도, 실제 운영에서 필요한 호출자 인증, 권한 판정, 자격증명 보관, 접근 철회, 감사 기록까지 정해 주지는 않는다는 데 있다.
에이전트에 더 많은 권한을 주려 할 때 “MCP 서버를 연결했는가”가 첫 질문이 되어서는 안 된다. 먼저 정할 것은 누가 어떤 사용자나 서비스를 대신하는지, 어떤 도구를 보게 할지, 쓰기 권한과 비밀값을 어디서 통제할지다. DoorDash의 사례는 이 경계를 에이전트마다 구현하지 않고, 모든 호출이 통과하는 중앙 게이트웨이에 두는 방식이다.
MCP 연결만으로 권한 문제가 끝나지 않는 이유는 무엇인가
DoorDash는 운영 환경의 도구 접근을 접근 권한, 도구 표면의 선별, 운영 관측이라는 세 부분으로 나눈다. 접근 권한에서는 호출한 주체와 적용할 자격증명 모델을 정한다. 도구 표면에서는 하위 MCP 서버가 내놓는 전체 목록이 아니라 업무에 필요한 도구만 에이전트에게 보인다. 운영에서는 호출별 제한, 추적, 지표, 비용 귀속, 소유자 정보를 남긴다.
이 세 가지가 분리되면 팀마다 GitHub·Jira·문서·관측 도구를 이어 붙일 때마다 인증 코드, OAuth 흐름, 비밀값 처리, 도구 목록, 로그를 다시 만들게 된다. 중앙 경계가 없으면 연결 수가 늘어나는 만큼 권한 규칙도 흩어진다. 반대로 게이트웨이에 모으면 정책을 바꾸거나 접근을 철회할 곳도 한곳이 된다.
누구의 권한으로 실행하는지 어떻게 분리해야 하나
게이트웨이는 요청마다 호출자를 사용자, 서비스, 또는 사용자 맥락을 위임받은 에이전트로 해석한다. 이후 “이 에이전트가 이 서버를 쓸 수 있는가”, “이 사용자가 이 에이전트를 통해 이 도구를 호출해도 되는가”, “읽기 전용만 허용할지 쓰기 동작도 열지”, “팀 자동화에 사람 계정 대신 서비스 주체를 쓸지”를 중앙에서 판정한다. 이 신원은 자격증명 주입, 라우팅, 관측 정보까지 함께 전달된다.
자격증명의 보관 위치도 권한의 일부다. 사용자 문서를 읽거나 그 사용자의 이름으로 티켓을 바꾸는 작업에는 사용자별 OAuth 권한이 필요하다. 팀 자동화에는 개인 계정을 빌려 쓰기보다 비개인 서비스 주체가 맞다. DoorDash는 사용자별 OAuth 권한을 에이전트·사용자·서버 조합에 묶고, 최초 연결 때만 OAuth 흐름을 시작한 뒤 이후 호출에는 암호화해 보관한 토큰을 주입한다고 설명한다. 에이전트는 공급자 API 키나 OAuth 갱신 토큰 같은 원시 자격증명을 받지 않는다.
도구를 적게 보여 주는 일이 왜 성능과 보안을 함께 바꾸나
하위 MCP 서버의 전체 목록은 에이전트에게 좋은 인터페이스가 아니다. 제3자 서버는 관리자 기능, 파괴적 작업, 결제 API, 드물게 쓰는 제공자 기능까지 수백 개를 노출할 수 있다. 실제로 장애를 조사하고 코드를 수정해 검토 요청을 열려는 에이전트에게 필요한 것은 서버 목록이 아니라 이슈·저장소·관측·문서·배포 확인 도구로 구성한 업무 묶음이다.
DoorDash의 번들은 여러 MCP 서버의 선별 도구를 하나의 논리적 엔드포인트로 합친다. tools/list 요청에서는 권한과 필터를 적용해 승인된 목록만 돌려주고, tools/call 요청에서는 같은 정책을 다시 적용한 뒤 적절한 하위 서버와 자격증명 모델로 보낸다. 발견 단계와 실행 단계를 같은 경계로 묶는 이유는, 목록에서 감춘 도구가 호출 단계에서 우회되는 틈을 만들지 않기 위해서다.
중앙 게이트웨이는 승인창을 무엇으로 바꾸는가
중앙 경계는 실행을 막는 문지기만은 아니다. 모든 호출이 지나가므로 서버·도구·번들·소유 팀, 사용자·에이전트·서비스, 권한 판정 결과, 오류 원인, 지연 시간, 요청 크기, 하위 시스템이 알려 준 비용 정보를 구조화한 이벤트로 남길 수 있다. 추적 정보를 전파하면 에이전트에서 게이트웨이를 거쳐 하위 도구까지 한 호출의 경로를 따라갈 수 있다.
요청 제한도 서버별, 도구별, 호출자별, 사용자별, 번들별로 적용할 수 있다. DoorDash는 새 제한을 바로 차단하지 않고 그림자 모드로 먼저 돌려 어떤 요청이 거절될지를 확인할 수 있게 했다. 승인창을 계속 띄우는 방식이 사람에게 순간 판단을 떠넘긴다면, 이 방식은 권한 범위와 운영 기준을 먼저 정책으로 정하고 실제 호출 데이터를 통해 다듬는 방식이다.
우회하지 않는 경계는 어떻게 만들 수 있나
통제가 강해도 등록 과정이 느리면 팀은 비밀값을 복사해 직접 연결하는 길을 찾는다. DoorDash는 MCP 서버 등록, 원본 도구 목록 발견, 승인 도구 선택, 인증·소유자·정책 연결, 번들 구성, 트래픽·오류·비용 관찰을 제어면의 UI와 API에서 셀프서비스로 제공한다고 밝혔다. 회사 발표에 따르면 200개가 넘는 MCP 서버와 30개가 넘는 에이전트·서비스가 이 경로를 쓰며, 매주 수백만 건의 도구 호출이 인증·권한 확인·구조화 이벤트 기록을 거쳐 전달된다.
따라서 에이전트에 권한을 줄 때의 설계 순서는 도구 연결, 프롬프트 지시, 개별 예외 추가가 아니다. 호출자의 신원과 위임 범위, 업무별 도구 표면, 자격증명 보관 주체, 실행 뒤 남길 기록과 제한을 먼저 정하고 그 경계를 통과하도록 도구를 연결해야 한다. 에이전트가 할 수 있는 일을 넓힐수록, 그 일을 누구의 책임으로 어떤 범위에서 하게 할지가 제품의 핵심 인터페이스가 된다.
출처: DoorDash, How DoorDash Built a Centralized Gateway for AI Agent-Tool Access (2026-08-10 확인)