Grok Bot 공개: 상시 실행 에이전트 팀은 무엇이 달라졌나

xAI가 8월 11일 Grok Bot ↗을 Early beta로 공개했습니다. 한 번의 대화에서 답하는 Bot이 아니라, 각 Bot이 자체 컴퓨터를 갖고 여러 앱에서 일을 이어 하다가 판단이 필요할 때만 사람에게 돌아오는 형태입니다.

먼저 결론부터 말하면, Grok Bot의 흥미로운 점은 새로운 모델 능력 하나보다 에이전트를 실제 동료처럼 배치하는 UX에 있습니다. 클라우드 컴퓨터, 지속 실행, 스레드 기반 맥락, 여러 Bot의 협업을 한데 묶어 사용자가 작업 중계자가 되지 않도록 설계했습니다.

이 글에서는 다음을 살펴봅니다.

• 상시 실행 Bot을 가능하게 하는 제품 구조
• 여러 Bot을 동시에 쓸 때 달라지는 일의 흐름
• 실제 도입 전에 사람이 정해야 할 승인과 권한의 경계

대화형 AI에서 맡기는 AI로

공식 발표 ↗에 따르면 Grok Bot은 Bot별 컴퓨터를 클라우드에 두고, 사용자가 이미 쓰는 앱·도구·inbox에 로그인해 작업합니다. 사용자가 자리를 비운 동안에도 작업이 멈추지 않고, 완료하거나 승인이 필요한 시점에 다시 사용자에게 알려주는 방식입니다.

이 구조는 API나 MCP가 깔끔하게 준비된 도구만 겨냥하지 않습니다. xAI는 Bot이 앱, 도구, 웹사이트를 넘나들 수 있으며 API/MCP가 없는 플랫폼에서도 일할 수 있다고 설명합니다. 즉, 자동화의 출발점이 워크플로우 빌더가 아니라 “이 일을 맡아 달라”는 메시지가 되는 셈입니다.

이전 Grok 4.5는 xAI가 coding과 agentic task를 위한 모델을 강조한 흐름을 다뤘습니다. Grok 4.6의 포스트 트레이닝은 장기 에이전트의 검증 루프에 초점을 맞췄고, 이 글은 그 능력을 사용자가 어떻게 일로 위임할 수 있는지에 초점을 둡니다.

핵심은 네 가지가 함께 움직이는 것입니다

단일 에이전트에게 긴 프롬프트를 주는 것과, 일을 계속 맡겨 두는 것은 다릅니다. Grok Bot이 제시한 흐름은 실행 환경과 협업 맥락까지 포함합니다.

flowchart TD
    A[사용자: 업무 위임] --> B[Bot별 클라우드 컴퓨터]
    B --> C[앱·도구·웹사이트에서 다단계 작업]
    C --> D[스레드 맥락과 선호 기억]
    D --> E{승인이 필요한가?}
    E -->|예| F[사용자에게 판단 요청]
    E -->|아니오| G[결과·다음 작업으로 전달]
    F --> C

이 도식은 제품의 개념적 흐름이며, 각 기능이 항상 이 순서로 실행된다는 뜻은 아닙니다. 첫째는 실행 환경입니다. 작업이 로컬 브라우저 탭에 매여 있지 않으므로, 사람이 화면을 계속 열어 둘 필요가 없습니다. 둘째는 대화의 지속성입니다. 공식 발표 ↗는 데스크톱과 iOS에서 같은 Bot 스레드를 이어갈 수 있고, Bot이 대화와 선호를 기억한다고 설명합니다.

셋째는 관찰을 통한 routine화입니다. xAI는 사용자가 작업을 한 번 보여 주면 Bot이 단계를 관찰하고, 이후에는 수정 사항을 반영해 routine으로 저장할 수 있다고 소개합니다 ↗. 넷째는 승인 지점입니다. 공식 발표의 설명처럼 ↗, 이 제품의 약속은 무제한 자동 실행이 아니라, 끝까지 처리하되 중요한 판단에서는 사람을 다시 호출하는 데 있습니다.

여러 Bot을 쓰면 중계 비용이 줄어듭니다

사람이 여러 AI 채팅창을 오가면 계획을 복사하고, 진행 상태를 물어보고, 결과를 다시 다음 에이전트에게 전달해야 합니다. 공식 발표에서 ↗ Grok Bot은 여러 Bot이 병렬로 일하고, 서로 메시지를 보내며 스레드 안에서 맥락을 공유하는 형태를 제시합니다.

예시로 책임자를 보조하는 Bot 아래에 inbox 관리, 비용 처리, 채용, 버그 수정 같은 전문 Bot을 둘 수 있습니다. 프로젝트가 겹쳐도 사람이 매번 배경 설명을 붙이지 않도록 하는 것이 목적입니다. xAI가 내부 프로토타입에서 sales outbound, 마케팅 캠페인, 사무 운영, 버그 수정에 사용했다고 밝힌 사례 ↗도 이 구성이 단순 답변 생성보다 업무 흐름에 가깝다는 점을 보여 줍니다.

다만 병렬 처리량이 늘어나는 만큼, 누가 어떤 작업을 소유하고 어디까지 결정을 내릴 수 있는지는 더 분명히 해야 합니다. 멀티 에이전트의 병목은 종종 모델의 추론이 아니라 책임과 승인 경계입니다.

도입 전에는 권한보다 경계를 먼저 정해야 합니다

실무에서는 처음부터 모든 권한을 주기보다 다음 순서가 안전합니다.

1. 읽기와 초안 작성처럼 되돌리기 쉬운 업무부터 Bot에 맡깁니다.
2. 외부 발송, 데이터 변경, 비용 발생처럼 영향이 큰 작업은 명시적인 승인 단계 뒤에 실행되도록 둡니다.
3. routine은 원래 의도와 지금의 업무 규칙이 여전히 같은지 주기적으로 점검합니다.

이 체크는 Grok Bot만의 규칙은 아닙니다. Claude Code의 안전 모드에서 다룬 것처럼, 자율성은 권한을 넓히는 일이 아니라 사람이 확인해야 할 순간을 더 또렷하게 만드는 설계와 함께 가야 합니다.

마무리

Grok Bot은 에이전트를 “질문에 답하는 모델”에서 “계속 일하는 동료”로 재구성합니다. 클라우드 컴퓨터와 스레드 맥락, routine, Bot 간 협업을 결합해 사람의 중계 비용을 줄이려는 제품입니다.

Early beta인 만큼 곧바로 핵심 업무를 통째로 넘기기보다, 명확한 입력과 검토 가능한 결과가 있는 작은 반복 업무에서 먼저 경계를 시험해 보는 편이 좋습니다. 좋은 에이전트 도입은 일을 더 많이 시키는 데서 시작하지 않고, 무엇을 자동으로 계속하게 할지 합의하는 데서 시작합니다.

참고 자료

• xAI: Introducing Grok Bot ↗ — 공개일, 제공 범위, 작동 방식
• GeekNews: Grok Bot 공개 ↗ — 국내 요약과 토론