Clawe: 에이전트 팀을 굴리는 오픈소스 ‘Trello형 칸반’의 등장
Clawe는 여러 AI 에이전트를 “개인 비서”가 아니라 “팀”으로 운영하기 위해 만든 오픈소스 협업 시스템입니다. Trello처럼 칸반 보드로 일을 나누고 진행도를 관리하되, 에이전트가 주기적으로 깨어나(heartbeat) 업무를 확인하고, 멘션/변경사항을 거의 실시간으로 알림 받으며, 같은 컨텍스트를 공유하도록 설계되어 있죠1.
이 글에서는 Clawe가 기존 에이전트 도구와 뭐가 다른지, 아키텍처가 어떻게 생겼는지, 실제 팀에 붙여 쓰려면 어디부터 정리해야 하는지까지 한 번에 정리해봅니다.
‘에이전트 한 명’이 아니라 ‘스쿼드’로 설계된 이유
요즘 에이전트 프로젝트를 보면 “자동으로 뭔가 해주는 봇”은 많습니다. 그런데 막상 팀 업무에 넣으려 하면 벽이 생깁니다. 누가 어떤 일을 맡는지, 진행 상황은 어디서 보는지, 급한 이슈는 어떻게 알려주는지 같은 “운영의 디테일”이 비어 있는 경우가 많거든요.
Clawe의 재미는 그 빈칸을 제품의 기본값으로 채웠다는 점입니다. 역할이 다른 에이전트를 여러 명 띄워서 한 보드 안에서 티켓을 주고받고, 상태를 바꾸고, 멘션을 던지면 알림이 가는 구조가 처음부터 들어가 있습니다1. 한마디로 “에이전트 자동화”보다 “에이전트 조직 운영”에 더 가까운 도구예요.
Trello처럼 보이지만, 속은 ‘운영 엔진’이다
겉으로는 칸반 보드입니다. 카드가 있고, 담당자를 지정하고, 서브태스크를 쪼개고, 댓글로 커뮤니케이션하는 익숙한 흐름이죠.
하지만 Clawe의 핵심은 보드 UI가 아니라, 에이전트가 일을 놓치지 않게 만드는 운영 장치입니다. 에이전트는 상시 켜져서 수다 떠는 방식이 아니라, cron 스케줄로 “정해진 시간마다 깨어나 인박스/보드를 점검”하는 스타일로 움직입니다1. 그래서 서버 비용이나 레이트 리밋 같은 현실적인 문제를 다루기에도 유리합니다. 사람 팀도 사실은 24시간 일하지 않고 “정해진 리듬”으로 움직이잖아요. 그 리듬을 에이전트에 강제로 심어둔 느낌입니다.
Clawe 아키텍처 한 장 요약: Docker로 3개를 띄운다
Clawe는 Docker Compose 기반으로 크게 세 덩어리가 돌아갑니다. 에이전트를 실제로 실행하는 게이트웨이(openclaw), 에이전트 등록/스케줄/알림을 담당하는 watcher, 그리고 Next.js로 만든 웹 대시보드(clawe web)입니다1.
데이터는 Convex 백엔드에 저장되며 작업, 알림, 활동 로그 같은 운영 이벤트가 쌓입니다1. 즉, “보드 UI + 에이전트 런타임 + 이벤트/알림 백엔드”가 삼각형으로 맞물리는 구조예요.
키/토큰도 운영 관점에서 중요한데, 기본적으로 Anthropic API 키와 OpenClaw 토큰, Convex URL이 필요합니다1. OpenClaw 자체를 서버에 올려 돌리는 흐름은 Docker로 비교적 표준화되어 있어, VPS에서 30분 내외로 셋업하는 가이드도 흔히 볼 수 있습니다2. (Clawe는 OpenClaw 위에 팀 운영 레이어를 얹는 쪽에 가깝습니다.)
heartbeat, 루틴: “반복 업무 자동 생성”이 더 무섭다
Clawe가 팀에 붙으면 진짜 효율이 나는 지점은 “반복 업무”입니다. 매주 월요일 오전에 리포트 체크리스트를 만들고, 매일 오후에 SEO 점검 티켓을 생성하는 식의 일을 루틴으로 등록하면, 정해진 요일/시간에 인박스 작업이 자동 생성됩니다1.
여기서 디테일이 좋았던 건 내구성 설계예요. 서버가 잠깐 내려갔다 올라오는 상황을 고려해 일정 실행에 트리거 윈도우를 두는 방식이라, 운영 중 사고가 나도 “오늘 할 일이 증발”할 가능성을 줄였습니다1. 그리고 루틴으로 만들어진 작업은 생성자가 시스템으로 표시되어 수동 작업과 섞여도 구분이 됩니다1. 자동화는 ‘했냐/안 했냐’보다 ‘누가 만들었냐’가 나중에 책임 소재를 가르는 경우가 많거든요.
에이전트 작업공간(SOUL/HEARTBEAT)이 곧 팀 문화다
Clawe에서 가장 인상적인 부분은 “컨텍스트를 대화 로그가 아니라 운영 문서로 관리”하려는 태도입니다. 각 에이전트는 자기 전용 작업공간 디렉터리를 갖고, SOUL(정체성), USER(사용자 정보), HEARTBEAT(깨어났을 때 하는 루틴), MEMORY(장기 메모리), TOOLS(도구 메모) 같은 문서로 행동을 규정합니다1.
그리고 shared 영역을 통해 팀 공용 문서(예: WORKFLOW, 현재 진행 중 작업 메모)를 함께 보게 만들어, 각자 자율적으로 움직이면서도 팀 정렬(alignment)이 되게 설계했습니다1.
다만 여기엔 함정도 있습니다. 문서 기반 운영은 잘 굴러가면 강력하지만, 갱신 규칙이 없으면 금방 “옛날 기준서”가 쌓여서 에이전트가 과거의 회사 규정을 들고 일하는 상황이 옵니다. Clawe를 도입한다면 기술보다 먼저 “문서 유지보수 규율”을 팀 룰로 정하는 게 안전합니다.
바로 써보고 싶다면: ‘보드 규칙’부터 정해라
Clawe는 멋진 데모로 끝나기 쉬운 도구가 아닙니다. 오히려 너무 빨리 자동화가 돌아서, 팀 규칙이 없으면 보드가 금방 혼잡해질 수 있어요.
제가 추천하는 시작 순서는 이렇습니다. 먼저 역할별 작업공간 템플릿을 표준화하세요. SOUL에는 “이 에이전트가 절대 하지 말 것”을 명확히 넣고, HEARTBEAT에는 “매번 깨어나서 확인할 체크리스트”를 짧게 고정하는 게 좋습니다. 다음으로 칸반 상태를 줄이세요. To do/Doing/Review/Done 정도로 단순하게 시작하고, @mention이 붙은 카드는 알림 우선순위를 올리는 규칙을 만드세요. 마지막으로 데이터/보안 관점에서 Convex 의존과 API 키 운영 방식을 팀 정책과 맞춰 점검하는 걸 권합니다1.
시사점은 간단합니다. Clawe는 “에이전트가 똑똑해지는 도구”라기보다, “에이전트가 팀처럼 일하게 만드는 운영 시스템”에 가깝습니다. 지금 조직이 에이전트를 실험 단계에서 실제 업무로 옮기려는 타이밍이라면, Clawe는 보드와 알림, 스케줄링을 한 번에 묶어주는 꽤 현실적인 출발점이 될 수 있습니다1.