이 글은 Grok Bot이 기존의 자체 모델 중심 구조에서 벗어나 Claude Opus 5.5 같은 외부 모델을 활용하는 방식으로 바뀐 점을 설명한다. Grok Bot이 컴퓨터, 로그인, 기억, 반복 작업을 관리하는 '하니스' 역할을 하고, Opus 5.5가 실제 추론을 담당하는 구조다. 글은 이 조합을 활용해 전문 봇과 자동화 루틴을 만들되, 데이터 접근과 외부 행동에는 사람이 정한 엄격한 경계를 두라고 제안한다.
1. 모델과 하니스의 분리
글은 에이전트가 대체로 하나의 회사가 만든 모델과 실행 환경을 함께 제공해 왔다고 설명한다. 여기서 하니스란 에이전트가 사용하는 컴퓨터, 로그인, 기억, 작업 루틴 등을 말하고, 브레인은 그 안에서 판단하고 일을 수행하는 모델을 뜻한다.
글에 따르면 10월 6일 미국 시간 늦은 시각, 일론 머스크는 X에 SpaceX가 작업에 따라 가장 적합한 백엔드 모델을 사용하겠다고 밝혔다. 언급된 모델과 서비스에는 Claude Opus 5.5, Midjourney, Suno 등이 포함됐다. 머스크는 선택 기준을 다음과 같이 설명했다.
"무엇이든 가장 좋은 결과를 줄 가능성이 높은 것을 사용하겠습니다."
몇 시간 뒤 Grok Bot 팀의 Lauren은 이를 구체화해, 모든 봇이 Opus 5.5로 구동되며 Cursor 모델을 사용하는 클라우드 에이전트도 실행할 수 있다고 알렸다고 글은 전한다. 10월 7일에는 9to5Mac이 이 변경 사항을 보도했다.
글의 핵심 해석은 Grok Bot이 하니스를 계속 보유하면서, 그 안에서 작동하는 브레인으로 Anthropic의 모델을 채택했다는 것이다. 다만 성능 비교에는 주의가 필요하다고 덧붙인다. Artificial Analysis 자료에서 비교한 Grok은 Grok 4.6이며, Grok 4.7과 같은 시기에 측정된 것도 아니다. 글은 그럼에도 다단계 에이전트 작업을 평가하는 Terminal-Bench에서 격차가 크게 나타났다고 강조한다.
2. Grok Bot의 작동 방식과 첫 봇 만들기
글에 따르면 Grok Bot은 브라우저 탭이 아니라 Mac, iPhone, iPad에서 사용하는 앱이다. Grok 또는 Cursor 계정으로 로그인하며, 별도 상품이라기보다 일부 SuperGrok 및 유료 Cursor 요금제에 포함된 형태라고 설명한다.
화면은 챗봇보다는 메시징 앱에 가깝다. 왼쪽에는 이름을 붙인 봇들이 있고, 오른쪽에는 대화가 표시된다. 각 봇은 클라우드에 자신만의 컴퓨터를 갖는다. Grok Bot 팀의 설명대로라면 Opus 5.5는 모든 봇의 기본 모델이므로, 이용자가 따로 Claude 구독을 추가하거나 모델을 전환할 필요는 없다.
처음에는 여러 전문 봇을 만들기보다 Chief라는 범용 봇 하나로 시작하라고 글은 권한다. 어떤 전문 봇에 맡겨야 할지 아직 모르는 일을 우선 Chief에게 전달하는 방식이다. 처음부터 큰일을 맡기기보다는, 결과를 30초 안에 확인할 수 있는 작은 실제 업무를 줘서 신뢰도를 살펴보라는 조언도 포함된다.
프롬프트 하나가 일회성 요청이라면, 봇은 특정 역할을 맡아 기억을 쌓고 업무 영역을 관리하는 존재로 설명된다. 따라서 "질문에 답해 줘"보다는 Inbox Manager, Research Lead, Sales Outbound처럼 직무를 나타내는 이름을 붙이는 것이 좋다고 한다.
3. 역할과 권한을 정하는 헌장 쓰기
봇을 만들면 신입 직원에게 업무를 설명하듯 역할을 정해 줘야 한다. 글은 헌장에 세 가지를 명확히 쓰라고 제안한다. 봇이 무엇을 맡는지, 좋은 결과의 기준이 무엇인지, 어떤 상황에서 멈추고 사람에게 물어봐야 하는지다.
Opus 5.5를 쓰면 이전 기본 모델보다 긴 작업을 맡길 수 있지만, 그렇다고 권한까지 넓혀서는 안 된다고 강조한다. 글은 Opus 5.5가 API에서 100만 토큰의 컨텍스트 창과 최대 12만 8천 토큰의 출력을 지원한다고 소개하면서도, Grok Bot에서 이 기능을 어느 정도 제공하는지는 공개되지 않았다고 밝힌다.
연구 봇의 예시는 주제를 받으면 1차 자료를 찾고, 인용할 페이지를 직접 열어 확인하며, 최소 두 출처에서 수치를 대조한 뒤 1,500단어 분량의 보고서를 작성하도록 한다. 모든 수치 옆에 링크를 붙이고, 출처가 다르면 평균을 내지 말고 충돌 사실을 표시하게 한다. 완성본은 채팅이 아니라 Drive 폴더에 저장한다.
반면 외부에 게시하거나 이메일을 보내는 일은 금지하고, 두 출처의 차이를 해결하지 못하면 멈춰서 물어보도록 설정한다. 글의 원칙은 분명하다.
"더 똑똑한 브레인은 더 많은 단계를 맡아야지, 더 많은 권한을 가져서는 안 됩니다."
4. 연결 서비스와 데이터 접근 제한
Grok Bot에는 Notion, Slack, Google Drive, AWS Agents, AWS SageMaker, Browserbase, Composio, Context7 등의 플러그인을 한 번에 연결하는 패널이 있다고 글은 설명한다. 연결은 계정 단위라서 Gmail을 한 번 연결하면 새로 만든 봇들도 사용할 수 있다. 편리한 대신, 봇이 접근할 수 있는 범위가 넓어질 수 있다.
글은 Opus 5.5가 작업에 사용하는 데이터를 Anthropic에 전달하게 된다는 점도 짚는다. 머스크의 게시물 아래에 올라온 데이터 제공 거부 관련 질문에는 답이 아직 없으며, SpaceXAI도 무엇이 공유되는지에 관한 약관을 발표하지 않았다고 서술한다. 따라서 이용자가 모델이 실행되는 장소를 직접 선택하지 못하더라도, 봇이 무엇을 열어 볼지는 제한해야 한다는 조언이다.
모든 봇의 헌장에 법무·재무 폴더, 변호사·회계사·은행의 이메일, 비밀번호·시드 문구·2단계 인증 코드가 포함된 메시지는 열거나 읽거나 요약하지 말라고 적으라고 제안한다. 이런 정보가 필요한 업무라면 먼저 멈춰서 물어보고, 문서를 다룰 때는 작업에 필요한 내용만 사용하게 하라는 것이다.
"베타 기간에는 모든 연결이 모든 봇에 닿고, 이제는 한 곳이 아니라 여러 회사가 데이터를 처리합니다."
5. API가 없는 서비스와 안전한 로그인
실제 회사에서 쓰는 소프트웨어에는 API나 MCP 서버가 없는 경우가 많다. 글은 Grok Bot이 이런 서비스도 다룰 수 있는 방식으로 클라우드 브라우저와 사용자 로그인 인계를 소개한다.
봇은 클라우드 브라우저로 사이트를 탐색하다 로그인 화면을 만나면 사용자에게 화면을 넘긴다. 사용자가 직접 로그인하고 완료를 누르면, 봇은 같은 브라우저 세션에서 작업을 이어 간다. 이 방식에서는 봇에게 비밀번호를 채팅으로 알려 주는 대신 로그인된 세션을 넘겨주는 셈이라고 설명한다.
특히 외부 모델이 작업에 참여하는 상황에서는 비밀번호를 대화창에 붙여 넣지 않는 것이 중요하다고 강조한다.
"어떤 도구든 메시지에 비밀번호를 붙여 넣으라고 한다면, 그건 잘못된 경로입니다."
6. 작업을 한 번 보여 주고 반복 루틴 만들기
봇에게 직접 작업을 한 번 보여 주며 절차를 익히게 할 수도 있다. 사용자가 화면에서 과정을 수행하면 봇이 단계를 저장하고, 다음에는 스스로 실행하는 방식이다. 글은 첫 번째 자동화 대상으로 매주 반복되고, 두 개 이상의 앱을 거치며, 절차가 잘 바뀌지 않는 일을 추천한다. 말로 설명하기에는 번거롭지만 직접 보여 주기에는 짧은 업무가 적합하다는 뜻이다.
루틴은 복잡한 워크플로 빌더 없이 자연어로 예약하거나 조건을 지정할 수 있다고 설명한다. 예를 들어 평일 오전 7시에 캘린더와 받은편지함, Slack의 #launches 채널을 확인해 그날 일정과 답장이 필요한 일, 밤사이 바뀐 내용을 짧게 정리하게 할 수 있다. 또는 연락처에 없는 도메인에서 가격을 언급한 이메일이 오면 템플릿에 따라 답장 초안을 작성하고 보관하도록 할 수 있다.
좋은 결과를 냈던 작업 뒤에 "이걸 매주 실행해"라고 말해 루틴으로 만드는 방법도 제시한다. Opus 5.5의 강점은 웹사이트 레이아웃이나 입력 형식이 바뀌어 루틴이 흔들릴 때, 작업을 조정해 복구할 가능성이 더 높다는 점이라고 글은 설명한다.
7. 여러 전문 봇과 Cursor 에이전트 활용하기
여러 업무를 한 봇에 몰아주기보다 영역별 봇을 병렬로 운영하는 것이 좋다고 글은 제안한다. 봇마다 기억과 맥락이 분리되므로 어떤 부분에서 문제가 생겼는지 확인하기 쉽다. SpaceXAI 내부에서도 영업 연락, 마케팅, 사무 운영, 버그 수정 등을 담당하는 봇을 쓴다고 소개한다. 업무의 크기보다 업무 영역을 기준으로 나누라는 조언도 덧붙인다. 예를 들어 영수증만 다루는 Expense Manager는 해당 사용자의 영수증 처리에 익숙해질 수 있다.
또 하나의 기능은 봇이 Cursor의 여러 모델을 사용하는 클라우드 에이전트를 실행할 수 있다는 점이다. 글은 이를 Opus 기반 봇이 작업 계획과 맥락을 맡고, Cursor 에이전트들이 병렬로 실제 코딩을 수행한 뒤, 봇이 결과를 검토하는 구조로 설명한다. SpaceX가 8월 600억 달러 규모의 거래로 Cursor를 인수했다는 내용도 이 연결의 배경으로 언급한다.
예시로는 GitHub에서 버그 표시가 붙은 이슈를 발견하면 봇이 먼저 재현하고 실패 테스트를 작성한 뒤, Cursor 에이전트에게 새 브랜치에서 수정하게 하고 전체 테스트를 실행하는 흐름을 제안한다. 결과는 수정 사항과 테스트, 세 줄 요약이 담긴 초안 PR로 열게 하되, 병합하거나 main 브랜치에 푸시하지 않도록 한다. 인증, 결제, 데이터베이스 마이그레이션을 건드리는 수정은 사람에게 넘긴다.
글은 봇들이 서로 메시지를 주고받으며 작업을 나누고 맥락을 공유할 수도 있다고 설명한다. SpaceXAI의 예에서는 한 엔지니어링 봇이 버그를 재현해 티켓을 만든 다음, 디버깅에 더 적합한 두 번째 봇에게 업무를 넘긴다. 이런 봇 간 책임 이관은 단일 대화형 도구와 구별되는 기능으로 제시된다. 9월 말부터는 팀이 공유 봇을 게시해 동료가 앱이나 Slack에서 사용하는 기능도 가능해졌다고 한다.
8. 그룹 봇에는 작업 목록보다 목표를 주기
여러 봇을 한 그룹 대화에 넣을 때는 세부 작업을 일일이 나열하기보다 공통 목표를 주는 방식이 효과적이라고 글은 권한다. 작업 목록을 주면 사람이 이미 업무를 나눈 셈이지만, 목표만 주면 봇들이 스스로 업무를 분해하고 적절한 역할에 배정할 수 있기 때문이다.
예를 들어 "금요일 오후 5시까지 10월 뉴스레터를 출시한다"는 목표를 주고, Research Lead는 사실과 출처를, Inbox Manager는 구독자 답장을, Chief는 일정과 막힌 부분을 맡도록 정할 수 있다. 봇들에게는 일을 스스로 나누게 하되, 외부에 공개될 내용은 사람의 검토를 기다리게 한다.
9. 되돌릴 수 있는 일과 승인받을 일을 구분하기
Grok Bot의 기본 구상은 봇이 업무를 끝까지 진행하고, 사람의 승인이 필요한 순간에만 돌아오는 것이다. 따라서 봇이 무엇을 승인 없이 해도 되는지 사람이 명확히 정해야 한다고 글은 강조한다.
기준은 업무의 크기가 아니라 되돌릴 수 있는지다. 초안 작성, 분류, 요약, 조사, 준비, 대조처럼 쉽게 되돌릴 수 있는 일은 봇이 처리하고 기록하게 한다. 반면 회사 밖의 사람에게 메시지를 보내는 일, 돈을 쓰거나 옮기는 일, 가격을 약속하는 일, 공개 게시, 중요한 파일 삭제, 약관 동의나 가입은 사람에게 넘긴다.
"1분 안에 되돌릴 수 없다면, 멈추고 물어보세요."
글이 권하는 이상적인 상태는 초안은 충분히 쌓이되 외부로 전송된 것은 없는 모습이다. 즉, 되돌릴 수 있는 단계는 모두 완료하고, 되돌릴 수 없는 행동 직전에 확실히 멈추는 것이다.
10. 비용과 제공 상태를 확인하고 정기적으로 점검하기
글은 Opus 5.5가 저렴한 모델은 아니라고 설명한다. API 가격을 기준으로 입력 3만 토큰, 출력 8천 토큰 정도의 작은 작업은 Opus 5.5가 약 28센트, Grok은 약 11센트라고 예시를 든다. 다만 매우 긴 컨텍스트에서는 비용 관계가 뒤집힐 수 있는데, 글에 따르면 Grok 요금은 20만 토큰을 넘으면 두 배가 되는 반면 Opus 요금은 일정하게 유지된다.
Grok Bot에서는 토큰별로 직접 결제하지 않고 요금제에 포함되지만, Opus 작업이 요금제 한도를 더 빨리 소모하는지는 SpaceXAI가 밝히지 않았다고 한다. 그래서 처음 한 주는 사용량을 관찰한 뒤 루틴을 늘리라는 조언이 이어진다.
발표된 모든 기능이 곧바로 사용 가능한 것은 아니다. Midjourney와 Suno의 제공 일정은 없고, 출시 첫날 한 사용자의 봇은 Suno를 사용할 수 없다고 답했다고 글은 전한다. 따라서 글은 확인된 Opus 5.5 활용부터 시작하고 나머지는 실제 제공 여부를 기다리라고 제안한다.
마지막으로 매주 15분을 정해 봇들에게 그 주의 작업을 보고하게 하라고 권한다. 각 루틴이 몇 번 실행됐는지, 무엇을 만들었는지, 무엇을 건너뛰거나 실패했는지, 어떤 판단을 추측으로 처리했는지, 사람에게 맡겼지만 답을 받지 못한 항목이 무엇인지 확인한다. 봇이 자기 작업을 평가할 때는 스스로의 맹점도 있을 수 있으므로, 루틴별 결과물 하나는 사람이 직접 점검해야 한다고 덧붙인다.
글의 결론은 모델 자체만을 고르던 경쟁에서, 모델이 작업하는 환경인 하니스의 중요성으로 초점이 옮겨가고 있다는 것이다. 봇에게 맡길 일, 권한의 끝, 접근 가능한 데이터를 헌장에 명시하고, 그 경계 안에서 더 강력한 모델이 일을 수행하도록 하라는 메시지로 마무리한다.