Muse·Dots·Grok Bot 비교: 같은 업무를 맡기면 무엇이 달라지나

지금 비교할 것은 모델보다 업무가 이어지는 방식이다

Muse는 Meta의 개인 에이전트, Dots는 OpenAI의 지속 업무 에이전트, Grok Bot은 컴퓨터를 사용하는 xAI의 봇 제품이다. 이 글의 Muse는 동명의 다른 서비스를 뜻하지 않으며, Grok Bot을 일반 Grok 채팅이나 모델 API와 같은 것으로 다루지 않는다. Muse 소개, Dots 소개, Grok Bot 소개

최근 변화는 모델과 제품의 경계를 더 중요하게 만든다. Meta의 10월 12일 Muse Wonder·Wonder Full 발표는 Wonder의 API·Muse Code 제공과 개인 Muse에 대한 향후 반영을 구분한다. 발표 페이지에는 10월 13일 수정 날짜도 함께 표시된다. 따라서 모델의 새로운 능력을 읽었다고 해서 자신의 개인 Muse에 이미 적용됐다고 판단할 수는 없다. Wonder 발표

비교 기준일은 2026년 10월 15일이다. 아래는 공식 문서에 근거한 구조 비교와 편집 분석이며 세 제품을 직접 실행한 대결이 아니다. 응답 품질, 성공률, 한국 계정의 접근 가능 여부, 실제 청구액은 측정하지 않았다. 이 범위에서도 “내 자료를 어디에 두고, 어떤 일을 맡기며, 무엇을 받아 검토할 것인가”는 구체적으로 결정할 수 있다.

세 제품을 한 과제에 놓고 읽는 지도

예를 들어 한 팀이 사용하는 공개 서비스의 문서가 바뀌었다고 하자. 담당자는 공식 변경 사항을 확인하고, 팀 안내서를 고치고, 예제 페이지의 수정안까지 받고 싶다. 매번 자료를 모으고 앞선 결정을 설명하는 시간이 아깝다. 지속형 에이전트가 겨냥하는 문제다.

이때 아래 세 질문을 순서대로 보자. 어디서 실행하는가 → 무엇이 다음 작업에 남는가 → 사람이 어디서 결과를 받는가. 같은 클라우드 컴퓨터라도 작업 분리 방식이 다르면, 기다리거나 되돌아가야 하는 지점이 달라진다.

제품	문서에서 확인한 작업 구조	도입 때 먼저 판단할 것
Muse	전용 클라우드 VM에서 브라우저·파일·도구를 사용. 주 대화와 side chats, 문서·웹페이지 같은 산출물	목표와 자료를 개인 에이전트에게 모아 주는 방식이 내 업무에 맞는가
Dots	자체 클라우드 컴퓨터에 더해 연결된 개인 컴퓨터, Work·Codex 작업을 조율	필요한 파일·실행 도구가 클라우드와 로컬 중 어디에 있는가
Grok Bot	한 사용자의 여러 봇이 파일·브라우저·로그인을 포함한 지속 컴퓨터를 공유	역할을 나눈 봇들이 같은 작업 공간을 써도 되는가

근거: Muse 설계, Dots 컴퓨터와 앱, Grok Bot FAQ. 오른쪽 열은 이 글의 판단 기준이다. 특정 제품에서만 가능한 업무라는 뜻은 아니다.

Muse: 목표와 결과물을 한 개인 작업 공간에 모은다

Muse 설계 글은 하나의 긴 주 대화에 여러 요청을 이어 가되, 주제를 나눌 필요를 위해 side chats를 제공한다고 설명한다. 일정과 관련 이벤트에 따라 작업을 이어 가고, 문서·PDF·웹페이지 등의 결과물을 만들 수 있다는 설명도 있다. 개인의 여러 일을 함께 조율하려는 제품 구성으로 읽을 수 있다.

이 구조를 위의 팀 안내서 과제에 적용하면, 먼저 공식 자료와 기존 안내서를 주고 어떤 결과물을 갱신해야 하는지 정하는 접근이 자연스럽다. 단순히 “이 주제를 기억해”보다 “이 문서가 기준이고, 새 정보가 기존 결정을 바꾸면 수정 초안을 보여 줘”가 검토하기 쉽다. 이는 제안한 사용 방식이며, Muse에서 해당 안내서를 실제로 수정한 결과는 아니다.

실행 공간을 이해할 때는 전용 VM이라는 말만으로 충분하지 않다. Meta의 기술 설명은 실행 영역과 민감 서비스를 분리하고, 바깥의 Sentinel이 연결 도구의 행동과 외부 통신 권한을 판단한다고 설명한다. 자격 증명도 실행 에이전트가 직접 보는 방식과 분리한다. 공급자가 설명한 설계이며 이 글에서 침투 시험이나 보호 효과를 검증한 것은 아니다.

Dots: 책임은 이어 가되 실행 작업의 위치를 확인한다

Dots의 작업 문서는 지속적인 책임을 맡는 dot과 실제로 만들어진 작업을 구분한다. 클라우드 코딩에는 미리 구성한 Codex 환경을 사용할 수 있고, 로컬 작업은 연결된 컴퓨터에서 수행한다. 선택한 컴퓨터를 바꿔도 이미 만든 작업이 자동으로 이동하지는 않는다.

따라서 안내서만 고칠 때와 로컬 개발 도구로 예제를 빌드할 때는 준비가 달라진다. 컴퓨터 연결 문서에 따르면 클라우드 작업은 개인 기기가 꺼져 있어도 이어질 수 있지만, 개인 컴퓨터를 쓰려면 그 기기가 온라인이고 ChatGPT 앱이 열려 있어야 한다. 클라우드 브라우저는 개인 브라우저의 로그인 상태를 그대로 물려받지 않는다.

여기서 얻는 선택 기준은 명확하다. 밤새 맡길 일이 노트북의 특정 파일·앱에 의존한다면, 먼저 클라우드에서 처리할 수 있는 부분과 로컬이 필요한 부분을 나누자. “dot이 계속 켜져 있다”와 “작업에 필요한 내 컴퓨터가 이용 가능하다”를 별도로 확인해야 한다.

Grok Bot: 역할 분담과 공유 상태를 함께 설계한다

Grok Bot 101은 대화, 루틴·이벤트, 다른 봇의 호출을 작업 시작 경로로 소개한다. 공식 DevRel 사례에서는 자료를 모으는 봇이 초안을 제시하고, 승인 후 Cursor Cloud Agent에 구현을 넘겨 PR과 화면 자료로 돌려받는다. 이는 공급자의 사용 사례이며 이 글의 실행 기록은 아니다.

현재 제품 FAQ는 한 사용자의 봇들이 지속 컴퓨터 하나를 공유하며, 격리 단위가 봇이 아니라 사용자라고 명시한다. 조사 봇과 구현 봇의 이름을 다르게 붙여도 파일·브라우저·로그인이 독립된 계정 공간으로 바뀌지는 않는다.

가이드는 별도 검토 에이전트가 행동을 허용·차단하거나 사람에게 넘기며, 자연어 규칙과 허용·차단 목록을 참고한다고 설명한다. 역할을 여러 개 만들었다는 사실만으로 별도 권한 경계가 생기지는 않는다.

공유는 인계 때 자료를 다시 옮기는 부담을 줄일 수 있다. 반대로 같은 안내서나 예제를 여러 봇이 함께 고치면 어느 결과가 최신인지 정해야 한다. 이 과제에서는 조사 담당이 근거 목록을 만든 뒤 구현 담당에게 넘기고, 최종 파일을 갱신하는 담당은 하나로 두는 방식을 제안한다. 실제 동시 편집 충돌을 관측했다는 뜻은 아니다.

같은 입력으로 맡길 첫 과제: 안내서와 예제의 불일치 찾기

다음은 독자가 자기 자료로 수행할 수 있도록 설계한 가상 과제다. 세 제품에서 실행하거나 완성한 예제가 아니다. 최초 비교에서는 비공개 고객 자료 대신 공개 문서와 배포하지 않는 복사본을 사용하면 연결·기억·인계를 구체적으로 살펴보기 쉽다.

상황은 이렇다. 가상 서비스가 첨부 파일 한도를 바꾸겠다고 예고했다. 발표문에는 미래 적용일이 있고, 현재 도움말과 팀 안내서에는 종전 한도가 남아 있다. 예제 페이지에도 기존 제한값이 들어 있다. 이때 새 숫자만 복사하면 아직 적용되지 않은 기능을 사용자에게 안내할 수 있다.

목표: 공개 문서 변경이 팀 안내서와 예제에 미치는 영향을 정리한다.
입력: 공식 발표·현재 도움말 URL, 안내서 복사본, 예제 복사본.
기준: 발표일 / 실제 적용일 / 이번 확인일을 각각 적는다.
결과: 근거표, 안내서 수정안, 필요할 때만 예제 변경안.
보류: 적용 대상이나 날짜가 다르면 임의로 하나를 선택하지 않는다.
제한: 외부 발송·실서비스 변경·자동 병합은 하지 않는다.
인계: 변경 파일, 확인한 동작, 미실행 검사, 남은 질문을 함께 준다.

결과물은 길이가 아니라 서로 맞는지로 확인한다. 미래 적용일이라면 안내서는 “현재 조건”과 “예정 조건”을 나눠야 하고, 예제의 즉시 변경은 보류할 수 있다. 반대로 새 조건이 이미 적용됐다는 근거가 있으면 안내서와 예제 모두 같은 조건을 설명해야 한다. 제품을 바꿔도 이 완료 조건은 유지된다.

제품에 맞춰 구체화할 부분	이 과제에서 요청할 인계	막혔을 때 판단
Muse: 자료와 갱신할 산출물을 지정	근거가 붙은 안내서 초안과 수정할 파일 목록	저장소 연동을 확인하지 못했다면 파일 수정안 단계에서 받고 개발 환경으로 인계
Dots: 클라우드 또는 로컬 작업 환경 지정	작업 위치·Activity 항목·변경안·실행 기록	로컬이 오프라인이면 클라우드에서 가능한 조사만 이어 갈지 결정
Grok Bot: 조사·구현 담당과 인계 시점 지정	조사 근거 묶음과 구현 담당의 미병합 PR 또는 파일 변경안	공유 컴퓨터의 기존 작업과 겹치면 수정 담당과 순서를 다시 지정

이 표는 공식 구조에 맞춘 과제 설계안이다. Muse가 저장소 작업을 못 한다거나 Dots·Grok Bot이 모든 저장소에 바로 접근한다는 판정이 아니다. 연결 가능한 서비스와 계정 권한을 먼저 확인해야 한다. 산출물 형식을 통일하면 연결 설정이 덜 됐던 제품과 모델 판단이 틀렸던 제품을 구별해 기록할 수 있다.

받는 쪽에서 확인할 인계 묶음

가상 입력의 상태를 “발표문은 다음 달 적용, 현재 도움말은 종전 조건”으로 놓으면, 아래와 같은 결과를 요구할 수 있다. 이는 정답 형식의 예시이며 관측 결과가 아니다.

인계 항목	이 상황에서 남겨야 할 내용
근거와 시점	발표 URL·적용 예정일, 현재 도움말 URL·확인일
안내서 변경	현재 조건 유지, 예정 변경을 별도 문단으로 추가
예제 변경	즉시 활성화하지 않은 변경안 또는 보류 이유
검사 범위	문구 대조는 완료했는지, 예제를 실제 실행했는지 구분
다음 행동	적용일에 현재 도움말과 실제 동작을 다시 확인할 담당·시점

과제·인계 양식 내려받기를 복사해 입력 경로와 완료 조건을 바꿔 쓸 수 있다. 설치 파일이나 제품 전용 자동화가 아니라 이 글에서 만든 텍스트 양식이다.

화면에서는 대화·작업·결과를 나누어 찾는다

버튼을 많이 아는 것보다 어떤 정보를 어디서 확인하는지가 중요하다. 다음은 공식 설계·도움말을 읽은 UI 안내이며 직접 캡처하거나 화면 크기별로 시험한 결과는 아니다.

• Muse: 아바타 아래에는 현재 작업 요약이, 아바타를 누르면 활동 기록과 승인한 권한이 표시된다고 설명한다. Goals는 장기 목표와 계획을 보는 영역이다. 진행을 짧게 확인할 때와 계획을 바꿀 때의 경로를 구분하자. 결과물은 별도로 열어 원자료와 대조한다. 설계 근거
• Dots: 데스크톱에서 프로필의 Activity는 작업의 진행·파일·결과를 여는 경로다. Computers에서는 실행 컴퓨터를 확인하며, 창을 여는 것과 Take over로 조작권을 받는 것은 다르다. 예약은 Scheduled에서 별도로 본다. 작업 문서, 컴퓨터 문서, 제어 문서
• Grok Bot: 가이드는 봇 창에서 클라우드 데스크톱으로 들어가 사람의 로그인이 필요한 단계를 이어받는 흐름을 설명한다. 봇 역할은 Settings의 이름·설명으로, 행동 규칙은 Settings → General → Agent에서 정한다. 봇 이름을 역할과 연결하면 그룹 대화에서도 다음 담당을 찾기 쉽다. 가이드

휴대폰에서 결과를 확인할 때는 긴 대화만으로 소스 변경을 승인하기 어렵다. 원문 링크 → 바뀐 부분 → 아직 확인하지 못한 것 → 필요한 결정 순서로 짧은 인계를 요청하는 방법을 권한다. 넓은 화면에서는 원문과 수정안을 함께 비교하고, 좁은 화면에서는 결정할 항목부터 확인한 뒤 상세 결과물을 열면 된다. 이는 세 앱의 실제 반응형 배치를 설명하는 말이 아니라 검토 방식에 대한 제안이다.

멈췄다가 다시 시작할 때도 차이가 난다

지속 작업에서 “중지”는 하나의 동작이 아닐 수 있다. Dots의 제어 문서는 Pause가 현재 주 작업을 멈추지만, 위임한 모든 작업이나 미래 예약까지 취소하지는 않는다고 설명한다. 작업은 Activity, 반복 일정은 Scheduled에서 따로 확인해야 한다. 이미 수행한 행동도 중지로 되돌아가지는 않는다.

이 구체적인 Dots 동작을 다른 제품에 그대로 적용할 수는 없다. Muse·Grok Bot에서도 이름이 비슷한 중지 기능이 같은 범위를 가진다고 가정하지 말고 현재 작업·하위 작업·반복 실행의 상태를 각각 확인하자. 이번 문헌 비교에서는 세 제품의 중지·복구를 직접 시험하지 않았다.

재개할 때는 “계속해” 한마디보다, 마지막으로 확인한 산출물과 남은 행동을 함께 주는 편이 검토하기 쉽다. 예를 들어 “안내서 수정안은 받았고 예제 실행은 미완료다. 원문 적용일 확인부터 이어 가라”라고 적을 수 있다. 지속 기억이 있더라도 그것이 모든 대화의 완전한 사본이라고 가정하지 않는 방식이다. Dots 문서 역시 저장 노트와 대화 전체를 구분한다. 기억의 범위

가입 전 확인할 이용 조건과 남은 공백

발표 당시 조건과 지금의 도움말을 섞으면 잘못된 선택을 하기 쉽다. 아래는 10월 15일 읽은 자료의 범위다. 구독 이름은 접근 조건이고, 업무량 한도나 실제 비용은 별도 항목이다.

제품	공식 자료에서 확인한 조건	이번에 확인하지 못한 것
Muse	9월 출시 공지는 미국의 iOS·Android·웹 제공과 무료 사용·추가 구독을 설명	현재 한국 제공 여부, 최신 구독 금액·사용량. 홈페이지 접근이 실패해 출시 범위를 현재 전 세계 범위로 확대하지 않음
Dots	현재 도움말상 Pro 100·200·500은 18세 초과이며 EEA·영국·스위스 밖의 사용자. Business Premium·Enterprise는 전 세계 순차 제공, Enterprise는 관리자 활성화 필요	개별 계정의 실제 활성화 시점·남은 사용량
Grok Bot	현재 FAQ상 Cursor Pro·Pro+·Ultra, SuperGrok·Plus·Heavy, Cursor Standard·Premium Teams 및 Enterprise에 접근 경로가 있음. macOS·Windows·iOS 명시	국가별 범위와 한국 계정 접근, 실제 추가 사용 청구액

근거: Muse 출시 공지, Dots 현재 접근 조건, Grok Bot 현재 FAQ. Muse의 미국 출시 기록은 지금도 다른 지역에서는 전부 미지원이라는 증거가 아니다. Dots도 해당 요금제라는 이유만으로 순차 제공이 끝났다고 볼 수 없다.

비용 구조에서도 단순 월정액 비교는 부족하다. Dots는 대화와 Work·Codex 작업의 사용 한도를 구분한다. Grok Bot FAQ는 주간 포함 사용량과 토큰 비용에 따른 추가 사용을 설명한다. 각 제품의 실제 사용 화면에서 포함량, 추가 사용의 승인 방식, 이번 과제에 들어간 사람의 수정 시간을 함께 기록해야 한다. 확인하지 못한 가격을 채워 넣은 비용 순위는 제시하지 않았다.

설치 경로도 현재 문서를 보자. Dots의 9월 발표는 초기 설정을 데스크톱 중심으로 설명하지만, 현재 도움말은 모바일 앱에서도 생성할 수 있다고 안내한다. 모바일 웹은 지원하지 않는다. Grok Bot 페이지의 눈에 띄는 macOS 다운로드 버튼만 보고 Windows 지원이 없다고 읽는 것도 부정확하다. 같은 페이지의 FAQ에 Windows가 명시돼 있다.

내 업무에는 무엇부터 시도할까

공식 구조를 토대로 한 선택은 다음처럼 좁힐 수 있다. 개인 목표와 여러 산출물을 대화로 계속 조율하고 싶다면 Muse의 이용 가능 여부와 앱 연결부터 살펴볼 수 있다. 기존 ChatGPT·Work·Codex 작업, 특히 내 컴퓨터의 개발 환경과 이어야 한다면 Dots의 작업 위치와 온라인 조건을 먼저 확인할 만하다. 조사와 구현을 여러 역할로 나누고 Cursor 작업에 넘기는 흐름을 만들고 싶다면 Grok Bot의 공유 컴퓨터와 역할 인계를 검토할 수 있다. 이는 우열 순위가 아니라 첫 시험을 정하는 기준이다.

반대로 자료를 한 번 읽어 답을 받는 일이거나 실행 순서가 항상 같은 짧은 작업이라면, 지속형 에이전트의 기억·연결을 관리하는 비용이 이득보다 클 수 있다. 세 제품을 동시에 도입할 필요도 없다. 처음에는 연결 설정이 가능한 하나에서 위의 과제를 수행한 뒤, 빠진 근거, 사람이 고친 부분, 다시 설명해야 했던 정보를 남겨 보자. 다른 제품을 검토할 때도 같은 입력과 완료 조건을 유지하면 비교 이유가 분명해진다.

실제 운영 비용을 비교할 단계라면 에이전트 도입 평가, 코딩 세션 안에서 인계 정보를 직접 관리하고 싶다면 Claude Code Mods의 인수인계 보드, 모델과 개발 도구의 제공 경로를 더 구분하려면 Gemini 4 Argon 분석으로 이어갈 수 있다. 이 글을 저장해 과제 양식을 다시 쓰거나 소프트웨어 주제 모음과 RSS에서 후속 분석을 확인할 수 있다.