에이전트의 활용 범위가 넓어질수록 기술 연결보다 접근 관리에 더 많은 운영 부담이 생긴다. 여러 팀과 시스템이 얽힌 환경에서는 개별 연동만으로 일관된 기준을 유지하기 어렵다.
MCP가 다루지 않는 범위
MCP가 정한 것은 툴의 이름과 인자, 응답 형식뿐이다. 누가 어떤 자격증명으로 어느 툴을 호출할 수 있는지는 정하지 않는다.
실제로 DoorDash도 중앙 게이트웨이를 만들기 전에는 에이전트와 툴을 연결할 때마다 인증, OAuth(외부 서비스 권한을 위임하는 인증 표준), 시크릿(API 키, 토큰 같은 비밀 정보), 호출 제한, 로그를 따로 구현했다. MCP가 호출 형식만 표준화하고 운영 정책은 구현체에 남겨 뒀기 때문이다.
게다가 연결이 늘수록 위험도 커진다. 트렌드마이크로는 인증이나 암호화 없이 공개된 MCP 서버 492대를 찾았다. 그 수는 이후 1,467대로 늘었다. 여기에 에이전트가 자격증명까지 들고 있다면 프롬프트 인젝션(악성 지시를 입력해 모델을 조종하는 공격)이 권한 오용으로 번질 위험이 있다. 결국 인증과 정책을 한곳에서 처리하고 모든 동작을 감사할 중앙 경로가 필요하다.
자격증명을 넘기지 않는 구조
DoorDash는 호출을 처리하는 프록시와 정책을 보관하는 레지스트리를 나눴다.
- 프록시는 권한 검사, 호출 제한, 자격증명 주입, 라우팅, 로그 기록을 맡는다.
- 레지스트리에는 소유자, 인증 방식, 정책, 공개할 툴 목록이 들어간다.
개발자는 하나의 게이트웨이 주소만 사용한다.
API 키나 OAuth 토큰은 게이트웨이가 보관했다가 호출할 때만 주입한다. 사용자 인증이 필요하면, elicitation을 지원하는 클라이언트는 OAuth 연결을 마친 뒤 요청을 재개한다. 지원하지 않는 클라이언트는 연결 URL이 담긴 인증 필요 응답을 받는다. 자격증명 원본은 에이전트에 넘기지 않는다.
또한 중앙 계층은 프로토콜이 바뀌어도 그 변화를 게이트웨이 안에서 처리한다. 2026년 7월 사양부터 Mcp-Method와 Mcp-Name 헤더에 이 정보가 담겨 게이트웨이가 라우팅과 호출 제한을 처리하기 쉬워졌다. Mcp-Name은 툴 호출에서는 툴 이름을 가리키지만 헤더 자체는 Streamable HTTP 요청 전반에 쓰인다. 이 사양은 세션과 초기화 절차, 요청과 응답, 인증, SDK까지 바뀌었지만 헤더 처리는 게이트웨이 쪽만 손보면 된다.
적은 노출, 높은 정확도
MCP 서버의 전체 목록에는 관리나 삭제처럼 민감한 툴도 섞여 있다. 게이트웨이는 툴을 업무별로 묶어 사용자와 환경, 에이전트의 권한에 맞는 것만 보여준다.
목록이 짧으면 모델의 선택도 정확해질까. RAG-MCP 실험에서는 관련 툴만 골라 제공하자 정확도가 13.62%에서 43.13%로 올랐다.
필요한 툴만 불러오면 토큰도 아낀다. Anthropic은 툴 검색으로 툴 정의에 쓰이던 토큰을 85% 줄였다.
검색이 ‘필요한 툴’을 찾는다면, 게이트웨이는 먼저 ‘볼 수 있는 툴’을 제한한다.
모든 호출에 주체와 대상을 남겨라
통제가 번거로우면 개발팀은 우회로를 찾는다. DoorDash는 각 팀이 UI와 API에서 서버와 에이전트를 직접 등록하고 인증 방식, 툴 필터, 소유권을 설정하게 했다. 새 서버는 몇 분 안에 등록된다. 호출 제한은 먼저 섀도 모드(shadow mode)로 영향을 확인한 뒤 적용한다.
호출 기록도 한곳에 모은다. 누가 어떤 툴을 불렀는지, 권한 검사를 통과했는지, 어디서 오류와 지연이 생겼는지 남긴다. 이 기록은 감사, 권한 회수, 장애 분석, 비용 배분에 함께 쓰인다.
그 결과 DoorDash의 게이트웨이는 200개가 넘는 MCP 서버를 연결해 매주 수백만 건을 처리한다. 관리 대상은 호출자, 자격증명, 공개할 툴, 사용 한도, 호출 기록이다.
그렇다면 직접 구축할 것인가, 상용 서비스를 쓸 것인가. 에이전트 수보다 OAuth와 정책 구현이 얼마나 반복되는지를 보고 판단해야 한다. 에이전트에는 자격증명 원본을 주지 않으며 허용된 툴만 보여주고 모든 호출에 주체와 대상을 남긴다.
운영 계층이 성숙했는지는 정상 호출이 아니라 변경과 예외를 다루는 방식을 보면 안다. 팀과 도구가 늘어날수록 빠른 연결보다 정책 변경의 영향 범위를 좁히는 설계가 더 유효하다.