Gemini Enterprise Agent Platform의 운영·오케스트레이션·거버넌스 설계

흩어진 에이전트 운영을 하나의 제어 평면으로 묶는다

Google Cloud Next '26에서 공개된 Gemini Enterprise Agent Platform의 초점은 새로운 모델 하나를 제공하는 데 있지 않다. Vertex AI를 기반으로 모델 선택, 에이전트 빌딩, 시스템 통합, DevOps, 오케스트레이션, 거버넌스, 최적화, 보안을 단일 제어 평면에 모아 분산된 에이전트 툴체인을 일관되게 운영하는 데 있다.

운영 대상도 Gemini 모델군으로 제한하지 않는다. 서드파티 모델을 같은 오케스트레이션·거버넌스 파이프라인에서 다룰 수 있도록 설계해 특정 모델 벤더에 종속되지 않는 멀티모델 운영을 지향한다. 플랫폼을 평가하려면 모델 성능뿐 아니라 에이전트 수명 주기, 실행 상태 관리, 접근 통제와 감사 구조까지 함께 봐야 한다.

Agent Registry에서 시작하는 배포 수명 주기

Agent Registry는 에이전트의 이름, 설명, 소유자, 태그 같은 메타데이터와 모델 ID·버전, 도구 바인딩, 시스템 프롬프트, 파라미터 설정을 하나의 엔트리로 관리한다. 변경 사항에는 시맨틱 버전이 부여된다.

버전은 latest, staging, production 채널을 거쳐 이동한다. latest에는 최신 커밋 버전이 자동 반영되고, QA 테스트를 통과한 릴리즈 후보는 staging에 배치된다. production 진입에는 수동 승인 게이트가 필요하다. GitFlow와 닮은 이 구조는 에이전트 변경이 운영 환경에 미칠 영향을 단계적으로 검증하기 위한 장치다.

배포 과정은 Vertex AI Pipelines에 선언적 YAML 파이프라인으로 정의된다. CI에서는 에이전트 스키마, 도구 호출 단위 테스트, 모델 응답 기대값 비교를 검사한다. CD에서는 전체 트래픽의 5%를 신규 버전으로 보내는 카나리 배포를 시작하고, 오류율과 지연 시간이 기준 안에 머무르면 트래픽을 점진적으로 늘린다. 카나리 확장 조건은 사용자가 조정할 수 있으며 기본값은 에러율 1% 미만, p95 레이턴시 500ms 이하다.

⤢✕

테스트 결과를 롤백과 SLO로 연결한다

테스트는 단위, 통합, 평가 계층으로 나뉜다. 단위 테스트는 개별 도구 호출의 입출력 스키마 준수 여부를 확인한다. 통합 테스트는 외부 API, 데이터베이스, 메시징 시스템과의 연동을 샌드박스 환경에서 검증한다. 평가 테스트는 Vertex AI Evaluation Service와 연계해 골든 데이터셋으로 최종 출력 품질을 측정한다. 이 데이터셋도 레지스트리에서 버전 관리되므로 에이전트가 변경될 때마다 같은 테스트 케이스로 회귀 테스트를 수행할 수 있다.

장애 대응에는 즉각 롤백과 점진적 롤백을 구분해 사용한다. 에러율이 임계값을 순간적으로 넘거나 심각한 장애 신호가 감지되면 즉각 롤백이 발동해 수 초 이내에 이전 프로덕션 버전으로 트래픽을 100% 전환한다. 성능이 서서히 나빠지는 경우에는 이전 버전의 트래픽을 단계적으로 복구하고 신규 버전의 비중을 줄인다. 롤백을 마치면 플랫폼이 사후 분석 리포트를 생성해 담당 팀에 알린다.

운영 지표는 Vertex AI Monitoring과 Cloud Monitoring을 연결해 에이전트 단위의 SLI로 관리한다. 대상은 응답 지연, 오류율, 도구 호출 성공률, 토큰 소비량, 품질 점수다. 품질 점수는 Gemini 기반 Auto-Evaluator가 에이전트 응답 샘플을 실시간으로 채점해 계산한다. 각 SLI에 SLO를 설정하고 Error Budget Burndown Chart로 소진률을 표시하면 에이전트 운영을 SRE 방식으로 다룰 수 있다.

실행 구조에 맞춰 오케스트레이션 토폴로지를 고른다

오케스트레이션 엔진은 Agent-to-Agent(A2A) 프로토콜을 이용해 에이전트 간 직접 통신을 지원한다. 복잡한 멀티스텝 작업에는 오케스트레이터가 서브에이전트에 태스크를 나누는 계층형 토폴로지를 적용할 수 있다. 데이터 변환, 요약, 분류처럼 앞 단계의 출력이 다음 단계의 입력이 되는 작업은 파이프라인 토폴로지에 맞는다. 여러 전문가 에이전트가 대등하게 협업해야 한다면 공유 메시지 버스를 사용하는 메시 토폴로지가 적합하다.

이 구조를 실행하는 관리형 런타임이 Agent Engine이다. 에이전트 인스턴스의 스케일링과 상태 관리, 체크포인팅을 자동으로 처리하며, 실행 중간 상태는 Cloud Spanner 기반 영구 저장소에 기록한다. 인스턴스가 장애로 멈춰도 마지막 체크포인트부터 재개할 수 있어 수 시간 동안 이어지는 워크플로우에서도 작업 손실을 막는다.

⤢✕

IAM 정책을 에이전트 실행 경계까지 확장한다

거버넌스 계층의 기반은 Google Cloud IAM이다. 에이전트는 서비스 계정으로 실행되며, Workload Identity Federation을 이용하면 온프레미스나 다른 클라우드의 워크로드도 같은 IAM 정책 아래에서 구동할 수 있다. 각 서비스 계정에는 해당 에이전트가 작업에 사용하는 Google Cloud API와 데이터 리소스만 허용하는 최소 권한 원칙을 적용한다.

접근 정책은 조직, 프로젝트, 런타임 계층으로 구분된다. 조직 정책은 특정 프로젝트나 데이터셋처럼 에이전트가 접근해서는 안 되는 리소스 유형을 전사적으로 선언한다. 개별 팀이 재정의할 수 없는 하드 가드레일이다. 프로젝트 정책은 개발·스테이징·프로덕션 환경에 따라 접근 범위를 달리 설정한다. 에이전트 런타임 정책은 실행 중 호출할 수 있는 도구와 API의 화이트리스트·블랙리스트를 정의하며, Agent Registry 엔트리에 선언된 내용이 배포 과정에서 적용된다.

Agent Governance Console에서는 에이전트별 접근 권한 매트릭스를 시각적으로 관리한다. 보안 팀은 지난 30일 동안 각 에이전트가 호출한 API와 접근한 데이터 리소스를 확인할 수 있다. IAM Recommender를 에이전트 시나리오로 확장한 자동 추천 기능은 사용되지 않은 권한을 찾아 제거하는 데 쓰인다.

⤢✕

감사 로그와 DLP를 입출력 경로에 배치한다

모든 에이전트 활동은 Cloud Audit Logs에 기록된다. 에이전트 전용 감사 이벤트는 에이전트 ID와 버전, 실행 요청자, 호출한 도구, 접근한 리소스, 입출력 토큰 수, 소요 시간, 결과 상태를 표준화된 스키마에 담는다. 로그는 수정하거나 삭제할 수 없는 불변 스토리지에 저장된다. 기본 보존 기간은 400일이고, 규제 요건에 따라 7년까지 늘릴 수 있다.

PII 필터링은 에이전트의 입력과 출력 파이프라인에 삽입된 DLP 인스펙터가 맡는다. Cloud DLP API를 호출해 이름, 주민번호, 신용카드 번호, 이메일 주소 같은 민감 정보 패턴을 실시간으로 찾고, 정책에 따라 마스킹·토큰화·접근 차단 중 하나를 수행한다. 탐지 사건은 별도의 보안 감사 로그에 남으며 데이터 보호 담당자에게 전달된다. 출력 단계의 검사는 에이전트 응답을 통한 민감 정보 유출을 막는 출구 제어다.

컴플라이언스 검증에는 Assured Workloads가 연결된다. HIPAA, FedRAMP, ISO 27001, GDPR 등 규제 프레임워크별로 미리 구성된 컨트롤 패키지를 에이전트 플랫폼이 상속한다. 대시보드는 각 활성 에이전트 인스턴스에 적용된 컨트롤과 충족 상태를 실시간으로 보여 주며, 위반이 발견되면 Security Command Center가 즉시 알림을 보낸다. 수동 감사에 의존하던 검증을 지속적인 자동 모니터링으로 전환해 감사 준비 비용을 대폭 낮추는 구조다.

런타임 격리와 프롬프트 방어를 겹쳐 놓는다

에이전트 런타임은 Google Cloud Confidential Computing 인프라에서 동작하며, 인스턴스 사이의 메모리 격리를 하드웨어 수준에서 보장한다. 각 인스턴스는 독립 컨테이너에서 실행되고 컨테이너 탈출 공격을 막기 위한 gVisor 샌드박스가 기본 적용된다. 외부 API나 인터넷 리소스에 접근하려면 VPC Service Controls가 정한 서비스 경계를 통과해야 하므로 허가되지 않은 외부 리소스는 네트워크 수준에서 차단된다.

프롬프트 인젝션 방어도 한 지점에 의존하지 않는다. 입력 시점에는 탐지 모델이 시스템 프롬프트 오버라이드 패턴을 검사한다. 실행 중에는 시스템 프롬프트와 사용자 입력을 구조적으로 분리된 컨텍스트 슬롯에 배치한다. 출력 시점에는 응답이 허용된 행동 범위를 벗어났는지 다시 검사한다. 도구 호출이 실제 시스템 변경으로 이어지는 환경에서는 이 삼중 방어가 에이전트의 공격 표면을 줄이는 역할을 한다.

⤢✕

AWS Bedrock Agents와 비교하면 운영 계층의 차이가 보인다

AWS Bedrock Agents는 Lambda 함수 기반 Action Group, OpenSearch·Kendra 기반 Knowledge Base, 콘텐츠 필터를 담당하는 Guardrails를 제공한다. Lambda, S3, DynamoDB, Redshift 같은 AWS 서비스와 빠르게 연결할 수 있고 진입 장벽이 낮다는 점이 강점이다. 반면 오케스트레이션이 복잡해질수록 에이전트 간 조율, 상태 관리, 장시간 실행 워크플로우 지원에 한계가 드러난다는 평가가 있다.

Gemini Enterprise Agent Platform의 첫 번째 차이는 오케스트레이션 엔진이다. Agent Engine은 Cloud Spanner 기반 체크포인팅과 A2A 프로토콜에 의한 에이전트 간 직접 통신을 지원한다. 복잡한 멀티에이전트 토폴로지를 기본 인프라에서 처리하는 반면, Bedrock Agents에서 동등한 오케스트레이션을 구현하려면 Step Functions 같은 서비스를 추가로 조합해야 한다.

두 번째는 모델 운용 범위다. Model Garden을 통해 Gemini뿐 아니라 Llama, Mistral, Gemma 같은 오픈소스 모델을 같은 파이프라인에서 실행할 수 있다. Bedrock도 Amazon Nova와 Anthropic Claude, Meta Llama 등 서드파티 모델을 지원하지만 오픈소스 모델의 커스텀 파인튜닝과 배포에는 제약이 있다.

세 번째 차이는 데이터 분석 생태계와의 결합이다. BigQuery, Looker, Dataflow를 네이티브로 연결할 수 있어 Google Cloud에서 데이터 파이프라인을 운영하는 조직은 에이전트를 기존 데이터 인프라에 직접 붙일 수 있다.

Azure AI Foundry와는 데이터·검색·멀티모달에서 갈린다

Azure AI Foundry는 Azure OpenAI Service, Semantic Kernel 기반 에이전트 프레임워크, Azure Monitor 옵저버빌리티를 중심으로 구성된다. Microsoft 365와 Copilot의 결합은 기존 Microsoft 업무 환경을 에이전트로 확장하려는 기업에 강한 락인 요인이 된다. OpenAI 모델 우선 접근권과 GPT-4o 시리즈의 엔터프라이즈급 SLA 지원도 경쟁 요소다.

Vertex AI 쪽의 핵심은 데이터 플라이휠이다. Google Cloud에 데이터를 저장하고 처리하는 기업은 BigQuery ML, Vertex AI Feature Store, Vertex AI Datasets의 자산을 에이전트 파이프라인에 직접 연결할 수 있다. 기업 데이터로 파인튜닝한 에이전트 모델을 만들 때 필요한 데이터 준비 비용이 현저히 낮아진다. Azure도 Azure Data Factory와 Synapse Analytics로 비슷한 통합을 시도하지만, Google의 BigQuery-Vertex AI 연결처럼 단일 벤더 서비스로 완성된 통합의 긴밀도에서는 차이가 있다고 평가된다.

검색 자산도 구분점이다. Grounding with Google Search는 에이전트가 실시간 웹 정보를 신뢰할 수 있는 소스에서 조회하도록 지원한다. 멀티모달 측면에서는 Gemini가 텍스트, 이미지, 오디오, 비디오, 코드를 단일 모델에서 처리한다. 모달리티별 전문 모델을 별도 파이프라인으로 엮는 구성과 비교하면 지연 시간과 오케스트레이션 복잡도가 낮다.

⤢✕

클라우드는 모델 이름보다 운영 조건으로 선택한다

2026년 엔터프라이즈 에이전트 클라우드 선택에는 기존 인프라 종속성, 모델 전략, 거버넌스·컴플라이언스, 개발자 경험, TCO가 핵심 기준으로 작용한다.

데이터와 워크로드의 70% 이상이 특정 클라우드에 있다면 같은 클라우드의 에이전트 플랫폼을 선택해 데이터 이동 비용, 네트워크 지연, 크로스 클라우드 인증 복잡성을 제거하는 편이 합리적이다. 특정 모델 벤더인 Anthropic, OpenAI, Google에 최적화된 사용 사례가 있다면 해당 모델을 네이티브로 통합하는 플랫폼이 유리하다. 금융·의료·공공 분야에서는 데이터 레지던시와 HIPAA, FedRAMP, ISO 27001 같은 규제 프레임워크의 사전 검증 여부가 선택에 직접 영향을 준다.

개발자 경험은 로컬 도구, SDK 품질, 디버깅 환경, 커뮤니티 생태계에 좌우된다. Vertex AI는 AI Studio와 Cloud Shell을 활용한 빠른 프로토타이핑 환경을 제공하지만 에이전트 전용 로컬 시뮬레이터의 성숙도에는 개선 여지가 있다는 평가를 받는다.

TCO에는 모델 추론, 오케스트레이션 엔진 실행, 스토리지와 네트워크, 모니터링과 거버넌스 도구의 비용이 함께 들어간다. Google Cloud에서는 Committed Use Discount와 Spot VM을 이용한 추론 비용 최적화, BigQuery·Looker 사용량 기반 번들 할인이 TCO를 조정하는 수단으로 작동한다.

선택 기준	Gemini Enterprise	AWS Bedrock	Azure AI Foundry
오케스트레이션 성숙도	높음 (Agent Engine)	중간 (Step Functions 조합 필요)	중간-높음 (Semantic Kernel)
데이터 통합 깊이	높음 (BigQuery 네이티브)	중간 (Glue·Redshift)	중간 (Synapse·Data Factory)
모델 다양성	높음 (Model Garden)	높음 (Bedrock Model IDs)	중간-높음 (Azure OpenAI 집중)
거버넌스·컴플라이언스	높음 (Assured Workloads)	높음 (AWS Compliance Programs)	높음 (Microsoft Compliance Center)
검색·그라운딩	높음 (Google Search)	낮음	낮음
Microsoft 생태계 통합	낮음	낮음	높음 (M365·Teams)

2026년 경쟁의 중심은 모델 API 제공에서 에이전트의 빌드, 테스트, 배포, 모니터링, 거버넌스를 포괄하는 플랫폼 완성도로 옮겨가고 있다. Gemini Enterprise Agent Platform은 기존 Vertex AI MLOps 생태계 위에 에이전트 전용 계층을 쌓는 진화형 접근을 택했다. 새로운 플랫폼으로 전면 교체하지 않고 기존 인프라 투자를 유지하면서 에이전트 운영 체계를 도입하는 경로다.

Google Cloud에 데이터 자산이 집중된 조직이라면 BigQuery 데이터 플라이휠, Agent Engine, Google Search 그라운딩, Gemini의 네이티브 멀티모달 처리가 직접적인 선택 요인이 된다. 다른 환경에서는 기존 데이터 인프라 종속성, 모델 전략, 거버넌스 요건의 세 축을 먼저 대조해야 한다. 2026년 이후 경쟁은 모델 성능만이 아니라 수명 주기 관리, 거버넌스, 데이터 통합의 완성도를 기준으로 재편될 것으로 전망된다.