Google의 Gemini agent, 이메일·문서·코딩을 한 창에서 처리한다

Google Cloud가 2026년 10월 8일 Gemini at Work 행사에서 기업 업무용 Gemini agent를 발표했다. 조직의 업무 맥락을 활용해 한 입력창에서 질문에 답하고, 문서를 만들고, 코드를 작성하며, 연결된 도구로 작업을 수행하도록 설계된 에이전트다. 결과물은 직원이 이미 사용하는 문서, 받은편지함, 개발 환경에 남기는 방식으로 제시됐다.

도입의 첫 대상은 기업이다. TechCrunch의 출시 보도에 따르면 Google은 기업에 먼저 이 에이전트를 제공하는 데 집중하고 소비자 확대는 이후 단계로 보고 있다. 발표된 것은 모든 국내 계정에서 곧바로 사용할 수 있다는 안내가 아니라, 질문 응답과 사용자를 대신한 작업 수행을 한 에이전트에 묶겠다는 제품 구상이다. 한국 기업에는 어떤 업무 시스템을 연결할 수 있고 실행 권한과 비용을 어떻게 관리할 수 있는지가 도입 판단의 핵심이다.

한 입력창에서 시작해 연결된 도구로 작업한다

에이전트가 하는 일은 답변 생성에서 끝나지 않는다. Google Cloud 최고경영자 토머스 쿠리안은 공식 발표문에서 이용자가 “objectives, not instructions”를 맡긴다고 표현했다. 목표를 받으면 필요한 단계를 계획하고 기술과 도구를 골라 실행한 뒤 결과를 원래 업무가 이뤄지는 곳으로 돌려준다는 뜻이다. 따라서 ‘한 창’은 모든 작업과 결과가 하나의 새 앱 안에만 머문다는 의미가 아니다.

연결 대상으로 제시된 서비스에는 Google Workspace, Microsoft 365, Slack, Jira, Confluence, Git, BigQuery, Databricks, Postgres, Snowflake 등이 있다. 회사 안팎의 Model Context Protocol 서버와 연결하는 경로도 포함된다. 직원은 파일이나 폴더, 특정 업무 프로젝트를 요청에 붙일 수 있으며, 에이전트는 허용된 연결을 통해 필요한 맥락을 얻는다. 실제로 어느 시스템의 정보를 읽고 수정할 수 있는지는 조직이 연결한 도구와 그 도구에 부여한 권한에 달려 있다.

질문에 필요한 자료를 찾아 답하는 일과 업무 시스템에 결과를 남기는 일은 실행 범위가 다르다. 예를 들어 에이전트는 문서 작성뿐 아니라 코드 작성과 실행, 일정 조율처럼 여러 단계를 거치는 과업도 맡도록 설계됐다. 긴 작업은 클라우드에서 이어지고, 필요하면 일시적인 하위 에이전트에 단계를 나눠 맡길 수 있다. 이런 구조에서는 직원이 처음 입력한 요청뿐 아니라 각 단계에서 어떤 도구가 실제로 호출되는지도 운영상 중요해진다.

작업을 수행하는 에이전트와 그 아래에서 쓰는 모델도 구분된다. 발표된 모델 선택지에는 Google의 Gemini 계열과 Anthropic의 Claude가 포함되며, 다른 민간·오픈 모델은 향후 계획으로 제시됐다. 모델을 바꾸거나 과업에 따라 자동 선택하더라도 업무 데이터에 접근하는 주체의 권한이 함께 넓어지는 것은 아니다. 모델 선택은 결과의 품질과 실행 비용에, 에이전트의 신원과 도구 권한은 실제로 할 수 있는 일에 각각 영향을 준다.

Workspace에서는 에이전트 자신의 이름으로 일한다

Gemini agent는 별도 입력창에서 시작한 일을 Google Workspace 안으로 이어가도록 설계됐다. Gmail, Drive, Docs, Slides, Sheets, Chat, Calendar에서 같은 기억과 기술, 통제를 사용한다는 설명이다. 직원은 메일 대화나 문서, 채팅 공간에서 업무를 맡기고 그 공간에서 결과를 받을 수 있다. 이 방식은 입력 위치를 하나로 모으면서도 결과물이 기존 업무 기록 안에 남게 한다.

팀이 함께 쓰는 coworker agent에는 별도의 Workspace 계정이 부여된다. 이 계정에는 이메일 주소와 캘린더, Drive 공간, 사내 디렉터리 항목이 포함된다. 동료는 채팅 공간에 에이전트를 추가하거나 언급해 일을 맡길 수 있고, 문서 댓글에서 요청한 편집도 에이전트 자신의 이름으로 기록된다. 사람이 실행한 작업과 에이전트가 실행한 작업을 구분할 수 있는 신원 체계다.

접근 범위에는 기존 공유 설정과 구성원 자격이 적용된다. 에이전트가 팀의 모든 자료를 자동으로 볼 수 있다는 뜻이 아니라, 공유받은 내용과 승인된 도구 안에서 일한다는 설명이다. 직원이 특정 문서를 공유해 초안을 맡기는 경우와 팀의 메일이나 일정에 접근하도록 맡기는 경우에는 필요한 권한이 달라진다. 메일 발송이나 문서 수정처럼 다른 사람에게 영향을 주는 작업이라면 결과물의 소유자와 변경 기록도 분명해야 한다.

조직의 맥락을 활용한다는 기능은 협업에 편리하지만, 업무 신원을 추가한다는 결정도 수반한다. 기존 직원 계정의 공유 범위, 외부 협업 도구의 접근 범위, 에이전트에게 허용할 쓰기 권한을 함께 보아야 한다. 특히 팀 전체를 대신하는 에이전트라면 개인에게만 공유된 자료와 팀에 공유된 자료의 경계가 실제 작업 범위를 가른다. 발표된 계정 구조의 의미는 에이전트를 사람과 구별해 관리하고 작업을 추적할 수 있다는 데 있다.

Gemini Enterprise 고객 사례와 새 에이전트의 성과는 다르다

이번 발표에는 Gemini Enterprise를 사용해 온 기업들의 사례도 함께 등장한다. 그러나 기존 플랫폼에서 만든 맞춤형 에이전트나 자동화의 성과를 새 Gemini agent의 실사용 성과로 옮겨 읽을 수는 없다. Gemini agent는 직원이 업무 목표를 맡기는 범용 실행 주체로 제시됐고, Gemini Enterprise는 기업이 에이전트와 조직 데이터를 운용해 온 제품 맥락이다. 두 이름이 같은 발표에 나온다는 사실만으로 계약 범위나 기능의 자동 이전이 정해지는 것은 아니다.

기존 환경과 연결해 볼 운영 요소는 기억과 실행 공간의 통제다. 새 에이전트는 이용자와 조직의 맥락을 바탕으로 작업을 이어가고, 팀이 반복해서 쓰는 기술도 활용하도록 설계됐다. 반면 기업이 이미 만들어 둔 개별 에이전트가 어떤 조건에서 같은 신원, 기억, 실행 정책을 사용하는지는 배포 설정과 계약에 따라 확인해야 한다. 이름이 비슷한 기능이라도 조회만 하는 자동화와 시스템에 변경을 남기는 에이전트는 운영 범위가 다르다.

Google Cloud가 소개한 기존 고객 사례 역시 적용된 제품과 과업을 따져 읽을 필요가 있다. 예를 들어 이미 운용 중인 기업별 맞춤형 에이전트는 새 범용 에이전트의 전체 성능을 보여주는 시험 결과가 아니다. 이번 발표에서 직접 확인되는 변화는 직원이 단일 요청으로 여러 도구에 걸친 일을 맡기고, 필요하면 팀의 독립된 업무 주체로 에이전트를 둘 수 있다는 제품 설계다. 기존 계약에 어떤 기능이 포함되는지와 언제 계정에 적용되는지는 별도의 제공 조건이 필요하다.

실행 권한과 감사 기록이 업무 범위를 가른다

조직 데이터에 연결된 에이전트에는 자료를 읽는 권한과 실제로 바꾸는 권한을 따로 다뤄야 한다. 발표된 관리 체계에서는 에이전트마다 신원을 부여하고, 역할에 따른 세부 접근 권한을 조직의 보안 관리자가 승인한다. 외부 시스템에 접속할 때는 OAuth 같은 표준을 사용해 그 신원을 전달하도록 설계됐다. 직원의 요청을 받은 에이전트가 어떤 권한으로 행동했는지 확인할 수 있어야 작업 책임도 추적할 수 있다.

에이전트의 행동은 사람의 계정에 섞이지 않고 에이전트의 신원으로 감사 기록에 남는 구조다. 코드 실행을 위해 만들어진 실행 환경에도 그 신원이 이어지므로 관리자는 작업의 출처를 살필 수 있다. 이 점은 같은 문서를 직원이 직접 수정했는지, 에이전트가 위임받아 수정했는지를 구분하는 데 중요하다. 대화 내용만 보관하는 방식으로는 외부 도구에서 실제로 일어난 변경을 설명하기 어렵다.

실행 환경의 경계로는 Agent Sandbox와 Agent Gateway가 제시됐다. 에이전트 작업은 자체 네트워크 경계를 가진 샌드박스에서 수행되고, 에이전트 안팎과 에이전트 사이의 트래픽에는 조직 정책이 적용된다. 특정 등급의 문서를 열지 못하게 하는 정책도 예시로 제시됐다. 조직이 어떤 자료를 연결했는지만큼 어떤 분류의 자료를 차단하고 각 커넥터의 쓰기 권한을 누가 승인하는지가 중요하다.

같은 요청이라도 읽기와 실행을 구분하면 권한 경계가 선명해진다. 회의 가능 시간을 요약하는 일에는 일정 조회가 필요하지만, 참석자에게 메일을 보내 약속을 확정하는 일에는 발송 권한까지 필요하다. 코드의 문제점을 설명하는 일과 코드를 실행해 개발 환경에 결과를 남기는 일도 마찬가지다. 이런 구분은 범용 에이전트의 기능 목록보다 실제 배포 범위를 더 정확히 보여준다.

비용 한도와 국내 제공 조건이 배포 규모를 정한다

여러 도구를 거쳐 오래 실행되는 작업에는 비용 관리가 필요하다. 발표된 Smart Routing은 과업에 맞는 모델을 배정하고, 프로젝트별 실시간 지출 한도는 Cloud Billing Console에서 설정하도록 설계됐다. 한도에는 토큰 사용량과 샌드박스 비용이 반영된다. 상한에 도달하면 해당 프로젝트의 에이전트가 일시 중지되고 관리자가 재개할 수 있다.

따라서 같은 에이전트라도 어떤 프로젝트에서 실행되는지에 따라 허용 비용이 달라질 수 있다. 모델을 자동으로 고르는 기능은 개별 요청의 비용을 낮추는 수단이고, 지출 한도는 누적 비용이 정해진 범위를 넘을 때 실행을 멈추는 장치다. 반복 작업이나 하위 에이전트를 동원한 긴 작업에서는 두 장치의 역할이 특히 다르다. 결과물이 나오기 전에 한도에 걸린 작업을 누가 검토하고 재개할지도 운영 절차에 포함된다.

한국 기업에는 국내 계정과 요금제에서 이용할 수 있는 시점, 기존 Gemini Enterprise 계약에 포함되는 범위, 지역별 데이터 처리 조건이 남아 있다. 발표된 설계만으로 모든 Workspace 계정의 즉시 이용 가능 여부를 판단할 수는 없다. 제공 조건이 구체화되면 기업은 연결할 업무 시스템과 에이전트의 독립 신원, 관리자 승인 범위, 프로젝트별 비용 한도를 함께 맞춰 실제 배포 범위를 정하게 된다.

함께 읽기:

• Gemini Enterprise가 에이전트의 기억·기술·실행공간을 따로 통제한다
• AI 에이전트에 관리자 권한을 주지 마라…작업마다 잠깐 빌려줘야 한다
• Cyera에 또 4억 달러…이번 돈은 AI 에이전트의 권한을 겨냥한다