Gemini Enterprise Agent Platform은 Google Cloud가 Vertex AI를 기업용 AI 에이전트 개발·운영 플랫폼으로 확장한 새 흐름이다. Google Cloud는 2026년 4월 23일 공식 블로그에서 이 플랫폼을 발표하며, 앞으로 Vertex AI의 서비스와 로드맵 진화를 Agent Platform 중심으로 제공하겠다고 설명했다.
이름부터 살짝 숨이 찬다. Gemini도 있고, Enterprise도 있고, Agent도 있고, Platform도 있다. 제품명이 회의실에서 길어지다가 그대로 출시된 느낌이다.
초보자가 헷갈리는 이유는 이름이 길어서만은 아니다. 이게 새 모델인지, 챗봇인지, 개발 도구인지, 클라우드 상품인지 한 번에 안 잡히기 때문이다. 그래서 이번 글은 어려운 클라우드 용어를 잠깐 내려놓고, “구글이 뭘 만들겠다는 건지”부터 쉽게 잡아보는 글이다.
먼저 이렇게 보면 된다. Gemini Enterprise Agent Platform은 AI 에이전트를 만드는 공장, 실행하는 작업장, 감시하는 관제실, 고치는 정비소를 한 건물에 넣겠다는 구글 클라우드의 계획이다.
한 문장으로 잡기
AI 에이전트는 단순히 질문에 답하는 챗봇보다 한 단계 더 나간 개념이다. 사용자의 목표를 받고, 필요한 도구를 부르고, 여러 단계를 실행하고, 경우에 따라 며칠 동안 상태를 유지하면서 일을 이어가는 소프트웨어에 가깝다.
예를 들어 “이번 달 잠재 고객 목록을 정리하고, 우선순위를 매기고, 이메일 초안까지 만들어줘”라고 했다고 해보자. 일반 챗봇은 설명이나 초안을 줄 수 있다. 에이전트는 CRM을 보고, 고객 데이터를 읽고, 규칙에 따라 분류하고, 이메일 도구까지 연결해서 작업 흐름을 이어갈 수 있다.
문제는 여기서부터다. 에이전트가 실제 회사 데이터와 도구에 접근하면 갑자기 질문이 많아진다. 이 에이전트는 누구 권한으로 실행되는가. 어떤 도구까지 써도 되는가. 중간에 이상한 행동을 하면 누가 막는가. 실패하면 로그는 어디에 남는가.
Gemini Enterprise Agent Platform은 바로 이 질문들을 한꺼번에 다루려는 플랫폼이다. 모델만 던져주는 게 아니라, 기업이 에이전트를 만들고 운영할 때 필요한 기본 장비를 묶어주겠다는 쪽에 가깝다.
Vertex AI는 어떻게 바뀌나
Vertex AI는 원래 Google Cloud에서 머신러닝 모델을 만들고, 학습하고, 배포하고, 관리하는 대표 플랫폼이었다. AI 개발자가 모델을 고르고, 데이터를 연결하고, API로 서비스에 붙일 때 자주 등장하던 이름이다.
이번 발표에서 중요한 문장은 “Vertex AI의 진화가 Agent Platform을 통해 제공된다”는 부분이다. 쉽게 말하면 구글이 Vertex AI를 버린다는 뜻이 아니라, Vertex AI 위에 에이전트 시대에 필요한 운영 층을 더 크게 얹겠다는 뜻에 가깝다.
비유하면 이렇다. 예전 Vertex AI가 좋은 엔진과 부품을 제공하는 자동차 공장에 가까웠다면, Gemini Enterprise Agent Platform은 그 차들이 실제 도로에서 안전하게 달리고, 정비받고, 관제되는 전체 교통 시스템을 만들겠다는 이야기다.
그래서 초보자는 “Gemini Enterprise Agent Platform이 Vertex AI를 대체하나?”보다 “Vertex AI가 에이전트 운영 중심으로 확장되는구나”라고 이해하면 덜 헷갈린다. 이름표는 바뀌어도 핵심 방향은 모델 개발에서 에이전트 운영으로 넓어지는 것이다.
들어있는 기능을 쉽게 풀면
Google Cloud는 이 플랫폼을 Build, Scale, Govern, Optimize 네 흐름으로 설명한다. 영어가 예쁘긴 한데, 초보자 입장에서는 “만들기, 굴리기, 통제하기, 개선하기”로 바꿔 읽으면 된다.
Build는 에이전트를 만드는 단계다. Agent Studio는 비교적 낮은 코드로 시작하는 시각적 도구에 가깝고, ADK는 더 복잡한 로직을 코드로 다루는 개발 키트에 가깝다. 처음에는 Studio로 틀을 잡고, 복잡해지면 ADK로 내보내 이어 개발하는 흐름을 구글은 강조한다.
Scale은 에이전트를 실제로 굴리는 단계다. Agent Runtime은 에이전트가 빠르게 시작하고, 며칠짜리 작업도 상태를 유지하면서 이어갈 수 있게 하는 실행 환경이다. 단발성 질문 답변이 아니라 장기 업무 흐름을 다루려면 이 부분이 중요해진다.
Memory Bank는 에이전트의 기억에 해당한다. 매번 처음 만난 사람처럼 행동하는 AI는 편하지 않다. 사용자의 선호, 과거 대화, 업무 맥락을 기억해야 더 자연스럽게 이어갈 수 있다. 다만 기억은 편한 만큼 위험할 수 있어서 관리와 삭제, 정확성도 같이 중요해진다.
Govern은 통제와 보안이다. Agent Identity는 에이전트마다 신분증을 주는 개념이고, Agent Registry는 승인된 에이전트와 도구 목록을 관리하는 장부에 가깝다. Agent Gateway는 에이전트가 도구를 부를 때 지나가는 검문소처럼 생각하면 된다.
Optimize는 개선 단계다. Agent Simulation, Evaluation, Observability는 배포 전 테스트하고, 실제 사용 중 성능을 평가하고, 에이전트가 어떤 판단 흐름으로 움직였는지 추적하는 기능이다. 사람으로 치면 연습 경기, 성적표, CCTV가 한 세트로 붙는 셈이다.
왜 기업은 이런 플랫폼이 필요할까
AI 에이전트가 혼자 메모를 요약하는 수준이면 큰 플랫폼이 필요 없을 수 있다. 그냥 챗봇 하나 열고 붙여넣어도 된다. 문제는 에이전트가 회사 시스템 안으로 들어올 때다.
회사 업무에는 권한이 있다. 영업 데이터, 고객 정보, 결제 정보, 내부 문서, 코드 저장소, 배포 시스템은 아무 자동화나 마음대로 만지면 안 된다. 아무리 똑똑한 AI라도 권한 경계가 없으면 생산성 도구가 아니라 사고 예약 버튼이 된다.
예를 들어 에이전트가 브라우저를 조작하거나 코드를 실행할 수 있다고 해보자. 편하다. 정말 편하다. 그런데 그 에이전트가 잘못된 명령을 실행하거나, 악성 프롬프트에 속거나, 허용되지 않은 외부 주소로 접속하면 일이 커진다.
그래서 구글은 Agent Sandbox, Agent Anomaly Detection, Agent Threat Detection 같은 보안 기능을 함께 강조한다. 에이전트가 만든 코드를 격리된 환경에서 실행하고, 이상한 추론이나 위험한 활동을 감지하겠다는 방향이다.
초보자 버전으로 줄이면 이렇다. 에이전트가 똑똑해질수록 “뭘 할 수 있나”보다 “어디까지 하게 둘 건가”가 중요해진다. 이것이 Gemini Enterprise Agent Platform이 단순 AI 모델 발표가 아니라 운영 플랫폼 발표에 가까운 이유다.
모델 선택도 넓어진다
Google Cloud 발표에서 또 하나 눈에 띄는 부분은 Model Garden이다. 구글은 Model Garden을 통해 200개 이상의 모델에 접근할 수 있고, 자체 모델뿐 아니라 Anthropic Claude 계열 같은 서드파티 모델도 지원한다고 설명했다.
이 말은 기업 입장에서 꽤 중요하다. 모든 작업에 같은 모델을 쓸 필요가 없기 때문이다. 빠른 분류 작업에는 가벼운 모델을 쓰고, 복잡한 추론에는 더 강한 모델을 쓰고, 이미지나 오디오가 필요한 작업에는 다른 모델을 고를 수 있다.
초보자에게는 “AI 모델 백화점” 정도로 이해하면 쉽다. 단, 백화점이 있다고 해서 무조건 쇼핑을 잘하는 것은 아니다. 어떤 업무에 어떤 모델이 맞는지 고르는 기준이 필요하고, 비용·속도·정확도·보안 요구사항을 함께 봐야 한다.
그래서 Agent Platform에서 모델 선택은 출발점일 뿐이다. 진짜 승부는 선택한 모델을 어떤 도구와 연결하고, 어떤 권한으로 실행하며, 어떤 평가 기준으로 개선할지에 있다.
작은 팀이나 개인에게도 의미가 있을까
당장 Google Cloud 엔터프라이즈 플랫폼을 도입하지 않을 사람에게도 이 발표는 의미가 있다. 왜냐하면 구글이 큰 회사용으로 설명한 문제가 작은 팀과 개인 자동화에도 똑같이 축소판으로 나타나기 때문이다.
개인도 AI 에이전트를 여러 개 붙이기 시작하면 비슷한 일이 생긴다. 글 요약 에이전트, 블로그 작성 에이전트, 코드 수정 에이전트, 일정 정리 에이전트가 생긴다. 처음에는 편한데, 어느 순간 “얘가 뭘 읽고, 어디에 쓰고, 무슨 권한으로 실행하는지”가 흐려진다.
작은 팀이라면 더 그렇다. Slack, GitHub, Notion, Google Drive, 내부 API, 배포 도구가 붙기 시작하면 에이전트는 단순한 보조자가 아니라 작은 실행 주체가 된다. 이때 필요한 것은 대단한 클라우드 계약서보다 먼저, 에이전트 목록과 권한표다.
자료 기준으로 내가 운영 기준을 잡는다면 세 가지부터 보겠다. 첫째, 에이전트마다 목적과 소유자를 적는다. 둘째, 사용할 수 있는 도구와 금지 도구를 나눈다. 셋째, 자동 실행 결과와 실패 로그를 남긴다.
이 세 가지는 Google Cloud 제품을 쓰지 않아도 바로 적용할 수 있다. Agent Identity는 에이전트 이름표로, Registry는 에이전트 목록표로, Gateway는 실행 전 승인 규칙으로 작게 시작하면 된다.
초보자가 기억할 5가지
첫째, Gemini Enterprise Agent Platform은 새 챗봇 이름이 아니다. 기업이 AI 에이전트를 만들고 운영하는 전체 플랫폼에 가깝다.
둘째, Vertex AI의 방향이 모델 개발 중심에서 에이전트 운영 중심으로 확장되고 있다. 모델을 잘 고르는 일만큼, 모델이 실제 업무에서 안전하게 움직이게 하는 일이 중요해진 것이다.
셋째, Agent Studio와 ADK는 에이전트를 만드는 쪽이다. Studio는 시작을 쉽게 만들고, ADK는 복잡한 로직을 개발자가 더 세밀하게 다룰 수 있게 한다.
넷째, Runtime과 Memory Bank는 에이전트가 일을 이어가게 하는 쪽이다. 하루짜리 답변이 아니라 며칠짜리 업무 흐름, 사용자 맥락, 장기 기억을 다루려면 이 부분이 중요하다.
다섯째, Identity, Registry, Gateway, Sandbox, Evaluation은 에이전트를 통제하고 검증하는 쪽이다. 에이전트가 많아질수록 프롬프트보다 권한표와 로그가 더 중요해진다.
초보자가 피할 오해 5가지
첫 번째 오해는 “Gemini가 들어갔으니 그냥 새 모델 발표겠지”다. 이번 발표의 핵심은 특정 모델 하나가 아니라, 모델을 업무 도구와 연결해 에이전트로 운영하는 전체 구조다. 모델 성능 뉴스처럼 읽으면 절반만 본 것이다.
두 번째 오해는 “Agent Studio가 있으니 개발자가 필요 없겠네”다. 간단한 에이전트는 저코드로 시작할 수 있어도, 회사 데이터와 내부 API를 안전하게 연결하려면 결국 권한, 로그, 장애 대응, 테스트 기준이 필요하다. 버튼은 시작을 쉽게 만들지만, 운영 책임을 없애주진 않는다.
세 번째 오해는 “Memory Bank가 있으면 무조건 편하겠네”다. 기억은 편하지만, 잘못된 기억은 조용히 답변을 오염시킨다. 어떤 맥락을 저장하고, 언제 지우고, 민감한 정보는 어디까지 허용할지 정해야 한다.
네 번째 오해는 “200개 모델을 쓸 수 있으면 선택지가 많아서 무조건 좋다”다. 선택지가 많으면 비용·속도·보안·정확도 기준도 같이 필요하다. 기준 없이 모델만 늘리면 AI 백화점에서 길을 잃는다. 쇼핑백은 많은데 집에 와보니 양말만 열 켤레인 상황이 된다.
다섯 번째 오해는 “우리 팀은 작으니 이런 건 상관없다”다. 작은 팀일수록 오히려 기본 원칙이 중요하다. 에이전트가 하나일 때는 감으로 굴러가지만, 셋이 되는 순간 누가 무엇을 읽고 어디에 쓰는지 헷갈리기 시작한다.
지금 당장 뭘 하면 좋을까
개발자라면 ADK와 Agent Runtime을 먼저 보면 된다. 특히 여러 에이전트를 나눠서 쓰거나, 긴 작업을 상태 유지하며 실행해야 하는 경우에는 실행 환경과 오케스트레이션 개념을 이해하는 게 도움이 된다.
기획자나 PM이라면 Agent Studio와 Agent Garden 같은 저코드·템플릿 흐름을 보면 좋다. 직접 코드를 쓰지 않아도 어떤 업무가 에이전트화될 수 있는지 감을 잡을 수 있기 때문이다.
보안이나 운영 담당자라면 Agent Identity, Registry, Gateway, Sandbox 쪽을 먼저 봐야 한다. 에이전트가 실제 도구를 호출하는 순간부터는 “잘 답하나”보다 “안전하게 실행되나”가 먼저다.
개인 사용자라면 제품명보다 원칙을 가져오면 된다. 내 자동화에도 이름표, 권한표, 로그, 실패 시 중단 규칙이 있는지 보자. 이것만 해도 에이전트 자동화의 사고 확률을 꽤 줄일 수 있다.
마무리
Gemini Enterprise Agent Platform 발표를 한 줄로 줄이면 “AI 에이전트는 이제 데모가 아니라 운영 대상이다”에 가깝다. 모델이 좋아지는 것도 중요하지만, 기업 현장에서는 그 모델이 어떤 권한으로 어떤 일을 하고, 실패하면 어떻게 복구되는지가 더 중요해진다.
초보자라면 모든 기능 이름을 외울 필요는 없다. 일단 네 단어만 잡으면 된다. 만들기, 굴리기, 통제하기, 개선하기. Google Cloud는 이 네 단계를 Gemini Enterprise Agent Platform이라는 이름 아래 묶으려는 것이다.
앞으로 AI 에이전트 시장은 “어느 모델이 제일 똑똑한가”만으로 갈리지 않을 가능성이 크다. 누가 더 안전하게 연결하고, 오래 실행하고, 잘 관찰하고, 실패를 빠르게 고치는지가 중요해진다.
그래서 이 발표는 클라우드 개발자만 볼 뉴스가 아니다. AI 자동화를 쓰는 사람이라면 누구나 한 번쯤 봐야 할 신호다. 에이전트가 많아지는 시대에는 똑똑함보다 운영 질서가 더 비싼 자산이 된다. 이름은 길지만, 메시지는 꽤 현실적이다.
FAQ
Q. Gemini Enterprise Agent Platform은 Gemini 모델이랑 같은 건가?
아니다. Gemini 모델은 AI 모델이고, Gemini Enterprise Agent Platform은 그 모델과 여러 도구, 실행 환경, 보안, 평가 기능을 묶어 에이전트를 만들고 운영하는 플랫폼에 가깝다.
Q. Vertex AI는 없어지는 건가?
공식 발표 기준으로는 Vertex AI의 모델 선택, 모델 빌딩, 에이전트 빌딩 기능이 Agent Platform 안에서 이어지고 확장되는 흐름에 가깝다. 초보자는 “Vertex AI가 에이전트 운영 플랫폼 쪽으로 커진다”고 이해하면 된다.
Q. 코딩을 못 해도 쓸 수 있나?
Agent Studio 같은 저코드 도구는 비개발자도 시작할 수 있게 설계된 쪽이다. 다만 복잡한 업무 로직, 내부 시스템 연동, 보안 정책까지 다루려면 ADK와 클라우드 운영 지식이 필요할 수 있다.
Q. 작은 팀도 꼭 써야 하나?
꼭 도입해야 한다기보다, 이 발표에서 나온 원칙을 참고하면 좋다. 에이전트 목록, 권한표, 승인 규칙, 실행 로그부터 작게 만들면 클라우드 플랫폼을 바로 쓰지 않아도 운영 수준을 올릴 수 있다.
Q. OpenAI Agents SDK나 Microsoft Foundry와 비교하면 뭐가 다른가?
세부 기능과 생태계는 다르지만 큰 방향은 비슷하다. 단순 모델 호출을 넘어서 에이전트 개발, 도구 연결, 실행, 평가, 보안, 관측성을 한 흐름으로 묶으려는 경쟁이다. Google Cloud는 Vertex AI와 Google Cloud 보안·운영 기능을 기반으로 엔터프라이즈 쪽을 강하게 강조한다.
출처
- GeekNews – Gemini Enterprise Agent Platform
- Google Cloud Blog – Introducing Gemini Enterprise Agent Platform