How I''m Using Buzz AI Agents (LIVE: Watch Me Work)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Buzz AI 에이전트를 실제 업무에 쓰는 핵심은 작은 역할별 팀으로 하나의 콘텐츠 워크플로를 끝까지 검증하고, 외부 영향과 비용에만 사람의 승인을 남기며 점진적으로 확장하는 것이다.

📌 핵심 요점

1. Buzz는 기획·리서치·스크립트·썸네일·콘텐츠 캘린더를 한 작업 공간에 연결하고, 마케팅·YouTube·LinkedIn·X 등 역할별 에이전트가 같은 콘텐츠 제작 흐름에 참여하도록 구성됐다.
2. 사람의 승인은 프로덕션 변경, 대리 게시, 비용 지출처럼 외부 사용자나 비용에 영향을 주는 작업에 집중한다. 로컬 단계마다 승인을 요구하면 안전장치가 오히려 제작 속도를 떨어뜨린다.
3. 도입은 기본 팀과 하나의 실제 워크플로에서 시작한다. 결과가 반복적으로 검증될 때 책임을 한두 개씩 추가하고, 필요하면 다른 채널의 전문가를 태그해 현재 작업에 합류시키는 방식이다.
4. 시연된 파이프라인은 약 1시간 20분에서 20분 이하로 단축되고 사람에게 묻는 차단점도 한 번으로 줄었다. 다만 작업 인계 누락, 콘텐츠 카드 위치, 챕터 형식, 썸네일 품질 문제는 자동화 이후에도 별도 검증이 필요함을 보여준다.
5. 시연자의 원격 LAN 환경에서는 OpenClaw가 Buzz 안에서 Hermes보다 자연스럽고 안정적으로 작동했다. 그렇더라도 전체 팀을 한꺼번에 이전하기보다 필요한 에이전트와 컨텍스트만 하나씩 연결하고, 검증된 버전을 보수적으로 유지하는 접근이 권장된다.

🧩 배경과 문제 정의

• Buzz 안에서 기획·리서치·스크립트·썸네일·콘텐츠 캘린더 전달을 연결해 다중 에이전트 콘텐츠 제작 흐름을 구축하는 것이 목표다.
• 외부 사용자와 비용에 영향을 주는 작업만 승인 장벽으로 남기고, 로컬 작업의 잦은 확인은 줄여야 제작 속도를 높일 수 있다.
• 기존 Hermes·OpenClaw 팀을 그대로 연결할지 Buzz 안에 새 팀을 만들지 결정하려면 사용성·안정성·이관 비용을 함께 따져야 한다.
• 새 에이전트에는 방법론과 시각 자산을 학습시켜야 하며, 자동화 범위보다 반복 제작에서 실제 시간을 줄이는지가 중요하다.

🕒 시간순 섹션별 상세정리

1. 두 개의 스크립트와 공개 계획

• Buzz에서 스크립트 두 개를 준비하며, 그중 하나에는 실제 콘텐츠 제작 과정을 그대로 담는다. [01:16]
• 제작 과정을 담은 스크립트는 다음 날 장편 영상으로 공개하고, 다른 사용자가 복사해 자체 워크플로의 출발점으로 활용할 수 있게 한다. [01:20]

2. 사람의 승인이 필요한 작업 경계

• Kanban 승인은 외부 고객이나 사용자가 접하는 프로덕션 코드처럼 다른 사람에게 직접 영향을 주는 변경에만 적용한다. [03:10]
• 대리 게시와 비용 지출은 반드시 차단점으로 남기되, 로컬 작업의 사소한 단계까지 승인받으면 보안 절차가 오히려 작업 흐름을 방해한다. [03:31]

3. Buzz 팀 구성과 기존 에이전트의 배치

• Bee는 마케팅, Dexter는 LinkedIn, Jacked는 엔지니어링을 맡고, Sour·Spicy·Sweet는 YouTube 팀을 이루며 Muddy는 실행 보조 역할을 담당한다. [05:08]
• Hermes 에이전트는 ACP 프로토콜을 사용하지 않아 Buzz의 에이전트 목록에 나타나지 않으며, Buzz 안에서는 OpenClaw 에이전트가 더 자연스러운 사용 경험을 제공한다. [05:35]

4. 점진적인 도입과 썸네일 에이전트 학습

• 초기에는 Buzz를 마케팅에 집중해 사용하고, 학습이 쌓일 때마다 한두 가지 책임만 추가해 운영 위험을 제한한다. [06:47]
• Sweet는 YouTube 썸네일을 담당하며, 비슷한 아이디어를 연속 실행했을 때 이전 결과가 대체된 문제를 피하려고 새 작업의 차이를 명시한다. [07:16]

5. 팀 경계를 넘는 전문가 협업

• YouTube 작업 도중 마케팅 담당 Xavier를 호출해 이미 생성된 X 게시물을 확장하고, 하나의 콘텐츠에서 7일 배포 계획까지 만든다. [08:48]
• 다른 채널의 에이전트도 태그만으로 현재 작업에 합류하며, 각자의 전문 분야·설정·책임에 맞는 결과물을 기존 팀에 보탠다. [09:16]

6. BuzzBench 포크의 운영 원칙

• 자체 포크에는 브라우저와 내장 터미널을 적용했지만, 터미널이 화면 전체를 위로 밀어 텍스트와 문맥을 가리는 레이아웃 문제가 남아 있다. [10:40]
• 포크와 인프라 수정은 주말에만 진행하고, 평일에는 Buzz 안에서 실제 업무를 처리해 도구 개선이 본업을 잠식하지 않게 한다. [11:03]

7. 단축된 제작 파이프라인과 실행 상태

• 이전 라이브에서 약 1시간 20분 걸렸던 파이프라인이 약 20분 이하로 줄었고, 사람에게 요구하는 차단점이나 질문도 한 번으로 감소했다. [11:38]
• Sweet의 썸네일 생성 단계를 새로 넣으면 처리 시간과 승인 횟수가 달라질 수 있어 이번 실행에서 그 영향을 함께 시험한다. [11:41]

8. 다중 에이전트 위임의 설정 비용

• 오케스트레이터와 여러 에이전트 사이의 위임 규칙을 만들면 단일 에이전트보다 설정 시간이 길어지며, 이는 특정 사용자의 구성에만 국한된 문제가 아니다. [13:42]
• 오케스트레이터가 각 에이전트를 어떻게 통제하고 작업을 넘길지 명시적으로 정의해야 하므로 충분한 반복 조정과 인내가 필요하다. [13:55]

9. OpenClaw와 Hermes의 실전 장단점

• OpenClaw는 업데이트를 거치며 Hermes와 비슷한 기능을 갖췄고, 다중 에이전트 팀을 만드는 과정은 Hermes보다 쉽고 즐거웠다. [14:54]
• Hermes는 초기부터 게이트웨이 안정성이 강점이었던 반면 OpenClaw는 초기에 불안정했기 때문에, 최신 버전을 무조건 따라가기보다 검증된 상태를 유지한다. [15:06]

10. Buzz의 통합 기능과 초보자 접근성

• Buzz는 Slack식 협업 공간에 Hermes·OpenClaw·각종 에이전트 하네스의 기능을 결합해 팀 구성과 소통을 한 인터페이스에서 처리한다. [16:16]
• Codex나 Claude 구독을 서드파티 하네스에서 사용하면 기존 앱에 세션이 과도하게 쌓이는 비용이 생기며, 공유 컴퓨팅은 대안이 될 수 있지만 아직 직접 시험하지 않았다. [16:58]

11. 포크와 버전 업데이트의 보수적 관리

• 기존 Buzz 앱을 별도로 유지해 필요할 때 전환하고, 상류 버전을 먼저 업데이트한 뒤 커스텀 기능을 보존하는 조건으로 변경분을 포크에 병합한다. [18:52]
• 새 터미널 버튼의 위치는 기존 작업 흐름과 맞지 않아 기능 추가보다 사용성 검토가 뒤처진 상태다. [19:03]

12. 첫 결과 선택과 시각 자산 표준화

• 파이프라인은 제목·썸네일·도입부·선택 근거를 포함한 세 가지 아이디어를 생성해 사람이 최종 방향을 고를 수 있게 한다. [20:22]
• 의도한 메시지와 맞지 않거나 사실성이 떨어지는 후보를 제외하고 첫 번째 조합을 선택한다. [21:02]

13. 공유 가능한 기반과 자동화 우선순위

• 실제 워크플로는 다음 날 장편 영상과 기본 프롬프트로 공개하지만, 세부 방법론과 운영 규칙은 각 사용자가 자신의 환경에 맞게 구성해야 한다. [24:03]
• 영상 편집 에이전트는 이미 선행 구현을 시작한 사례를 먼저 확인한 뒤 주말에 시험해, 중복 개발과 시행착오를 줄인다. [24:50]

14. YouTube 방법론과 콘텐츠 캘린더 인계

• YouTube 제작 방법론은 Patty Galloway를 비롯한 성공적인 크리에이터들의 사례를 조사해 구성하며, 에이전트가 따를 리서치 기준으로 활용한다. [25:57]
• 작업이 다음 단계에 도달하면 팀이 Muddy를 호출하고, Muddy는 완성된 패킷을 받아 콘텐츠 캘린더에 배치한다. [26:59]

15. 생성형 영상 도구의 선택과 시험 과제

• 최근에는 고객 업무 때문에 생성형 영상을 자주 만들지 못했지만, Google Business Workspace의 인공지능 구독을 활용할 수 있는 Google Flow를 주력 도구로 유지한다. [27:56]
• 자막상 ‘Cedance’로 들리는 도구와 최근 화제가 된 다른 영상 모델은 충분히 비교하지 못했으므로 별도의 테스트가 필요하다. [28:13]

16. 서드파티 에이전트 하네스에 대한 개방성

• Anthropic이 서드파티 활용에서 제약을 키우는 동안 OpenAI는 구독을 Hermes·OpenClaw 등 모든 서드파티 에이전트 하네스에서 사용할 수 있게 열어 이용자 선택권을 넓혔다. [29:36]
• 해당 정책이 샘 올트먼 개인의 결정인지는 불확실하지만, 그가 회사를 이끄는 시기에 이런 조치를 취했다는 점이 지속적인 지지의 근거가 된다. [29:52]

17. 성장에 따른 기업 방향 전환과 시장 확대

• 오픈소스로 출발한 조직도 성장하면 초기 관심사에서 멀어질 수 있고, 사업 초점의 변화는 성장 과정에서 생기는 현실이다. [30:13]
• 최고 책임자의 직접 관여 범위는 불분명하지만, 회사 차원의 반복된 판단 실수가 스스로 경쟁력을 훼손하는 상태다. [30:56]

18. 반복되는 작업 인계 실패 진단

• 작업 시작 후 22분이 지났는데도 인계 완료 신호가 없었고, 확인 결과 다음 단계로 실제 전달되지 않았다. [32:39]
• 같은 문제가 반복되고 있으며 기존 지시가 있었음에도 작동하지 않아, 워크플로의 인계 구간을 수정해야 한다. [33:53]

19. Sweet의 비동기 실행과 Muddy 세션 분리

• Sweet가 백그라운드 작업을 계속하는 동안 같은 화면에서 세부 주제를 논의하거나 문제를 수정해도, 예정된 결과물 생성은 중단되지 않는다. [35:08]
• 필요한 절차가 다시 진행되기 시작했으므로 즉시 개입하기보다 완료될 때까지 기다리는 단계로 전환했다. [35:17]

20. 대기 시간을 없애는 비동기 운영 방식

• 실제 운영에서는 에이전트 화면을 계속 지켜보지 않고 다른 채널과 소셜 활동, 별도 업무를 처리한 뒤 결과가 준비되면 돌아오는 편이 효율적이다. [37:54]
• 현재 화면 대기는 모든 실행 단계를 노출하기 위한 시연 방식일 뿐이며, 일반적인 사용 방식과는 다르다. [37:59]

21. Buzz의 구조와 기존 메신저와의 차이

• Buzz는 인간과 AI 에이전트가 동일한 구성원으로 참여할 수 있는 셀프 호스팅 작업 공간이다. [39:38]
• Discord처럼 봇 토큰 ID를 연결하거나 외부 네트워크 릴레이에 의존하지 않아, 에이전트를 작업 공간의 독립된 주체로 운영할 수 있다. [39:52]

22. 새 작업보다 현재 파이프라인 검증 우선

• 다른 작업을 추가로 시작하고 싶은 상황에서도 흐름을 분산시키지 않고, 현재 콘텐츠 파이프라인이 끝까지 작동하는지 먼저 검증하기로 했다. [43:35]
• Buzz 사용 여부와 실제 활용법을 사용자 의견으로 수집하고, 아직 시작하지 않은 사람들의 도입 의향도 함께 확인했다. [46:29]

23. 대기 중 업무 보완과 다중 시안 협업

• 에이전트의 처리를 기다리는 시간에는 전날 놓친 업무를 보충해, 자동화 대기 시간을 별도 생산 활동으로 전환했다. [47:48]
• 명시적으로 요청한 기억이 없는데도 에이전트들이 세 가지 변형을 함께 만들고 있어, 협업 과정이 예상보다 넓게 분기됐다. [48:48]

24. 댓글 스트림 장애와 원격 접속 우회

• Social Stream Ninja가 스스로 종료되면서 실시간 댓글이 사라졌고, 앱을 다시 활성화해야 소통을 이어갈 수 있었다. [49:22]
• 서버의 Buzz에 데스크톱 클라이언트가 연결되지 않는다면, 로컬 이전에 앞서 공개 릴레이에서 전용 서브도메인을 확보해 접속부터 시험할 수 있다. [50:01]

25. 다인 Hermes 팀을 Buzz로 옮길 때의 비용

• 여러 사람이 사용하는 Hermes Agent 체계는 Buzz 안에서 팀 단위로 어떻게 작동시킬지가 중요한 연결 과제로 남는다. [50:18]
• Hermes 자체 데스크톱 앱과 기능을 이미 활용한다면 팀 전체를 Buzz로 옮기는 작업은 투입 시간에 비해 실익이 작다. [50:43]

26. Buzz 연동에서 갈린 Hermes와 OpenClaw의 안정성

• Hermes 기반 비서 Neo의 Buzz 경험은 불안정한 반면, OpenClaw 기반 Muddy는 Telegram이나 Discord에서 대화하는 것처럼 자연스러워 기존 메신저를 대체하려는 목적에 가까웠다. [51:43]
• 두 시스템에 같은 수준의 설치 시간과 노력을 투입했지만, Buzz에서 안정적으로 가동된 쪽은 OpenClaw였다. [52:18]

27. 먼저 사용하고 나중에 셀프 호스팅하는 단계적 도입

• 커뮤니티 하나를 미니 서버로 이전할 계획이지만 아직 직접 경험이 부족하며, 당장은 기존 제작자들의 단계별 설치 자료를 활용할 수 있다. [53:13]
• 처음부터 로컬 구축에 집중하기보다 서비스를 먼저 사용해 적합성을 확인했고, 만족한 뒤 자체 서버로 옮기는 것을 두 번째 단계로 잡았다. [53:33]

28. 대상별 에이전트 선택과 Buzz의 중간 위치

• OpenClaw는 개인용 에이전트로서 Hermes와 비슷하거나 더 높은 안정성을 보였고, 반대로 Hermes 업데이트가 처음으로 시스템을 망가뜨리면서 과거의 신뢰성 구도가 뒤집혔다. [54:09]
• OpenClaw는 안정 릴리스와 제한적인 후속 업데이트를 제공하는 LTS 방식을 준비해, 운영 환경의 예측 가능성을 높이려 한다. [54:24]

29. 유행보다 지속적인 실사용을 우선하는 도구 평가

• OpenClaw는 칸반 형태의 Workboard까지 추가하며 꾸준히 개선됐지만, 관심이 Hermes로 쏠린 뒤 발전 상황이 충분히 주목받지 못했다. [55:59]
• 도구의 가치는 새로운 제품을 연달아 다루는 홍보보다 실제 고객 서비스와 구축 업무에서 계속 사용하는지로 판단해야 하며, 실사용과 단순한 유행 추종을 구분해야 한다. [56:12]

30. 첫 썸네일 결과물의 품질 검수

• 워크플로 실행이 완료되고 세 가지 썸네일 시안과 관련 결과물이 첨부돼, 에이전트가 다중 변형 생성 단계까지 수행했다. [57:18]
• 시안에는 빈 공간이 지나치게 많고 글자가 작으며, YouTube 썸네일보다는 PowerPoint 슬라이드에 가까운 구성이라는 문제가 남았다. [57:50]

31. 콘텐츠 카드 반영과 마지막 형식 검증

• 새로운 도구만 좇는 흐름 때문에 OpenClaw가 과소평가됐지만, 실제 기능과 안정성은 지속적으로 크게 개선됐다. [58:53]
• 콘텐츠 카드는 예상 위치가 아닌 다른 영역에 생성됐으며, 전체 구조와 최근 영상 링크는 올바르게 작동했다. [59:49]

32. 유튜브 산출물의 첫 검수와 파이프라인 수정

• 유튜브 설명은 거의 완성됐지만 챕터 명칭을 타임스탬프로 바꾸고, 한 문단에 묶인 구간들을 각각 별도 줄로 분리해야 한다. [1:00:31]
• 현재 결과만 손보는 것으로는 부족하며, 같은 포맷 오류가 재발하지 않도록 생성 파이프라인 자체를 수정해야 한다. [1:01:02]

33. 두 에이전트의 대화로 Buzz 연결하기

• Hermes가 현재 컴퓨터가 아닌 원격 LAN 서버에 있으므로, 연결을 시작할 때 위치와 네트워크 조건을 구체적으로 전달해야 한다. [1:02:44]
• Hermes 측 에이전트와 Buzz 기본 에이전트 Fizz 양쪽에 각각 연결 목표를 주면, 서로 필요한 설정 절차를 단계별로 안내할 수 있다. [1:03:14]

34. OpenClaw의 성숙도와 Hermes가 만든 경쟁

• OpenClaw도 장시간 상시 실행되는 복잡한 시스템을 구축할 수 있지만, 안정적인 수준까지 끌어올리려면 상당한 학습·구축 시간이 필요하다. [1:04:18]
• Hermes의 인기는 에이전트 시장에 경쟁을 만들고, OpenClaw가 사용자가 선호하는 기능을 관찰해 유용한 요소를 도입하도록 압박한다. [1:04:46]

35. 용도별 플랫폼 선택과 에이전트 신뢰성

• OpenClaw와 Hermes의 기능 범위는 상당히 겹치므로 선호하는 도구를 쓰면 되지만, Clear Mud의 일상 업무에는 OpenClaw를 더 많이 쓰고 고객 작업에는 Hermes만 사용한다. [1:06:06]
• Hermes 연결 과정을 담은 약 80분 분량의 녹화는 결과가 만족스럽지 않았고, Neo와의 실제 소통도 여전히 Telegram에 의존한다. [1:06:39]

36. 하나의 실제 워크플로에서 시작하는 학습

• 구체적인 결과물을 만들다가 막힌 파이프라인 단계가 조사 방향을 만들기 때문에, 실험과 경험이 에이전트 활용 지식을 가장 빠르게 늘린다. [1:08:31]
• 처음부터 거대한 에이전트 조직을 만들지 않고 기본 팀으로 워크플로 하나를 완성한 뒤, 특정 용도의 팀을 차례로 확장해야 한다. [1:08:44]

37. OpenClaw 안정화와 ACP 연결 방식

• 업데이트마다 기능을 다시 고쳐야 했던 문제는 초기 단계의 현상이었으며, 현재 OpenClaw는 이전보다 크게 안정화됐다. [1:10:06]
• ACP 연결에서는 Muddy가 Buzz의 에이전트 목록에 나타나고 OpenClaw의 메인 설정을 상속하지만, Hermes로 연결한 Neo는 목록에 나타나지 않고 오프라인 상태다. [1:10:30]

38. 점진적 팀 확장과 Linux 클라이언트 문제

• 에이전트를 한꺼번에 많이 배치하면 작업이 흩어지므로, 작은 팀에서 시작해 필요한 역할을 천천히 추가하는 방식이 더 적합하다. [1:12:09]
• Linux 데스크톱 앱은 GTK 패닉으로 정상 작동하지 않았고, 당시에는 웹 GUI가 대체 경로가 될 수 있을 것으로 추정했다. [1:12:38]

39. 문서와 양쪽 에이전트를 이용한 실제 설정 절차

• OpenClaw 공식 문서에서 Buzz 항목을 찾고 관련 내용을 복사해, 먼저 Muddy 하나를 연결한 뒤 다른 에이전트로 확장하는 순서를 택했다. [1:14:09]
• Buzz 측 Fizz에는 OpenClaw 에이전트 연결 준비를 맡기고 같은 문서 링크를 전달해, 연결 양쪽이 각자 필요한 설정을 처리하도록 했다. [1:14:35]

40. 설치 환경에 따라 달라지는 통합 안정성

• 같은 연결 절차에서도 OpenClaw는 정상 동작했지만 Hermes의 Neo는 응답하지 않았으며, 다른 사용자에게는 반대 결과가 나올 가능성도 있다. [1:15:42]
• Hermes·OpenClaw·Buzz가 같은 컴퓨터와 루트 디렉터리에 설치된 환경은 통신 경로가 단순해 연결이 더 쉬울 것으로 추정된다. [1:15:48]

41. 전용 실험 장비와 고객별 비용 구조

• 기존 M1 장비를 전용 실험기로 바꿔 전체 디스크 접근 권한과 월 100달러 한도의 카드를 제공하고, Buzz·OpenClaw·Hermes·Pi를 제한 없이 시험할 계획이다. [1:16:34]
• 고객 환경은 예산에 따라 API 또는 OpenAI 구독을 선택하며, 고객 명의의 구독을 사용하면 계약 중단 시 OAuth 토큰을 다시 구성할 필요가 없다. [1:18:08]

42. 대화형 조사와 작업 카드의 후속 확인

• 수동 절차를 그대로 따라가기보다 에이전트에게 질문하며 설정 흐름을 배우면, 학습과 여러 작업의 동시 처리가 가능하다. [1:19:06]
• 데스크톱 앱 대신 브라우저에서 Buzz를 사용할 방법이 있는지 Fizz와 Jack에게 함께 확인한다. [1:19:14]

43. 썸네일 ‘3요소 원칙’과 재생성 기준

• 썸네일의 세 핵심 요소는 진행자 또는 사람, 브랜드·도구를 나타내는 아이콘, 그리고 텍스트·스크린샷·UI 목업 같은 보조 시각 요소다. [1:21:41]
• 높은 대비와 어두운 배경을 기본으로 삼되, 밝은 버전과 어두운 버전을 함께 비교할 수 있도록 변형안을 허용한다. [1:21:49]

44. 워크벤치 마찰과 에이전트 실험의 운영 경계

• 답글이 스레드 안에 또 다른 스레드를 만들 가능성과 계획 고정 기능의 부재가 작업 흐름을 방해하며, 작은 불편도 자체 포크 개발로 빠지는 계기가 된다. [1:23:50]
• Cloudflare Pay 지갑은 아직 예약 단계로 보이며, 별도의 가상 신용카드에 한도를 설정하면 에이전트의 결제 권한과 위험을 격리할 수 있다. [1:24:48]

45. 생성 결과 점검과 웹 클라이언트의 실제 한계

• Canvas와 스크립트 본문은 대체로 정상 생성됐지만, 도입부 훅의 구성과 초 단위 배치가 어긋나 관련 스킬을 개선해야 한다. [1:26:23]
• 공식 사용자 클라이언트는 Tauri 데스크톱 앱이며, 릴레이가 호환 브라우저 클라이언트를 받을 가능성과 완전한 Buzz 웹 앱 제공은 서로 다른 문제다. [1:27:20]

46. 임시 우회책과 포크 공개의 한계

• macOS 가상 머신에 Buzz를 설치하면 즉시 시험할 수 있지만, 자원과 운영 효율이 낮은 임시 우회책에 가깝다. [1:28:13]
• 포크를 공개한다면 기존 이름과 아이콘을 바꿔야 할 가능성이 있으며, 목적은 원본을 재포장하거나 공로를 가져가는 것이 아니라 당장의 사용성을 높이는 데 있다. [1:28:38]

47. 금요일 일정과 휴식 판단

• 피로 누적으로 오후 낮잠이 필요하지만 오후 1시 회의와 어머니에게 선물을 전달하는 일정이 함께 잡혀 있다. [1:30:01]
• 사진 인화와 외출을 토요일 아침까지 미루기보다 금요일 교통 체증이 시작되기 전에 처리하는 쪽으로 결정한다. [1:30:19]

48. 버섯 커피와 블랙커피 취향

• 버섯 커피는 급격한 피로를 줄여 주지만 카바 뿌리 음료와 비슷한 흙 맛이 나고, 입이 저리는 느낌만 빠진 듯해 취향에 맞지 않는다. [1:31:22]
• 설탕과 우유 없이 에스프레소나 프렌치프레스로 내린 블랙커피를 선호하며, 이런 습관을 2015년 무렵부터 10년 넘게 유지했다. [1:31:53]

49. 수면 보조 조합과 아침 보충제

• 테아닌, 정확한 종류를 기억하지 못한 마그네슘, 캐모마일은 커피와 섞지 않고 저녁에만 사용하는 별도 조합이다. [1:33:13]
• 세 가지를 함께 먹으면 약 20분 안에 잠들 수 있지만 꿈도 강렬해지는 개인적 경험이 있다. [1:33:27]

50. Buzz·OpenClaw·Hermes의 역할 분담

• OpenClaw에는 Clear Mud 운영을 위한 자동화·웹 앱·도구가 쌓여 있고, Buzz는 하루 중 에이전트들과 소통하는 주 작업공간을 맡는다. [1:36:41]
• Hermes 팀과는 주로 Telegram이나 TY 채팅으로 소통하며, 서로 다른 로컬 루트 디스크에 놓인 환경 때문에 Buzz 연동은 현재 불안정하다. [1:37:04]

51. 전문 마케팅 에이전트의 교차 호출

• 작동이 확인된 Suite 흐름에서 마케팅 팀을 호출해 해당 영상용 크리에이티브 일곱 개를 여러 플랫폼에 배포할 수 있도록 요청한다. [1:38:40]
• YouTube 전용 채널 안에서도 다른 책임과 전문성을 가진 에이전트를 태그할 수 있으며, Dexter는 LinkedIn을, Xavier는 X를 담당한다. [1:39:01]

52. 콘텐츠 캘린더에서 48시간 배포로 확장

• Buzz에서 YouTube 스크립트를 시작하고 캘린더에 등록한 뒤, 녹화·게시 단계에서 향후 48시간 동안 사용할 LinkedIn·X 게시물 일곱 개를 추가로 요청하는 흐름을 구상한다. [1:39:50]
• 아직 이 배포 주기를 꾸준히 실행하지는 않지만 기반은 갖춰졌으며, 가족 일정에 따라 이번 주말이나 다음 주부터 본격적으로 시작할 계획이다. [100:10] [1:41:18]

53. 에이전트별 책임과 스레드 협업

• Dexter는 LinkedIn의 창업자 관점 콘텐츠를 전담하고 Xavier는 X 게시물을 준비해 플랫폼별 책임을 분리한다. [100:53] [1:42:47]
• B는 Dexter와 Xavier의 논의가 길어질 때 전체 내용을 요약하므로 두 에이전트와 같은 그룹에 배치된다. [101:08] [1:43:26]

54. 썸네일 두 번째 시안의 수정 방향

• 두 번째 시안은 개선됐지만 그대로 사용할 수준은 아니며, 참조 사진의 배경은 버리고 인물만 분리해야 한다. [102:53] [1:44:45]
• 주제에 맞는 배경 요소로 시각적 주목도를 높이고 빈 공간은 줄이되, 아직 불완전한 텍스트 배치를 함께 수정해야 한다. [103:11] [1:45:45]

55. 가변 타이포그래피와 후킹 요소 훈련

• 여러 줄 문구는 각 줄의 시작점과 끝점이 맞도록 글자 수에 따라 폰트 크기와 줄 간격을 동적으로 바꿔야 한다. [103:23] [1:46:44]
• Buzz 로고를 더 크게 배치하고, 오른쪽에는 왼쪽을 바라보는 놀란 인물, 중앙에는 에이전트 세 명, 상단에는 문구를 두는 구도를 시도한다. [104:20] [1:46:59]

56. 채널 설명과 Canvas 기반 지침

• 개발 작업에는 별도 개발 채널을 만들고 각 채널의 설명에 용도를 적어야 에이전트가 작업 위치를 구분하고 커뮤니티 구조도 정돈된다. [106:35] [1:48:43]
• Canvas가 채널별 지침 역할을 하며, 에이전트들의 도움으로 각 Canvas를 최적화하고 마케팅 채널에도 전용 지침을 배치했다. [106:54] [1:49:42]

57. 온보딩 역할 부여와 임시 아티팩트

• 커뮤니티 온보딩은 정해진 단계를 완료하면 역할을 부여하는 단순한 구조지만, 이미 참여한 사용자의 역할이 빠진 예외가 발견된다. [107:55] [1:50:41]
• 검사 화면에서 로컬 아티팩트를 열지 못한 원인은 해당 데이터가 임시로 생성됐다가 사라졌기 때문일 가능성이 있다. [108:31] [1:51:21]

58. GitHub README를 YouTube 스크립트로 전환

• Buzz README의 첫 부분을 독립적인 YouTube 콘텐츠로 바꾸고 실제 시스템을 이용한 시연까지 결합한다. [110:05] [1:52:15]
• 스크립트는 Buzz가 무엇인가, 어떻게 사용하는가, 왜 사용해야 하는가의 순서로 구성한다. [110:37] [1:53:19]

59. 대용량 프롬프트와 로컬 실행 환경의 한계

• 긴 README 내용을 첫 게시물에 한꺼번에 붙이자 메시지가 지나치게 커지고 이전 작업으로 돌아가기 위한 스크롤 비용도 증가한다. [111:51] [1:54:38]
• 루트 메시지 일부를 접거나 숨길 방법이 보이지 않아, 다음부터는 초기 요청을 먼저 보내고 추가 맥락을 후속 메시지로 나누는 방식이 더 적합하다. [113:09] [1:55:18]

60. 세션 종료와 후속 콘텐츠 계획

• 전체 스크립트를 계속 검토하기보다 교통 체증이 시작되기 전에 개인 용무를 처리하기 위해 세션을 조기 종료한다. [116:10] [1:56:37]
• 후속 콘텐츠로 YouTube 에이전트 팀 구축 프롬프트와 초보자용 Buzz 영상을 우선하며, 가치가 낮고 경험도 좋지 않았던 Buzz·Hermes 초기 설정 영상은 후순위로 둔다. [116:52] [1:57:10]

🧾 결론

• Buzz 활용의 성패는 에이전트 수보다 역할·위임·인계·완료 조건을 얼마나 명확히 설계했는지에 달려 있다.
• 사람은 모든 중간 단계를 감시하기보다 외부 영향, 비용, 최종 방향 선택, 품질 검수에 개입하는 편이 효율적이다.
• 첫 산출물이 생성됐다는 사실만으로 파이프라인이 완성된 것은 아니다. 캘린더 반영, 포맷, 시각 품질, 재발 방지까지 확인해야 반복 가능한 시스템이 된다.
• Buzz·OpenClaw·Hermes의 우열은 절대적이지 않으며, 설치 위치·네트워크·기존 자산·이관 비용을 포함한 실제 운영 환경에서 판단해야 한다.

📈 투자·시사 포인트

• 에이전트 플랫폼의 경쟁력은 모델 기능만이 아니라 협업 인터페이스, 통합 안정성, 비동기 실행, 역할별 컨텍스트 관리에서 결정될 가능성이 크다.
• 하나의 YouTube 콘텐츠를 LinkedIn·X 게시물과 배포 계획으로 확장하는 구조는 콘텐츠 조직의 재사용 효율을 높일 수 있지만, 실제 성과는 꾸준한 실행과 품질 표준화가 뒷받침돼야 한다.
• 구독을 서드파티 하네스에서 활용할 수 있는 개방성은 이용자 선택권을 넓히는 요소인 반면, 세션 누적·키 보관·고객별 계정 관리 비용은 도입 장벽으로 남는다.
• 자체 포크는 당장의 사용성을 높일 수 있지만 유지보수가 본업을 잠식할 수 있다. 안정 릴리스, 제한적 업데이트, 공식 클라이언트 지원이 장기 채택에 중요한 신호다.

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

• OpenClaw가 Hermes보다 안정적이었다는 결과는 원격 LAN과 서로 다른 루트 디스크를 사용한 시연자의 환경에서 나온 것이다. 같은 컴퓨터에 설치하거나 다른 게이트웨이 구성을 사용하면 반대 결과가 나올 수 있다.
• 약 1시간 20분에서 20분 이하로 줄었다는 수치는 이번 콘텐츠 파이프라인의 관찰 결과다. Sweet의 썸네일 단계를 포함한 반복 실행에서도 시간과 승인 횟수가 유지되는지는 확인되지 않았다.
• 공유 컴퓨팅은 직접 시험되지 않았고, 자막상 ‘Cedance’로 들린 영상 도구와 다른 생성형 영상 모델도 충분히 비교되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 기획부터 콘텐츠 캘린더 반영까지 하나의 산출물 흐름을 정하고, 각 단계의 담당 에이전트·입력·출력·완료 신호를 문서화한다.
• 프로덕션 변경, 외부 게시, 비용 지출만 승인 장벽으로 지정하고 로컬 리서치·초안·변형 생성은 비동기로 실행한다.
• 기본 팀으로 동일 워크플로를 반복 실행하며 총 소요 시간, 사람의 질문 횟수, 인계 실패, 재작업 횟수를 기록한다.
• 캘린더 카드 존재 여부, 챕터 줄바꿈과 타임스탬프, 썸네일 ‘3요소 원칙’을 최종 검수 항목으로 추가하고 생성 지침에도 반영한다.

❓ 열린 질문

• Sweet의 썸네일 생성과 재생성을 포함해도 파이프라인의 20분 이하 처리 시간과 한 번의 승인 장벽을 유지할 수 있는가?
• 반복된 작업 인계 실패는 위임 지침, 완료 신호, 스레드 인터페이스 가운데 어느 지점에서 발생했으며 어떻게 자동 감지할 수 있는가?
• Buzz·OpenClaw·Hermes를 같은 호스트에 배치했을 때 원격 LAN 구성과 비교해 연결 안정성이 얼마나 달라지는가?