Google Cloud, Gemini Enterprise Agent Platform 공개… 그러나 진짜 시험대는 제어

Google Cloud는 확장된 Agent Platform을 선보인 지 불과 3개월 만인 7월 29일, 여러 Gemini Enterprise 기능을 정식 출시했다. 이번 공개로 영구 메모리, 7일 실행, 에이전트 ID, 거버넌스, 평가, 관측성이 더 폭넓은 프로덕션 환경에서 사용 가능해졌다. 긴 자율성은 더 큰 가치를 만들지만, 동시에 소프트웨어가 중대한 실수를 저지를 시간과 권한도 더 많이 부여한다는 긴장이 분명하다.

이는 단순히 에이전트를 구축하기 위한 또 하나의 도구 모음이 아니다. Google은 AI 모델과 그것이 변경할 수 있는 엔터프라이즈 시스템 사이의 운영 계층을 제공하려 하고 있다. 이 계층은 며칠간 이어지는 워크플로 전반에서 컨텍스트를 유지하고, 권한을 할당하며, 작업을 기록하고, 정책을 집행하고, 결과를 측정해야 한다.

Amazon과 Microsoft도 Bedrock AgentCore 및 Microsoft Foundry를 통해 같은 제어 지점을 노리고 있다. 경쟁의 중심은 더 이상 어느 기업이 가장 뛰어난 모델을 제공하느냐에만 있지 않다. 보안팀, 개발자, 사업 책임자가 승인할 수 있을 만큼 자율 작업을 관리 가능하게 만드는 클라우드가 어디인지가 갈수록 중요해지고 있다.

Google Cloud, 에이전트 프리뷰를 프로덕션 플랫폼으로 전환

이번 공개는 Gemini Enterprise Agent Platform을 야심 찬 프레임워크에서 기업이 배포하고 거버넌스할 수 있는 운영 시스템으로 옮겨 놓는다.

Google은 4월 22일 Vertex AI의 진화 형태로 현재 플랫폼을 소개했다. 회사가 밝힌 목적은 모델 접근, 에이전트 개발, 배포, 보안, 최적화를 하나의 환경에 결합하는 것이었다. 또한 향후 Vertex AI 서비스와 로드맵 업데이트는 별도 제품군이 아니라 Agent Platform을 통해 제공될 것이라고 밝혔다.

3개월 뒤 Google은 7가지 핵심 기능을 정식 출시했다. Agent Memory Bank는 세션 간 구조화된 컨텍스트를 유지한다. Agent Runtime은 최대 7일간 지속되는 비동기 작업을 지원한다. Agent Identity는 접근 제어와 감사를 위해 각 에이전트에 전용 ID를 부여한다.

Agent Gateway, Agent Registry, Agent Evaluation, Agent Observability는 제어 계층을 완성한다. 이 기능들은 함께 도구 연결을 관리하고, 배포된 에이전트를 목록화하며, 동작을 측정하고, 실행을 추적한다. Google은 에이전트를 안전하게 확장하는 데 초점을 맞춘 Agent Platform 업데이트에서 이러한 기능을 설명했다.

가장 눈에 띄는 변화는 7일 런타임이다. 일반적인 챗봇은 세션 안에서 응답한 뒤 다음 요청을 기다린다. 장기 실행 에이전트는 며칠에 걸쳐 영업 시퀀스를 관리하거나, 공급망 상황을 모니터링하거나, 온보딩 프로세스를 조율할 수 있다.

이러한 지속성은 엔지니어링 문제를 바꾼다. 에이전트에는 내구성 있는 상태, 복구 로직, 권한 경계, 그리고 각 작업의 기록이 필요하다. 사용자가 애플리케이션을 닫은 뒤에도 동일한 프로세스가 계속 작동한다면, 일시적인 모델 오류는 더 심각해진다.

Memory Bank는 선택한 사실을 구조화된 스키마로 추출해 이 과제의 일부를 해결한다. 에이전트가 대화 기록 전체에서 모든 것을 재구성하지 않아도 선호도, 계정 이력, 이전 결정을 유지할 수 있다. Google은 이 설계가 장기 실행 작업 전반에서 더 낮은 지연 시간의 개인화를 지원한다고 설명한다.

저장된 메모리와 원시 대화 기록의 차이는 중요하다. 대화 기록에는 관련 없는 세부 사항과 오래된 지시를 포함해 발언된 모든 내용이 담긴다. 구조화된 메모리는 계속 유용할 것으로 예상되는 정보를 선택한다. 하지만 이 선택 과정은 시스템이 잘못된 추론을 저장할 수 있으므로 새로운 실패 지점도 만든다.

따라서 Google은 런타임과 메모리를 한 쌍으로 제공하고 있다. 런타임이 작업을 계속 실행하게 한다면, Memory Bank는 그 컨텍스트를 사용할 수 있게 유지한다. 두 기능 모두 단독으로 에이전트의 신뢰성을 보장하지는 않지만, 함께 사용하면 개발자는 단일 요청의 범위를 넘어서는 워크플로를 시도할 수 있다.

이번 공개는 Google 모델만으로 구축된 에이전트를 넘어 플랫폼의 범위도 넓힌다. 출시 당시 Google은 Model Garden이 200개 이상의 자체, 타사, 오픈 모델에 대한 접근을 제공한다고 밝혔다. 이는 고객이 다른 제공업체의 모델을 선택하더라도 Google이 배포와 거버넌스를 제어하려 한다는 점을 시사한다.

이 전략은 Agent Platform을 단순한 Gemini 배포 채널보다 더 중요하게 만든다. Google은 이를 이기종 에이전트 플릿을 위한 인프라로 자리매김하고 있다. 조직이 이러한 플릿 전반의 공통 제어 수단으로 ID, 레지스트리, 게이트웨이, 모니터링 서비스를 채택할 때 플랫폼은 성공한다.

Google Cloud가 에이전트 제어를 두고 경쟁하는 이유

엔터프라이즈 구매자는 모델 가용성보다 에이전트 작업을 둘러싼 운영 위험에 더 크게 제약받고 있다.

프로토타입 에이전트는 제한된 데이터세트와 몇 개의 도구로 작동할 수 있다. 프로덕션 에이전트는 고객 기록, 내부 애플리케이션, 자격 증명, 승인 체계, 컴플라이언스 요구 사항을 다룬다. 연결이 하나씩 추가될 때마다 에이전트의 유용성과 잠재적 피해 범위도 함께 커진다.

Google Cloud는 에이전트를 위해 특별히 설계된 ID 모델로 대응하고 있다. Agent Identity는 단순히 재사용한 서비스 계정이 아니라 네이티브 ID 및 액세스 관리 유형이다. Google은 이것이 액세스를 런타임에 연결하고, 최소 권한을 적용하며, ID 수명 주기를 관리하고, 부인 방지가 가능한 감사 기록을 생성한다고 설명한다.

최소 권한이란 정의된 작업에 필요한 접근 권한만 부여하는 것을 뜻한다. 개념 자체는 익숙하지만, 에이전트는 구현을 더 어렵게 만든다. 실행 중 계획이 바뀔 수 있고, 하나의 광범위한 목표를 추구하는 동안 여러 도구를 호출할 수 있기 때문이다.

기존 서비스 계정은 애플리케이션이 변경되거나 사라진 뒤에도 활성 상태로 남는 경우가 많다. 팀이 통합을 추가하면서 권한도 누적될 수 있다. Best Buy는 Google 발표에서 고아 계정, 불분명한 소유권, 확대되는 권한을 반복적인 문제로 설명했다.

전용 에이전트 ID는 더 명확한 책임 단위를 만든다. 관리자는 어떤 에이전트가 작업했는지, 무엇에 접근했는지, 누가 소유하는지, 어떤 런타임이 해당 작업을 승인했는지를 확인할 수 있다. 에이전트가 매 단계마다 사람의 승인을 받지 않고 결정을 내릴 때 이러한 가시성은 필수적이다.

Agent Gateway는 다음 경계를 담당한다. 에이전트, 모델, 도구 간 상호작용을 중앙화한다. 관리자는 ID 조건과 자연어 규칙을 적용할 수 있으며, Model Armor는 프롬프트 인젝션, 도구 오염, 데이터 유출을 감지하기 위해 트래픽을 검사한다.

프롬프트 인젝션은 악의적이거나 신뢰할 수 없는 콘텐츠가 에이전트의 지시를 조작하는 경우를 말한다. 도구 오염은 손상된 도구 설명 또는 응답이 에이전트의 행동을 바꾸는 것을 의미한다. 에이전트가 파일에 접근하고, 메시지를 보내고, 기록을 업데이트하거나, 소프트웨어를 수정할 수 있을 때 두 공격 모두 더 중대한 결과를 낳는다.

Agent Registry는 조직 확산이라는 다른 문제를 다룬다. 회사 전반의 에이전트, 서버, 연결을 위한 카탈로그를 제공한다. 팀은 기존 구성 요소를 발견할 수 있고, 관리자는 소유권을 파악하고 배포를 모니터링할 수 있다.

레지스트리가 중복되거나 안전하지 않은 에이전트를 자동으로 막지는 않는다. 즉각적인 기여는 가시성이다. 중앙 팀이 존재 자체를 모르는 소프트웨어에는 일관된 제어를 적용할 수 없다.

Google의 시점은 파일럿 프로젝트와 거버넌스가 적용된 프로덕션 시스템 사이의 거리가 커지고 있음을 반영한다. 많은 팀이 모델, 프롬프트, 여러 API를 조합해 유용한 에이전트를 만들 수 있다. 하지만 ID, 메모리, 평가, 사고 조사를 위한 공통 시스템을 갖춘 곳은 그보다 적다.

이 격차는 고객이 기존 인프라와 통합되는 운영 제어를 선호하기 때문에 클라우드 제공업체에 압력을 가한다. ID 정책, 로깅 시스템, 네트워크 제어, 데이터 서비스는 이미 클라우드 환경에 존재한다. 에이전트 플랫폼은 이러한 기반을 재사용할 수 있을 때 더 매력적이 된다.

같은 역학은 독립적인 에이전트 프레임워크에도 압력을 가한다. 오픈 프레임워크는 개발자에게 이식성과 유연성을 제공할 수 있지만, 엔터프라이즈 팀에는 여전히 런타임과 거버넌스 계층이 필요하다. Google은 오픈 표준과 Agent Development Kit를 지원하지만, 관리형 운영 계층은 자사 클라우드의 더 깊은 사용을 유도한다.

따라서 전략적 보상은 모델 사용량보다 크다. 승리하는 플랫폼은 기업이 에이전트를 등록하고, 권한을 부여하고, 추적을 검사하고, 성능을 판단하는 기본 장소가 될 수 있다. 이러한 제어가 워크로드를 둘러싸면, 이를 옮기는 일은 더 복잡해진다.

메모리, ID, 평가를 연결하는 메커니즘

Google의 핵심 베팅은 실행, 권한, 컨텍스트, 측정이 하나의 제어 플레인을 공유할 때 자율 에이전트를 관리할 수 있다는 것이다.

Agent Runtime은 실행 환경을 제공한다. Memory Bank는 선택된 컨텍스트를 유지한다. Agent Identity는 시스템이 행위자로 간주하는 주체를 결정한다. Agent Gateway는 모델과 도구에 대한 접근을 통제하며, Registry는 무엇이 배포됐는지 기록한다.

Evaluation과 Observability는 피드백 고리를 완성한다. Observability는 추론 추적, 도구 사용, 지연 시간, 실행 동작을 포함해 에이전트가 수행한 작업을 기록한다. Evaluation은 결과가 예상된 기준을 충족했는지 묻는다.

Google은 두 기능을 하나의 엔진에 결합한다. 개발자는 구축 단계와 배포 이후에 같은 측정 로직을 사용할 수 있다. 회사는 평가 옵션에 사전 정의된 지표, 맞춤형 Python 함수, 모델 기반 평가자, Google DeepMind와 함께 개발한 적응형 루브릭이 포함된다고 설명한다.

이러한 연속성은 오프라인 벤치마크가 실제 운영 조건을 제대로 나타내지 못하는 경우가 많기 때문에 중요하다. 테스트 데이터세트는 모든 고객 요청, 변화하는 도구 응답, 권한 상태를 예측할 수 없다. 온라인 평가는 출시 후 성능 저하와 행동 드리프트를 식별할 수 있다.

행동 드리프트란 에이전트의 명시된 목적이 그대로여도 결과가 시간이 지남에 따라 변하는 현상을 의미한다. 모델 업데이트, 수정된 프롬프트, 새로운 데이터 소스, 변경된 도구가 이런 변화를 일으킬 수 있다. 지속적인 모니터링은 팀이 변화가 언제 시작됐는지 찾는 데 도움이 된다.

그러나 평가는 주관적 판단을 없애지 못한다. 모델 기반 평가자는 평가를 수행하는 모델의 편향이나 약점을 물려받을 수 있다. 맞춤형 지표는 중요한 비즈니스 결과를 놓친 채, 측정하기 쉬운 대리 지표에 맞춰 최적화될 수 있다.

프로덕션 팀에는 여전히 명시적인 성공 기준이 필요하다. 고객 지원 에이전트는 해결 품질, 정책 준수, 에스컬레이션 정확도, 고객 노력으로 측정될 수 있다. 응답 속도에만 초점을 맞추면 자신감은 있지만 틀린 답변에 보상이 돌아갈 수 있다.

통합 아키텍처는 평가가 운영 조치를 촉발할 수 있을 때 더 유용해진다. 점수가 하락하면 에이전트 권한을 줄이거나, 작업을 사람에게 전달하거나, 워크플로를 중단할 수 있다. Google의 발표는 모니터링 기능을 설명하지만, 고객은 여전히 적절한 개입 정책을 설계해야 한다.

AT&T는 구체적인 메모리 사례를 제공한다. 이 회사는 자사의 영업 에이전트가 Memory Bank를 사용해 이전 고객 상호작용의 사실을 종합함으로써, 중단 후에도 대화를 재개할 수 있다고 밝혔다. 또한 앱, 음성, 웹 채널 전반의 연속성을 구현하는 방향으로 작업하고 있다.

이 사례는 이점과 위험을 모두 보여준다. 기억된 컨텍스트는 고객이 정보를 반복해서 제공하지 않게 할 수 있다. 그러나 부정확하거나 지나치게 광범위한 메모리는 채널 전반으로 전파돼 이후의 결정에 영향을 줄 수도 있다.

Commerzbank는 거버넌스 측면을 제시한다. 이 은행은 검색 가능성, 정책 적용, 액세스 관리, 관측성, 감사 기능을 위해 Agent Registry와 Agent Gateway를 평가 중이라고 밝혔다. 이 같은 관심은 중앙집중식 계층이 규제 산업의 조직에 왜 매력적인지 보여준다.

WellSky는 중앙집중식 레지스트리를 사용해 에이전트를 수명 주기 전반에 걸쳐 목록화하고, 버전 관리하며, 운영한다고 설명한다. 회사는 이 카탈로그를 컴플라이언스 정책 및 프로덕션 승인과 연계한다. 이는 소비자 대상 AI 기능이라기보다 소프트웨어 자산 관리에 더 가깝다.

CodeMender는 같은 메커니즘을 소프트웨어 보안으로 확장한다. Google은 이를 코드 취약점을 찾아 검증하고 수정안을 제시하는 관리형 에이전트로 설명한다. 핵심 추론은 클라우드에서 실행되는 반면, 컴파일, 테스트, 익스플로잇 시뮬레이션은 고객이 관리하는 샌드박스나 격리된 가상 머신에서 수행된다.

CodeMender design은 사람의 승인 단계를 유지한다. 개발자는 제안된 변경 사항을 로컬 diff 형태로 받고, 에이전트가 이를 프로덕션 리포지토리에 직접 커밋하지는 않는다. Google은 고객 코드가 자사의 파운데이션 모델 학습에 사용되지 않는다고도 밝혔다.

이 경계는 시사하는 바가 크다. CodeMender는 분석과 패치 생성을 자동화하지만 개발자의 책임을 없애지는 않는다. 잘못된 변경이 새로운 취약점을 만들거나 프로덕션을 방해할 수 있는 지점에서 사람의 검토 단계가 자율성을 제한한다.

지식 집약형 에이전트에도 비슷한 경계가 필요하다. 팀은 검색 가능한 knowledge base를 사용해 내부 근거를 정리할 수 있지만, 검색 기능만으로 에이전트의 행동 권한이 부여되지는 않는다. 맥락, 권한, 검증은 여전히 별개의 설계 결정이다.

AWS와 Microsoft도 같은 제어 계층을 구축하고 있다

Google의 기능군은 독보적인 카테고리 때문이 아니라 통합 방식에서 차별화된다. 주요 클라우드 경쟁사들도 이제 유사한 에이전트 인프라를 제공하기 때문이다.

Amazon Bedrock AgentCore는 에이전트의 로직과 관리형 인프라를 분리한다. Runtime은 격리, 확장, 세션, 인증 게이트, 관측성 연결 기능을 제공한다. 개발자는 오케스트레이션 루프의 제어권을 유지하고 Memory, Gateway, Identity 등 다른 서비스와 연결할 수 있다.

AgentCore runtime은 서로 다른 프레임워크로 작성된 코드를 호스팅할 수 있다. 이 방식은 단일 에이전트 프레임워크를 채택하지 않으면서 관리형 인프라를 원하는 팀에 매력적이다. 또한 Amazon의 경쟁 대응을 Google 플랫폼과 직접 비교할 수 있게 한다.

AWS는 자동화된 워크로드를 위한 특화된 ID 및 자격 증명 서비스를 제공한다. identity documentation에 따르면 AgentCore Identity는 인증, 권한 부여, 서드파티 자격 증명, 감사 추적을 지원한다. 워크로드 ID는 기존 ID 패턴을 따르면서 에이전트 전용 속성을 추가한다.

Microsoft Foundry Agent Service 역시 런타임, 오케스트레이션, ID, 안전성, 관측성을 결합한다. 관리형 런타임은 세션을 격리할 수 있으며, Microsoft Entra는 ID 및 역할 기반 액세스 제어를 제공한다. Application Insights는 추적과 프로덕션 모니터링을 지원한다.

Microsoft는 Microsoft 365와 Copilot을 통한 추가적인 배포 우위도 갖고 있다. 이미 Entra, Teams, SharePoint, Microsoft 365를 사용하는 조직은 Foundry를 기존 업무 환경의 확장으로 볼 수 있다. Google도 Google Workspace와 클라우드 데이터 제품을 통해 유사한 주장을 펼칠 수 있다.

Microsoft는 일부 외부 호스팅 에이전트를 관측성과 평가 목적으로 등록할 수 있게 한다. external agent controls는 OpenTelemetry 추적을 사용해 Foundry가 에이전트 런타임을 호스팅하거나 호출하지 않고도 이를 모니터링할 수 있게 한다. 외부 에이전트를 위한 사람 평가와 레드팀 스캔을 포함한 여러 관련 기능은 아직 미리 보기 상태다.

따라서 세 플랫폼은 같은 논지의 서로 다른 버전을 반영한다. 엔터프라이즈 에이전트에는 관리형 실행, 지속적 컨텍스트, ID, 도구 거버넌스, 모니터링이 필요하다. 클라우드 사업자들은 이러한 서비스를 모든 에이전트 아래의 표준 기반 계층으로 만들고자 한다.

Google의 강점은 새롭게 제공되는 스택의 일관성이다. Runtime, Memory Bank, Identity, Gateway, Registry, Evaluation, Observability는 하나의 제품 범주 아래에 묶여 있다. Gemini Enterprise는 통제된 애플리케이션을 통해 직원들에게 에이전트를 배포할 수도 있다.

과제는 통합 스택이 더 나은 운영 결과를 낸다는 점을 입증하는 것이다. 유사한 기능 이름이 더 뛰어난 신뢰성을 보장하지는 않는다. 고객은 통합 품질, 정책 정밀도, 인시던트 대응, 지역별 가용성, 프레임워크 지원, 각 시스템 운영에 필요한 노력을 평가할 것이다.

이식성 역시 해결되지 않은 문제다. Google은 Agent Platform이 서드파티 모델과 개방형 표준을 지원한다고 말한다. 그러나 해당 ID 유형, 메모리 스키마, 레지스트리, 평가 엔진, 게이트웨이 정책을 중심으로 구축된 에이전트는 이전 비용이 커질 수 있다.

AWS와 Microsoft도 비슷한 종속성을 만든다. 이들의 관리형 서비스는 고객을 위해 플랫폼별 선택을 내림으로써 엔지니어링 작업을 줄인다. 이러한 상충 관계는 클라우드 컴퓨팅에서 흔하지만, 자율 에이전트는 거버넌스 데이터와 행동 이력도 제공업체에 묶이게 하기 때문에 위험도를 높인다.

따라서 기업은 모델 이식성과 운영 이식성을 구분해야 한다. 에이전트 뒤의 모델을 바꾸는 일은 설정 변경만으로 가능할 수 있다. 반면 ID 이력, 지속 메모리, 평가 기록, 게이트웨이 정책, 감사 추적을 옮기는 일은 더 큰 마이그레이션이다.

경쟁은 가장 긴 기능 목록으로 결정되지 않을 것이다. 플랫폼이 보안 검토를 통과하고 신뢰할 수 있는 프로덕션 동작을 지속하는 데 필요한 작업을 얼마나 줄이는지가 관건이다. 그러한 결과를 입증하려면 출시 발표 이상의 근거가 필요하다.

해결되지 않은 위험은 거버넌스가 속도를 따라갈 수 있는지다

에이전트 제어 기능은 알려진 위험을 줄이지만, 더 긴 런타임과 폭넓은 도구 접근 권한은 대시보드가 자동으로 해결할 수 없는 실패 모드를 만든다.

7일간 실행되는 에이전트는 오래된 데이터, 상충하는 지시, 만료된 자격 증명, 예상치 못한 도구 동작을 마주할 기회가 더 많다. 이후의 결정으로 초기 실수를 누적시킬 수도 있다. 따라서 런타임 지속 시간은 기능인 동시에 위험 증폭 요인이다.

지속 메모리도 또 다른 긴장을 만든다. 에이전트가 선호도와 과거 결정을 기억할수록 개인화는 개선된다. 하지만 팀이 시스템이 무엇을 추출해야 하는지, 해당 정보를 얼마나 오래 보관해야 하는지, 사용자가 이를 어떻게 수정할 수 있는지를 결정해야 하므로 거버넌스는 더 어려워진다.

구조화된 스키마는 규율을 제공하지만, 스키마 설계는 정책 선택이다. 영업 에이전트는 민감한 개인 정보를 보관하지 않고도 계정의 제품 관심사를 알아야 할 수 있다. 내부 에이전트는 모든 추정성 의견을 확정된 사실로 취급하지 않으면서 프로젝트 결정을 파악해야 할 수 있다.

Agent Identity는 어떤 소프트웨어 행위자가 작업을 수행했는지 보여줄 수 있다. 그렇다고 해당 작업이 왜 발생했는지까지 설명하는 것은 아니다. 완전한 조사를 위해서는 에이전트 지시문, 모델 버전, 검색된 컨텍스트, 도구 응답, 메모리 상태, 정책 결정, 평가 결과가 필요할 수 있다.

Observability는 이러한 증거의 상당 부분을 수집할 수 있다. 하지만 모든 것을 기록하면 개인정보 및 저장소 문제가 발생한다. 상세한 추론 추적에는 고객 정보, 기밀 문서, 민감한 도구 출력이 포함될 수 있다.

팀은 어떤 추적을 안전하게 보관할 수 있는지와 누가 이를 검토할 수 있는지를 결정해야 한다. 또한 법적 의무에 부합하는 보관 기간과 마스킹 정책도 필요하다. 중앙화는 이러한 선택을 적용하는 데 도움이 되지만, 선택 자체를 단순하게 만들지는 않는다.

자연어 게이트웨이 규칙도 이와 비슷한 수준의 검토가 필요하다. 정책을 표현하기는 쉬워지지만, 보안 제어는 적대적 조건에서도 예측 가능하게 작동해야 한다. 조직은 동등한 요청이 일관된 결정을 받는지, 정책 충돌이 안전하게 실패하는지를 테스트해야 한다.

Google은 Model Armor가 프롬프트 인젝션, 도구 오염, 데이터 유출 방어에 도움이 된다고 말한다. 이러한 보호 기능은 에이전트가 안전하다는 증거가 아니라 계층형 시스템 내의 제어 수단으로 다뤄야 한다. 어떤 필터도 모든 악의적 지시나 손상된 통합을 예상할 수는 없다.

Google 발표에 포함된 고객 발언은 고무적이지만 한계가 있다. 이는 독립적이고 비교 가능한 측정치가 아니라 일부 배포 사례와 평가를 설명한다. 이번 업데이트는 플랫폼 전반의 오류율, 보안 인시던트율, 운영 노력의 정량적 감소치를 제공하지 않는다.

새롭게 제공되는 제품에 이러한 정보가 없는 것은 이해할 만하다. 그러나 구매자는 일반 공급 전환을 모든 워크로드에서 성숙한 성능의 증거로 받아들이지 말아야 한다. 가장 강력한 검증은 측정 가능한 제어 아래에서 지속적으로 이루어지는 프로덕션 사용에서 나올 것이다.

영향이 큰 작업에는 여전히 사람의 검토가 필요하다. CodeMender는 개발자가 패치를 승인하도록 요구함으로써 이 원칙을 보여준다. 금융 이체, 계정 폐쇄, 프로덕션 변경, 법적으로 중요한 커뮤니케이션에도 이와 마찬가지로 명시적인 경계가 필요하다.

적절한 자율성 수준은 되돌릴 수 있는 정도에 따라 달라진다. 작업을 쉽게 검토하고 되돌릴 수 있다면 에이전트에 더 많은 자유를 부여할 수 있다. 되돌릴 수 없거나 외부에 노출되는 결정에는 더 좁은 권한, 더 강력한 평가, 신뢰할 수 있는 에스컬레이션이 필요하다.

기업에는 플랫폼 팀 외부의 소유권도 필요하다. 보안 담당자는 액세스 규칙을 정의할 수 있고, 비즈니스 책임자는 허용 가능한 결과를 정의한다. 법무 및 개인정보 보호 팀은 어떤 정보가 메모리나 로그에 들어갈 수 있는지를 결정한다.

공동 소유권이 없다면 Agent Registry는 아무도 적극적으로 관리하지 않는 시스템의 카탈로그가 될 위험이 있다. 평가 대시보드는 대응 프로세스 없이 점수만 산출할 수 있다. ID 기록은 인시던트 이후 책임 소재를 확인할 수는 있어도 인시던트를 예방하지는 못한다.

Google은 신뢰할 수 있는 제어 플레인에 필요한 구성 요소를 갖췄다. 남은 질문은 조직이 이러한 구성 요소를 강제 가능한 운영 관행으로 전환할 수 있는지다. 기술은 결정을 드러낼 수 있지만, 책임은 여전히 사람에게 있다.

Gemini Enterprise 확장 이후 주목할 점

다음 단계는 추가적인 에이전트 시연이 아니라 실제 도입, 검증된 거버넌스 결과, 경쟁사의 대응을 통해 평가될 것이다.

첫 번째 신호는 7일 워크플로를 위한 프로덕션 증거다. 고객은 완료율, 개입 빈도, 복구 동작, 여러 단계에 걸쳐 누적되는 실패 건수를 문서화해야 한다. 신뢰할 수 있는 장기 실행 성능은 Agent Runtime이 짧은 채팅 세션을 넘어선다는 Google의 주장을 강화할 것이다.

낮은 완료율은 반대 방향을 가리킬 것이다. 이는 지속적 실행이 계획 신뢰성보다 더 빠르게 도입되고 있음을 시사한다. 중요한 척도는 에이전트가 7일 동안 활성 상태를 유지하는지가 아니라, 정의된 한계 안에서 유용한 작업을 완료하는지다.

두 번째 신호는 Agent Identity와 Gateway가 감사 및 인시던트 상황에서 어떻게 작동하는지다. 기업은 권한이 계속 제한적으로 유지되는지, 자격 증명 수명 주기가 올바르게 종료되는지, 조사관이 중요한 작업을 재구성할 수 있는지에 대한 증거가 필요하다. 금융, 헬스케어, 통신 분야에서 성공적인 검토가 이루어진다면 Google의 거버넌스 주장을 뒷받침할 수 있다.

보안 팀은 성공적인 배포뿐 아니라 차단된 이벤트도 살펴봐야 한다. 유용한 공개 정보에는 차단된 인젝션 시도, 거부된 도구 호출, 정책 충돌, 비정상 동작 에이전트를 식별하는 데 걸린 시간이 포함될 수 있다. 집계 보고는 고객 세부 정보를 노출하지 않고도 구매자가 제어 기능을 비교하는 데 도움이 될 수 있다.

세 번째 신호는 AWS와 Microsoft의 대응이다. 두 회사는 이미 런타임, ID, 메모리, 게이트웨이, 관측성 서비스를 제공하고 있다. 다음 출시를 통해 Google이 의미 있는 우위를 구축했는지, 아니면 부상하는 클라우드 기준선에 단지 보조를 맞췄는지가 드러날 것이다.

프레임워크와 텔레메트리의 이식성은 특히 중요하다. Microsoft의 외부 호스팅 에이전트 트레이스 지원은 한 가지 접근 방식을 제시한다. AWS는 관리형 런타임 내에서의 프레임워크 유연성을 강조한다. Google은 통합된 경험이 고객에게 실질적인 선택권 포기를 요구하지 않는다는 점을 입증해야 한다.

구매자는 각 플랫폼을 동일한 대표 워크플로로 테스트해야 한다. 이 테스트에는 장기 실행 작업, 권한 변경, 주입된 지시문, 실패한 도구, 메모리 수정, 평가 회귀가 포함되어야 한다. 기능 체크리스트만으로는 전체 시스템이 압박 상황에서 어떻게 작동하는지 알 수 없다.

개발자는 플랫폼이 실패를 이해 가능하게 만드는지도 물어봐야 한다. 트레이스는 결과를 원인이 된 지시문, 컨텍스트, 도구, 정책, 모델과 연결할 때만 유용하다. 시스템이 이러한 관계를 체계적으로 정리하지 못한다면, 텔레메트리가 많아질수록 오히려 혼란이 커질 수 있다.

지식 근로자에게도 관련된 우려가 있다. 지속형 에이전트는 점점 더 메모, 문서, 회의, 과거 의사결정에 기반해 행동하게 될 것이다. 개인 AI 워크플로는 이러한 맥락을 정리하는 데 도움이 될 수 있지만, 엔터프라이즈 수준의 실행에는 명시적인 권한과 검토가 필요하다.

Google Cloud는 이제 주요 에이전트 제어 기능을 정식 출시 상태로 전환했다. 이는 의미 있는 제품 전환이지만, 자율형 엔터프라이즈 업무가 해결됐다는 증거는 아니다. 이 플랫폼의 진정한 시험은 에이전트가 며칠 동안 작동하고, 시스템 경계를 넘나들며, 개발자가 예측하지 못한 상황을 마주할 때 시작된다.

에이전트의 권한을 확대하기 전에 한 가지 실질적인 질문을 던져야 한다. 팀이 가장 큰 피해를 줄 수 있는 개연성 높은 행동을 재구성하고, 중단하고, 안전하게 되돌릴 수 있는가? 답이 불확실하다면, 새 제어 기능을 활용해 먼저 워크플로의 범위를 좁혀야 한다. 정식 출시는 더 폭넓은 배포를 가능하게 한다. 이를 책임 있게 만드는 것은 증거, 책임 주체, 그리고 절제된 한계다.