Google Cloud는 10월 8일 팀의 업무를 맡는 Gemini “coworker agent”에 별도 Workspace 계정을 부여하는 구상을 발표했다. 관리자가 역할을 정하면 에이전트가 이메일, 캘린더, Drive와 회사 디렉터리를 갖춘 팀 구성원처럼 작동한다. 파일을 수정하면 기록에 에이전트 이름이 남고, 에이전트는 팀이 공유한 맥락에 접근한다. 핵심 변화는 자동화가 직원의 로그인 정보를 빌리는 대신 구분 가능한 업무 주체를 갖는다는 점이다.
Google은 장기간 맡을 역할을 가진 coworker agent와 작업을 나누기 위해 잠시 생성되는 하위 에이전트를 구분한다. coworker는 여러 세션에 걸쳐 팀과 일하는 지속형 업무 동료이고, 하위 에이전트는 특정 과제를 수행하는 임시 작업자다. 각각 별도 신원을 가질 수 있어도 Workspace 계정과 이메일을 가진 팀 동료형 에이전트와 같은 범주로 볼 수는 없다.
계정이 바뀌면 관리할 일도 달라진다
에이전트가 자기 계정으로 메일을 보내거나 문서를 고치면, 관리자는 사람과 자동화의 활동 주체를 기록에서 나눠 볼 수 있다. 팀은 어떤 자료를 공유할지 정하고, 에이전트의 계정과 도구 권한을 업무 역할에 맞춰야 한다. 담당 역할이 끝났을 때 계정을 중지하거나 접근을 거두는 절차도 기존 계정 관리에 포함해야 한다. 별도 신원은 누가 행동했는지를 선명하게 하지만, 허용된 자료와 작업 범위까지 자동으로 최소화하지는 않는다.
예를 들어 일정 조율 에이전트가 팀 캘린더와 회의 자료만 읽게 할지, 행사 준비 문서까지 수정하도록 할지는 조직이 정할 문제다. 에이전트 명의의 메일과 Drive 활동을 감사할 수 있다는 설명은 책임 추적의 실마리를 준다. 다만 발표 자료만으로 관리자 제어 항목, 출시 시점, 지역·앱별 사용 범위를 확정할 수는 없다.
기업은 새 계정을 만들기 전에 권한 승인, 공유 범위, 로그 보존, 비활성화 방식이 기존 보안 도구와 어떻게 연결되는지 확인해야 한다. Gemini 동료형 에이전트는 팀 업무에 AI를 투입할 때 서비스 계정과 감사 체계를 함께 설계하게 만드는 변화다. 실제 도입 판단은 모델보다 계정 관리와 데이터 접근을 회사 정책에 맞출 수 있는지에 달려 있다.
