MCP만으로 부족했던 운영 통제, DoorDash의 Agent Gateway 설계

MCP만으로 부족했던 운영 통제, DoorDash의 Agent Gateway 설계

AI 뉴스 썸네일

MCP를 붙이면 AI 에이전트가 여러 도구를 같은 방식으로 찾고 호출할 수 있어요. 하지만 실제 사내 시스템에 연결하려면 누가 어떤 도구를 쓸 수 있는지, 자격 증명을 어디에 둘지, 호출 기록을 어떻게 남길지까지 정해야 해요. DoorDash는 이 운영 문제를 Agent Gateway 한곳에서 처리하는 구조를 공개했어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
도입 배경	MCP 밖에 남은 인증·권한·자격 증명·감사 문제를 게이트웨이에 모았어요	팀마다 같은 보안 기능을 다시 만드는 일을 줄일 수 있어요
기본 구조	Proxy가 요청을 처리하고 Registry가 서버·도구·정책 정보를 관리해요	데이터 평면과 제어 평면의 책임을 나눈 실제 설계예요
도구 노출	여러 MCP 서버의 도구를 업무별 묶음과 필터로 정리해요	승인되지 않은 기능을 숨기고 모델의 도구 선택 혼란도 줄여요
자격 증명	사용자별 OAuth와 서비스 계정 자격 증명을 게이트웨이가 주입해요	에이전트가 원본 토큰이나 API 키를 직접 보관하지 않아도 돼요
운영 규모	200개 넘는 MCP 서버와 30개 넘는 에이전트·서비스가 연결돼요	매주 수백만 건의 호출을 다루는 프로덕션 사례예요

1. MCP 호출 앞에 공통 통제 지점을 뒀어요

표준 호출 형식만으로는 운영이 끝나지 않아요

MCP는 도구 설명과 탐색, 호출 형식을 맞춰 줘요. 프로덕션 환경에서는 그 앞뒤에 더 많은 결정이 붙어요. 호출자가 사용자·서비스·AI 에이전트 중 누구인지 확인해야 해요. 특정 사용자와 에이전트의 조합에 쓰기 권한을 줄지, 읽기만 허용할지도 구분해야 해요. 외부 SaaS에는 사용자 OAuth를 쓸지 팀 서비스 계정을 쓸지도 정해야 해요. 2

각 팀이 이를 따로 구현하면 인증 코드, OAuth 연결 화면, 토큰 저장소, 속도 제한, 호출 로그가 에이전트마다 생겨요. 권한을 회수할 때도 여러 서비스를 찾아다녀야 해요. DoorDash는 도구 호출이 반드시 Agent Gateway를 지나게 했어요. 게이트웨이는 호출자를 인증한 뒤 권한을 검사하고, 허용된 도구만 보여줘요. 실제 호출 때는 필요한 자격 증명을 주입하고 하위 MCP 서버로 요청을 전달한 뒤 사용 기록을 남겨요.

728x90

Proxy와 Registry가 서로 다른 책임을 맡아요

Proxy는 요청이 통과하는 데이터 평면이에요. 인증과 인가, 속도 제한, 자격 증명 주입, 요청 전달, 관측 데이터 생성을 처리해요. Registry는 제어 평면의 기준 정보 저장소예요. AI 에이전트와 MCP 서버, 소유 팀, 전송 방식, 인증 방식, 정책, 발견된 도구 목록을 관리해요.

이 분리 덕분에 에이전트는 하위 서버마다 다른 인증과 주소를 알 필요가 없어요. 도구 소유 팀은 기능과 정책을 한 번 등록하고 실제 사용량을 볼 수 있어요. 보안팀은 한곳에서 접근을 허용하거나 회수해요. DoorDash는 사내용 호출과 외부 서비스용 호출의 Proxy도 나눴어요. 인터넷에 노출된 경로에서 문제가 생겨도 내부 업무 경로까지 번지는 범위를 줄이려는 설계예요.

원본 자격 증명은 에이전트 밖에 남겨요

게이트웨이는 내부 서비스 신원, 게이트웨이가 보관하는 토큰, 사용자별 OAuth, 팀 서비스 계정을 구분해요. 사용자 문서를 읽거나 SaaS 데이터를 수정하는 호출에는 개인 권한이 필요해요. 최초 호출에서 OAuth 연결을 시작하고, 발급받은 토큰은 암호화해 저장해요. 이후 같은 사용자·에이전트·서버 조합의 호출에 필요한 토큰을 자동으로 넣어요.

MCP 클라이언트가 사용자 입력 요청을 지원하면 도구 호출을 잠시 멈추고 연결 화면을 보여준 뒤 원래 호출을 이어갈 수 있어요. 지원하지 않는 클라이언트에는 연결 URL이 포함된 구조화 응답을 돌려줘요. 권한이 없는 상태를 단순 오류로 끝내지 않고, 사용자가 연결을 마친 뒤 복구할 수 있는 흐름으로 만든 셈이에요.

서버 대신 업무별 도구 묶음을 보여줘요

코딩 업무에는 GitHub, Jira, 코드 검색, CI, 관측, 문서 도구가 함께 필요할 수 있어요. 반대로 각 MCP 서버가 제공하는 수백 개 기능을 모두 보여주면 관리자 기능이나 파괴적인 작업까지 섞일 수 있어요. 모델도 비슷한 도구 사이에서 잘못 고르기 쉬워요.

DoorDash는 여러 서버의 도구를 하나의 논리적 주소로 합치는 묶음과, 실제 노출할 기능을 고르는 필터를 사용해요. 개발자 도구 묶음에는 저장소와 PR, 이슈, 로그, 문서에 필요한 기능만 넣을 수 있어요. 도구 목록을 요청하면 게이트웨이가 여러 서버의 목록을 합친 뒤 권한과 필터를 적용해요. 호출 단계에서는 권한을 다시 검사하고 알맞은 서버로 전달해요.

도구를 적게 보여주는 선택은 보안뿐 아니라 실행 품질에도 영향을 줘요. 이름이 비슷하거나 현재 작업과 관계없는 도구가 줄면 모델이 선택할 후보도 선명해져요. DoorDash는 도구 목록을 단순 메타데이터가 아니라 AI 에이전트가 실제로 사용하는 인터페이스로 다뤄요.

모든 호출을 같은 기준으로 관측해요

게이트웨이는 서버, 도구, 묶음, 소유 팀, 사용자, 호출 주체, 권한 결과, 오류 위치, 지연시간, 요청·응답 크기를 구조화된 이벤트로 남겨요. 하위 서비스가 비용 정보를 제공하면 어느 팀과 작업에서 비용이 생겼는지도 연결해요. 서버·도구·사용자·묶음별 속도 제한을 걸 수 있고, 실제 차단 전에 어떤 요청이 막힐지 관찰하는 시험 모드도 사용해요.

현재 DoorDash는 200개가 넘는 MCP 서버를 등록했고 30개가 넘는 에이전트와 서비스가 게이트웨이를 사용한다고 밝혔어요. 수천 명의 직원이 승인된 도구에 접근하고, 게이트웨이는 매주 수백만 건의 호출을 인증하고 기록해요. 중앙 통제 경로가 우회되지 않도록 서버 등록과 도구 탐색, 필터 설정, 묶음 관리도 UI와 API에서 직접 처리할 수 있게 했어요.

왜 중요한가요

MCP를 도입하는 기업은 서버 연결 개수보다 권한의 수명주기를 먼저 설계할 필요가 있어요. 누가 어떤 에이전트를 통해 어떤 도구를 호출했는지 남아야 해요. 사용자 퇴사나 역할 변경, 도구 폐기 때 접근을 한곳에서 회수할 수 있어야 해요. DoorDash 사례는 이런 기능을 개별 에이전트 코드나 도구 설명에 흩어 두지 않고 공통 플랫폼으로 옮긴 방법을 보여줘요. 2

도구 카탈로그도 운영 대상이에요. 승인된 기능만 노출하면 위험한 호출 범위를 줄일 수 있어요. 업무별로 작은 도구 묶음을 만들면 모델이 관계없는 기능을 고르는 문제도 줄어들어요. 보안 정책과 모델의 도구 선택 품질이 같은 필터 설계에서 만나는 지점이에요.

다만 중앙 게이트웨이는 모든 호출이 의존하는 핵심 경로가 돼요. Proxy 장애 범위를 분리하고, Registry 변경을 추적하며, 인증 공급자와 하위 MCP 서버 장애를 구분해서 관측해야 해요. 팀이 직접 연결하는 편이 더 빠르다고 느끼면 통제 경로를 우회할 수도 있어요. 등록과 권한 신청, OAuth 연결, 사용량 확인까지 셀프서비스로 제공해야 중앙화가 실제 운영에서 유지돼요.

참고 자료

1. DoorDash가 AI 에이전트-도구 접근을 위한 중앙 게이트웨이를 구축한 방법 — GeekNews
2. How DoorDash Built a Centralized Gateway for AI Agent-Tool Access — DoorDash Engineering