제5장 공유 클라우드 컴퓨터: 파일, 브라우저 및 제어권 인수

Grok Bot을 처음 접하는 사용자는 보통 몇 가지 흔한 오해를 하곤 합니다. 이러한 오해는 향후 개발과 유지보수 과정에서 걸림돌이 되기 쉽습니다:

• 새로운 Bot을 생성하면 독립된 가상 머신이 하나 더 생긴다고 오해하는 경우.
• 여러 Bot에게 함께 작업을 시킬 때, 서로의 대화 기록을 직접 읽을 수 있다고 오해하는 경우.
• 서드파티 도구 로그인이 필요할 때 계정 비밀번호나 API Token을 채팅창에 그대로 붙여넣는 경우.

그러다 시스템 유지보수나 인프라 업데이트로 클라우드 컴퓨터가 갑자기 초기화되어 설치해 둔 환경과 스크립트가 전부 사라지고 나서야, 비로소 자신이 이 클라우드 컴퓨터의 내부 메커니즘을 전혀 모르고 있었다는 사실을 깨닫게 됩니다.

동일한 계정의 모든 Bot은 동일한 클라우드 컴퓨터에서 작업하며, 동일한 디스크와 파일 시스템을 공유합니다. 서로의 대화 기록은 볼 수 없으며, 협업은 오직 디스크 상의 파일 전달을 통해서만 이루어집니다.

로그인 인증이 필요할 때 올바른 방법은 클라우드 브라우저에서 직접 화면 제어권을 인수하여 자격 증명을 입력하는 것이지, 모델에게 비밀번호를 넘겨주는 것이 아닙니다. 또한 이 클라우드 컴퓨터는 본질적으로 언제든 재구축될 수 있는 임시 컨테이너이므로, 플랫폼 인프라 업데이트나 관리자 유지보수 시 수동으로 설치한 패키지는 모두 유실됩니다.

이번 장에서는 이 클라우드 컴퓨터의 실제 작동 방식을 자세히 살펴봅니다. 여러 Bot 간에 파일과 화면을 안전하게 인수인계하는 방법, 화이트리스트 제한에 대응하기 위해 로컬 데스크톱을 통해 네트워크 트래픽을 라우팅하는 방법, 그리고 환경이 초기화된 후에도 체계적이고 신속하게 복구할 수 있는 가볍고 표준화된 재해 복구 파이프라인 구축 방법을 배웁니다.

공유 컴퓨터의 내부 메커니즘: 단일 머신과 여러 Bot

사용자 계정의 모든 Bot은 동일한 관리형 Linux 컴퓨터를 공유합니다. 어떤 Bot으로 전환하든 동일한 /workspace 루트 디렉터리와 영구 디스크를 마주하게 됩니다.

대화 기록은 외부에 별도로 저장되므로, 머신 내부에서 rm -rf로 완전히 삭제하거나 시스템 충돌로 재부팅되더라도 대화와 목록은 그대로 유지됩니다.

새로운 Bot을 생성한다고 해서 보안이 격리되는 것은 아닙니다. 어떤 Bot이든 명령줄 권한을 얻으면 /workspace 내부의 모든 데이터를 읽고 쓸 수 있으므로, 암호화되지 않은 민감한 정보는 절대로 보관하지 마세요.

버전 변화:

• v0.68.0: 설정에서 다른 컴퓨터 제거 지원
• v0.68.1(2026-10-07 출시): 화면 해상도가 1280×800에서 1920×1200으로 향상되어 조작 및 스크린샷 응답 속도 개선
• v0.70.2: 전용 이메일 추가, 웹페이지 직접 PDF 저장 지원

자세한 내부 구조는 《4.6 가상 머신, 기억 및 백업》을 참조하세요.

다중 Bot 화면 및 작업 상태 모니터링

상태 및 설정

사이드바에는 세 가지 상태가 상시 표시됩니다.

• 주의 필요: 답변, 승인 또는 인수인계 대기 중.
• 읽지 않은 활동: 작업 완료, 결과 확인 대기 중.
• 작업 중: 스크립트 실행, 웹 크롤링 또는 도구 호출 중.

상단 이름을 클릭하여 '대화 세부정보 보기'로 들어가면 현재 Bot의 이름, 태그 및 프로필 사진을 변경할 수 있습니다. 개인 Bot에는 별도의 설명 입력란이 없으므로, 직접 메시지를 보내서 역할을 조정할 수 있습니다.

모니터링 및 알림

클라우드 작업 시 실시간 화면 보기를 지원합니다.

창이 포커스 상태일 때는 알림이 자동으로 억제되어 사이드바와 Dock에만 읽지 않음으로 표시됩니다. 오프라인 상태일 때는 설정 파일에서 알림을 활성화하여 데스크톱이나 모바일로 푸시를 보낼 수 있습니다.

브라우저 제어권 인수: 화면은 넘겨도 비밀번호는 넘기지 않기

채팅창에 계정 및 비밀번호를 보내지 마세요. 사용자와 Bot은 브라우저를 공유하므로 화면은 넘겨도 비밀번호는 넘기지 않아야 합니다.

제어권 인수 단계

1. 일시정지 트리거: Bot이 로그인 페이지를 열고 계정/비밀번호, QR코드 스캔 또는 2FA를 만나면 일시정지합니다.
2. 입력 제어권 인수: 전체 화면을 클릭하여 키보드와 마우스 제어권을 가져옵니다.
3. 수동 로그인: 직접 계정/비밀번호를 입력하거나 QR코드를 스캔하여 인증합니다.
4. 실행 인계: 로그인 후 Bot에게 알려 Cookie를 재사용하여 실행하도록 하므로, 평문 비밀번호에 접근할 수 없습니다.

승인 게이트

Cmd+,를 눌러 '일반' - 'Bot'에서 설정합니다.

• 규칙 충돌 시 '먼저 묻기'(Ask first)가 우선 적용됩니다.
• 엔터프라이즈 규칙에 Required by your admin. You can't edit or delete this rule.로 표시되는 항목은 수정할 수 없습니다.
• v0.70.2에서는 이메일 발송 및 게시물 등록, 결제, 프로덕션 환경 수정 전 확인 절차가 강화되었습니다.

자세한 내용은 설정 및 알림을 참조하세요.

다중 Bot 파일 인수인계 규칙 및 디렉터리 계획

파일 협업 모드

Bot 간에는 대화 기록을 읽을 수 없으므로, 다중 Bot 협업의 유일한 통로는 공유 디스크 파일입니다.

프롬프트에는 이전 작업자의 파일 경로만 전달하면 됩니다. 자세한 내용은 《4.6 가상 머신, 기억 및 백업》을 참조하세요.

1. 정리 담당자가 수집하여 tweets.md 생성
2. 분석가가 핵심을 추출하여 profile.md 출력
3. 디자이너가 프로필을 바탕으로 design.md 생성
4. 엔지니어가 설계를 읽고 코드 작성

디렉터리 계획

머신 생성 초기에 디렉터리를 정해 두어야 여러 Bot이 파일을 어지럽히는 것을 방지할 수 있습니다.

디렉터리 경로	저장 내용	작성 규칙
/workspace/handoff/	중간 산출물	작업 접두사를 붙여 Markdown 또는 JSON으로 통일
/workspace/projects/	프로젝트 코드 및 자산	프로젝트별 독립 하위 디렉터리로 분리, Git 저장소 연동
/workspace/tools/	로컬 자체 제작 스크립트	키가 없는 소스 코드만 유지, 점검 후 백업 저장소 동기화
~/.env 또는 로컬 파일	API 키	로컬에만 보관, 코드 저장소 커밋 또는 대화창 출력 엄격히 금지

디스크 정리와 Disk Saver

시스템에서 Computer is low on disk space 또는 Computer is critically low on disk space 경고가 발생하면 사이드바에서 Disk Saver의 "Go to Disk Saver"를 클릭하여 정리 제안을 확인하세요.

확인 없이는 절대로 파일을 임의로 삭제하지 않으며, 정리를 거부하면 기존 파일은 그대로 유지됩니다.

로컬 네트워크 아웃바운드: 라우팅 및 사설망 접근

WeChat 공식 계정, 사내 인트라넷 IP 화이트리스트 또는 로컬 네트워크 접근을 해결하려면 로컬 장치를 통해 트래픽을 릴레이하면 됩니다.

활성화 단계

1. Cmd+,를 눌러 설정으로 이동한 뒤 컴퓨터를 클릭합니다.
2. 내 컴퓨터에서 현재 컴퓨터를 찾아 현재 컴퓨터를 통해 트래픽 라우팅을 켭니다.

제한 사항 및 주의점

• 한 번에 한 대만 가능합니다. 외부에서는 로컬 IP로 식별되며, Bot도 로컬 네트워크에 직접 접근할 수 있습니다.
• 새로운 요청에만 적용되며, 기존 TCP 장시간 연결은 기존 경로를 유지합니다.
• 관리자가 Allow Local Egress Routing을 끄면 스위치가 비활성화(회색)되며 Disabled by your admin. You can't turn this on. 메시지가 표시되고 5분 이내에 강제 연결 해제됩니다. 설정 및 알림을 참조하세요.
• Execution on this computer는 로컬 Shell을 제어하며 기본적으로 명령마다 개별 확인을 거치므로, 임의로 전자동 모드를 허용하지 마세요.

재빌드, 업데이트 및 종료: 클라우드 컴퓨터의 수명 주기

재빌드 시 직접 설치한 환경은 초기화되지만 디스크와 로그인 상태는 유지됩니다.

Grok Bot 컴퓨터 및 Grok Bot 컴퓨터 관리를 참조하세요.

작업	유지 항목	삭제 항목 및 주의점
소프트웨어 업데이트	전체	없음
업데이트/재빌드	디스크 및 파일	직접 설치한 환경 초기화, 스크립트 재실행 필요
VM 종료	디스크	30일 유휴 시 종료되어 진행 상황 유실
Recover/Reset	저장된 데이터	작업 중단, 저장되지 않은 코드 유실

Reconnecting이 표시될 때 무작정 Reset하지 말고, 순서대로 점검하세요.

1. Retry 클릭: 재연결 중에는 디스크가 온전하므로 무분별하게 조작하여 상태를 망가뜨리지 마세요.
2. 완전 종료: macOS에서는 닫기 버튼만 누르지 말고 Cmd+Q로 완전히 종료한 후 다시 시작하세요.
3. 업데이트 확인: '설정' > '컴퓨터'로 이동하여 Bot이 유휴 상태일 때 업데이트를 진행하세요.
4. Recover 우선 선택: 팝업 옵션이 나타나면 이를 먼저 선택하여 최대한 스냅샷을 보존하세요.
5. 최후의 수단으로 Reset: 저장되지 않은 코드가 없고 모든 방법이 실패했음을 확인한 후 초기화하세요.

재해 복구 파이프라인: 서비스 원장 및 멱등 복구 스크립트

업데이트나 초기화가 발생하면 환경이 비워집니다. 铁柱AGI(@cgnot996)가 2026-10-10에 제시한 방안은 머신 전체를 보관하지 않고 구동 방법만 백업하는 것입니다.

그는 5.1MB 프라이빗 저장소로 10개 Bot의 20개 서비스(상주 4개, 온디맨드 14개, 키 경로 항목 2개를 포함한 필수 복구 18개 항목)를 관리하고 있으며, 자세한 내용은 튜토리얼을 참조하세요.

표준 구조 및 원장 등록

저장소 vm-services는 네 부분으로 구성됩니다.

• REGISTRY.md 및 registry.json: 전체 원장 및 구성.
• restore/restore-<服务名>.sh: 단일 서비스 스크립트, 반드시 멱등성을 보장해야 함.
• restore/restore-all.sh: 순서대로 라이브러리와 CLI를 설치하고 백그라운드 서비스를 실행하며 실패 항목 집계.
• service-src/: 소스 코드 아카이브(.env, 로그 및 가상 환경 제외).

신규 서비스 등록에는 다음 항목들이 포함됩니다: 짧은 ID 및 담당 Bot, 코드 및 데이터 경로, 설치 방식(apt/pip/npm/Docker) 및 시스템 의존성, 시작 및 상태 확인 명령(--version 또는 포트), 필수 복구 여부, 키 절대 경로(평문 기록 엄격히 금지), QR코드 스캔 또는 OAuth 등의 단계.

두 가지 프롬프트 세트

'가상 머신 서비스 관리자' Bot에게 전달하여 다른 Bot들이 배포 시 이를 기준으로 인수인계하도록 합니다.

배포 및 등록 프롬프트

你是「虚拟机服务管家」，只管一件事：记下这台虚拟机上部署过的所有第三方服务，并在电脑更新或换账号之后，按记录把它们原样恢复。

你维护的东西：
1. 一份登记总账，人和机器各读一份：REGISTRY.md（表格）和 registry.json（给脚本读）。
2. 每个服务一个恢复脚本 restore/restore-<服务>.sh，必须幂等，重复跑也不会出错。
3. 一个总入口 restore/restore-all.sh，按依赖顺序调用各个恢复脚本，最后汇总哪些失败了。
4. 一份源码备份 service-src/：各 Bot 自己写的服务代码和脚本，同步时排除密钥、日志、运行状态、虚拟环境和个人数据，并先扫一遍明文密钥，命中就停。
5. 以上全部跟着一个私有 Git 仓库存（「你的备份仓库地址」）。总账、恢复脚本、源码都在仓库里，密钥永远不进仓库。

登记规则（其他 Bot 部署任何服务都必须来找你登记）：
每项必须包含：
- 名称和短 id、用途、负责的 Bot
- 路径：代码、配置、数据分别在哪
- 安装方式和依赖（apt / pip / npm / Docker / 系统定时任务）
- 启停命令、健康检查命令
- 更新后的恢复步骤，或者对应的恢复脚本
- 是否必恢复：是 / 否
- 密钥：只写存放路径，绝不写明文
- 需要真人完成的步骤（OAuth 登录、扫码、导入 cookie）单独标出来

你的工作方式：
- 先弄清哪些会丢、哪些能留：电脑更新一般保留工作目录，但系统包、常驻进程、全局安装的命令行工具会丢；重置则什么都不留。所以要记的是“怎么重建”，不是去拷整台机器。
- 能从公开渠道重装的（apt、pip、npm、上游 Git 仓库）只记安装命令；自己写的代码必须进源码备份，否则重置后就找不回来。
- 收到登记先核对：路径是否真实存在、健康检查能不能过。登记写的和实际不一样时，以实际为准，并告诉负责的 Bot。
- 多个定时任务合并成一份 crontab 真源时，检查每一条是不是都在真源里，不在的要靠恢复脚本补回去。
- 故意停掉的服务要写清楚“为什么停、什么条件下重开”，免得被当成漏装。
- 只有主人说“电脑更新完了”才跑总恢复，不盲跑。跑完交验收：每项是成功、失败，还是要真人处理。
- 每次有服务新增、删除或源码大改，先重新同步源码备份，再把总账、脚本、源码一起提交推送到备份仓库。换账号或重置时，就靠这份备份把整套设定带走。
- 删掉的服务要彻底清除：总账只反映现在真实的状态。

초기화 후 Git 자격 증명을 설정하고 복구 Bot에게 전달합니다. 검수 기준은 체크리스트에 따라 결과, 소요 시간 및 점검 상태를 보고하는 것입니다.

초기화 후 원클릭 복구 프롬프트

这台电脑刚重置过（或者是换了新账号），之前部署的服务都没了。请按我的备份把它们恢复到可用状态，规则如下。

备份在哪：
- 备份仓库：<你的备份仓库地址>，分支 <分支名>
- 仓库里有：登记总账（REGISTRY.md 和 registry.json）、每个服务的恢复脚本（restore/）、自写服务的源码备份（service-src/）
- 仓库里没有密钥，这是故意的

请按这个顺序做：
1. 把备份仓库拉到工作目录，先读总账，告诉我一共登记了几项、哪些标了「必恢复」、哪些只留密钥不用恢复。先列出来，不要动手。
2. 把自写服务的源码从 service-src/ 放回总账写的原位置。只补缺失的，已经存在的目录不要覆盖。
3. 按总账的依赖顺序逐项恢复：先装系统依赖（比如 cron、ffmpeg），再装命令行工具，最后拉起常驻服务和定时任务。每项都用它自己的恢复脚本，脚本要能重复跑。
4. 每装完一项就跑它登记的健康检查。失败了先看日志、试着修一次；修不好就记下原因，接着做下一项，不要卡住。
5. 把需要我本人做的事汇总成一张清单：要重新提供的密钥（只说放哪个路径、叫什么名字，别让我把密钥贴进聊天）、要重新登录授权的工具（OAuth、扫码、设备码）。然后一项一项带我做，每做完一项马上复查。
6. 故意暂停的任务保持暂停，总账里写了原因和重开条件的照办。别因为“看起来漏装了”就自作主张打开。
7. 最后交验收清单，每项一行：服务名、结果（成功 / 失败 / 等我处理）、健康检查输出摘要、花了多久。再告诉我总共用了多少时间、成功了几项。

不要做的事：
- 不要把任何密钥写进仓库、日志或聊天
- 不要跑总账没登记的安装
- 不要用“重置电脑”当修复手段
- 恢复完如果有任何改动（路径变了、版本升级了），更新总账，提交推回备份仓库

흔히 겪는 실수

자격 증명 및 권한

• 채팅창에 키를 붙여넣지 마세요: 웹 환경에서는 수동으로 입력하고, CLI용 Token은 ~/.env에 작성하여 스크립트가 환경 변수를 읽도록 합니다.
• Bot 간 격리 부재: /workspace와 권한을 공유합니다. 민감한 자산은 프라이빗 저장소와 수동 승인에 의존해야 하며, 여러 개를 생성해도 소용없습니다.

협업 및 의존성

• 인수인계는 디스크에 저장 필수: Bot끼리는 대화 내용을 읽을 수 없습니다. A의 결과는 Markdown 또는 JSON으로 저장해야 하며, 말로만 전달하면 B에게 환각(할루시네이션)이 발생합니다.

• 의존성 미유지: 업데이트, Recover 또는 Reset 시 apt install 및 npm install -g로 설치된 내용이 초기화되며, node_modules와 .venv 역시 백업되지 않습니다.

  복구 스크립트에는 반드시 npm install 및 pip install -r requirements.txt가 포함되어야 합니다.

운영 및 네트워크

• Reconnecting이 보일 때 Reset을 누르지 마세요: 저장되지 않은 변경 사항이 유실되고 강제로 재구축되므로, 먼저 재시도하거나 클라이언트를 재시작하세요.
• 예약 작업 중앙 관리: crontab은 반드시 Git 저장소에 통합하여 관리해야 합니다.
• 로컬 라우팅 활성화 시 재시작 필요: '현재 컴퓨터를 통해 트래픽 라우팅'을 켰는데도 IP가 변경되지 않았다면 해당 프로세스를 재시작하세요.

완료 후 검증 방법

1. Bot A가 /workspace/handoff/test.json에 타임스탬프를 작성합니다. Bot B가 이를 읽고 정확히 말할 수 있다면 정상적으로 연동된 것입니다.
2. '설정' > '컴퓨터'에서 '현재 컴퓨터를 통해 트래픽 라우팅'을 켜고, 터미널에서 curl -s https://api.ipify.org를 실행합니다. 공인 IP가 데이터센터 IP가 아닌 로컬과 일치해야 합니다.
3. Bot에게 GitHub 로그인 페이지를 열도록 지시하고, 반드시 비밀번호 입력란 앞에서 일시정지하며 제어권 인계를 요청해야 합니다. 수동으로 로그인한 후 계속 진행하여 로그에 평문 비밀번호가 없는지 확인합니다.
4. 프라이빗 Git에 REGISTRY.md, registry.json 및 스크립트가 커밋되었는지 확인합니다. 테스트 디렉터리에서 가져와(pull) 실행합니다:

bash restore/restore-all.sh

상태 확인(Health Check)을 모두 통과해야 하며, 충돌 오류가 없고 원장의 서비스가 정상적으로 수신 대기(listening) 중이어야 합니다.

참고 자료

공식 문서 및 지식 베이스

• Grok Bot 컴퓨터 관리: 엔터프라이즈 버전의 다중 컴퓨터 일괄 재구축, 종료 및 30일 유휴 정리 관련 공식 전체 규칙.
• 설정 및 알림: 데스크톱 설정, 로컬 명령 실행, 트래픽 릴레이 라우팅 및 Auto-review 모드에 대한 공식 설명.
• Grok Bot 컴퓨터: Update, Recover, Reset의 차이점 및 문제 해결 점검 목록에 대한 공식 안내.

커뮤니티 실전 참고 자료

• 《4.6 가상 머신, 기억 및 백업》: 클라우드 컴퓨터의 내부 아키텍처, 컨텍스트 구성 맵 및 다중 Bot 파일 협업에 대한 상세 분석.
• 《Grok Bot 가상 머신 초기화 후 도구가 모두 사라졌다면? 백업 복구 튜토리얼 (프롬프트 포함)》: 커뮤니티 작성자 铁柱AGI(@cgnot996)가 공유하는 가상 머신 서비스 관리자 설계, 원장 등록부 및 원클릭 복구 실전 가이드.