Google Cloud의 Gemini Agent는 아키텍처 차원의 변화를 보여줍니다. Google은 또 하나의 대화형 엔드포인트를 출시하는 대신, 기업 내부에서 업무를 총괄하는 단일 에이전트로 설계된 제품을 선보였습니다. 핵심 가치는 자연어 처리의 새로움에만 있는 것이 아니라, 여러 단계의 업무를 계획하고 전문 스킬과 도구를 호출해 사람들이 이미 일하는 공간, 즉 문서와 받은편지함, IDE에 완성된 결과물을 전달하는 데 있습니다. 의사결정자에게 이는 통합에 관한 질문을 새롭게 제기합니다. Gemini는 기존 시스템에 덧붙이는 기능일까요, 아니면 중앙에서 도입해야 할 에이전트 계층일까요?
운영 측면에서 Gemini의 가치는 서로 맞물리는 세 가지 역량으로 나뉩니다. 맥락을 고려한 계획 수립, 도구와 스킬의 호출, 완성된 결과물의 전달입니다. 맥락을 고려한 계획 수립이란 에이전트가 단일 프롬프트에 답하는 데 그치지 않고, 권한과 프로세스 템플릿, CRM 맥락 등 조직 데이터를 활용해 작업 순서를 정할 수 있다는 뜻입니다. 도구 호출 기능을 통해 에이전트는 커넥터를 실행하고 API를 호출하거나 내부 스킬을 사용해 하위 작업을 완료합니다. 특히 중요한 것은 결과물 전달입니다. 에이전트가 사용자가 이미 쓰고 있는 앱에 결과물을 돌려주므로 업무 인계와 변화 관리에 따르는 마찰을 줄일 수 있습니다.
엔지니어링 및 플랫폼 팀이 주목할 또 다른 특징은 에이전트에 내장된 모델 및 비용 거버넌스입니다. Gemini는 작업에 가장 적합한 모델을 선택하고 비용을 제어하며, 엔터프라이즈 SLA에 맞는 관리자 제어 기능을 제공합니다. 이를 통해 임시로 구성한 모델 엔드포인트를 줄이고 관측 가능성을 높일 수 있습니다. 다만 허용 가능한 모델 동작과 지출 수준에 관한 결정이 에이전트 설정에 집중되므로, 팀은 이 절충점을 면밀히 검토해야 합니다.
제품 및 운영 책임자에게 당장 중요한 질문은 실무적입니다. Gemini는 기존 ID 및 데이터 정책과 어떻게 연동될까요? 스킬을 사업 부문별로 어떻게 매핑할까요? 정보 유출이나 잘못된 자동화를 막으려면 어떤 안전장치가 필요할까요? Google이 거버넌스와 관리자 제어를 강조한다는 점은 엔터프라이즈 환경에 필요한 준비를 우선시했음을 보여줍니다. 그러나 통합의 복잡성과 변화 관리는 여전히 실제 도입을 가로막는 장벽입니다. 이 글에서는 기술 및 운영 측면의 영향을 살펴보고, Gemini를 엔터프라이즈 에이전트 계층으로 고려하는 팀을 위한 다음 단계를 제안합니다.


