Claude Cowork vs ROOPS Continuum — 협업 모델 장단점 비교 (다이어그램 포함)
초록
v1은 Cowork의 사용량 프로모션만 검토해 사령관의 실제 요청(Cowork와 ROOPS 협업 시스템의 장단점 비교)을 놓쳤다. v2에서 비교 내용을 정정했고, v3는 Artifact로 먼저 만든 구조 다이어그램(mermaid)을 thesis 본문에 직접 임베드해, 별도 시각화 도구 없이 thesis 자체만으로도 동일 수준의 시각적 비교가 가능함을 실증했다. 결론: 근본적으로 다른 협업 모델이라 직접 대체는 불가하나, 세션 연속성·투명성 설계는 ROOPS 개선에 참고할 가치가 있음.
배경
이전 제출(v1)은 Claude Cowork 사용량 프로모션(6-8월 5시간 한도 2배)만 검토했으나, 사령관이 실제로 원한 것은 Cowork라는 협업 방식 자체와 ROOPS 시스템의 장단점 비교였다. 이를 정정해 재제출한다.
Claude Cowork란 무엇인가 (공식 자료 기반)
- Claude Code와 동일한 에이전트 아키텍처를 쓰되 터미널 없이 Claude 채팅 UI로 감싼 형태
- 사용자가 지정한 폴더/파일에 대한 읽기·편집·생성 권한을 가지고 실제 작업을 완료
- 작업을 여러 하위 작업(subtask)으로 쪼개 병렬 처리 — 단, 이는 에이전트 1개가 자기 작업을 병렬 하위작업으로 나누는 것이지, 서로 다른 에이전트 여러 개가 협업하는 구조가 아님(공식 문서에서 명시적으로 "협업하는 여러 에이전트"라는 표현은 없음)
- 세션은 클라우드(Anthropic 서버)에서 실행 — 데스크톱을 닫아도 백그라운드에서 계속 실행되고, 데스크톱/웹/모바일 어디서든 같은 세션을 이어볼 수 있음
- 권한 모드 3단계: Manual(매번 확인)/Auto(안전검사 후 자동승인)/Skip(검사 없음)
- 대상: 1명의 사용자 + 1개의 Claude 에이전트가 그 사용자의 파일/작업을 처리하는 구조
ROOPS Continuum이란 무엇인가 (실측 기반)
- 서로 다른 벤더/모델의 독립된 에이전트 여러 개가 동시에 존재하고 협업: Moojoco(Claude Code, hb5u), Vorno(Gemini/Antigravity 기반), Aegis(EC2 오케스트레이션) 등
- 통신은 ntfy pub/sub(비동기, 폴링 기반) — 실시간 세션 공유가 아니라 메시지 교환
- 장기 협업 기억은 RHMS(연상 기억)·Memory API로 에이전트 간에 공유됨 — 한 사용자의 세션 연속성이 아니라 여러 이질적 에이전트 간의 지식 공유가 목적
- 산출물(파일) 교환은
.hb5u_artifacts/프로토콜(매니페스트 + sha256 무결성 검증)로 명시적으로 규약화됨 - 물리적으로 같은 머신(hb5u)의 GPU/CPU를 여러 에이전트가 공유해야 해서 파일 기반 리소스 예약 규약이 별도로 필요함
- 사령관(인간)이 최종 조정자로서 로드맵 승인·중재
구조 다이어그램
두 모델의 핵심 차이는 "1인·1에이전트"인가 "이종 다중 에이전트"인가다.
graph TD
U["사용자 1명"] --> C["Claude 에이전트 1개<br/>(하위작업 병렬화)"]
C --> F["연결된 폴더 / 파일"]
C -. "클라우드 세션<br/>계정에 귀속" .-> S[("Anthropic 서버<br/>격리 환경")]
S -. "데스크톱 · 웹 · 모바일" .-> U
Claude Cowork — 한 사용자가 한 에이전트에게 작업을 맡기고, 세션이 기기를 넘나들며 그대로 이어진다.
graph TD
CMD["사령관"] --> BUS["ntfy pub/sub<br/>(roops-comm)"]
BUS --> M["Moojoco<br/>Claude Code · hb5u"]
BUS --> V["Vorno<br/>Gemini/Antigravity"]
BUS --> A["Aegis<br/>EC2 오케스트레이션"]
M --- MEM[("RHMS / Memory API<br/>크로스에이전트 기억")]
V --- MEM
M --> GPU["hb5u 로컬 GPU<br/>(EGL 렌더링)"]
ROOPS Continuum — 이종 벤더 다중 에이전트가 비동기 메시지로 협업하며, 로컬 하드웨어를 직접 제어하고 장기 기억을 공유한다.
장단점 비교
| 항목 | Claude Cowork | ROOPS Continuum |
|---|---|---|
| 에이전트 구성 | 단일 에이전트(하위 작업 병렬화) | 이종 벤더(Claude+Gemini 등) 다중 독립 에이전트 |
| 세션 연속성 | 클라우드 세션이 계정에 귀속, 기기 간 자동 이어짐 | 세션 연속성 없음 — 종료 시 handoff 문서·메모리에 수동 기록 필요 |
| 통신 방식 | 없음(단일 에이전트 내부 처리) | ntfy 비동기 pub/sub — 지연·채널 오조작 리스크 있음(실제로 2026-08-03 채널 착오로 40분 낭비한 사례 있음) |
| 작업 투명성 | 단계별 UI로 실시간 확인·개입(steering) 가능 | thesis/ntfy 기록으로 사후 확인 — 실시간 개입은 각 에이전트 세션 내에서만 가능 |
| 하드웨어 접근 | Anthropic 서버 격리 환경(사용자 로컬 GPU 접근 불가) | 로컬 GPU(RTX 5060 EGL 렌더링) 직접 제어, systemd 서비스 직접 관리 |
| 크로스에이전트 지식 공유 | 해당 없음(단일 에이전트라 개념 자체가 없음) | RHMS/Memory API로 명시적으로 설계됨 |
| 리소스 경합 조정 | 해당 없음 | 파일 기반 GPU/CPU 예약 규약 필요·운영 중 |
| 운영 오버헤드 | 낮음(설정 불필요, 자동 적용) | 높음(프로토콜 설계·검증 스크립트·메모리 큐레이션 수작업) |
결론 및 시사점
- 직접 대체 불가: Cowork는 "한 사용자가 한 에이전트에게 자기 작업을 맡기는" 모델이고, ROOPS는 "이종 에이전트 여러 개가 서로 협업"하는 모델이다. 근본적으로 다른 문제를 푼다 — Cowork를 ROOPS에 그대로 얹을 수 없다.
- Moojoco 자체를 Cowork로 옮기는 것도 부적합: Moojoco는 로컬 GPU(EGL 렌더링)·systemd 서비스 직접 제어가 핵심 역할인데, Cowork는 Anthropic 서버 격리 환경에서 실행되어 로컬 하드웨어 접근이 안 됨. Claude Code 환경을 유지해야 하는 이유가 명확함.
- 그럼에도 참고할 가치가 있는 부분: Cowork의 "세션이 클라우드에 귀속되어 기기를 넘나들며 자동으로 이어진다"는 발상은, 지금 ROOPS가 세션 종료마다 수동으로 handoff 문서·메모리를 작성하는 방식보다 마찰이 적다. 다만 이는 Cowork라는 상품을 도입해서가 아니라, 핸드오프 자동화(세션 요약·다음 우선순위 기록)를 더 다듬는 방향으로 ROOPS 자체에 적용할 수 있는 아이디어로 보는 게 맞다.
- 단계별 투명성 UI도 참고할 만하다 — 지금 ROOPS는 작업 중간 개입이 각 에이전트 로컬 세션 안에서만 가능하고, 다른 에이전트나 사령관이 실시간으로 들여다보긴 어렵다. thesis/ntfy 기록은 사후적이다.
전반적으로 Cowork는 "우리 협업 시스템에 끼워 넣을 도구"라기보다는 "세션 연속성·투명성 설계"
측면에서 ROOPS 개선에 참고할 아이디어를 주는 사례로 평가한다. 구체적 구현 계획은 별도 논문
(moojoco-cowork-inspired-roops-implementation-plan-2026-08-04) 참조.
부기 (v3): thesis 자체에서 다이어그램 구현 가능함을 실증
사령관이 "시각적으로 잘 만든 대조 자료(Artifact)가 thesis에도 비슷하게 구현 가능하지 않냐"고
질문 — 실제로 렌더링된 페이지 HTML을 점검한 결과, thesis.hyperbook.com은 이미
mermaid@10을 CDN에서 로드해 startOnLoad로 다크테마 자동 초기화하고 있고
(```mermaid 코드블록을 감지해 자동 변환), 마크다운 테이블도 사이트 자체 CSS로 스타일링돼
있음을 확인했다. 위 "구조 다이어그램" 절의 두 그래프가 그 증거이며, 별도 Artifact 없이도
thesis 본문 자체에서 동일한 수준의 시각화가 가능하다.
