Gemini 업무 에이전트, 사번과 예산이 경쟁력이 된다

Google이 Gemini를 질문에 답하는 창에서 목표를 맡아 실행하는 업무 에이전트로 확장한다. TechCrunch의 10월 8일 보도와 Google Cloud 공식 발표는 계획 수립, 도구 사용, 하위 에이전트 위임, 여러 모델 선택을 하나의 업무 환경으로 묶는 구상을 설명한다. 공식 페이지의 표시 날짜는 10월 9일이다.

중요한 변화는 새로운 모델 이름보다 누가 작업하고, 어떤 권한으로 실행하며, 예산을 어디서 멈추는가에 있다. Google은 우선 기업 고객에 초점을 맞춘다. 발표된 기능을 모든 개인 계정이나 국내 계약에서 곧바로 쓸 수 있다고 일반화해서는 안 되며, 실제 제공 범위와 조건은 확인이 필요하다.

에이전트가 독립된 업무 계정을 갖는다

Google은 동료형 에이전트에 자체 Workspace 계정과 이메일, 캘린더, Drive, 조직 디렉터리상의 존재를 부여한다고 설명한다. 사람이 공유하거나 채팅에 초대하고 문서에서 호출하는 방식으로 함께 일하며, 작업 내역도 사람 이름이 아니라 에이전트의 신원으로 기록한다는 설계다.

사람의 계정을 그대로 빌려 쓰는 자동화와 비교하면 책임 추적이 명확해질 수 있다. 누가 시킨 일인지와 실제로 어느 에이전트가 수정했는지를 구분할 수 있기 때문이다. 그러나 별도 계정만 만든다고 과도한 권한이나 잘못된 공유가 해결되지는 않는다. 에이전트의 소유자, 접근 범위, 폐기 시점을 정하는 운영 규칙이 필요하다.

에이전트 메시징과 신원 분석에서 다룬 문제처럼, 대화가 끝나도 작업이 이어지면 신원은 단순한 화면 장식이 아니라 권한과 책임을 연결하는 기본 단위가 된다.

모델은 선택지가 되고 업무 문맥은 플랫폼에 남는다

공식 발표는 Gemini 에이전트와 그 아래에서 실행되는 모델을 별개로 설명한다. 현재 Gemini 계열과 Anthropic Claude를 사용하고, 다른 비공개·공개 모델은 향후 확장 대상으로 제시한다. Google의 에이전트가 경쟁사의 모델을 선택할 수 있다는 점은 모델 성능 경쟁과 업무 플랫폼 경쟁이 같지 않다는 신호다.

사용자는 모델을 바꾸더라도 프로젝트 문맥과 도구, 반복 작업 규칙을 유지할 수 있다는 장점을 얻을 수 있다. 반대로 기억과 스킬, 권한 연결이 한 플랫폼에 깊게 쌓일수록 다른 플랫폼으로 옮기는 비용은 커질 수 있다. 모델 선택권이 있다는 사실만으로 전체 시스템의 종속성이 사라지는 것은 아니다.

발표는 세션·의미·절차·경험에 해당하는 네 종류의 기억을 설명한다. 팀이 축적한 규칙을 재사용하면 반복 설명을 줄일 수 있지만, 오래된 정책을 기억한 채 실행하는 문제도 관리해야 한다. 에이전트 기억과 최신 문서의 관계처럼 기억의 양보다 최신 업무 규칙과의 일치가 중요하다.

도구 연결은 권한을 자동으로 정리해 주지 않는다

Google은 Workspace·Microsoft 365·Slack·Jira·Git·여러 데이터베이스와의 연결, 그리고 MCP 서버 사용을 제시한다. 연결 표준은 도구를 호출하는 형식을 맞추는 데 도움을 주지만, 모든 업무 시스템의 승인 규칙까지 통일하는 것은 아니다. 읽기 권한과 수정 권한, 외부 발송과 내부 초안 저장을 나눠 설계해야 한다.

공식 발표는 독립 신원, 세분화된 역할별 권한, 감사 기록, Agent Sandbox와 Agent Gateway를 설명한다. 이는 공급사가 제시한 통제 구조이며 본지가 실제 차단 동작을 시험했다는 의미는 아니다. 일반적인 권한 관리 원칙은 Google Cloud IAM 개요에서도 확인할 수 있지만, 개별 에이전트 기능의 계약과 설정은 별도 검토 대상이다.

국내 기업은 인사 이동이나 프로젝트 종료 때 접근권을 회수했을 경우 이미 실행 중인 작업에도 반영되는지 확인할 수 있다. 공유 문서를 기억한 에이전트가 이후 그 문서의 권한을 잃었을 때 무엇을 계속 보관하는지도 질문해야 한다. 이메일 주소를 가진다는 것은 법적 책임 주체가 된다는 뜻이 아니라 시스템상의 실행 주체를 구별한다는 뜻이다.

비용 상한은 업무 실패 처리와 함께 설계해야 한다

Google은 Smart Routing과 여러 모델 조합, 프로젝트별 실시간 지출 상한을 설명한다. 발표에 따르면 토큰 사용과 샌드박스 비용을 추적하고 한도에 도달하면 에이전트를 멈추며 관리자가 재개할 수 있다. 값싼 모델로 분류나 추출을 처리하고 복잡한 판단에 더 강한 모델을 배정하는 방식은 합리적일 수 있다.

하지만 비용이 멈춘 순간 업무도 멈춘다. 예를 들어 보고서 초안만 만든 상태인지, 데이터베이스 일부를 수정한 뒤인지에 따라 복구 책임이 다르다. 한도 초과를 오류로 기록하고 완료되지 않은 작업을 담당자에게 넘기는 경로가 필요하다. 이는 지속 실행과 재시작 문제와 연결되는 운영 과제다.

도입 성과는 생성한 문서 수보다 승인까지 끝난 업무당 비용, 사람이 다시 수정한 비율, 중단 후 복구 시간을 함께 봐야 한다. Google의 발표는 업무 에이전트 경쟁이 모델 점수에서 신원·문맥·비용 관리로 넓어졌음을 보여준다. 한국 기업에 중요한 질문도 '얼마나 똑똑한가'에서 '우리 조직의 규칙 안에서 끝까지 일을 마치는가'로 이동한다.

FAQ

개인용 Gemini에 모두 즉시 제공되는가?

보도는 기업 우선 접근을 설명한다. 개인 계정, 국내 계약, 각 기능의 실제 제공 시점까지 이 발표만으로 보장할 수 없다.

Google 모델만 사용할 수 있나?

공식 발표는 Gemini 계열과 Claude를 현재 선택지로 설명한다. 다른 공개·비공개 모델은 향후 확장 대상으로 구분한다.

에이전트 이메일은 왜 중요한가?

사람 대신 별도의 실행 신원으로 공유와 작업 기록을 남길 수 있기 때문이다. 다만 계정 소유자와 권한 관리 책임은 조직이 정해야 한다.

지출 한도에 도달해도 업무는 계속되나?

발표에 따르면 해당 프로젝트의 에이전트가 일시정지하고 관리자가 재개할 수 있다. 중단 시점의 작업 상태와 복구 절차를 확인해야 한다.

국내 기업이 먼저 시험할 업무는 무엇인가?

읽기 전용 자료 조사와 내부 보고서 초안처럼 완료 기준이 명확한 업무부터 평가할 수 있다. 외부 발송이나 원장 변경은 별도 권한과 승인 규칙을 붙이는 편이 좋다.