🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Fable 5로 AI Agent Dashboards를 만드는 핵심은 화려한 3D 화면보다, 에이전트 상태·작업·리소스 병목을 실시간으로 믿고 볼 수 있는 운영 대시보드로 만드는 데 있다.

📌 핵심 요점

1. 라이브의 중심 작업은 Claude Fable 5, OpenClaw, Hermes를 함께 쓰며 Agent Atlas와 Claw Crib 대시보드를 실제로 개선하는 것이었고, 특히 floor plan·2D isometric·3D 뷰의 일관성이 핵심 과제로 다뤄졌다.
2. Claw Crib은 OpenClaw gateway 데이터를 기반으로 에이전트 상태와 작업 보드를 시각화하는 도구로 확장되고 있으며, 단순한 장식형 화면이 아니라 에이전트가 무엇을 하는지 확인하는 상시 관찰 화면을 목표로 한다.
3. Hermes의 skill 구성과 agent profile 설계는 단순 설정 문제가 아니라 컨텍스트 비용, 역할별 권한, 작업 라우팅, 생산성에 직접 영향을 주는 운영 설계 문제로 제시됐다.
4. 실제 테스트 과정에서 heartbeat가 없는 에이전트 누락, 뷰 전환 시 상태 초기화, 2D·3D·floor plan 간 동기화 불일치, 카메라 조작 한계, CPU 100% 병목 같은 문제가 드러났다.
5. 라이브 후반부에는 대시보드 개발 자체만큼이나 서버 자원, VM 배분, 로컬 호스팅, API 비용, Claude CLI 사용 방식 변화, 음성 AI 비용 같은 운영 조건이 AI 에이전트 시스템의 지속 가능성을 좌우한다는 점이 강조됐다.

🧩 배경과 문제 정의

• 이 영상은 Claude Fable 5, OpenClaw, Hermes를 실제 작업 환경에서 함께 사용하며 Agent Atlas와 Claw Crib 대시보드 개발을 진행하는 라이브 작업 기록이다.
• 작업 전 OpenClaw, Hermes, Claude Code의 업데이트와 모델 버전 확인이 필요하며, 시스템 상태가 맞지 않으면 이후 개발·시연·검증 결과가 흔들릴 수 있다.
• Claw Crib은 OpenClaw gateway 데이터를 바탕으로 에이전트 상태를 floor plan, 2D isometric, 3D 뷰로 시각화하는 대시보드로 확장되고 있다.
• Hermes agent의 skill 구성, tool 접근 권한, 역할별 agent 분리는 생산성뿐 아니라 컨텍스트 비용과 운영 안정성에 직접 영향을 주는 설계 문제로 다뤄진다.
• 라이브 후반부에는 Claw Crib의 실시간 상태 동기화, 카메라 조작, 에이전트 이동 시각화, 리소스 병목, 서버 이전 계획, Claude-P 대응 전략까지 이어지며 실제 AI agent 운영 환경의 제약이 드러난다.

🕒 시간순 섹션별 상세정리

1. 라이브 작업 목표와 초기 시스템 업데이트

• Claude Fable 5, OpenClaw, Hermes를 사용해 실제 빌드 작업을 시작하며, 오늘의 핵심 대상은 Agent Atlas와 Claw Crib이다 [00:10]
• 본격 작업 전에 OpenClaw와 Hermes 양쪽 시스템을 업데이트하고, 이후 tmux 기반 작업 흐름도 함께 사용할 계획이다 [01:16]

2. Claw Crib의 설치 방식과 대시보드 방향

• Claw Crib은 OpenClaw 머신의 CLI에서 npx claw crib install 형태로 설치되는 방향이며, OpenClaw gateway 데이터를 가져와 표시하는 구조다 [03:35]
• 기본 화면은 floor plan, 2D isometric, 3D 뷰를 포함하며, 향후에는 사용자가 직접 floor plan을 만들 가능성도 있다 [03:42]

3. Hermes skill 구성과 역할별 권한 설계

• Hermes는 기본적으로 여러 skill이 사전 설정된 상태로 시작하며, 아직 각 agent가 접근할 skill과 tool 수를 강하게 제한하지 않은 상태다 [05:18]
• Hermes agent 조직 구성은 예상보다 느리지만, OpenClaw 시스템은 안정적으로 맞춰져 있고 shared executive assistant chat을 통해 많은 작업이 진행된다 [05:35]

4. skill 수와 컨텍스트 비용의 균형

• 너무 많은 skill이 생산성을 떨어뜨릴 수 있다는 우려가 나오지만, skill 수에 절대적인 정답은 없고 작업 진행을 막는 수준으로 보기는 어렵다 [07:16]
• skill metadata는 각 chat session 시작 시 컨텍스트에 로드되며, 전체 skill 내용이 아니라 각 skill의 TLDR 수준 정보만 들어간다 [07:55]

5. 스포츠 시뮬레이션 아이디어와 개인 리그 자동화 구상

• 브라우저 기반 NBA 시뮬레이션 게임 사례에서 fantasy football league용 도구를 vibe coding으로 만들 아이디어가 나온다 [08:36]
• 장기간 운영 중인 fantasy football league는 buy-in을 해마다 올렸고, 올해는 같은 멤버가 유지되면서 더 안정적인 참여 구조가 만들어졌다 [09:22]

6. 3D 뷰 작업 준비와 Claude Code 업데이트

• 업데이트가 끝난 뒤 Claw Crib 화면이 다시 열리고, 오늘의 구체적인 작업 초점은 3D view 쪽으로 이동한다 [10:34]
• 현재 화면은 엄밀한 3D가 아니라 2D isometric에 가까워서, 이 구분을 분명히 하고 더 정교하게 다듬을 필요가 있다 [10:44]

7. 실험과 실패가 AI 도구 신뢰의 기준이 된다

• Hermes Agent를 잘 쓰는 사람에 대한 신뢰는 정교한 기능 목록보다 실제로 여러 번 만들고 실패하고 부수며 배운 경험에서 나온다 [12:13]
• 탐색하고 실험하는 사람은 도구의 한계와 가능성을 직접 확인하므로, 단순 사용법을 정리한 사람보다 실전 판단력이 높다 [12:27]

8. 판타지 리그 참여 이탈을 막기 위한 인센티브가 필요하다

• 이전 시즌에는 정규 시즌 마지막 주에 한 참가자가 라인업을 제대로 설정하지 않아 플레이오프 진출 결과가 영향을 받았다 [12:43]
• 해당 참가자의 벤치 자원까지 분석했을 때 경기를 이기기는 어려웠지만, 끝까지 시도하지 않은 행동 자체가 리그 공정성에 문제를 만들었다 [13:10]

9. 커뮤니티 제작 메일 앱은 통합 메일함과 AI 기능으로 확장된다

• 커뮤니티 구성원이 Fable과 함께 Superhuman에 아직 부족한 통합 메일함 기능을 갖춘 메일 앱을 만들었다 [14:21]
• 화면 공유 중 개인 이메일 노출 가능성이 생기면서, 라이브 스트림의 공개성과 실제 앱 데모 사이에 프라이버시 리스크가 발생한다 [14:56]

10. 자동 라인업 도구보다 참여 유도 장치가 우선된다

• 탈락한 팀의 로스터를 AI가 자동 조정하는 아이디어가 나오지만, 커미셔너가 참가자의 라인업을 대신 바꾸는 일은 예외 상황에 가깝다 [16:02]
• 신혼여행처럼 참가자가 직접 라인업을 관리하기 어려운 경우에는 벤치의 다음 최선 옵션을 대신 넣는 방식이 가능하다 [16:26]

11. API 비용과 검색 차단은 에이전트 운영 방식에 영향을 준다

• AI 작업량이 늘어나면서 API 사용료가 부담이 되고, Claude 선호 여부나 OpenAI 구독 사용 가능성이 비용 전략의 핵심 변수로 떠오른다 [17:40]
• 검색 기능은 빠르게 차단될 수 있어, 에이전트가 headless browser 대신 별도 브라우저 프로필을 호출하는 방식이 필요해진다 [18:33]

12. 소규모 사업자의 AI 비서 학습은 챗봇 사용에서 시작된다

• 배관 회사를 운영하는 소규모 사업자가 AI secretary를 배우는 출발점을 묻고, 실제 업무 자동화 수요가 커뮤니티 질문으로 등장한다 [20:24]
• 초반 학습은 OpenAI, Anthropic, Gemini 같은 frontier model 중 하나를 골라 직접 써보는 방식으로 시작하는 것이 현실적이다 [20:45]

13. 이메일 리드 분류에서 시작하는 기본 자동화

• Codex 앱 안에서 외부 리소스를 연결하면 자체 OpenClaw나 Hermes 에이전트 시스템을 직접 배포하지 않아도 더 단순한 내부 도구와 자동화를 만들 수 있다 [24:00]
• AI 비서의 첫 단계는 Gmail 같은 메일 제공자에서 모든 인바운드 이메일을 에이전트 전용 이메일로 포워드하거나 CC 처리하는 구조다 [24:39]

14. 경쟁사 분석 브리프와 단순 자동화의 확장

• 다음 자동화 후보는 경쟁사 검색과 제공 서비스 분석이며, 에이전트가 정해진 워크플로와 액션 아이템을 따라 야간에 경쟁 분석을 수행할 수 있다 [26:41]
• 새벽 2~3시에 경쟁사 분석을 실행하면 오전 6~8시 사이 이메일 inbox로 경쟁사 인사이트 브리프를 받을 수 있고, 사업자는 하루 시작 전에 시장 변화를 확인한다 [26:57]

15. 프런티어 모델, 프라이버시, 웹 자동화 도구의 한계

• Claude와 GPT-5 계열 같은 프런티어 모델을 쓰는 환경에서는 개인정보 보호 우려가 남고, 일반적인 인터넷 사용에서도 완전한 프라이버시는 현실적으로 어렵다 [27:56]
• 완전한 비공개 인터넷 사용 방법은 일부 존재하지만 대부분의 사용자는 그 절차를 따르지 않기 때문에, 실용적으로는 모델의 가능성과 기회를 활용하는 쪽으로 무게가 간다 [28:17]

16. AI 전화 접수원의 가능성과 현재 품질 한계

• 전화 응대를 AI가 맡는 구조는 이론적으로 가능하지만, 현재 음성 응답은 많은 사람에게 AI처럼 들리고 완성도가 충분하지 않다 [29:00]
• OpenClaw의 메인 executive assistant인 Muddy에 Twilio 전화번호를 붙여 통화 경험을 시험했지만, 실제 접수원 수준에는 아직 도달하지 못해 추가 시간을 크게 쓰지 않았다 [29:16]

17. 실제 에이전트에게 전화 스크리닝 설계를 요청하는 흐름

• Hermes의 executive assistant를 Telegram 새 세션으로 열고, 답을 직접 만들기보다 운영 중인 에이전트에게 전화 응대 문제의 해결책을 묻는 방식으로 접근한다 [30:35]
• 전화가 계속 걸려오는 상황에서 별도 AI receptionist를 만들지, 기존 에이전트 프로필을 활용할지, workspace·profile·identity·rule·tool 접근 권한을 어떻게 나눌지가 핵심 설계 문제가 된다 [31:39]

18. 음성 AI 예산, 11 Labs, 실제 학습 데이터 요구

• 11 Labs 사용은 부트스트랩 브랜드의 예산 문제와 연결되고, 현재 음성은 오픈소스 방식으로 만들기 때문에 Muddy와 대화하는 경험이 만족스럽지 않다 [34:35]
• 11 Labs가 후원하거나 매달 사용할 inference를 제공하면 더 적극적으로 음성 데모와 전화 응대 실험을 할 수 있고, 제품 데모를 위한 협업 가능성도 생긴다 [34:56]

19. 스마트폰 개인정보 보호의 현실과 기술 수용

• 주요 통신사 스마트폰을 쓰는 순간 통화와 데이터가 이미 감시·스크리닝될 가능성이 높고, 완전한 프라이버시를 기대하기 어렵다는 관점이 나온다 [36:21]
• 스마트폰을 쓰면서 원하는 수준의 개인정보 보호를 유지하기는 어렵기 때문에, 현실을 인정하고 기술을 받아들여 유용한 것을 만드는 쪽이 낫다는 결론으로 계속된다 [36:52]

20. AI 전화 접수원은 단일 에이전트가 빠른 분류를 맡는 구조가 적합함

• AI 전화 스크리너·접수원은 스팸, 리드, 결제, 지원을 각각 별도 에이전트로 나누기보다 하나의 에이전트가 inbound 번호별 프로필과 라우팅을 처리하는 구조가 더 적합하다 [38:18]
• 기본 에이전트는 운영자·빌더·오케스트레이터에 가깝고, 고객을 직접 상대하는 층은 명확한 업무 설명을 가진 전문 AI receptionist 또는 screener가 맡는 편이 자연스럽다 [38:45]

21. 자동화 설계는 실제 도구 연결과 낮은 위험 구간부터 시작함

• 배관 서비스 흐름과 맞는지 확인하면서, 스트림 화면의 유용한 부분을 캡처해 Hermes agent에 넣으면 직접 프롬프트를 세밀하게 작성하지 않아도 설계 힌트를 얻을 수 있다 [39:40]
• “헷갈리면 스크린샷을 찍어 에이전트에 먹인다”는 방식은 작업 중 나온 아이디어를 자동화 입력으로 재활용하는 실용적 운영 패턴이 된다 [40:02]

22. 로컬 호스팅은 학습과 통제권을 주지만 모델 의존성은 남음

• 원격 호스팅 솔루션과 원클릭 설치는 편리할 수 있지만, 개인정보 기준이 실제로 얼마나 잘 지켜지는지는 서비스마다 다르고 외부 의존성이 생긴다 [41:22]
• 로컬 호스팅은 시스템을 직접 이해하게 만들고 제3자에게 의존하지 않는 통제권을 주기 때문에, 장기적으로 더 많은 학습 효과를 남긴다 [41:44]

23. 서비스 중심 커뮤니티 운영과 긴급 대응의 경제성

• 채널 운영의 초점은 빠른 자극, 좋아요 유도, 보상형 장치보다 커뮤니티 질문에 신중하게 답하고 실제 작업을 라이브로 진행하는 데 있다 [42:52]
• 엔터테인먼트 중심 콘텐츠는 빠른 상호작용과 hype를 만들지만, 이 라이브에서는 질문 응답과 실시간 문제 해결이 더 중요한 차별점으로 작동한다 [43:16]

24. 에이전트 이름 짓기와 Agent Atlas의 라우팅 방식

• Hermes Agent 시스템에서는 Neo나 Matrix 관련 이름이 자주 보이며, 개인적 체감상 상당수 사용자가 Matrix 세계관을 에이전트 명명에 가져온다 [44:09]
• 커뮤니티에 Matrix 이름을 쓴 에이전트가 있는지 묻는 흐름은 Hermes Agent 사용자 문화와 네이밍 관습을 확인하는 가벼운 상호작용으로 계속된다 [46:40]

25. Agent Atlas의 3D 작업을 Claude Fable 5로 전환하기 위한 조건 정리

• Agent profiles의 이름 패턴을 기준으로 research lane과 Oracle 아래 배치를 자동으로 파악하는 구조가 확인되고, department head에는 이름을 붙이지만 모든 구성원에게 이름을 붙이기는 부담스럽다는 운영 기준이 나온다 [48:01]
• Agent Atlas 작업은 목록 부분보다 floor plan과 3D 부분이 핵심이며, Claude Fable 5를 구독 계정 기반으로 CLI에서 쓰려면 기존 Claude -P 방식 대신 interactive mode를 고려해야 한다 [49:43]

26. 대기 시간 동안 드러난 수면, 에너지, 생산성 맥락

• 응답을 기다리는 동안 전날 밤 12시 30분쯤 잠들고 5시 41분에 완전히 깨어난 상황이 공유되며, 추가 수면 대신 하루를 시작하고 점심 이후 낮잠을 선택하는 리듬이 형성된다 [51:05]
• 약 5시간 수면에도 오전 생산성이 유지됐고, 커피 없이도 상당 시간을 버틴 상태라 단기적으로는 집중이 가능하지만 밤에는 수면 보충이 필요할 가능성이 남는다 [51:29]

27. 휴식과 환경 전환이 창의적 에너지를 만든 흐름

• 골프 이후 컴퓨터와 연구실에서 벗어난 시간이 창의적 에너지를 크게 높였고, 쉬지 않고 화면 앞에 붙어 있는 방식은 일정 수준까지만 생산적이라는 판단이 나온다 [53:15]
• 친구와의 대화, 관심사 자극, 업무 환경 밖의 시간이 새로운 아이디어로 이어졌고, 평소 10시에 화면을 끄는 습관을 넘겨 자정까지 작업할 만큼 몰입이 지속됐다 [53:45]

28. Claude interactive mode 중심의 handoff 전략

• Claude 구독을 쓰려면 워크플로를 Claude -P 비대화형 호출에 묶지 않는 편이 안전하고, 6월 15일 이후 변화에 맞춰 terminal에서 Claude interactive mode를 직접 실행하는 방향이 적합하다 [54:46]
• CLI에 연결된 계정과 웹앱용 계정은 다를 수 있어 model 확인이 필요하지만, 현재 CLI에는 웹앱용 구독이 연결돼 있지 않다는 판단이 나온다 [55:18]

29. Hermes 팀 안에 Claude 전용 전문 에이전트를 두는 구상

• 당장은 Claude -P를 사용할 수 있지만, 다음 주 별도 라이브 스트림에서 Claude 기반 모델을 interactive mode로 다루는 전문 에이전트를 만들 가능성이 열린다 [56:51]
• Hermes agent team 안의 engineering lane 아래에 “engineering Claude” 같은 전문 에이전트를 두고, cloud-based model 사용 요청을 해당 에이전트로 라우팅하는 구조가 구상된다 [57:03]

30. 채팅 응답과 Codex 사용 경험으로 넘어간 후반부

• 더운 밤과 골프 중 햇볕 노출 이야기가 이어지고, 전날은 낮에 매우 더웠지만 Bay Area의 밤은 시원하고 바람이 불어 수면 환경이 나쁘지 않았다 [57:47]
• Codex는 매일 쓰는 도구이며, 200달러 월간 플랜을 사용하지만 한 번에 주로 하나의 프로젝트에 집중하고, 여러 프로젝트를 동시에 다룰 때는 CMUX를 더 선호한다 [58:26]

31. Codex와 Claude를 같은 화면에서 병렬로 쓰는 작업 방식

• Codex 화면에서 오른쪽에 터미널을 열고 Claude를 호출하면, 같은 앱과 같은 인터페이스 안에서 Codex와 Claude가 동시에 같은 작업을 다룰 수 있다 [1:00:00]
• 터미널만으로도 Claude를 쓸 수 있지만, Codex 쪽에는 플러그인과 스킬이 최적화되어 있어 Convex·Stripe 같은 외부 서비스 연결 작업의 마찰이 줄어든다 [1:00:29]

32. Hermes Agent A-to-Z 학습 수요와 부트캠프 계획

• Hermes Agent를 A부터 Z까지 다루는 단일 가이드는 아직 없고, 현재는 설정·구성·멀티 에이전트 팀 구축·자동화 관련 영상을 조합해야 한다 [1:02:24]
• 무료 Hermes Agent 부트캠프를 YouTube에서 진행할 계획이며, 웹사이트 리소스의 boot camp 영역에는 coming soon 상태로 예고가 걸려 있다 [1:02:46]

33. Atlas와 대시보드 새 기능, 데스크톱 비교 관심

• Atlas 로딩이 느리게 느껴지는 가운데 Hermes agent dashboard 전체에서 새 기능이 발견되고, 해당 변화가 데스크톱에도 들어갔는지 확인 대상이 된다 [1:04:26]
• OpenClaw desktop과 Hermes desktop app을 비교하는 별도 영상을 녹화할 계획이 있으며, 두 앱의 차이를 보여주는 콘텐츠가 유용할 것으로 판단된다 [1:05:50]

34. Claude CLI 우회와 Hermes 대시보드 성능 장애

• claw-p는 금지되거나 동작 방식이 바뀔 때까지 계속 쓰고, 다음 주 라이브에서는 Claude라는 이름의 특수 agent를 engineering에 추가해 interactive Claude CLI agent로 우회하는 구성이 계획된다 [1:06:42]
• Hermes Agent 업데이트 이후 특정 탭뿐 아니라 대부분의 탭 로딩이 매우 느려졌고, 좌하단 gateway status가 stopped로 표시되는 문제가 동시에 나타난다 [1:07:15]

35. 포르투갈과 미국을 오가는 작업 환경, 생산성 공간의 차이

• 국적 배경은 미국 출생의 포르투갈계이며, 평소에는 포르투갈과 미국을 각각 약 6개월씩 오가는 생활 패턴을 가진다 [1:08:18]
• 최근에는 포르투갈에 약 13개월 연속 머물렀고, 과거 영상의 배경처럼 보이는 지하실 느낌의 공간은 포르투갈 사무실이다 [1:08:32]

36. 브라우저 새로고침 확인 후 짧은 휴식

• 대시보드 느림 문제와 관련해 브라우저 하드 리프레시는 이미 수행됐고, 추가 조사는 Neo에게 맡기는 흐름으로 넘어간다 [1:09:15]
• 원래 이런 작업 지시는 TY chat에서 주는 편이 더 맞지만, 이번에는 현재 흐름 안에서 문제 조사를 요청한 상태다 [1:09:21]

37. 대기 이후 작업 복귀와 Fable 접근 방식 판단

• Neo 작업이 아직 끝나지 않아 대기 상태가 이어지고, 짧은 휴식이 전체 진행에는 큰 영향을 주지 않은 상황이다 [1:20:00]
• Anthropic Fable을 API로 쓰기보다 구독이나 trial 계정 방식으로 접근하는 편이 낫고, 22일까지 사용할 수 있는 기간을 고려해 첫 달 가입 후 취소하는 선택지가 거론된다 [1:20:19]

38. Neo 대기 병목과 Claw Crib 작업 전환

• Neo의 처리 시간이 지나치게 길어지면서 Clock Rib 또는 Claw Crib 쪽 작업을 먼저 진행하는 방향으로 전환된다 [1:21:10]
• 새 탭을 열어 별도 작업 흐름을 시작하고, 기존 대기 작업과 병렬로 다른 개선 항목을 진행할 수 있는 상태를 만든다 [1:21:19]

39. Floor plan 비율과 glass office 배치 개선

• 다음 개선 대상은 floor plan, 2D view, 3D view이며, 현재 floor plan은 전반적으로 괜찮지만 화면 비율이 지나치게 넓다는 문제가 있다 [1:21:47]
• 초기 floor plan은 1:1에 가까운 정사각형 비율이 더 적합하고, 이후 필요하면 4:3 비율로 확장하는 단계적 접근이 가능하다 [1:21:54]

40. 실제 workboard 라이브 표시와 3D 보드 확장

• 2D와 3D 모드 안에서 실제 workboard를 live streaming 형태로 표시할 수 있는지가 핵심 요구사항으로 떠오른다 [1:22:24]
• 3D 모드에는 이미 workboard가 보이며, 실제 task가 표시되는 것처럼 보이는 상태라면 agent dashboard의 몰입감과 실용성이 커진다 [1:22:33]

41. 2D isometric 카메라 조작과 agent 작업 테스트

• 2D isometric view에는 카메라 이동 기능이 없으며, 3D처럼 viewpoint 위치를 바꿀 수 있는 조작 기능이 필요하다 [1:22:54]
• 2D view에도 동일한 camera positioning 기능이 들어가야 floor plan과 agent workspace를 다양한 시점에서 점검할 수 있다 [1:23:01]

42. 실시간 에이전트 대시보드 테스트가 시작된다

• 커스텀 웹앱은 OpenClaw 시스템에 설치 가능한 패키지 형태이며, 사용자가 에이전트들의 실시간 행동을 시각적으로 확인하는 목적을 가진다 [1:24:02]
• Chief of Staff 역할 테스트를 위해 Gary Warren과 Elon을 대상으로 요청을 보내려 하고, 백엔드 설정이 맞으면 화면에서 에이전트 움직임이 나타나야 한다 [1:24:12]

43. 자동화 관찰용 상시 화면이라는 사용 맥락이 드러난다

• 기능은 충분히 사전 검증되지 않은 상태라 현재 라이브 환경에서 실제 동작을 확인하는 흐름이며, 이동 애니메이션이 의도대로 방 안에서 시작되는지가 관건이다 [1:25:13]
• 자동화는 하루 끝, 아침 첫 시간, 밤사이에 실행되는 경우가 많아 사용자가 새벽에 계속 대시보드를 지켜보기 어렵다 [1:25:18]

44. 세션·태스크 상태 확인에서 관찰 신호의 한계가 드러난다

• Muddy의 입력 상태는 화면 상단에 나타나며, Discord처럼 하단에 타이핑 표시가 나올 것이라는 기존 기대와 실제 UI 위치가 다르다 [1:26:35]
• 에이전트가 입력을 멈춘 듯 보이지만 실제 작업 여부가 불확실해, 대시보드 대신 태스크 매니저에서 세션과 작업 연결 상태를 확인한다 [1:27:21]

45. 활성 상태 시각화의 기대 동작이 구체화된다

• 초기 프로토타입에서는 에이전트의 활성 세션이 3D 뷰, 2D 뷰, 플랜 뷰 전체에서 애니메이션으로 반영되는 구조였다는 기대가 있다 [1:28:14]
• 에이전트가 일을 시작하면 워크보드나 불펜으로 이동하고, 협업이 필요한 작업에서는 불펜으로 가는 동선이 자연스럽다 [1:28:29]

46. 실제 작업 실행과 대시보드 버그가 함께 점검된다

• 코드베이스 작업 중이라 화면에 움직임이 보이지 않을 가능성이 있고, 실제 태스크를 에이전트들에게 보내 움직임과 상태 반영을 다시 확인하려 한다 [1:29:28]
• dot이 방 안에서 움직이고 모든 뷰포인트와 좌표가 맞물리는 기능은 이미 테스트된 적이 있어, 현재 화면은 그 동작을 재확인하는 기준점이 된다 [1:29:58]

47. 이름 매핑과 음성 입력 문제 뒤에 Hermes 데모가 계속된다

• 에이전트 응답이 뒤늦게 보이지만 이름이 잘못 붙어 있고, Claude가 W가 들어간 이름으로 표기되는 오타는 그대로 두기로 한다 [1:34:01]
• 음성 입력 예측 기능은 사용자의 원문 의도보다 예측 변환을 앞세워 잘못된 텍스트를 만들 수 있으며, 기본값은 원문에 가까운 음성 전사여야 한다는 불만이 나온다 [1:34:34]

48. 자동화 음성 데모와 회의 루프 알림

• AI가 선의적이어도 기업들이 합리적으로 자동화를 밀어붙이면 서로를 죽음의 나선으로 몰 수 있다는 농담성 콘텐츠가 재생되며, 자동화 경쟁의 부작용이 짧게 부각된다 [1:36:15]
• Hermes 음성 알림은 5분 뒤 시작되는 미팅 집중 시간을 알리고, 캘린더 노트 기반으로 반복 피드백 사이클을 활용한 루프 사고 세션이라는 핵심 맥락을 잡는다 [1:36:30]

49. OBS 크래시와 라이브 복구

• OBS가 월 1회 정도 발생하는 기술적 글리치로 크래시했고, 라이브가 다시 연결됐는지 확인하는 복구 절차가 즉시 우선순위가 된다 [1:37:09]
• 방송은 다시 라이브 상태로 돌아오지만, 송출 중단은 시연 흐름을 끊고 작업 신뢰도와 시청 경험을 동시에 떨어뜨린다 [1:37:28]

50. 느린 채팅 로딩과 외부 음성 서비스 협업 구상

• 복구 대기 중 채팅 로딩이 늦어지고, 별도 프라이빗 브라우저에서도 페이지 반응이 느려 시스템 리소스 부족 가능성이 다시 떠오른다 [100:22] [1:37:43]
• 느린 로딩은 단순 브라우저 문제가 아니라 VM 코어 배정이나 전체 호스트 자원 부족과 연결될 수 있어, 데모 환경의 병목 진단이 필요해진다 [100:55] [1:37:58]

51. 작업 공간 조건과 로컬 환경 부담

• 실내 온도가 올라가면서 작업 공간 자체가 장시간 라이브 진행의 부담 요소가 되고, 외부 온도 확인이 필요한 상황이 된다 [102:17] [1:41:24]
• 큰 프렌치 도어와 아침 햇빛은 평소에는 장점이지만, 폭염이나 더운 날에는 건물 한쪽을 종일 달궈 실내 온도를 크게 올린다 [102:26] [1:42:25]

52. 서버 이전이 리소스 병목 해결 우선순위로 상승

• 현재 문제는 시스템 리소스 부족일 수 있고, VM에 더 많은 자원을 할당해야 할 가능성이 커진다 [103:59] [1:43:25]
• 약 2주 안에 Hermes와 OpenClaw를 더 강력한 서버로 이전할 계획이 있으며, 새 환경은 기존보다 훨씬 많은 리소스와 적은 제약을 제공할 것으로 기대된다 [104:08] [1:44:26]

53. VM 자원 배분과 Apple Silicon 가상화 한계

• 8코어 시스템의 CPU 종류와 스레드 수가 중요해지고, AMD·Intel 기반에서는 코어와 스레드를 더 세밀하게 VM에 배분할 수 있다 [106:06] [1:46:06]
• Apple Silicon 환경에서는 VM 소프트웨어에서 코어만 선택할 수 있고, 코어 하나에 여러 스레드를 붙이는 방식의 세밀한 가상 코어 구성이 어렵다 [106:15] [1:46:28]

54. 여러 VM과 미니 PC 활용 가능성

• 고성능 장비라면 VM 4개와 각각의 멀티 에이전트 팀을 나눠 운영할 수 있지만, 안정적으로는 2개 정도가 더 현실적인 상한으로 보인다 [108:02] [1:46:43]
• 장비가 매우 강력하면 로컬 에이전트 팀을 병렬로 돌리는 실험 범위가 넓어지고, 하드웨어 병목 때문에 아이디어 구현이 막히는 상황을 줄일 수 있다 [108:18] [1:46:58]

55. ASUS NUC의 사무용 배치 경험과 한계

• 과거 지역 비즈니스 고객용 PC를 매주 수백 대 조립하던 환경에서는 ASUS NUC를 24인치 모니터 뒤에 장착하는 구성이 인기를 얻었고, 책상 위 배선과 본체 공간 문제가 크게 줄었다 [108:42] [1:49:31]
• 일반 직원용 컴퓨터의 약 75%는 모니터 뒤에 장착한 ASUS 미니 PC로 충분했지만, Photoshop이나 애니메이션 작업을 맡은 크리에이티브 인력은 별도 데스크톱이 필요했다 [109:34] [1:50:31]

56. 최신 ASUS 미니 PC 사양 검토와 Mac Mini 대비 판단

• 최신 ASUS 미니 PC는 외형과 구성 면에서 매력적이며, 일부 모델은 CPU가 미리 장착된 형태로 보인다 [110:51] [1:51:32]
• 가격 대비 얻을 수 있는 사양은 괜찮지만, 메모리 가격이 비정상적으로 높아 전체 구축 비용의 부담이 커진다 [112:01] [1:52:33]

57. VMware 유지와 Proxmox 실험 계획

• 기존 서버 환경이 ESXi 기반이라 VMware Fusion을 계속 쓰고 있으며, VM을 드래그 앤 드롭으로 옮길 수 있어 가상 디스크 변환 같은 추가 작업이 줄어든다 [113:23] [1:53:27]
• Proxmox는 바로 운영 환경에 채택하기보다 오래된 실험용 컴퓨터에 먼저 설치해 감을 익히는 단계가 필요하다 [113:42] [1:54:35]

58. 메모리·스토리지 가격 부담과 예산 제약

• 30GB 이상 RAM 같은 구성이 가능하더라도, 현재 메모리 가격은 지나치게 높아 개인 예산 안에서 바로 구매하기 어렵다 [114:08] [1:55:36]
• 이미 남는 4TB NVMe가 있어 저장장치 일부는 재활용할 수 있지만, 96GB 구성을 위해 48GB 2개 듀얼 채널 키트를 맞추려면 메모리 비용이 핵심 부담으로 남는다 [114:38] [1:56:36]

59. 하드웨어 투자 철학과 장기 로컬 모델 목표

• 강력한 장비를 미리 준비하는 선택은 과투자가 아니라, 하드웨어 한계 없이 더 큰 실험과 빌드를 시도할 수 있게 만드는 장기적 준비로 볼 수 있다 [116:41] [1:57:37]
• 구상 중인 Supermicro 랙마운트 로컬 모델 빌드는 Blackwell 기반 Nvidia GPU 4개 수준이며, GPU 하나가 약 7,500달러라 전체 비용은 4만 달러 이상으로 올라간다 [117:05] [1:57:52]

60. 안정적인 서버 운영 기준과 버전 선택 원칙

• 운영체제나 VM은 최신 Ubuntu 릴리스를 매번 따라가기보다 장기 지원 로드맵이 뚜렷한 안정 버전을 고르고, 해당 기간 동안 같은 릴리스를 유지하는 방식이 더 안전하다 [120:13] [2:00:38]
• 새 모델이나 새 릴리스가 5~10년 지원을 보장하면 선택 기준이 바뀔 수 있지만, 기본 원칙은 한두 버전 뒤의 검증된 릴리스를 보는 쪽에 가깝다 [120:24] [2:00:40]

61. RAID 10 선호와 비용 현실

• Seagate나 Western Digital의 NAS용 레드 계열 드라이브 4개를 쓰면 RAID 10에서 중복성과 RAID 0 방식의 성능 향상을 함께 얻을 수 있다 [122:25] [2:01:41]
• RAID 10은 장애 대응 여유와 성능 개선을 동시에 노릴 수 있어 기본 서버 구성에서 선호되는 방식이며, 반복 구축에서도 같은 원칙이 유지된다 [122:32] [2:02:41]

62. Claw Crib 뷰 테스트와 초기 시각화 문제

• 1x1 레이아웃에서 두 방이 함께 전환되고 에이전트가 작업 공간으로 이동하는 모습이 확인되지만, 2D 아이소메트릭에서는 움직임이 멈춰 보인다 [123:55] [2:03:42]
• 3D 뷰에서는 에이전트가 테이블을 통과해 걷는 문제가 나타나며, 공간 충돌 처리나 경로 계산 로직을 수정해야 하는 상태다 [124:14] [2:04:11]

63. 카메라 조작과 실시간 활동 스트림의 결함

• Claw Cribs의 시각적 스크린세이버에서 활성 세션이 생기는지 관찰하는 동안, 입력 대기 상태를 보여주는 점 표시 기능은 유용한 작은 개선으로 작동한다 [125:21] [2:04:26]
• 3D 카메라는 좌클릭 드래그 시 90도까지만 회전하고, 방 안 어느 위치에서도 360도 회전이 가능해야 탐색성이 좋아진다 [125:46] [2:06:45]

64. 세 가지 뷰의 상태 동기화 요구

• 최초 로드 시 에이전트들이 각자 사무실에 있지만, 실제 목표는 에이전트 활동을 실시간 스트림처럼 유지하는 것이므로 백엔드 연결 어딘가에 불일치가 있다 [126:33] [2:07:46]
• 3D에서 중앙에 있던 메인 에이전트가 2D나 다른 뷰로 이동하면 다시 사무실 위치로 초기화되며, 세 가지 뷰 모두 같은 실시간 상태를 공유해야 한다 [126:50] [2:08:01]

65. Claw Crib v3의 제품 방향과 출시 계획

• Claw Crib v3는 처음에는 복잡한 시스템으로 커졌지만, 기능을 덜어내고 OpenClaw 멀티에이전트 팀용 npx 설치 패키지로 단순화하는 방향이 더 현실적이다 [127:55] [2:08:16]
• 로컬 OpenClaw 시스템과 같은 머신에서 설치되고 기본 대시보드 포트에 연결되며, 구성된 에이전트 수, 서브에이전트, 작업 보드와 태스크를 가져오는 구조가 핵심이다 [128:19] [2:08:31]

66. 중단 이후 워커 시뮬레이션 초기화 문제를 단일 공유 구조로 고친다

• 잠시 자리를 비운 뒤 다시 작업으로 복귀하고, 빈 화면만 보이는 상황에서도 진행 중임을 알 수 있도록 비디오를 켜두는 방식이 나온다 [135:39] [2:11:49]
• Elon, Gary, Warren 같은 워커들이 실제로 움직였는지, 아니면 Muddy만 반복적으로 보였는지 확인하면서 렌더링 상태 점검으로 돌아간다 [136:01] [2:13:46]

67. 하드 리프레시 뒤 2D·3D 뷰의 일관성과 사용성을 다시 확인한다

• 하드 리프레시로 새 구조를 테스트하고, Muddy를 화면 밖으로 옮겨 다른 요소를 함께 확인할 수 있는 작업 환경을 만든다 [136:45] [2:13:51]
• 2D 화면에서는 동일한 상태가 안정적으로 유지되며, 로딩은 다소 느리지만 현재 단계에서는 계속 작업 가능한 수준으로 판단된다 [136:57] [2:15:47]

68. OpenClaw 업데이트 이후 반응 저하와 CPU 병목이 작업 지속을 막는다

• Muddy의 반응이 평소보다 느리고, 당일 OpenClaw 업데이트 이후 체감 성능이 떨어진 상태로 보인다 [137:12] [2:15:52]
• 버전이 65에서 66으로 올라간 뒤 느려졌다는 점 때문에, 65로 되돌리는 방안까지 고려될 만큼 성능 저하가 뚜렷하다 [137:32] [2:16:53]

69. Claw Crib·Agent Atlas 작업은 월요일로 미뤄지고 Claude-P 대응이 다음 주 과제가 된다

• 작업을 계속하고 싶은 의지는 있지만, 성능 병목 때문에 Claw Crib과 Agent Atlas 개발은 월요일까지 중단된다 [139:36] [2:19:44]
• 다음 주에는 Claude-P의 명령 사용 방식 변화에 대응하기 위해 라이브에서 우회 방안을 직접 만들고 작동 여부와 난이도를 확인할 계획이다 [139:49] [2:19:53]

70. 시청자 감사와 주말 영상 예고로 라이브가 마무리된다

• 라이브 시청자들에게 감사 인사를 전하고, 스트림이 중간에 끊긴 탓에 채팅을 계속 위로 스크롤할 수 없는 상황도 드러난다 [140:23] [2:19:56]
• Calvin, Mr. Baker, Duval 등 시청자 이름을 다시 확인하며, 반복해서 기억하겠다는 가벼운 마무리 분위기로 전환된다 [140:57] [2:20:31]

🧾 결론

• 이 영상은 완성된 제품 데모라기보다, 실제 AI 에이전트 대시보드를 만들면서 발생하는 설계·성능·운영 문제를 공개적으로 디버깅하는 작업 기록에 가깝다.
• Claw Crib의 제품 방향은 OpenClaw 멀티에이전트 팀을 위한 설치형 대시보드로 정리되며, 에이전트 수, 세션 상태, 작업 보드, 태스크를 가져와 2D·3D·평면도 형태로 보여주는 것이 핵심이다.
• 가장 중요한 기술적 결론은 각 뷰가 별도 상태를 갖는 구조가 아니라, 하나의 공유 상태를 기준으로 에이전트 위치·활동·작업 흐름을 일관되게 표시해야 한다는 점이다.
• Hermes와 OpenClaw 운영에서는 더 많은 agent, skill, 자동화가 곧바로 더 나은 결과를 의미하지 않으며, 역할·권한·도구 접근·리소스 사용량을 함께 설계해야 한다.
• 검증 필요: Claude CLI의 비대화형 사용 제한 변화, Claude Fable 5 구독 기반 활용 방식, Claw Crib v3의 7월 전후 출시 및 Discord 베타 계획은 라이브 발언 기준이므로 실제 릴리스나 공식 공지로 별도 확인이 필요하다.

📈 투자·시사 포인트

• AI 에이전트 대시보드의 가치는 “멋진 3D 사무실”보다 실제 운영 신뢰성에 있다. 투자 관점에서는 시각화 자체보다 실시간 상태 동기화, 작업 추적, 알림, 장애 진단 기능을 갖춘 운영 레이어가 더 중요해 보인다.
• 멀티에이전트 시스템이 커질수록 CPU, 메모리, VM 배분, 브라우저 자동화 비용, API 비용이 병목으로 드러난다. 따라서 AI 에이전트 도입 비용은 모델 구독료뿐 아니라 로컬 인프라와 관찰 도구 비용까지 포함해 봐야 한다.
• 소규모 사업자용 AI 자동화는 거창한 전면 자동화보다 이메일 분류, 경쟁사 브리프, missed call 이후 SMS, 전화 1차 스크리닝처럼 낮은 위험 구간에서 시작하는 것이 현실적인 진입점으로 제시된다.
• AI receptionist나 음성 에이전트는 가능성이 크지만, 실제 상담 품질을 내려면 과거 상담 데이터, 지식베이스, 라우팅 기준, 긴급 상황 escalation 설계가 필요하다. 단순히 음성 모델을 붙이는 것만으로 현장 접수원을 대체하기는 어렵다.
• 로컬 호스팅과 자체 서버는 통제권과 학습 효과를 주지만, frontier model을 쓰는 한 외부 모델 서버 의존성은 남는다. 완전한 독립성보다 비용·프라이버시·성능·운영 편의성 사이의 균형이 핵심이다.
• 하드웨어 투자에서는 고성능 서버, RAID 구성, NAS용 드라이브, Proxmox·VMware 같은 가상화 선택이 장기 운영 안정성과 연결된다. 다만 메모리·GPU·스토리지 가격 부담이 크기 때문에, 필요가 확인된 뒤 점진적으로 확장하는 전략이 더 합리적으로 보인다.

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

• Claw Crib에서 일부 에이전트가 누락되는 원인이 “heartbeat가 없는 워크스페이스/에이전트” 때문일 가능성이 언급됐지만, 실제 데이터 소스·상태 구독·필터링 로직 중 어디에서 빠지는지는 추가 확인이 필요하다.
• OpenClaw 업데이트 후 대시보드와 에이전트 응답이 느려진 현상이 v65→v66 업데이트 때문인지, VM CPU 100% 병목 때문인지, Hermes dashboard/gateway 상태 문제 때문인지는 단정할 수 없다.
• Claude Fable 5를 API가 아니라 구독·trial 기반으로 쓰는 전략이 더 유리하다고 판단했지만, 실제 비용·환불·사용 제한 조건은 영상 안에서 확정되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Claw Crib에서 heartbeat가 없는 에이전트/워크스페이스가 목록과 뷰에서 누락되는 경로를 확인하고, 표시 기준을 명확히 정리한다.
• 3D 뷰에서 에이전트가 테이블을 통과하는 문제를 재현하고, 경로 계산 또는 충돌 처리 로직을 점검한다.
• 2D isometric 뷰, 3D 뷰, floor plan이 동일한 워커 상태와 위치를 공유하도록 상태 소스와 구독 구조를 점검한다.
• 2D isometric 뷰에도 카메라 이동·시점 조작 기능을 넣을 수 있는지 설계한다.

❓ 열린 질문

• Claw Crib은 heartbeat가 없는 에이전트도 “비활성/unknown” 상태로 표시해야 하는가, 아니면 heartbeat가 있는 에이전트만 신뢰 가능한 대상으로 보여줘야 하는가?
• 2D isometric, 3D, floor plan 세 뷰의 단일 상태 소스는 프론트엔드 singleton으로 충분한가, 아니면 백엔드에서 세션·위치·활동 상태를 명시적으로 제공해야 하는가?
• Agent Atlas와 Claw Crib은 장기적으로 별도 제품/플러그인으로 유지하는 편이 좋은가, 아니면 Hermes/OpenClaw 대시보드 안의 공통 시각화 계층으로 통합하는 편이 좋은가?