Gemini Enterprise 에이전트 거버넌스: Identity·Registry·Gateway 설계

에이전트를 만드는 기능만으로는 부족하다

Google은 2026년 4월 22일 Google Cloud Next '26에서 Gemini Enterprise Agent Platform을 정식 출시했다. Vertex AI의 후속이자 통합 플랫폼으로 제시된 이 제품은 에이전트 빌드·배포·거버넌스·모니터링을 한 환경에서 다룬다.

발표의 초점은 개별 에이전트의 성능보다 기업 전체에 배포된 에이전트를 신뢰할 수 있게 만드는 운영 구조에 있었다. 에이전트가 수백 개로 늘어나면 신원을 구분하기 어려워지고 권한 경계가 흐려지며, 실행 결과를 누가 만들었는지 추적하기도 힘들어진다. Google은 이 문제를 Agent Identity, Agent Registry, Agent Gateway라는 3계층 거버넌스 아키텍처로 풀었다.

플랫폼에는 Agent Studio, 업그레이드된 Agent Development Kit(ADK), Agent Runtime, Agent-to-Agent Orchestration, Agent Gateway, Agent Identity, Agent Registry, Agent Observability, Agent Simulation, Agent Evaluation 등 10개 이상의 모듈이 함께 포함됐다.

⤢✕

개발부터 개선까지 이어지는 플랫폼 경계

Gemini Enterprise Agent Platform은 에이전트 라이프사이클을 Build, Scale, Govern, Optimize의 4개 영역으로 나눈다.

Build에는 개발자와 비개발자가 에이전트를 만들 수 있는 Agent Studio와 ADK가 배치된다. Scale은 Agent-to-Agent Orchestration을 중심으로 단일 에이전트를 멀티 에이전트 워크플로우로 확장한다. Optimize에서는 Agent Observability·Evaluation·Simulation으로 동작을 관찰하고 품질을 개선한다.

이번 발표에서 운영 관점의 무게가 가장 크게 실린 곳은 Govern이다. 모든 에이전트에 고유한 신원을 할당하고, 사용 가능한 능력을 카탈로그에 등록하며, 실제 호출 경로에서 정책을 집행하는 구조다. 추적 가능성(traceability)과 정책 일관성(policy consistency)을 에이전트 코드 바깥의 플랫폼 계층에서 확보하려는 접근이다.

⤢✕

Agent Identity가 사용자 계정과 에이전트를 분리한다

Agent Identity는 X.509 인증서와 SPIFFE(Secure Production Identity Framework for Everyone) 개방 표준을 기술적 기반으로 삼는다. Envoy 기반 에이전트 게이트웨이가 런타임의 각 에이전트에 고유한 암호화 신원을 할당하며, 이 신원은 인간 사용자의 계정과 분리된다.

기존 서비스 계정은 여러 워크로드가 공유할 수 있고 장기 유효 키를 만들 수 있었으며, 특정 조건에서는 개발자가 직접 임시 토큰을 발급받을 수 있었다. Agent Identity에서는 각 신원이 기본적으로 단일 워크로드에 귀속된다. 장기 키를 만들거나 개발자가 직접 토큰을 생성하는 것도 허용하지 않는다.

Google Cloud 액세스 토큰은 에이전트의 고유 X.509 인증서에 암호화 방식으로 바인딩된다. 토큰이 탈취되더라도 원본 인증서가 없으면 재사용할 수 없게 만드는 구조다. Default Context-Aware Access 정책은 토큰을 재생 불가(unreplayable) 상태로 만들어 토큰 도용과 계정 탈취를 구조적으로 차단한다.

사용자 권한을 그대로 물려주지 않는 OAuth 위임

에이전트가 사용자를 대신해 행동하더라도 사용자의 전체 권한을 상속하지는 않는다. OAuth 위임 범위를 명시적으로 제한하고, 에이전트가 선언한 능력(capability) 안에서만 권한을 부여한다. Agent Gateway는 도구가 호출될 때마다 이 범위를 실시간으로 확인한다.

최소 권한 원칙(Principle of Least Privilege)은 Agent Registry의 메타데이터와 연결된다. 에이전트는 Registry에 등록된 도구와 스킬에만 접근할 수 있다. 권한 정보가 플랫폼에서 관리되므로 에이전트 코드마다 별도의 권한 로직을 구현할 필요가 없다.

모든 호출이 통과하는 Agent Gateway

Agent Gateway는 에이전트와 데이터 또는 외부 시스템 사이에 놓이는 중앙 정책 실행 지점이다. Envoy를 기반으로 하며 도구 호출마다 인증·인가·감사를 수행한다.

에이전트끼리 상호작용할 때 필요한 인증은 Gateway가 처리한다. 개발자가 에이전트마다 별도의 인증 코드를 작성하지 않아도 되고, 보안 정책은 중앙에서 동일하게 적용된다. 도구 호출 전체에 대한 감사 로그도 이 경로에서 생성되므로 컴플라이언스 요구사항에 대응할 수 있다.

Agent Registry에 에이전트와 도구를 모은다

Agent Registry는 엔터프라이즈 안에서 사용할 수 있는 에이전트와 능력의 단일 진실 공급원(Single Source of Truth)이다. 조직 내부에서 만든 에이전트·도구·스킬뿐 아니라 Google 제공 에이전트, 서드파티 에이전트, MCP 서버까지 하나의 카탈로그에서 인덱싱한다.

⤢✕

MCP(Model Context Protocol) 서버를 등록할 때는 도구 이름과 어노테이션, 사용 정책을 함께 캡처한다. 에이전트는 Registry를 조회해 적합한 MCP 도구를 발견하고 호출한다. 외부 MCP 서버에 제한 없이 접근하는 대신, 승인된 서버만 프로덕션 환경에서 사용할 수 있게 관리하는 방식이다.

Registry는 에이전트 간 능력 협상(capability negotiation)에도 관여한다. 각 에이전트의 능력을 선언적으로 기록해 두면 오케스트레이터가 이를 쿼리한 뒤 태스크에 맞는 에이전트를 동적으로 고를 수 있다.

버전 정보 역시 같은 카탈로그에서 관리한다. 업데이트 과정에서는 구버전과 신버전을 병렬로 운영하며 점진적으로 전환할 수 있다. 컴플라이언스 조건에 따라 특정 버전만 사용하도록 정책을 고정하는 것도 가능하다.

ADK 그래프로 멀티 에이전트 작업을 연결한다

Agent Development Kit(ADK)는 2026년 버전에서 그래프 기반 오케스트레이션 프레임워크로 업그레이드됐다. 개발자는 에이전트 사이의 관계를 DAG(Directed Acyclic Graph)로 정의하고 태스크 흐름을 선언적으로 구성한다.

그래프로 표현한 워크플로우는 에이전트의 연결 관계를 시각화하기 쉽다. 비개발자도 흐름을 파악할 수 있고, 오케스트레이션 로직을 인프라 코드와 분리해 유지보수할 수 있다. 정책 엔진은 그래프 구조를 분석해 잠재적인 권한 위반을 사전에 검출한다.

규칙 기반과 능력 기반 태스크 라우팅

플랫폼은 태스크 라우팅을 두 방식으로 지원한다. 정적 라우팅에서는 미리 정한 규칙에 따라 오케스트레이터가 특정 에이전트에 작업을 맡긴다. 경로를 고정해야 하는 컴플라이언스 워크플로우에 적합하다.

동적 라우팅은 Agent Registry를 실시간으로 조회한 뒤 태스크 요구사항에 가장 잘 맞는 에이전트를 선택한다. 이 방식은 능력 기반 라우팅이라고도 한다.

작업 결과는 태스크 성격에 따라 순차 집계(sequential aggregation), 병렬 집계(parallel aggregation), 합의 기반 집계(consensus-based aggregation) 방식으로 모을 수 있다.

⤢✕

통제된 경로와 생성형 경로를 함께 쓴다

결정론적(deterministic) 오케스트레이션은 에이전트가 반드시 정해진 경로를 지나야 하는 컴플라이언스 흐름에 사용한다. 생성형(generative) 오케스트레이션에서는 오케스트레이터 에이전트가 상황에 맞는 경로를 스스로 결정한다.

Gemini Enterprise Agent Platform은 두 방식을 하나의 워크플로우 안에서 혼합할 수 있다. 고정해야 하는 구간은 결정론적으로 통제하고, 선택 여지가 필요한 구간에는 생성형 판단을 적용해 자율성과 통제성의 균형을 조정한다.

실행 이력을 거버넌스 데이터로 남긴다

Agent Observability는 에이전트가 수행한 모든 작업을 추적한다. 각 호출에는 Agent Identity가 발급한 고유 실행 ID가 붙는다. 여러 에이전트가 연쇄적으로 작업한 경우에도 어떤 에이전트가 어떤 단계를 수행했는지 식별할 수 있다.

Agent Simulation은 프로덕션 배포 전에 에이전트 동작을 시뮬레이션해 의도하지 않은 행동 패턴을 감지한다. Agent Evaluation은 에이전트 품질 메트릭을 정량화하고 개선 사이클을 체계화한다. 두 모듈은 Optimize 영역에 배치되지만, Govern 영역에서 생성된 감사 데이터를 입력으로 사용한다는 점에서 거버넌스 구조와 맞물린다.

Vertex AI에 거버넌스 연결 계층을 더하다

Gemini Enterprise Agent Platform은 Vertex AI를 에이전트 중심으로 재배치한 결과물이다. TechTarget은 이 플랫폼이 Vertex AI에 “결합 조직(connective tissue)”을 추가했다고 평가했다. 분산돼 있던 ML 서비스를 에이전트 거버넌스 계층으로 연결해 기업 운영에 필요한 통제성을 제공한다는 의미다.

경쟁 플랫폼과 비교하면 신원 모델의 차이가 선명하다. Microsoft Azure AI Agent Service는 Azure AD 통합을 바탕으로 거버넌스를 제공하고, AWS Bedrock Agent는 IAM 역할로 접근을 제어한다. Google은 이와 달리 에이전트 전용 신원 시스템인 Agent Identity를 별도 계층으로 구축했다. 에이전트를 기존 클라우드 리소스가 아니라 독립적인 주체로 다루겠다는 설계 철학이다.

Agent Identity·Registry·Gateway로 구성된 3계층은 수십·수백 개의 에이전트가 기업 환경에서 안전하게 자율 동작하도록 뒷받침한다. 2026년은 에이전트 빌드의 시대를 넘어 에이전트 거버넌스의 시대로 이행하는 원년이 될 것이며, Google의 발표는 그 방향을 구체적인 아키텍처로 제시한 이정표다.