I moved my OpenClaw work to Grok Bot. It mostly worked

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 업무를 Grok Bot으로 옮긴 결과, 초기 안전장치와 복구 체계를 갖추자 대부분의 실무는 이전됐고 사람의 지속적인 돌봄은 크게 줄었다.

📌 핵심 요점

1. 5일간 67개 작업을 실행한 결과 40개는 도움 없이 완료됐고, 14개는 개입 후 완료됐으며, 전체 50개 작업은 사용자 개입이 필요하지 않았다.
2. 단순한 사용자 요청을 매니저 에이전트가 개인 맥락과 평가 기준을 담은 전문 브리프로 변환한 것이 작업 품질과 편의성을 높인 핵심 메커니즘이었다.
3. OpenClaw 구성을 그대로 이식하는 방식은 실패했지만, Sharky라는 COO 역할의 매니저와 7개 전문 봇으로 Grok Bot에 맞게 재설계하자 실제로 작동했다.
4. 데이터센터 IP 차단, 의도하지 않은 게시, 업데이트 후 패키지 소실이라는 세 가지 초기 문제가 있었고, Tailscale 출구 노드·쓰기 승인 가드·부트스트랩 스크립트로 각각 보완했다.
5. 연구·모니터링·파일 기반 업무·일상 자동화에는 충분히 유용했지만, 복잡한 코딩과 강한 에이전트 격리에서는 아직 OpenClaw보다 불리하다는 평가다.

🧩 배경과 문제 정의

• 제작자는 1월부터 OpenClaw 에이전트를 매일 사용했지만, 업데이트 후 수리·로그인 장애·조용한 실패를 계속 관리해야 했다.
• 이를 줄이기 위해 기존 업무를 Grok Bot으로 옮겨 5일간 67개의 실제 장기 작업을 실행하고, 성공 여부와 사람의 개입량을 관찰했다.
• 검증의 핵심은 단순한 작업 수행 능력뿐 아니라 개인 맥락 이전, 서비스 로그인, 안전한 쓰기 권한, 업데이트 복구, 비용과 사용량까지 포함한 운영 가능성이었다.

🕒 시간순 섹션별 상세정리

1. OpenClaw의 유지보수 부담과 이전 결과

• 제작자는 OpenClaw를 매일 운영하며 업데이트 수리, 로그인 장애, 알림 없는 실패에 지나치게 많은 시간을 썼고, 이를 계기로 업무를 Grok Bot으로 옮겼다. [00:16]
• 5일 동안 67개 작업 중 40개가 도움 없이 완료됐고 14개가 개입 후 완료됐으며, 50개는 사용자 개입 자체가 필요하지 않았다. [01:10]

2. 짧은 요청을 완전한 브리프로 변환

• 보석 수리점을 찾아 달라는 짧은 요청이 동네, 업력, 평판, 제외 조건, 순위 기준을 포함한 연구 브리프로 자동 확장됐다. [01:45]
• 개인 맥락을 반영한 브리프 덕분에 네 곳의 후보와 영업시간, 짧은 추천 결과를 얻었고 사용자가 들인 시간은 0분이었다. [02:16]

3. 일대일 이식 실패와 매니저 중심 재설계

• 기존 OpenClaw 저장소를 통째로 옮기려던 첫 계획은 두 시스템의 구조가 일대일로 대응하지 않아 실패했다. [02:52]
• 이후 COO 역할의 Sharky가 7개 전문 봇에 구조화된 브리프를 작성하는 Grok Bot 전용 팀으로 재구축했고, 이 방식은 정상적으로 작동했다. [03:30]
• 매일 사용하는 소프트웨어의 캐릭터와 애니메이션이 주는 쾌적함도 장기간 누적되는 제품 가치로 평가했다. [04:08]

4. 데이터센터 IP 차단과 Tailscale 우회

• 모든 봇은 데이터센터 IP를 쓰는 하나의 클라우드 컴퓨터와 브라우저를 공유했고, 이 때문에 Twitter 로그인이 자동화 트래픽으로 의심받아 차단됐다. [05:18]
• 클라우드 컴퓨터에 Tailscale을 설치하고 항상 켜져 있는 Mac Studio를 출구 노드로 지정해 웹사이트가 주거용 IP를 보도록 만들었다. [06:08]
• Twitter 문제가 수정되더라도 다른 사이트의 차단과 CAPTCHA를 피하기 위해 제작자는 이 구성을 유지하기로 했다. [06:27]

5. 의도하지 않은 게시와 쓰기 승인 가드

• 트윗을 읽어야 할 봇이 잘못된 명령을 실행해 실제 게시물을 올렸지만, 오류를 인식하고 즉시 삭제했다. [06:48]
• 개발 봇이 승인 가드를 추가해 사용자의 명시적 허가 없이는 해당 컴퓨터에서 Twitter에 게시할 수 없게 했다. [07:08]
• 모든 봇이 같은 로그인 정보를 공유하므로 별도 봇을 보안 경계로 사용해서는 안 된다는 한계도 확인됐다. [07:19]

6. 업데이트 후 환경 소실과 자동 검토

• 클라우드 컴퓨터 업데이트가 파일은 유지하면서 Tailscale 같은 설치 패키지를 제거해 Obsidian 동기화가 두 차례 조용히 중단됐다. [07:45]
• 업데이트 뒤 누락된 패키지를 재설치하고 동작 상태를 점검하는 부트스트랩 스크립트를 만들어 복구 절차를 표준화했다. [08:18]
• 명령 자동 검토 기능은 스크립트 실행, Gist 업로드, 개인 키 출력과 검토 우회 시도까지 차단했으며, 제작자는 이를 원하는 수준의 보안으로 평가했다. [09:11]

7. 계정·커넥터·개인 지식 연결

• 플러그인 설정에서 Gmail과 캘린더를 포함해 서비스별로 여러 계정을 손쉽게 연결할 수 있었다. [09:37]
• MCP 문서 링크와 자격 증명만 제공해 새로운 데이터 서비스를 구성할 수 있어 통합 작업이 단순해졌다. [10:09]
• 약 4,000개의 Markdown 페이지가 있는 Obsidian 저장소를 동기화해 첫날부터 개인·업무·프로젝트 맥락을 활용할 수 있었다. [11:04]

8. 막힌 작업의 보고와 실제 자동화 범위

• 키워드 API가 작업 도중 고장 났을 때 숫자를 꾸며내거나 단계를 생략하지 않고 중단 사실을 알렸으며, 키를 수정하자 작업을 이어서 완료했다. [12:07]
• 콘텐츠 파이프라인, 비공식 Instagram 게시 실험, 승인과 세션 유지, 이메일·Slack·배송 모니터링 등 기존 OpenClaw 업무를 시험했다. [12:56]

9. 사용량과 구독 비용 판단

• 초기 설정과 67개 작업을 수행한 뒤 주간 사용량은 약 29~30%였고, 7일 체험 한도는 약 2시간 만에 소진됐다. [13:38]
• 제작자는 Grok Bot만을 위해 월 200~300달러를 추가 지불하지는 않겠지만, 기존 구독을 Cursor Ultra로 대체해 같은 수준의 비용 안에서 사용했다. [14:25]
• 별도 비용이 추가되는 사용자라면 결제 전에 자신이 실제로 쓰려는 워크플로를 체험 기간에 검증하라고 권했다. [14:37]

10. OpenClaw가 유지하는 비교 우위

• OpenClaw는 에이전트마다 메모리와 코드베이스 접근을 더 세밀하게 분리할 수 있어 전문화와 보안 격리에 유리하다. [15:16]
• 소프트웨어 자체는 무료이며 모델 사용료만 부담하고, 구독형·로컬 모델을 포함해 원하는 모델을 선택할 수 있다. [15:52]
• Grok Bot의 단일 모델은 일상 업무에는 충분하지만, 제작자는 복잡한 작업에서 상위 모델 수준으로 보지는 않았다. [16:03]

11. 도입 규칙과 최종 평가

• 먼저 매니저 에이전트를 만들고 전문 봇과 브리프 작성을 맡기며, 로그인 연결 전에는 파괴적 행동에 사용자 승인을 요구하라고 조언했다. [17:06]
• 파일은 재시작 뒤에도 보존되는 workspace에 두고, 패키지와 환경을 재생성하는 부트스트랩 스크립트로 조용한 실패에 대비해야 한다. [17:47]
• 당분간 OpenClaw와 병렬 운용하되, Grok Bot은 이미 연구·모니터링·파일 기반·관리 자동화에는 충분하고 복잡한 코딩보다는 빠른 수정에 적합하다는 결론을 내렸다. [19:17]

🧾 결론

• Grok Bot은 개인 맥락을 활용하는 매니저 에이전트와 전문 봇 구조를 통해 OpenClaw의 주요 업무를 실질적으로 이전할 수 있었다.
• 성과는 제품의 기본 기능만으로 얻어진 것이 아니라 네트워크 우회, 쓰기 통제, 환경 복구 자동화라는 운영 장치를 추가한 뒤에 가능했다.
• 5일간의 결과는 긍정적이지만, 제작자는 OpenClaw를 종료하지 않고 두 시스템을 병렬 운용하며 수주간 더 비교하기로 했다.
• 현재 기준으로는 연구·모니터링·관리·파일 워크플로에는 적합하고, 복잡한 코딩에는 제한적으로 사용하는 것이 타당하다.

📈 투자·시사 포인트

• 에이전트 경쟁력은 단일 모델 성능보다 사용자 맥락을 구조화하고 전문 에이전트에 정확한 브리프를 전달하는 관리 계층에서 차별화될 수 있다.
• 클라우드 컴퓨터형 에이전트가 확산될수록 주거용 네트워크 연결, 권한 승인, 상태 보존, 업데이트 후 자동 복구가 핵심 인프라 시장으로 부상할 가능성이 있다.
• 여러 서비스 계정과 커넥터를 쉽게 추가하는 경험은 에이전트를 실험용 챗봇이 아니라 상시 업무 운영체제로 전환하는 중요한 채택 요인이다.
• 월 구독료의 매력은 절대가격보다 기존 AI·코딩 구독을 대체할 수 있는지에 달려 있어, 번들 구성과 사용량 한도가 구매 결정에 큰 영향을 준다.

⚠️ 불확실하거나 확인이 필요한 부분

• 평가는 5일과 67개 작업에 한정된 초기 관찰이며, 장기간 운영했을 때 업데이트 장애와 개입 빈도가 계속 낮게 유지될지는 확인되지 않았다.
• 도움 없이 완료된 40개 작업과 개입이 필요 없었다는 50개 작업의 상태 범주가 완전히 동일하지 않아, 성공률과 무개입률을 구분해 해석해야 한다.
• 데이터센터 IP 차단과 업데이트 후 패키지 소실은 제작자의 우회책으로 완화됐을 뿐, Grok Bot 자체에서 근본적으로 해결된 것은 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Grok Bot을 도입하기 전에 실제로 이전하려는 연구·모니터링·파일 작업을 체험 기간에 그대로 실행해 성공률과 개입 횟수를 기록한다.
• 먼저 chief-of-staff·COO 역할의 매니저 에이전트를 만들고, 이 에이전트가 전문 봇의 설명과 작업 브리프를 작성하도록 구성한다.
• Gmail·캘린더·SNS·MCP 로그인을 연결하기 전에 게시·답장·삭제 등 되돌리기 어려운 동작에 명시적 사용자 승인을 요구한다.
• 데이터센터 IP가 차단되는 서비스는 Tailscale과 상시 가동 로컬 장비의 출구 노드 구성을 검토한다.

❓ 열린 질문

• 수주간 병렬 운용한 뒤에도 Grok Bot의 무개입 작업 비율과 낮은 유지보수 부담이 그대로 유지될까?
• 데이터센터 IP와 업데이트 후 패키지 소실 문제는 제품 차원에서 언제, 어떤 방식으로 해결될까?
• 공유 컴퓨터 구조의 편의성을 유지하면서 에이전트별 로그인·메모리·코드베이스를 안전하게 격리할 수 있을까?