Gemini Enterprise Agent Platform(제미니 엔터프라이즈 에이전트 플랫폼)

한 줄 정의

이 플랫폼은 회사 안에서 쓰는 AI 에이전트를 만들고 운영하는 Google Cloud 도구야. Gemini 모델 하나를 새로 부르는 이름이 아니라, Vertex AI의 모델 선택과 에이전트 개발 기능에 실행, 보안, 관측, 권한 관리를 더한 운영 경로라고 보면 돼.

처음에 갈라 볼 건 두 가지야. 하나는 모델 접근이야. 이 플랫폼은 Model Garden을 통해 200개가 넘는 모델을 보여 주고, Gemini 3.1 Pro, Gemini 3.1 Flash Image, Lyria 3, Gemma 4, Anthropic Claude Opus·Sonnet·Haiku 같은 선택지를 예로 들어. 다른 하나는 에이전트 운영이야. Agent Runtime, Agent Identity, Agent Registry, Agent Gateway, Agent Observability처럼 “모델이 답한다” 이후의 실행과 통제를 다룬다.

실제로 무엇을 하나

실제 기능은 build, scale, govern, optimize 네 묶음으로 읽으면 덜 헷갈려.

• Build: Agent Studio는 낮은 코드 화면에서 에이전트를 만들게 하고, Agent Development Kit(ADK)는 코드로 로직을 깊게 다루게 해. Agent Garden은 코드 현대화, 금융 분석, 경제 리서치, 송장 처리 같은 템플릿을 제공하는 쪽이야.
• Scale: Agent Runtime은 sub-second cold start와 seconds 단위 프로비저닝을 내세워. 며칠 동안 유지되는 긴 작업, Agent Sandbox의 코드 실행 환경, 에이전트끼리 일을 넘기는 오케스트레이션, Memory Bank와 Agent Sessions도 이 묶음에 들어가.
• Govern: Agent Identity는 에이전트마다 추적 가능한 암호학적 ID를 주고, Agent Registry는 내부 에이전트와 도구, 스킬을 색인해. Agent Gateway는 에이전트와 도구 연결에 정책과 Model Armor 보호를 걸어 주는 통제 지점에 가깝다.
• Optimize: Agent Simulation, Agent Evaluation, Agent Observability, Agent Optimizer는 배포 전 테스트와 배포 후 추적을 맡아. 단일 답변 점수보다 여러 턴의 대화와 실행 흔적을 보겠다는 방향이야.

예를 들어 사내 고객지원 에이전트를 만든다면 모델 선택에서 끝나지 않아. ADK로 대화 흐름을 짜고, Agent Runtime에 올리고, 고객 기록을 Agent Sessions와 연결하고, Agent Identity로 어떤 에이전트가 어떤 작업을 했는지 남겨야 해. 또 Agent Evaluation과 Observability에서 실패한 대화 흐름을 추적해야 운영자가 손볼 곳을 찾을 수 있어.

다른 장면은 사내 데이터 분석 에이전트야. BigQuery나 Pub/Sub 같은 Google Cloud 자원과 연결해 배치나 이벤트 기반 작업을 돌릴 수 있고, 필요하면 MCP 서버나 외부 도구 연결까지 같이 검토하게 돼. 이때 중요한 건 모델의 컨텍스트 윈도우 숫자만이 아니라, 어떤 데이터에 접근하고 누가 승인하고 어떤 로그가 남는지야.

왜 중요한가

이 이름이 중요한 이유는 Vertex AI가 더 이상 독립된 모델 운영 플랫폼처럼만 읽히지 않기 때문이야. Google Cloud Blog는 앞으로 Vertex AI 서비스와 로드맵 변화가 Agent Platform을 통해 제공된다고 적어. 그래서 “Vertex AI에서 한다”는 말은 점점 “제미니 엔터프라이즈 에이전트 플랫폼 안에서 운영한다”는 말에 가까워질 수 있어.

조직 입장에서는 Gemini API를 한 번 호출하는 일과 에이전트 플릿을 운영하는 일이 완전히 달라. API 호출은 모델명, 입력, 출력, 요금이 중심이야. Agent Platform 도입은 에이전트 신원, 레지스트리, 게이트웨이, 감사 로그, 장애 추적, 장기 메모리, 실행 환경까지 같이 설계해야 해. Enterprise라는 말이 붙는 이유도 여기에 있어.

또 하나는 멀티모델 선택이야. 플랫폼이 Gemini만 쓰는 길은 아니야. 공식 발표는 Model Garden에서 200개가 넘는 모델을 제공하고, Google 모델과 오픈 모델, Anthropic Claude 계열을 함께 예로 든다. 그래서 이 플랫폼을 “Gemini 성능표”로 보면 좁고, “Google Cloud 안에서 에이전트를 만들고 통제하는 운영 콘솔”로 보면 실무 판단이 맞아.

주의해서 볼 점

먼저 category를 헷갈리지 않는 게 좋아. 이 항목은 모델 계열이 아니라 tool이야. Gemini 3.1 Pro의 1 million token context 같은 숫자는 모델 문서에서 봐야 하고, Agent Platform 페이지에서는 어떤 모델을 고르고 운영에 올릴지, 어떤 보안과 관측 기능을 같이 쓰는지를 봐야 해.

두 번째는 기존 Vertex AI 사용자가 바로 같은 운영 경험을 얻는다고 단정하지 않는 거야. Google Cloud 계정, IAM, 리전, 청구, 로그 보관, 네트워크 정책은 여전히 프로젝트마다 다르게 남아. “전환”이라는 말은 제품 로드맵의 방향이지, 기존 운영 검토가 사라진다는 뜻이 아니야.

세 번째는 벤더 의존도야. Alibaba Cloud Model Studio처럼 다른 클라우드 모델 플랫폼도 모델 선택과 API, 에이전트 앱을 묶으려 해. Gemini Enterprise Agent Platform과 비교하면 이쪽은 Google Cloud의 데이터, 보안, Workspace, Vertex AI 자산과 강하게 맞물린다. 반대로 여러 클라우드와 사내 시스템을 섞어 쓰는 팀은 Agent Gateway, MCP, 외부 도구 연결, 로그 반출 범위를 먼저 확인해야 해.