🎬 Build a Multi-Agent Team with Openclaw

▶️ 유튜브

• 원본 링크: https://youtu.be/WqWMszBB9t0?si=x-9yxWwoqGoz7pKr

🖼️ 4컷 인포그래픽

💡 한 줄 결론

멀티 에이전트의 경쟁력은 숫자가 아니라 조직도, 위임 폐쇄루프, 세션 간 통신, 일정 자동화가 결합된 운영체계에서 나온다. OpenClaw를 제대로 쓰려면 “여러 봇”이 아니라 상하 보고와 정기 운영 리듬을 가진 실행 조직으로 설계해야 한다.

📌 핵심 요점

1. 28개 에이전트를 돌리는 구조에서도 실제 생산성을 만드는 요소는 규모가 아니라 CEO-COO-임원-실무 담당으로 이어지는 명확한 역할 분리와 보고선이다.
2. 멀티 에이전트 협업은 프롬프트 문장력보다 에이전트 ID, 기본 모델, sessions_send 같은 세션 간 통신 설정이 먼저 갖춰져야 재현된다.
3. 위임 후 방치하는 구조는 운영 실패에 가깝고, 요청 접수→담당자 전달→완료 보고→상위 복귀까지 닫힌 루프가 있어야 팀처럼 움직인다.
4. 하트비트, 크론, 커스텀 스킬, 회의록 파일을 붙이면 에이전트는 단발 응답 도구를 넘어 정기 회의·상태 점검·예약 실행을 수행하는 운영 레이어가 된다.
5. 남의 조직도를 그대로 복제해도 효과가 낮고, 자신의 업무 흐름·의사결정 방식·커뮤니케이션 구조에 맞게 조직과 프롬프트를 함께 설계해야 성과가 난다.

🧠 상세 요약

1) 배경과 문제 정의

이 영상의 출발점은 “에이전트를 많이 두면 자동으로 팀이 되는가”라는 질문이다. 발표자는 실제 운영 사례를 통해 핵심이 수량이 아니라 역할 구조, 위임 규칙, 실행 조건, 정기 운영 장치에 있음을 보여주며, 시청자가 자기 업무에 맞는 조직형 에이전트 시스템을 설계해야 한다는 관점을 제시한다.

2) 섹션별 상세 정리

1. 24시간 가동 체계를 하나의 ‘운영체제’로 소개 [00:00]

• 발표자는 24시간 돌아가는 28개 에이전트를 운영 중이며, 이를 단순 봇 모음이 아니라 Muddy OS라는 하나의 운영 시스템으로 설명한다.
• 목표는 자신의 구성을 자랑하는 데 그치지 않고, 시청자도 OpenClaw 안에서 유사한 다중 에이전트 구조를 만들 수 있게 원리를 공개하는 데 있다.

2. CEO와 COO를 중심으로 한 회사형 조직도 제시 [00:19]

• 발표자 본인은 CEO처럼 비전, 전략, 최종 판단을 맡고, 핵심 에이전트 Muddy는 연구·조율·위임을 담당하는 COO 겸 비서 역할을 맡는다.
• 중요한 운영 규칙은 “지금 바로 실행” 같은 직접 지시가 없는 한 Muddy가 독단적으로 실행하지 않고, 상위 의사결정자에게 보이도록 움직여야 한다는 점이다.

3. 임원진과 지역 담당자를 둔 중간관리층 설계 [00:49]

• Muddy 아래에는 직접 보고받는 지역 담당자들이 있고, 그 위에 CTO·CMO·CRO 같은 임원진이 역할별로 배치된다.
• 이 구성은 기능별 전문화와 보고 분산을 위해 필요하며, 실제 회사 조직을 에이전트 운영 모델로 번역한 사례로 제시된다.

4. 회의와 캘린더를 통한 운영 리듬 내장 [01:12]

• 시스템에는 주간·월간 일정 보기 기능이 포함돼 있고, 임원진 에이전트들은 매일 아침 자체 회의를 수행한다.
• 회의록 파일을 공유 작업공간에 남겨 전날과 지난주 논의를 추적하고, 반복 논의를 줄이며, 월간 캘린더 단위로 전체 시스템의 정상 작동 여부를 점검한다.

5. 완전 자율이 아니라 정기적 인간 유지보수를 포함한 구조 [01:44]

• 발표자는 토요일을 에이전트 휴무일로 두고, 그날 직접 인프라 관리와 백엔드 업그레이드를 수행한다.
• 즉 “24시간 운영”은 무인 완전자율이라기보다, 사람이 주기적으로 시스템을 정비하는 운영 모델 위에서 성립하는 자동화다.

6. 각 에이전트에 독립 작업공간과 고유 주기를 부여 [02:11]

• Muddy와 각 임원 에이전트는 각자의 작업공간, 운영 리듬, 하트비트를 가진다.
• 발표자는 이 구조를 복붙하지 말고, 각 에이전트를 특정 책임과 산출물에 맞게 설계해야 한다고 강조하며, 개별 에이전트의 전문성 설계를 핵심 원칙으로 둔다.

7. 처음부터 대규모가 아니라 필요에 따라 확장된 구조 [02:31]

• 처음에는 하위 역할이 몇 개 없었지만, 운영하면서 필요한 팀 구조가 보이자 점차 하위 에이전트와 역할을 늘려갔다.
• 이 대목은 멀티 에이전트 조직이 처음부터 완성형으로 설계되기보다, 실제 운영 경험 속에서 진화하는 구조임을 보여준다.

8. 협업의 핵심은 인프라 설정: ID·모델·세션 전송 [02:54]

• 발표자는 각 에이전트에 고유 ID와 기본 모델을 지정해야 하며, 특히 세션 간 메시징 설정이 매우 중요하다고 강조한다.
• sessions_send가 활성화되지 않으면 역할 분담이 있어도 실제 위임이 불가능하므로, 멀티 에이전트 팀의 기반은 조직도보다도 먼저 통신 인프라에 있다.

9. 실제 위임은 미리 정의된 경로 위에서 작동한다 [03:23]

• 예를 들어 프런트엔드나 백엔드 문제가 Muddy로 오면, Muddy는 CTO인 일론에게 해당 작업을 넘기는 식으로 흐름이 설계돼 있다.
• 이때 핵심은 즉흥적 판단이 아니라 “어떤 문제가 오면 누가 받고 어디로 넘기며, 누가 다시 보고하는가”가 사전에 정해져 있다는 점이다.

10. 실행 모드와 조율 모드를 분리하는 ‘지금 해’ 규칙 [03:38]

• 발표자는 위임 후 완료 보고를 반드시 받는 구조를 중요하게 여기며, 단순 전달 후 방치하는 행동을 실패로 본다.
• 동시에 모든 작업을 중간관리 에이전트가 직접 수행하면 병목이 생기므로, 기본은 조율 중심으로 두고 “지금 해” 같은 명시적 지시가 있을 때만 직접 실행 모드로 전환하게 만든다.

11. 에이전트 생성 프롬프트도 조직 설계의 일부 [04:15]

• 새 에이전트를 만들 때는 이름만 정하는 것이 아니라 SOUL.md, AGENTS.md, 정체성, 책임 범위, 상위 보고 체계, 메모리 파일까지 포함한 온보딩이 필요하다고 설명한다.
• 즉, 에이전트 생성은 단순 인스턴스 추가가 아니라 역할과 행동 규칙을 가진 조직 구성원 채용에 가깝다.

12. 위임 구조는 반드시 세션 전송 테스트로 검증해야 한다 [05:00]

• A가 B에게 일을 맡기고, B가 결과를 다시 A에게 보내며, A가 상위로 보고하는 흐름을 직접 시험해보라고 제안한다.
• 발표자는 이런 폐쇄 루프 검증이 있어야만 멀티 에이전트 자동화가 진짜 팀 단위 운영으로 넘어간다고 본다.

13. 하트비트·크론·커스텀 스킬로 예약 업무를 체계화 [05:19]

• 다음 단계로는 하트비트와 크론을 설정하고, 각 예약 작업이 전용 스킬을 참조하도록 만드는 구성을 권한다.
• 그래야 정기 실행이 단순 호출에 그치지 않고, 반복 가능하고 표준화된 워크플로로 굳어진다.

14. 자율 회의, 회의록, 음성, 텔레그램 보고까지 연결 [05:48]

• 임원진 회의를 매일 자동으로 열고, 최근 2~3회 회의록을 참고해 몇 차례 토론한 뒤 새로운 회의록을 생성하도록 설계한다.
• 그 결과를 음성 파일과 텔레그램 요약 보고까지 이어 붙여, 운영 결과가 기록·전달·확산되는 전체 체인을 자동화한다.

15. 핵심 조언은 ‘복제’보다 ‘자기 조직 설계’ [06:06]

• 발표자는 시청자가 네 가지 팁만 베낀다고 원하는 성과가 나오지 않는다고 선을 긋는다.
• 먼저 자신의 업무 구조, 팀 형태, 커뮤니케이션 방식, 목표 고객과 과업 흐름을 설계한 뒤, 그 위에 프롬프트와 에이전트 구조를 맞춰야 한다는 것이 핵심 조언이다.

16. 부트캠프와 마무리: 실전 공개 구축 철학 [06:47]

• 이후 수주간 무료 라이브 부트캠프를 통해 Muddy OS를 처음부터 다시 구축하는 과정을 공개하겠다고 안내한다.
• 마지막까지 발표자는 자신을 이론 전문가보다 공개적으로 만들고 검증하는 실전형 제작자로 위치시키며, 시청자 맞춤형 주제 제안도 받겠다고 말한다.

✅ 액션 아이템

• 현재 업무를 CEO, 운영 조율, 기술 실행, 고객/매출처럼 최대 4개 책임 축으로 쪼개고, 각 축마다 “받을 입력”, “내릴 결정”, “상위에 올릴 보고 형식”을 1페이지 조직도로 정리한다.
• OpenClaw에서 새 에이전트 1개를 만들 때 이름만 넣지 말고 SOUL.md, AGENTS.md, 책임 범위, 금지 행동, 상위 보고 대상, 기본 모델까지 포함한 온보딩 프롬프트로 생성해 본다.
• sessions_send가 가능한 두 에이전트로 A→B 위임, B→A 완료 보고, A→상위 요약 보고의 3단계 테스트를 한 번 돌려 보고, 어느 구간에서 메시지 누락이나 책임 공백이 생기는지 기록한다.
• 매일 아침 임원 회의용 크론 1개와 주 1회 인프라 점검 블록 1개를 따로 만들고, 회의록 누적 방식과 점검 주기 분리가 실제 운영 충돌을 줄이는지 2주 단위로 비교한다.
• 반복 업무 하나를 골라 단순 크론 호출이 아니라 전용 커스텀 스킬로 묶고, 동일 입력에서 동일 형식 산출물이 나오는지 일주일간 품질 편차를 측정한다.

❓ 열린 질문

• 28개 규모에서 성과가 난 핵심 요인이 역할 분리인지, 아니면 발표자 개인의 강한 통제와 프롬프트 숙련도인지 분리 검증하려면 어떤 생산성 지표를 먼저 잡아야 할까?
• sessions_send 기반 위임이 늘어날수록 조정 비용과 메시지 왕복 시간이 커질 텐데, 어느 시점부터는 에이전트 추가가 순이익보다 순손실이 되는지 어떻게 측정할 수 있을까?
• 최근 2~3회 회의록만 참조하는 방식은 반복 방지에는 유리하지만, 장기 전략 기억 손실이나 누적 맥락 왜곡을 막기에는 부족하지 않을까?
• 토요일 수동 유지보수가 필수라면, 이 시스템의 진짜 자동화 범위는 어디까지이며 “24시간 자율 운영”이라는 표현이 인간 개입 비용을 과소평가하게 만들 가능성은 없을까?