한 줄 정의
Google Cloud의 Agent Gateway는 Gemini Enterprise Agent Platform 안에서 에이전트와 도구 사이 트래픽을 검사하고, 허용 여부를 결정한 뒤, 그 결과를 남기는 네트워크 경계다. MCP가 도구 호출 규약을 정하는 층이라면, Agent Gateway는 그 호출을 운영 정책에 맞게 통과시킬지 막을지 판단하는 층에 가깝다.
실제로 무엇을 하나
Agent Runtime이나 Gemini Enterprise에서 외부 도구 호출이 나가면, Agent Gateway가 먼저 어떤 주체가 어떤 대상으로 가는 요청인지 본다. 이때 Agent Identity(에이전트 신원)로 주체를 확인하고, Agent Registry에 등록된 대상인지, IAM 기준으로 허용된 대상인지를 함께 본 뒤 정책에 맞는 요청만 통과시킨다.
통과한 요청은 실행 표면으로 전달되고, 남은 흔적은 Agent Observability(에이전트 관측성)과 로그에서 추적한다. 그래서 이 용어는 범용 API 게이트, Agent Platform(에이전트 플랫폼) 전체, 혹은 Alibaba Cloud Model Studio(알리바바 클라우드 모델 스튜디오) 같은 콘솔형 제작 도구와 구분해서 읽어야 한다.
활용 예시
고객 문의 자동화 에이전트에서는 티켓 조회 도구와 답변 작성 도구를 함께 붙일 수 있다. 이때 핵심은 도구를 많이 연결하는 것이 아니라, 어떤 신원이 어떤 도구 호출을 통과시킬 수 있는지를 게이트웨이에서 분리해 보는 것이다. 조회는 넓게 열고 작성이나 발송은 승인된 대상만 통과시키면, 실패 지점과 감사 지점을 한 경계에서 읽기 쉬워진다.
민감 데이터 처리 에이전트에서는 내부 문서 검색은 통과시키고, 등록되지 않았거나 승인되지 않은 외부 대상 호출은 막아 두는 식으로 운영할 수 있다. 이 경우 먼저 볼 것은 모델 답변 품질이 아니라, 어떤 호출이 왜 차단됐는지 남는 로그와 정책 매핑이다.
주의해서 볼 점
이 페이지는 Google Cloud 문맥만 다룬다. 다른 클라우드의 에이전트 콘솔이나 앱 게이트를 같은 말로 읽으면 역할이 어긋난다.
또 Agent Gateway가 Agent Runtime을 대체하는 것은 아니다. 실행은 런타임이 맡고, 호출 전 승인과 차단 경계는 게이트웨이가 맡는다.
마지막으로 Gateway 하나만 붙인다고 운영 통제가 끝나지 않는다. 등록, 신원, 정책, 로그 해석이 같이 맞물려야 실제로 쓸 수 있는 경계가 된다.
왜 중요한가
팀이 Agent Gateway를 도입할지 판단할 때 핵심은 기능 수가 아니라 경계 설계다. Google Cloud 문서 기준으로 이 계층은 등록된 대상과 승인된 정책을 중심으로 트래픽을 통제하므로, “도구를 연결하는 일”과 “도구 호출을 운영 가능한 상태로 만드는 일”을 분리해 준다.
반대로 에이전트가 단지 도구 프로토콜만 맞추면 되는 상황이라면 MCP나 런타임 설정만으로도 목적을 달성할 수 있다. 호출 승인, 등록, 감사 추적을 한 경계에서 다뤄야 할 때에만 Agent Gateway라는 말을 쓰는 편이 정확하다.