Google Gemini agent로 반복 업무 맡기기: 주간보고·미팅 준비와 승인 경계

2026년 10월 8일 발표한 Gemini agent의 모델 선택·도구·스킬·기억을 구분하고 주간보고와 미팅 준비를 자료 조회부터 승인·복구까지 시험하는 한국어 실무 가이드입니다.

개정 1판 · 최근 고침: Gemini agent 공식 발표와 기업 사례를 확인하고 주간보고·미팅 준비의 가상 실습, 권한·비용·기억·복구 검수 절차를 새로 작성했습니다. · 고침 기록 보기

공식 발표·기업 공동 사례와 편집부가 제안한 미실행 연습을 구분합니다. 계정별 제공 범위·메뉴는 조직에서 확인해야 하며, 사례를 독립 성능 검증이나 직접 사용 후기로 제시하지 않습니다.

월요일 보고서를 부탁하기 전에 정할 것

월요일 아침마다 프로젝트 문서와 지난주 대화를 뒤져 주간보고를 만드는 팀을 생각해 보겠습니다. AI에게 보고서 작성을 맡기면 검색과 초안 작성은 줄어들 수 있습니다. 하지만 취소된 일정이 보고서에 남거나 잠정 예산이 승인 예산으로 바뀌면 담당자가 다시 원문을 읽어야 합니다. 반복 업무를 맡기는 순간부터 자료의 범위, 결정 상태, 쓰기 권한을 함께 정하는 이유입니다.

Google은 2026년 10월 8일 Gemini at Work 2026에서 업무용 Gemini agent를 발표했습니다. 공식 발표의 방향은 하나의 에이전트에게 목표를 맡기고 여러 업무 도구를 연결하는 것입니다. 이 글은 발표 내용과 편집부의 미실행 연습을 구분해 읽습니다. 아래 주간보고·미팅 준비 예시는 실제 제품을 사용해 얻은 결과가 아닙니다.

이 절의 근거 S137

Gemini라는 에이전트와 그 아래 모델

공식 발표에서 Gemini agent는 도구·스킬·맥락을 이용해 일을 진행하는 실행 주체입니다. 그 아래에서 답을 만드는 모델은 별도의 선택이며 현재 Gemini와 Anthropic의 Claude 계열을 함께 조율한다고 설명합니다. 노트북을 닫아도 클라우드에서 작업을 지속하고 기기 사이에서 맥락을 유지하는 방식도 제시했습니다.

팀이 평가해야 할 대상도 둘로 나뉩니다. 문장을 잘 쓰는 모델인지 확인하는 시험과 올바른 파일을 읽고 허용한 곳만 바꾸는 에이전트 시험은 각각 필요합니다. 모델을 바꿨을 때 대답의 문체만 비교하면 담당자·수신자·도구 호출이 달라진 문제를 놓칠 수 있습니다. 업무별 입력과 기대 결과를 작은 평가 묶음으로 남겨 두는 편이 좋습니다.

이 절의 근거 S136

도구·스킬·맥락을 업무 언어로 나누기

Google은 도구를 시스템 연결, 스킬을 재사용할 작업 지침, 맥락을 기억과 개인화의 재료로 설명합니다. 발표에는 세션·의미·절차·일화 기억도 등장합니다. 개인 보조 에이전트와 독자적인 계정·저장소를 가진 동료 에이전트를 구분하며 동료 에이전트는 팀이 공유한 맥락을 본다고 안내합니다.

편집부가 권하는 연습에서는 도구 목록에 문서 조회와 문서 수정을 따로 적습니다. 스킬에는 보고서 형식과 미정 사항을 표시하는 규칙을 넣고 맥락에는 이번 프로젝트의 이름·보고 기간·최종 승인 문서 위치를 적습니다. 보고서 문체를 기억하는 것과 고객의 비공개 정보를 다른 프로젝트에 가져오는 것은 별개입니다. 오래 기억할 정보와 이번 실행에서만 참고할 정보를 먼저 나누세요.

이 절의 근거 S136

발표를 계정의 사용 가능 상태와 구분하기

이번 발표만으로 모든 Workspace 계정에서 같은 메뉴와 기능을 즉시 쓸 수 있다고 판단하기는 어렵습니다. Google Cloud의 긴 발표문 말미에는 폭넓은 준비 상태를 강조하지만 구체적인 전체 출시 일정이나 계정별 사용 절차가 제시되어 있지 않습니다. 조직에서 실제 시험을 시작할 때는 관리자에게 해당 계정의 제공 범위와 연결 가능한 도구부터 확인하는 편이 안전합니다.

확인할 질문은 구체적일수록 좋습니다. 우리 플랜에서 이 업무용 에이전트를 사용할 수 있는가, 문서 편집과 읽기는 각각 허용되는가, 팀용 계정은 누가 관리하는가, 비용 한도에 도달하면 실행은 어디서 멈추는가를 묻습니다. 같은 Gemini 이름을 쓰는 기존 사이드바 기능과 이번 agent 발표를 한 기능 목록으로 합쳐 설치 안내를 만들지 마세요.

이 절의 근거 S136

공식 사례에서 읽을 수 있는 운영 방식

On과 Google Cloud의 공동 발표는 코드 분석·설정 생성·검증을 에이전트의 단계별 작업으로 나누고 엔지니어가 코드 검토, 인프라 변경, 운영 전환을 승인했다고 설명합니다. On은 새 Gemini agent의 초기 테스트 파트너이기도 합니다. 다만 이 이전 사례 전체를 이번에 발표한 단일 agent만의 성능이라고 해석해서는 안 됩니다.

Orange Spain의 공식 발표는 장애 분류, 시스템 원인 분석, 사내 지식 검색 등 서로 다른 업무에 맞춘 에이전트를 소개합니다. 두 사례를 읽을 때는 대규모 도입 숫자보다 업무를 어디서 나눴는지 살펴보세요. 우리 팀에서는 보고 자료 수집과 최종 공유를 분리할 수 있는지, 결과를 받는 사람이 근거를 확인할 수 있는지를 먼저 시험할 수 있습니다. 두 발표는 회사 측 사례 소개이며 독립 비교 실험은 아닙니다.

이 절의 근거 S142 · S143

가상 주간보고에 자료 봉투를 만들기

다음 연습은 가상의 제품 출시 프로젝트를 대상으로 합니다. 지난주 확정 회의록, 이번 주 일정표, 변경 요청 문서 세 개를 준비하고 각 문서에 고유한 번호와 수정 시각을 적습니다. 읽을 범위를 이 세 문서로 제한하고 보고 기간을 명시합니다. 팀 전체 Drive를 검색하도록 시작하면 누락 원인을 자료 부족과 검색 실패 중 어느 쪽으로 볼지 판단하기 어려워집니다.

입력 문서에는 정상 정보만 넣지 않습니다. 회의록에는 출시일 잠정, 일정표에는 출시일 확정으로 서로 다른 상태를 적고 변경 요청에는 승인 대기라고 씁니다. 기대 결과는 충돌과 승인 대기를 보여 주는 보고서입니다. 날짜가 더 최근이라는 이유만으로 한 문서의 결정을 자동 채택하도록 허용하지 않습니다. 자료가 빠졌을 때는 무엇을 읽지 못했는지 표시하도록 요청하세요.

각 주장에 문서 번호와 원문 위치를 붙이면 검수자는 보고서 전체를 다시 검색하는 대신 해당 근거로 이동할 수 있습니다. 원문에 없는 담당자나 기한을 채우지 못하게 하는 제한도 함께 적습니다. 빈칸이 남았다는 이유만으로 실패로 보지 않고, 없는 정보가 확정 정보처럼 제시됐는지를 확인합니다.

이번 보고 기간의 주간보고 초안을 작성하세요.
입력은 지정한 문서 A·B·C로 제한합니다.
확정·잠정·승인 대기를 구분하고 각 행에 문서 번호와 근거 위치를 적으세요.
문서 간 충돌과 읽지 못한 자료는 별도 목록으로 남기세요.
원문과 공유 설정은 바꾸지 말고 초안만 제시하세요.

미팅 준비에서는 결정과 질문을 분리하기

주간보고를 검수한 다음 같은 자료로 프로젝트 미팅 준비안을 만듭니다. 의제는 확정된 진행 상황, 충돌하는 내용, 참석자가 결정할 질문으로 나눕니다. 예산 변경 요청이 승인 대기라면 예산 증액 확정이라는 결론 대신 누가 어느 조건에서 승인할지 묻는 항목으로 남깁니다. 요약이 짧아져도 업무 상태가 달라져서는 안 됩니다.

참석자 목록도 연습 자료에 명시합니다. 관련 대화에 이름이 나온 모든 사람을 참석자로 넣으면 불필요한 공유가 생길 수 있습니다. 읽기 전용 시험에서는 초대장을 보내거나 캘린더를 수정하지 않게 하고, 후보 시간과 참석자 제안만 받습니다. 시간대가 다른 참가자를 넣었을 때에는 기준 시간대와 변환한 시각이 함께 적혔는지 확인합니다.

발표의 편리한 회의 조정 예시를 우리 조직의 승인 정책으로 그대로 옮길 필요는 없습니다. 고객이 포함된 미팅과 내부 미팅은 공유 가능한 자료가 다를 수 있으므로 외부 참석자가 있는 의제에는 자료 공개 범위도 함께 점검합니다. 미팅 준비가 끝났다고 해서 공유나 발송까지 승인한 것으로 처리하지 마세요.

쓰기 승인은 수정안이 나온 뒤에 받기

초안이 통과하면 쓰기 범위를 문서 한 개의 지정 구역으로 좁힙니다. 예를 들어 주간보고의 이번 주 현황 표만 교체하고 제목, 지난주 기록, 공유 대상은 유지하도록 정합니다. 적용 전에는 기존 문서의 버전과 수정안을 나란히 보여 줍니다. 승인자가 무엇을 허용했는지 확인할 수 있어야 다음 주에도 같은 경계를 적용할 수 있습니다.

승인 후에는 에이전트의 완료 메시지보다 실제 파일을 확인합니다. 승인한 표만 바뀌었는지, 근거 링크가 살아 있는지, 잠정과 확정 표시가 유지됐는지 대조하세요. 공유 링크를 새로 만들거나 외부 사람에게 알리는 작업은 문서 편집과 다른 승인 대상으로 둡니다. 편집을 허용받았다는 이유로 연락까지 이어지는 흐름은 첫 시험에서 제외하는 편이 좋습니다.

적용 실패에 대비해 변경 전 사본과 변경 기록을 남깁니다. 파일 일부만 갱신됐는데 다시 전체 작업을 실행하면 중복 문단이 생길 수 있습니다. 먼저 실제 변경을 확인하고 미적용 구역만 다시 처리하거나 이전 버전으로 복구하는 순서를 정해 두세요. 복구도 원문과 대조한 뒤 완료로 기록합니다.

기억의 지속과 사실의 유효기간은 다르다

편집부의 기억 시험에는 두 번의 실행을 준비합니다. 첫 실행에서는 보고서의 고정 형식과 프로젝트 약어를 알려 줍니다. 다음 실행에서는 담당자와 일정이 바뀐 새 문서를 제공합니다. 기대 동작은 형식을 유지하면서 사실은 새 근거로 갱신하는 것입니다. 앞서 알려 준 담당자를 계속 적는다면 기억이 남았더라도 보고서는 틀린 것입니다.

오래된 결정을 폐기하는 연습도 넣습니다. 예전 문서에는 11월 출시, 새 승인 기록에는 일정 미정이라고 적어 두고 이전 일정을 현재 결정으로 재사용하는지 확인합니다. 결과에 기준일과 근거 문서의 수정일을 함께 넣으면 최신이라는 말의 범위를 확인하기 쉽습니다. 새 자료를 읽었는지, 현재 사실을 확인했는지, 단순히 이전 대화를 기억했는지는 각각 다른 항목으로 채점합니다.

접근을 잃은 자료가 있을 때에는 기억 속 내용만으로 최신 상태를 확정하지 않도록 합니다. 연습용 문서를 공유 대상에서 빼고 다시 요청한 뒤 접근할 수 없는 정보의 범위를 설명하는지 살펴보세요. 실제 민감 문서의 권한을 넓혀 시험하지 않습니다. 업무용 기억의 보존·삭제 정책은 관리자에게 확인하고 프로젝트가 끝난 뒤 남겨 둘 정보도 결정합니다.

누락과 잘못된 최신성을 따로 기록하기

보고서 품질은 문장의 유창함만으로 평가하기 어렵습니다. 원문에 있는 중요한 변경을 놓친 누락, 원문에 없는 결정을 추가한 오류, 오래된 정보를 현재 상태로 쓴 오류를 따로 기록합니다. 동일한 보고서에서 세 종류가 함께 생길 수 있기 때문입니다. 각 항목의 분모도 전체 문장 수 대신 시험에 넣은 중요 사실 수로 정합니다.

미팅 준비안에는 취소된 안건 하나와 아직 답을 받지 못한 질문 하나를 심어 둡니다. 취소 안건이 다시 의제로 올라왔는지, 답이 없는 질문에 결론을 만들어 붙였는지 확인합니다. 검색 결과가 비었다면 해당 자료가 없다고 단정하기 전에 검색 범위와 접근 가능 여부를 설명하게 하세요. 누락이 반복되는 자료 유형은 자동 보고에서 제외하고 담당자가 직접 확인할 항목으로 남깁니다.

이 연습에서는 오류 수뿐 아니라 사람이 근거를 대조한 시간과 수정한 시간도 적습니다. 생성은 빨랐지만 확인이 오래 걸린 초안을 구분할 수 있습니다. 읽지 못한 자료를 정직하게 표시한 결과는 빈칸을 꾸며 완성한 결과보다 운영하기 쉽습니다. 팀은 어떤 빈칸이면 배포를 보류할지 미리 정할 수 있습니다.

팀 계정의 권한은 역할별로 좁히기

Google은 에이전트별 신원, 세밀한 권한, 감사 기록, 샌드박스와 Agent Gateway를 제시합니다. 프로젝트의 토큰·샌드박스 비용을 감시하는 지출 상한에 도달하면 에이전트가 멈추고 콘솔에서 재개할 수 있다고 설명합니다. 이런 통제의 존재와 우리 조직에서 올바르게 설정됐는지는 별도로 확인할 문제입니다.

편집부 제안에서는 보고 담당 에이전트에 원본 자료 읽기와 보고 초안 쓰기만 맡깁니다. 인사 문서와 다른 고객 프로젝트는 제외하고 사용자 계정과 팀 계정의 작업 기록도 구별합니다. 팀에 새 구성원이 들어왔을 때 이전 프로젝트 자료가 따라 보이는지, 팀을 떠났을 때 접근이 남는지 관리자와 함께 확인하세요. 에이전트의 이름이 사람이 읽을 수 있다고 해서 권한 경계까지 검증된 것은 아닙니다.

권한을 거부당한 실행은 더 넓은 계정으로 우회하기 전에 실패 원인을 분류합니다. 필요한 자료가 공유되지 않았는지, 잘못된 자료를 요청했는지, 조직 정책이 금지한 작업인지에 따라 다음 조치가 다릅니다. 정책이 금지한 작업을 수행하지 못했다면 통제 시험에서는 정상 결과로 기록합니다.

이 절의 근거 S136

비용 한도는 완료 상태와 함께 읽기

지출을 줄일 때에는 한 번의 보고서가 최종 검수까지 끝났는지를 함께 봅니다. 실행 비용만 낮고 실패한 초안이 반복되면 사람이 다시 작업하는 시간이 커집니다. 팀은 작업별 모델 사용 비용, 연결 도구나 실행 환경의 비용, 검수 시간을 구분해 기록할 수 있습니다. 공식 상한이 감시하는 비용 범위를 외부 서비스의 전체 청구액과 같다고 가정하지 않습니다.

상한에 닿아 멈춘 가상 상황에서는 상태를 자료 수집 완료, 초안 작성 중, 적용 미승인처럼 표시합니다. 완료되지 않은 보고서가 다음 단계로 공유되지 않게 하고 재개할 때는 같은 문서를 다시 쓰지 않도록 마지막 적용 지점을 확인합니다. 금액을 늘리는 결정과 재실행 결정도 나누세요. 비용을 더 허용해도 입력 자료 충돌은 해결되지 않습니다.

모델 조율이 업무별로 달라지면 같은 요청의 비용과 결과가 변할 수 있습니다. 비교 기록에는 실행 날짜, 입력 문서 버전, 도구 범위, 확인 가능한 모델 정보를 적습니다. 전체 비용을 완료한 보고서 수로 나눈 값과 검수 후 완료 시간을 함께 보면 도입 효과를 과장하지 않고 판단할 수 있습니다.

모델이 바뀌면 작은 업무부터 다시 검수하기

에이전트의 맥락과 스킬을 유지하면서 모델을 바꾸는 방식은 유용해 보입니다. 그러나 같은 지침을 읽는 모델이 달라지면 미정 상태를 처리하는 방식이나 도구를 고르는 판단도 달라질 수 있습니다. 이전에 통과한 주간보고 입력을 새 환경에 다시 넣어 사실 보존과 승인 경계를 확인합니다. 결과가 달라졌을 때에는 문체 변화와 업무 오류를 구분해 기록하세요.

팀의 회귀 시험에는 문서 충돌, 권한 거부, 자료 누락, 비용 중단, 중복 적용 방지를 포함합니다. 한 항목이 실패했다고 전체 업무를 당장 폐기할 필요는 없습니다. 문서 조회는 유지하되 수정 적용을 멈추거나 미팅 의제 초안은 계속 받되 초대장 작성은 보류하는 식으로 문제가 생긴 기능을 나눠 중단할 수 있습니다. 재개 조건은 같은 실패 입력으로 다시 확인합니다.

사례와 영상을 다음 시험의 질문으로 바꾸기

공식 발표에는 Merck의 분자 연구 사례를 소개하는 영상 링크도 있습니다. 이 글은 Google이 설명한 사례 범위만 안내하며 영상의 전체 재생·자막·시간대별 내용을 검증한 후기를 제공하지 않습니다. 사례를 볼 때에는 완성된 화면보다 자료 입력, 사람의 승인, 실패 후 복구 장면이 드러나는지 살펴보면 우리 팀의 질문을 구체화하는 데 도움이 됩니다.

첫 도입은 주간보고 한 종류로도 충분합니다. 자료 범위를 고정하고 초안과 적용을 나눈 뒤 누락·상태 변경·무승인 쓰기를 검사하세요. 그 흐름이 반복해서 통과하면 미팅 준비나 다른 업무로 넓힙니다. 하나의 창에서 일을 맡기는 편리함은 담당자가 근거와 변경 내역을 쉽게 확인할 때 업무에서 쓸 만한 도구가 됩니다.

이 절의 근거 S144