🎬 How to Build a PREMIUM OpenClaw Mission Control Dashboard (Step-by-Step Guide)

▶️ 유튜브

• 원본 링크: https://youtu.be/2udlMLtEdcg?si=R4NDGudDjz7FDIZI

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 멀티 에이전트 운영의 핵심은 에이전트 분업, 채널 분리, 외부 DB 로깅, 초경량 대시보드를 결합해 낮은 인프라 비용으로도 실제 통제 가능한 운영 체계를 만드는 데 있다. 경쟁력은 기능 추가보다 어떤 에이전트가 어떤 모델로 어떤 작업을 했는지 추적 가능하게 설계해 비용 누수와 운영 혼선을 동시에 줄인 점에 있다.

📌 핵심 요점

1. 연구·콘텐츠·마케팅·개발·소셜 역할을 5개 에이전트로 분리하고, Telegram 라우터와 Discord 전용 채널을 함께 써서 자동 파이프라인과 개별 직접 호출을 모두 가능하게 만들었다.
2. 에이전트 활동 로그와 개인 칸반 데이터를 Supabase에 저장해 VPS를 가볍게 유지하면서도 최근 작업, 상태, 사용 모델, 작업량을 실시간으로 추적할 수 있게 했다.
3. 작업별 모델 사용 이력을 남겨 연구·개발·콘텐츠 작업에 과한 모델이 배정되는 순간을 식별하고, 크레딧 낭비를 운영 레벨에서 통제하는 구조를 만들었다.
4. 프론트엔드는 단일 HTML, Tailwind CDN, 바닐라 JS만으로 구성해 빌드 시스템과 무거운 런타임 의존성을 없애고 장애 지점과 리소스 사용량을 줄였다.
5. 대시보드는 보기용 화면이 아니라 에이전트 모니터링, 최근 로그 확인, 칸반 작업 관리, 향후 실행·일시정지 같은 제어 기능까지 수용하는 미션 컨트롤 콘솔로 확장되는 방향을 제시했다.

🧠 상세 요약

1) 배경과 문제 정의

이 영상의 출발점은 “멀티 에이전트 시스템을 실제로 오래 굴리려면 무엇을 분리하고 무엇을 기록해야 하는가”에 있다. 단순히 에이전트를 많이 만드는 것이 아니라 역할 충돌을 줄이고, 대화 채널을 분리하고, 로그와 저장소를 외부화해 운영 복잡도와 비용을 함께 통제할 수 있는지가 핵심 판단 포인트로 제시된다.

2) 섹션별 상세 정리

1. 전체 목표는 에이전트 팀과 운영 콘솔을 동시에 만드는 것 [00:00]

• 발표자는 연구원, 콘텐츠 작성자, 마케터, 개발자, 소셜 담당자까지 5명의 전문 에이전트를 세팅하고, 이들의 활동을 한눈에 보는 미션 컨트롤 대시보드까지 함께 구축하겠다고 선언한다.
• 목표물은 단순 채팅봇이 아니라 에이전트 협업, 작업 추적, 개인 생산성 관리가 한 시스템 안에서 연결되는 운영 구조다.

2. 저장은 VPS가 아니라 Supabase로 빼서 시스템을 가볍게 만든다 [00:53]

• 대시보드가 무거워지는 주된 원인을 로컬 저장과 서버 부하로 보고, 에이전트 로그와 To-do 데이터를 모두 Supabase에 저장하는 구조를 채택한다.
• 이렇게 하면 VPS는 실행과 라우팅에 집중하고, 데이터 적재와 조회는 외부 DB가 담당해 장기 운영 시 속도와 안정성을 확보할 수 있다.

3. Telegram은 라우터, Discord는 전용 작업 채널로 역할을 나눈다 [01:26]

• Telegram은 에이전트 생성, 전체 오케스트레이션, 빠른 명령 입력에 쓰고, Discord는 에이전트별 전용 채널을 둬 직접 작업을 주고받는 공간으로 설계한다.
• 이 분리는 한 채팅방에 모든 문맥이 섞이는 문제를 줄이고, 연구는 연구 채널에서, 개발은 개발 채널에서 바로 처리하게 만든다.

4. 저비용 VPS와 OpenClaw 초기 셋업으로 진입 장벽을 낮춘다 [02:14]

• 발표자는 OpenClaw 실행 환경으로 저가 VPS를 추천하며, Contabo와 Hostinger를 비교한 뒤 가격 대비 효율 측면에서 Contabo를 선택한다.
• SSH 접속, OpenClaw 온보딩, 모델 선택, OpenAI/Codex 인증까지 이어지는 흐름을 보여주며 “개인도 싼 비용으로 시작 가능하다”는 점을 강조한다.

5. 다섯 에이전트를 역할·프롬프트·워크스페이스까지 분리한다 [12:45]

• Alex, Maya, Jordan, Dev, Sam으로 대표되는 다섯 에이전트는 각자 다른 시스템 프롬프트와 정체성을 부여받고, 전용 워크스페이스와 메모리 구조까지 따로 갖는다.
• 이 분리는 단순 이름놀이가 아니라 각 에이전트가 어떤 맥락을 축적하고 어떤 종류의 일을 맡아야 하는지 구조적으로 고정하는 장치다.

6. 라우터와 파이프라인으로 자동 협업 흐름을 만든다 [15:50]

• Telegram 라우터 시트는 “대시보드가 안 된다” 같은 입력을 개발자에게 보내고, 연구 요청은 연구원에게 보내는 식으로 작업을 자동 분기한다.
• 동시에 Alex→Maya→Sam→Jordan 순으로 이어지는 콘텐츠 파이프라인도 구성해, 조사→작성→소셜 전환→홍보 전략까지 연쇄 처리되는 자동 협업을 시연한다.

7. Discord 채널별 매핑 검증으로 운영 오류를 초기에 잡는다 [18:57]

• 발표자는 각 에이전트가 Discord에서 자기 채널만 듣고 응답하도록 설정하고, 서버 ID·채널 ID·봇 권한을 정확히 매핑하는 과정을 상세히 보여준다.
• 이후 각 채널에서 “당신은 누구인가?” 같은 테스트를 실행해, 잘못된 채널 복제나 에이전트 오배정 같은 문제를 조기에 발견하는 검증 절차의 중요성을 강조한다.

8. 운영 대시보드의 핵심은 모델 사용 추적과 활동 로그 가시성이다 [31:41]

• 다섯 에이전트가 최근 무슨 작업을 했는지, 어떤 모델을 사용했는지, 활동 시간과 작업량이 어떠한지를 보여주는 모니터링 페이지가 대시보드의 첫 축으로 제시된다.
• 특히 과거에 비싼 모델이 불필요한 작업에 배정되어 크레딧을 낭비했던 경험 때문에, 모델 기록은 단순 통계가 아니라 비용 통제 장치로 다뤄진다.

9. Supabase 테이블을 로그 저장소와 칸반 저장소로 동시에 활용한다 [32:51]

• agent_logs에는 에이전트 이름, 작업 설명, 모델, 상태, 생성 시각 등을 남기고, todos에는 제목, 우선순위, 마감일 등 개인 작업 관리용 정보를 저장한다.
• 이후 실제 테스트 작업을 돌려 Sam, Maya, Dev 등의 로그가 들어오는지 확인하면서, 상태와 모델 기록이 운영 의사결정에 충분한지 검증한다.

10. 프론트엔드는 단일 파일로 시작하고 버그를 반복 수정해 완성도를 올린다 [41:30]

• 대시보드는 npm, 빌드 도구, 무거운 프레임워크 없이 단일 HTML + Tailwind CDN + 바닐라 JS로 제작된다.
• 중간에 탭이 비거나 Supabase 연결이 보이지 않는 문제도 발생하지만, 에이전트와 반복적으로 대화하며 수정하고 스크린샷으로 피드백을 주는 방식으로 점진 개선한다.

11. 에이전트 모니터링 화면은 비용과 작업 품질을 함께 읽는 운영 패널이 된다 [50:40]

• 수정이 끝난 뒤 다섯 에이전트의 마지막 작업, 사용 모델, 활동 시간, 오늘 작업량이 화면에 표시되며 실제 Supabase 데이터와도 일치함을 확인한다.
• 이로써 대시보드는 단순 시각화가 아니라, “누가 무엇을 어떤 모델로 처리했는가”를 바로 판단하는 통제판 역할을 수행하게 된다.

12. 칸반 보드와 홈 대시보드까지 연결되며 미션 컨트롤 구조가 완성된다 [56:35]

• To-do 칸반 페이지는 드래그 앤 드롭과 새 작업 생성이 가능하고, 추가·삭제 작업이 실제 Supabase todos 테이블과 동기화되는지도 확인한다.
• 마지막으로 홈 화면을 전체 현황을 보여주는 명령 센터로 발전시키면서, 에이전트 탭·작업 탭·메인 요약 화면이 분리된 운영 콘솔 구조를 완성한다.

13. 최종 메시지는 ‘고급 모델보다 운영 설계’에 가깝다 [60:15]

• 발표자는 이 결과물이 초고가 모델 없이 Codex 중심으로도 충분히 나왔다는 점을 높이 평가한다.
• 결국 경쟁력은 모델 자체보다 역할 분업, 로그 추적, 채널 구조, 저장소 분리, 경량 UI 같은 운영 설계의 조합에서 나온다는 메시지로 귀결된다.

14. 보안과 사용성은 SSH 터널 자동화로 절충한다 [62:23]

• 대시보드는 외부에 그대로 공개하지 않고 Python HTTP 서버와 SSH 터널을 조합해, 접속 가능한 사람을 VPS 접근 권한 보유자로 제한한다.
• 매번 수동으로 터널을 열어야 하는 불편은 SSH 키와 PowerShell 스크립트로 자동화해, 더블클릭으로 대시보드를 여는 방식으로 개선한다.

✅ 액션 아이템

• 현재 OpenClaw 환경에서 연구·개발처럼 경계가 자주 섞이는 에이전트 2개를 먼저 골라 시스템 프롬프트, 워크스페이스, 호출 경로를 분리하고, 각 에이전트가 응답해야 할 전용 채널을 하나씩 지정한다.
• Supabase에 최소한 agent_logs와 todos에 해당하는 스키마를 만들고, 모든 에이전트 응답 직전 또는 직후에 agent_name, task, model, status, created_at가 남도록 오케스트레이션 규칙을 삽입한다.
• 최근 1주일 작업 중 비용이 아까웠던 사례 3개를 기준으로 “작업 유형별 허용 모델 표”를 만들고, 실제 로그에서 연구·작성·개발 작업에 과한 모델이 배정된 구간이 있었는지 비교 점검한다.
• 대시보드 MVP는 React나 빌드 체인 없이 단일 HTML + Tailwind CDN + 바닐라 JS로 시작하고, 첫 버전에는 에이전트 상태 카드, 최근 로그 10건, 오늘 작업량만 먼저 연결해 운영 가시성을 확보한다.
• Discord를 이미 쓰고 있다면 에이전트별 전용 채널을 만든 뒤 각 채널에서 자기소개 테스트와 로그 적재 테스트를 함께 돌려, 채널 매핑 오류와 모델 기록 누락을 한 번에 검증한다.

❓ 열린 질문

• 에이전트별 모델 사용 로그만으로는 비용 통제는 가능하지만 품질 대비 효율까지는 판단하기 어렵다. 작업 결과의 재사용률, 수정 횟수, 최종 채택률 같은 품질 지표를 어떤 방식으로 함께 기록해야 모델 선택 최적화가 가능해질까?
• Discord 전용 채널 구조는 문맥 분리에 강하지만 에이전트 수가 늘수록 채널 관리와 권한 매핑 비용이 커진다. 어느 시점부터는 역할별 채널보다 파이프라인별 채널이나 태스크별 스레드 구조가 더 효율적이지 않을까?
• 24~48시간 로그 삭제는 경량 운영에 유리하지만, 장애 원인 분석과 장기 개선에는 과거 데이터가 필요하다. 원본 로그는 짧게 보관하되 어떤 집계 지표만 장기 보존해야 운영 가벼움과 분석 가능성을 함께 확보할 수 있을까?
• 프런트에서 Supabase를 직접 읽는 단순한 구조는 빠르게 만들기 좋지만, 쓰기 권한까지 같은 경로로 열어두면 운영 규모가 커질수록 위험해진다. 읽기 전용 대시보드와 쓰기 전용 오케스트레이터를 언제부터 분리해야 보안과 속도의 균형이 맞을까?