Grok Bot 심층 분석: 이메일·루틴·공유 컴퓨터로 반복 업무 맡기기

10월 업데이트에서 업무 흐름이 달라지는 지점

Grok Bot은 컴퓨터에서 앱·브라우저·파일을 다루고 지속적으로 일하는 에이전트 제품이다. 일반 Grok 채팅, 음성 모델, 코딩 도구인 Grok Build와 구분해야 한다. 이 글은 2026년 10월 16일 확인한 공개 문서를 바탕으로, 이미 제품을 검토 중인 독자가 반복 업무 하나를 설계하도록 돕는 분석이다. 직접 설치하거나 고객 자료로 실행한 사용기는 아니다.

공식 변경 기록의 10월 11일 v0.70.2 묶음에는 봇이 자기 이메일 주소를 받아 수신하고, 그 주소로 보내는 메일은 초안 카드에서 사용자 승인을 기다리는 기능이 나온다. 루틴을 저장한 뒤에는 할 일과 결과를 받을 대상을 요약하고 매 실행 결과를 그곳으로 전달한다고 설명한다. 해당 항목은 0.69.0부터 0.70.1까지도 포함하므로 모든 기능이 0.70.2에서 처음 생겼다는 뜻은 아니다. Grok Bot 변경 기록

이 변화의 의미는 “메일도 보낸다”보다 넓다. 반복 업무에는 입력이 들어오는 곳, 판단이 멈추는 곳, 결과가 도착하는 곳이 모두 필요하다. 셋을 정해 두면 사람이 매번 자료를 복사하고 진행 여부를 묻는 일을 줄일 가능성이 있다. 다만 실제 절약 시간은 연결 상태와 검토 부담에 따라 달라지며, 이 글에서는 측정하지 않았다.

여러 봇을 만들어도 작업 공간은 함께 쓴다

처음에는 문의 담당 봇 하나면 충분하다. 공식 입문 가이드는 이름·직함·설명을 대화나 Settings에서 지정하고, 대화 요청·루틴과 외부 이벤트·다른 봇의 호출로 일을 시작하는 방식을 설명한다. 별도 전문성이 필요해졌을 때 조사 담당이나 초안 담당을 추가하면 된다. Grok Bot 101

이때 구조를 정확히 읽어야 한다. 현재 제품 FAQ는 한 사용자의 봇들이 하나의 지속 클라우드 컴퓨터를 공유하며 파일·브라우저·로그인도 함께 사용한다고 명시한다. 같은 컴퓨터에 접근하는 봇의 이름을 ‘조사’와 ‘발송’으로 나눴다고 해서 서로 다른 계정 권한이 생기지는 않는다. 공유 컴퓨터 FAQ

이는 인계에 유리하다. 조사 담당이 정리한 파일을 초안 담당에게 매번 내려받아 올리는 단계를 줄일 수 있다. 대신 같은 업무표를 동시에 고치는 담당자가 여럿이면 최신 상태를 정하기 어렵다. 아래 사례에서는 업무표를 갱신하는 담당은 하나로 두고, 다른 봇은 근거와 초안을 그 담당에게 돌려주도록 제안한다. 제품이 강제하는 잠금 기능이 아니라 업무 운영 규칙이다.

공식 다중 봇 사례도 프로젝트별 채널과 Notion의 Projects·Tasks 데이터베이스로 일을 조율한다. 저자는 이를 실험 중인 패턴이라고 밝힌다. 그 글의 ‘PM 외 최대 다섯 봇’ 역시 작성자가 정한 수이지 제품 한도가 아니다. 팀을 그대로 복제하기보다 어떤 자료를 누가 갱신하는지부터 가져오자. 공식 다중 봇 운영 사례

사례: 아침 문의를 분류하고 답장 초안까지 준비하기

가상 소프트웨어 팀의 문의 담당자가 매일 아침 반복 질문과 오류 제보를 읽는다고 하자. 목표는 문의를 모두 자동 처리하는 것이 아니라 답할 수 있는 항목은 근거 있는 초안으로, 자료가 부족한 항목은 구체적인 질문으로 돌려받는 것이다. 아래 번호와 입력은 이 글에서 만든 가상 자료다.

공식 지원팀 가이드는 연결 도구와 업무 맥락을 준비한 뒤 버그 재현·정책에 따른 판단·보고서를 맡기고 반복 루틴으로 연결하는 사례를 제시한다. 가이드 자체도 숫자와 세부 사항을 설명용이라고 표시한다. 그 사례를 성공률 증거로 쓰지 않고, 다음과 같은 작은 도입 과제로 바꿔 볼 수 있다. Grok Bot for Support

1. 입력과 정본을 먼저 고정한다

시험용 문의 사본 다섯 건, 현재 공개 도움말, 사람이 관리하는 처리표를 준비한다. 실제 고객 계정·결제 도구를 연결하기 전에 이 자료만으로 분류와 인계가 맞는지 볼 수 있다. 봇 전용 이메일 수신 경로를 사용할지 기존 업무 도구를 연결할지도 정한다. 주소를 새로 만드는 것과 기존 고객지원 시스템의 모든 기능을 대체하는 것은 별개다.

가상 입력	요청할 산출물	완료로 세기 전 확인
Q01: 공개 도움말에 답이 있는 설치 질문	도움말 링크와 답장 초안	질문한 환경에 해당하는 설명인가
Q02: 오류 메시지만 있는 제보	필요한 버전·재현 단계 질문	재현하지 않았는데 해결했다고 쓰지 않았는가
Q03: 앞선 메일의 같은 질문을 다시 전달	기존 문의와의 연결 후보	다른 사건까지 같은 건으로 합치지 않았는가
Q04: 예외 처리가 필요한 계약 질문	판단 담당자에게 넘길 요약	새 약속이나 조건을 임의로 만들지 않았는가
Q05: 이미 답장한 문의에 추가 정보 도착	새 정보와 기존 답의 차이	보낸 답장을 다시 보내지 않는가

이 표의 중요한 단위는 메일 수가 아니라 문의의 상태다. Q03은 새 메일이지만 이미 진행 중인 문의일 수 있고, Q05는 오래된 문의지만 새 검토가 필요할 수 있다. 따라서 ‘지난번 이후 온 메일’만 기준으로 완료를 판단하면 재처리와 누락을 구별하기 어렵다.

2. 한 번 실행할 요청을 짧고 구체적으로 쓴다

아래는 복사해 수정할 수 있는 업무 지시 예시다. 실행 코드나 Grok Bot에 설치되는 템플릿이 아니며, 이 문구만으로 중복 방지·권한 통제가 기술적으로 보장되지는 않는다.

시험용 문의 사본 Q01~Q05를 읽고 처리표 초안을 만들어 줘.
답의 근거는 내가 지정한 공개 도움말로 제한해.
문의별로 원문 참조, 마지막 확인 시각, 판단 근거,
답장 초안 또는 부족한 정보, 다음 담당자를 남겨 줘.
중복처럼 보여도 근거 없이 합치지 말고 연결 후보로 표시해.
이미 보낸 답이 있으면 새 정보와 달라진 부분만 정리해.
외부 발송과 계약·계정 변경은 하지 말고 내 검토를 기다려.
읽지 못한 자료는 빈 결과로 처리하지 말고 막힌 위치를 알려 줘.

한 번의 결과가 맞으면 반복 요청으로 옮긴다. 예를 들어 ‘평일 09:00, Asia/Seoul 기준, 문의 담당자와의 대화에 결과 전달’처럼 시간대·작업·받을 사람을 함께 정한다. ‘아침마다’만 적어 두면 팀의 지역이 달라졌을 때 약속이 모호하다. 이는 제안한 일정 명세이며 Grok Bot의 내부 시간대 저장 방식이나 휴일 처리를 검증한 결과가 아니다. 반복 시각 설계는 UTC와 현지 시각 글에서 더 자세히 다룬다.

3. 초안과 실제 행동을 다른 상태로 남긴다

처리표의 ‘완료’ 하나로 끝내지 말자. 초안은 준비됐지만 아직 승인받지 못했거나, 승인 후 발송 결과가 확인되지 않았을 수 있다. 아래는 이 글의 권장 기록 형식이며 제품에 원래 있는 상태 이름은 아니다.

Q02는 ‘질문 초안 준비’가 적절한 결과다. 오류를 재현하지 못했어도 필요한 입력을 명확히 요청했다면 담당자의 다음 행동을 도왔다. 반대로 Q01의 답장이 그럴듯해도 실제 발송 증거가 없으면 ‘발송 완료’로 표시하면 안 된다. 초안의 품질과 외부 행동의 완료를 나누면 검토할 때 읽어야 하는 자료도 줄어든다.

화면에서는 상태·결과·조작권을 다른 곳에서 확인한다

다음은 공식 설계와 변경 기록을 읽은 안내다. 제품 화면을 직접 캡처하거나 창 크기별로 조작한 결과는 아니다.

공식 설계 글은 사이드바의 중심을 일회성 채팅보다 지속적인 봇 목록에 두고, 아바타의 움직임으로 활동 상태를 알린다고 설명한다. 컴퓨터는 상태 표시에서 시작해 옆 패널 미리보기, 필요할 때 전체 화면 인수로 깊이를 나눈다. 계속 지켜보도록 만드는 UI보다 필요한 순간에 들어가 확인하도록 설계했다는 취지다. 공식 인터페이스 설계

확인하려는 것	문서에서 찾을 영역	문의 사례에서 할 판단
지금 어느 담당자가 일하는가	봇 목록·아바타의 활동 표시	일이 진행 중인지 살펴본 뒤 필요한 대화 열기
무엇을 검토해야 하는가	대화 안 결과·초안 카드	Q01의 받는 사람·내용·근거 확인
접속 문제를 사람이 해결해야 하는가	컴퓨터 미리보기·전체 화면	보고만 있을지 직접 조작할지 결정
다음 회차가 어디로 전달되는가	저장한 루틴의 작업·수신자 요약	담당자에게 도착하도록 지정됐는지 확인

10월 변경 기록은 전체 화면 컴퓨터가 먼저 Watching으로 열리고, Take control을 눌러야 조작권을 받는다고 설명한다. 발송 가능한 계정이 여럿이면 사용할 주소를 묻고 발송한 주소도 알려 준다는 변경도 있다. 따라서 창이 열렸다는 것, 초안을 승인했다는 것, 어느 계정으로 보냈는지는 각각 확인할 항목이다. 현재 동작의 변경 근거

넓은 창에서는 대화와 컴퓨터 미리보기를 함께 보며 원인과 결과를 대조하는 것이 유용하다. 작은 화면에서 패널이 실제로 어떻게 재배치되는지와 키보드 포커스 순서는 이번에 확인하지 못했다. 모바일에서 검토한다면 요약만 보고 승인하지 말고, 받는 사람과 초안 전체를 열 수 있는지 먼저 확인하자. 이 글의 흐름도는 작은 화면에서도 위에서 아래로 읽도록 그렸으며 제품의 모바일 배치를 재현한 그림은 아니다.

중단됐을 때는 마지막 메시지보다 마지막 확인 상태로 돌아간다

아래는 예상할 수 있는 실패를 넣어 본 복구 설계다. 실제 제품 장애를 관측한 목록이 아니다. 필요한 상태를 처리표나 연결한 업무 도구에서 확인할 수 없다면 자동 재개를 서두르지 말고 사람이 먼저 대조한다.

중단 상황	먼저 확인할 것	재개할 범위
문의 시스템 조회 실패	조회 범위·마지막 성공 시각	못 읽은 범위만 다시 조회. 결과 없음으로 보고하지 않기
Q01 초안 뒤 도움말이 변경됨	초안이 참고한 근거와 새 문서	영향받는 문단을 다시 작성하고 검토 요청
사람이 답을 고치는 동안 다른 봇도 수정	현재 정본과 최종 수정 담당	두 변경을 대조한 뒤 담당 하나가 반영
발송 요청 뒤 결과를 받지 못함	보낸편지함·도구의 실제 결과	성공 여부가 불명확하면 즉시 재발송하지 않기
반복 회차가 다음 회차와 겹침	이전 회차의 처리 중 항목	이미 맡은 문의를 대조하고 남은 범위 결정

‘자동으로 계속 일한다’는 특성은 이 대조 과정을 없애지 않는다. 오히려 사람이 자리를 비운 동안 작업이 이어지므로 어느 입력을 읽었고 어떤 외부 행동이 확인됐는지가 다음 날의 출발점이 된다. 문의 업무 양식 내려받기에 시작 조건과 문의별 기록, 재개 점검 항목을 묶었다. 제품 전용 자동화나 실행 검증된 설치 파일은 아니다.

팀이 함께 쓰는 봇과 복제한 템플릿은 다르다

한 사람의 봇 여러 개를 조율하는 것과 여러 사람이 같은 Team Bot을 사용하는 것은 별도 문제다. 9월 28일 공식 발표는 Team Bots를 Teams·Enterprise의 공개 베타로 소개했다. 공통 파일·지침·스킬과 연결 도구를 제공하되 개인 대화의 맥락·기억은 사용자별로 분리한다고 설명한다. 현재 제품 FAQ의 일반 Enterprise 제공 설명을 Team Bots의 베타 종료 근거로 읽지는 않는다. Team Bots 발표

문의 담당자가 교대하는 조직이라면 이 구분이 중요하다. 공통 정책을 봇에 제공할 수 있어도, 한 담당자의 개인 대화에서 결정한 내용을 다음 담당자가 당연히 볼 수 있다고 가정하면 인계가 비게 된다. 정책 변경·최종 처리 상태·다음 담당자는 팀이 읽을 수 있는 정본에 남기는 방식을 제안한다. 개인 대화 전체를 공유하라는 뜻은 아니다.

템플릿은 다른 사용자에게 새 봇 사본을 만드는 경로다. 공식 템플릿 가이드는 지침·관련 기억·스킬·플러그인을 묶되 사용자 코드나 비표준 MCP 서버 등의 실행 환경까지 그대로 복제하지 않는다고 설명한다. 추가 전에 세부 내용을 확인하고, 새 사본의 연결과 필요한 설정을 갖춰야 한다. 템플릿 가이드

따라서 이 문의 업무를 동료에게 넘길 때는 먼저 목적을 정하자. 같은 문의를 공동 처리하려면 팀이 보는 정책·처리표·담당 체계가 필요하다. 자기 부서에서 별도로 실행하게 하려면 템플릿과 함께 어떤 도움말, 수신 경로, 처리표를 새로 연결해야 하는지 전달해야 한다. 완성된 봇의 이름만 공유해서는 두 요구 모두 충분히 설명되지 않는다.

이용 조건과 첫 도입의 판단 기준

10월 16일 제품 페이지의 개인 월 결제 표시는 Premium 30달러, Super 100달러, Ultra 200달러다. 주간 사용량이 포함되고 추가 사용은 토큰 비용에 따라 청구된다는 FAQ 설명이 있으므로, 월 요금을 무제한 업무 처리 가격으로 보면 안 된다. 데스크톱 macOS·Windows와 iOS 이용 경로를 안내하지만 한국 계정의 실제 가입·연결 화면은 이번에 확인하지 않았다. 현재 제품·요금 안내

10월 12일 The X Subscription 발표는 Grok·Grok Bot·Cursor·X Premium을 묶는 방향과 기존 구독의 전환을 설명한다. 기존 가입자는 현재 플랜을 유지할 수 있으며 전환 가능 여부는 계정 결제 설정에서 확인하도록 안내한다. 발표 당시의 전 세계 확대 계획을 모든 계정의 전환 완료로 받아들이지는 말자. 구독 통합 발표

도입 효과를 보려면 먼저 문의 사본으로 한 회차를 끝내고 근거가 맞는 초안, 부족한 정보를 정확히 짚은 질문, 중단 후 다시 설명해야 한 내용을 살펴보자. 반복 시험에서는 실제 사용량과 사람의 수정·검토 시간을 함께 기록한다. 봇 수나 만든 문서 수만으로 성과를 판단하면 확인 부담이 늘어도 성공처럼 보일 수 있다.

입력 도구가 연결돼 있고 비슷한 판단이 반복되며 검토할 담당자가 정해져 있다면 이 제품의 지속 작업 구조를 시험할 이유가 있다. 반대로 건수가 적은 일회성 질문이거나 매번 접근 권한과 정책이 바뀐다면, 봇과 루틴을 유지하는 일이 오히려 추가 업무가 될 수 있다. 제품 자체의 선택이 아직 남아 있다면 Muse·Dots·Grok Bot 비교로 돌아가 실행 장소부터 비교하고, 이번 업무 설계는 저장해 첫 회차와 다음 회차를 대조할 때 사용하면 된다.