새 팀원이 들어왔다. 이메일 주소가 있고, 채팅방에서 이름을 부르면 답한다. 문서 수정 기록에도 자기 이름이 남는다.
그런데 사람이 아니다.
Google은 10월 8일 Gemini at Work에서 업무용 Gemini agent를 발표했다. 그중 눈에 띄는 구상은 팀의 일원처럼 움직이는 coworker agent다. Google의 설명에 따르면 이 에이전트는 별도 Workspace 계정과 이메일, 캘린더, Drive를 갖고, 자기 신원으로 작업하며 공유받은 정보에 접근한다. Google Cloud 공식 발표
채팅창이 하나 더 생긴다는 이야기로 읽으면 핵심을 놓친다. 문서에 답변을 복사하는 사람이 나였던 구조에서, AI 자체가 업무의 참여자로 기록되는 구조로 넘어가려는 것이다.
이 변화가 실제로 유용할지는 “얼마나 사람처럼 말하는가”보다, 그 참여자에게 어떤 일을 맡기느냐에 달려 있다.
2026년 10월 12일 공식 발표를 바탕으로 작성했다. 아래 팀과 업무는 설명을 위한 가상 사례이며, 직접 사용한 후기나 모든 계정에서의 제공 여부를 검증한 글은 아니다. 도입 전에는 해당 조직의 제공 범위와 관리자 설정을 확인해야 한다.
첫 출근한 AI에게 ‘알아서’라고 말하지 않기
신제품 출시를 준비하는 작은 팀을 생각해 보자. 기획 문서에는 금요일 출시라고 적혀 있다. 채팅에서는 QA가 하루 더 필요하다고 말한다. 고객에게 보낼 안내 메일은 이미 초안이 작성돼 있다.
이 팀에 AI를 넣고 이렇게 말할 수 있다.
출시 준비를 알아서 정리해 줘.
친절한 요청처럼 보이지만, 실제로는 여러 결정이 숨어 있다. 어느 일정이 최종인가? 충돌하는 내용을 수정해도 되는가? 고객에게 변경된 일정을 알려도 되는가?
사람도 처음 출근한 날에는 알기 어려운 일이다. AI에게 회사 자료를 더 많이 읽힌다고 해서 결정권까지 자동으로 생기지는 않는다.
나는 첫 업무를 다음처럼 좁혀 주고 싶다.
이번 출시의 미해결 항목을 찾아 내부 검토용 문서로 작성해 줘. 읽을 자료는 지정한 출시 폴더와 프로젝트 채팅방으로 한정해. 일정이 충돌하면 한쪽을 정답으로 선택하지 말고 두 근거와 담당자를 적어 줘. 원본 일정은 변경하지 말고, 외부 메일도 보내지 마. 초안이 준비되면 이 채팅방에 검토를 요청해 줘.
이 문장은 Gemini의 공식 설정 예제가 아니다. 일을 위임할 때 합의할 내용의 예시다. 특히 “메일을 보내지 마”라는 문장만으로 전송 권한이 기술적으로 차단된다고 생각해서는 안 된다. 실제 연결 권한도 업무 범위에 맞게 제한해야 한다.
이렇게 시작하면 결과가 틀렸을 때도 원인을 찾기 쉽다. 필요한 자료가 없었는지, 충돌을 놓쳤는지, 담당자를 잘못 연결했는지 구분할 수 있기 때문이다. 반대로 ‘출시를 알아서 책임져라’는 요청은 실패했을 때조차 무엇이 실패했는지 설명하기 어렵다.
자기 이름으로 일한다는 것의 무게
Google이 설명하는 동료 에이전트는 사용자의 신원 대신 자신의 신원으로 행동한다. 또한 감사 기록에서 에이전트의 작업을 구분하는 방향을 제시한다. 에이전트 신원과 감사에 관한 발표 내용
개발자 입장에서는 이 부분이 말투보다 흥미롭다.
문서의 수치를 누가 바꿨는지 확인할 때, 담당자 이름 아래에 사람과 자동화의 작업이 섞여 있으면 조사부터 번거롭다. 별도 신원은 적어도 “어떤 실행 주체가 변경했는가”를 추적할 출발점이 된다.
다만 기록에 AI 이름이 남는다고 책임 문제가 해결되는 것은 아니다. 그 계정에 접근 권한을 준 사람, 업무를 정의한 사람, 결과를 승인한 사람은 여전히 조직 안에 있다. AI에게 계정을 발급하는 일과 업무 책임자를 지정하는 일은 따로 해야 한다.
가상의 출시 팀에서도 마찬가지다. AI는 두 개의 서로 다른 날짜를 찾아낼 수 있다. 하지만 어느 날짜를 고객에게 약속할지는 사업상 결정이다. 시스템이 잘 돌아갈수록 이런 결정 지점을 생략하고 싶어지는데, 오히려 그 지점을 명확하게 남겨두는 것이 중요하다.
오래 일하는 에이전트라면 권한 회수도 업무의 일부다. 출시가 끝났는데 옛 프로젝트 자료를 계속 볼 필요가 있는가? 담당자가 바뀌었는데 예전 사람에게 보고하고 있지는 않은가? 생성만큼 종료를 설계해야 한다.
Gemini라는 이름 아래 Claude가 일할 수도 있다
이번 발표에는 또 하나의 구분이 있다. Google은 Gemini라는 에이전트와 그 아래에서 쓰는 모델을 별도의 선택으로 설명하며, 현재 Gemini 계열과 Anthropic의 Claude 모델을 활용한다고 밝혔다. 모델 선택에 관한 공식 설명
이 대목을 “어느 회사 모델이 이겼나”로만 읽기에는 아깝다. 업무용 AI를 선택할 때 모델의 답변 품질 외에도 살펴봐야 할 층이 드러나기 때문이다.
우리 자료를 어디서 읽는가. 작업이 어떤 계정으로 실행되는가. 중단된 일을 누가 이어받는가. 결과를 어디에 남기는가. 모델을 바꾸면 기존 업무 규칙도 다시 만들어야 하는가.
이 질문들은 벤치마크 점수 하나로 답할 수 없다. 반대로 업무 연결이 편리하다고 모델의 오류가 사라지는 것도 아니다. 좋은 업무 환경과 좋은 추론 능력은 서로 대신할 수 있는 조건이 아니다.
출시 팀으로 돌아가 보자. 첫 주에 확인할 것은 AI가 작성한 문서 수가 아니다. 담당자가 놓치던 충돌을 찾아냈는지, 확인하는 시간이 줄었는지, 불필요한 알림을 늘리지는 않았는지다. 이는 실제 성과 수치가 아니라 도입 시 비교해 볼 평가 항목이다.
제대로 만든 초안 하나가 쓸모없는 보고서 열 개보다 낫다. 그 초안을 믿고 다음 단계로 넘어갈 수 있는 이유까지 남겨준다면 더 좋다.
이메일 주소를 가진 AI는 꽤 그럴듯한 동료의 모습을 하고 있다. 하지만 팀에 초대하기 전에 먼저 써야 할 것은 환영 메시지가 아닐지도 모른다.
첫 업무의 범위, 완료 조건, 그리고 결정이 필요할 때 물어볼 사람의 이름.