Files
hanarang-dashboard/docs/product-specs/openclaw-office-dashboard-prd.md

4.3 KiB

하나랑 오피스 대시보드 PRD

제품명

하나랑 오피스 대시보드

한 줄 정의

OpenClaw 4자매와 서브에이전트 협업을 2D 등축 투영 오피스로 시각화하고, 채팅/파이프라인/서버 헬스를 함께 운영하는 멀티에이전트 관제 프론트엔드.

배경

기존 하나랑 대시보드는 운영 정보는 잘 보여주지만, 4자매와 서브에이전트가 실제로 어떻게 협업하는지 한눈에 느끼기엔 한계가 있어.

자기야가 원하는 건 단순 상태 카드가 아니라:

  • 누가 자기 자리에서 대기 중인지
  • 누가 회의실로 이동했는지
  • 어떤 서브에이전트가 어떤 워크플로우에서 일하고 있는지
  • 지금 QA 루프인지 배포 직전인지 를 오피스라는 직관적인 은유로 읽는 화면이야.

제품 목표

  1. 4자매 메인 에이전트와 17개 서브에이전트, 총 21개 에이전트를 하나의 세계관 안에서 시각화한다.
  2. 4자매 독립 Gateway WebSocket을 통해 실시간 상태를 반영한다.
  3. Lobster 워크플로우와 Discord handoff를 자연스럽게 한 화면에 묶는다.
  4. 직접 채팅, 파이프라인 현황, 서버 헬스까지 운영 도구를 통합한다.

핵심 사용자

  • 자기야: 전체 파이프라인 운영 책임자
  • 하랑이: Planning / handoff orchestration
  • 나랑이: 구현 상태 추적
  • 다랑이: QA 루프 / blocker 판단
  • 이랑이: 배포 / 인프라 점검

핵심 시나리오

시나리오 1: 현재 누가 일하고 있는지 한눈에 보기

자기야가 메인 화면에 들어오면, 하랑/나랑/다랑/이랑 좌석과 주변 서브에이전트 상태를 보고 즉시 현재 국면을 판단한다.

시나리오 2: 구현 → QA → 배포 흐름 확인

나랑이 쪽 서브에이전트가 활발히 움직이다가, 다랑이 회의실로 연결선이 넘어가고, 승인되면 이랑이 인프라 영역으로 흐름이 넘어가는 걸 본다.

시나리오 3: 특정 자매와 직접 대화

자기야가 하랑이나 나랑이를 선택해서 direct chat을 열고 작업을 지시한다.

시나리오 4: 서버/헬스 이상 감지

대시보드 한쪽 패널에서 Gateway 연결, Dev 서버, Docker 상태 이상을 바로 감지한다.

기능 요구사항

필수

  1. 4자매 Gateway WebSocket 연결
  2. 2D 등축 투영 오피스 메인 화면
  3. 메인 에이전트 4명 고정 좌석
  4. 서브에이전트 동적 이동/상태 표시
  5. 상태: idle, thinking, tool_calling, speaking, error
  6. 협업 연결선 / 회의실 이동 시각화
  7. 자매 선택 직접 채팅 인터페이스
  8. Lobster 워크플로우 / 스프린트 / 사이클 패널
  9. 서버 상태 패널 (4자매 + Dev + Docker)

중요

  1. live / snapshot / fallback 구분
  2. 실브라우저/모바일 대응
  3. 기존 하나랑 대시보드 운영 패널과의 연속성 유지

정보 구조

메인 오피스 화면

  • 좌측 또는 중앙: 오피스 씬
  • 우측: 선택 에이전트 detail / chat / workflow
  • 하단 또는 보조 패널: 서버 헬스 / 최근 handoff / sprint state

오피스 씬 요소

  • 하랑이 데스크
  • 나랑이 데스크
  • 다랑이 데스크
  • 이랑이 데스크
  • 회의실
  • 임시 작업석
  • 인프라/서버 존
  • 서브에이전트 이동 경로

채팅

  • 자매 선택 탭
  • 메시지 히스토리
  • 입력창
  • tool call 상태 / streaming 표시

운영 패널

  • active workflow
  • current sprint
  • review loop
  • deploy gate
  • server health

데이터 소스

  • 4자매 Gateway WebSocket
  • activity log
  • workflow state
  • session/chat API
  • admin/system/health API

기술 원칙

  • 기존 Next.js + styled-components 유지
  • Backend는 기존 Nest.js + Prisma 유지
  • WebSocket은 OpenClaw Gateway 기준
  • 필요 시 polling reconciliation 허용
  • fake 데이터 하드코딩 금지

비기능 요구사항

  • 첫 화면에서 현재 협업 구조 이해 가능
  • 과한 애니메이션 금지
  • 모바일에서도 핵심 흐름 유지
  • 데이터 소스 구분이 명확해야 함

성공 기준

  • 자기야가 메인 화면만 보고 현재 상태를 설명할 수 있음
  • 4자매/서브에이전트 구조가 카드보다 더 직관적으로 읽힘
  • 채팅/워크플로우/서버 패널이 따로 놀지 않음
  • live / snapshot / fallback 구분이 사용자에게 정직하게 보임