Repo Mesh
스탠드얼론 + 클라우드
Repo Mesh는 셀프호스트 스탠드얼론 빌드와 클라우드 양쪽에서 동작합니다: 워크트리 노드, 태스크 큐, Refinery, MCP 메시 모드 전부 계정이나 클라우드 로그인 없이 로컬에서 돌아갑니다. 머신 간에는, 서로 직접 닿을 수 있는 스탠드얼론 데몬(같은 네트워크 또는 Tailscale)을 계정 없이 코드로 페어링할 수 있고, 서로 다른 네트워크의 동일 계정 데몬을 코디네이션하는 것은 클라우드 기능입니다. 멀티 머신 참고.
대시보드는 에이전트 하나씩 보여줍니다. Repo Mesh는 연결된 데몬들을 하나의 컨트롤 플레인 아래 둡니다: 하나의 코디네이터 세션이 여러 머신 — 또는 동일 머신의 여러 격리된 git 워크트리 — 에서 실행 중인 에이전트들에 작업을 넘기고 결과를 수렴합니다. 작업을 분할하고, 유휴 노드가 가져가게 하고, 머지를 착지시키세요.
클라우드 대시보드는 Repo Mesh 페이지(/mesh)에서 메시를 표시합니다. 스탠드얼론에는 대시보드 메시 페이지가 없습니다 — adhdev mesh CLI 명령과 MCP 서버의 메시 모드로 다루세요. 에이전트 기반 Repo Mesh 셋업 참고.
작동 방식
Repo Mesh는 직접 데몬-투-데몬 P2P DataChannel(node-datachannel 경유)을 통해 실행됩니다. 클라우드 서버 WebSocket은 SDP offer/answer/ICE 시그널링만 릴레이하고, 두 데몬 모두 동일 계정에 속하는지 인증합니다.
이것은 데몬 조율입니다 — 대시보드 명령 폴백이 아닙니다. 대시보드 명령 및 데이터 트래픽은 여전히 대시보드↔데몬 P2P 채널만 사용합니다. Repo Mesh는 그것을 서버를 통해 재라우팅하지 않습니다.
코디네이터 데몬이 집계 mesh_status 스냅샷을 소유합니다. 워커 세션은 코디네이터가 디스패치하고 기본적으로 자동 승인됩니다. 완료는 증거 기반입니다 — git status/체크포인트와 레저 이벤트, 에이전트의 자체 보고가 아닙니다. Repo Mesh 도구는 메시 모드의 MCP 서버를 통해 코디네이터 세션에 노출됩니다 — MCP 서버 참조.
핵심 개념
- 노드 — 메시에 참여하는 워크스페이스: 에이전트가 실행될 수 있는 레포 체크아웃 또는 격리된 git 워크트리.
- 미션 — 그것을 향해 작업하는 태스크들을 그룹화하고 지속적인 기록으로 유지되는 목표. 여러 태스크로 이루어진 작업을 큐에 넣기 전에 미션을 만들고, 결과가 결정되면
completed또는abandoned로 표시합니다. - 태스크 — 노드의 에이전트가 수행하는 작업 단위로,
pending → assigned → completed/failed순으로 이동.mesh_enqueue_task를 통해depends_on으로 다음 태스크를 이어 붙이는 것이 기본 방식입니다 — 그래프는 한 번에 전부 선언되는 대신 한 번에 하나씩 링크가 늘어납니다. - 큐 — 유휴 노드가 자율적으로 가져가는 대기 태스크의 데몬 로컬 목록. 큐는 로컬 우선으로 권위 있습니다. Cloud/D1은 경량 멤버십과 시그널링 메타데이터만 보유합니다.
- 레저 — 노드 간에 이미 일어난 일의 추가 전용 메시 감사 로그(히스토리, 할 일 목록이 아님). 제한된 P2P 레저 슬라이스를 통해 데몬 간에 조정됩니다.
- Refinery — 워크트리 브랜치를 베이스로 다시 수렴하는 프로세스: 검증 → 머지 → 푸시 → 정리.
오케스트레이션: pull 기반 태스크 큐
특정 머신에 태스크를 push하고 기다리지 않습니다. 미션에 대해 태스크를 큐에 넣으면, 유휴 노드가 로컬 우선 큐에서 자율적으로 작업을 가져갑니다. 즉:
- 머신과 프로바이더에 걸쳐 동시에 작업을 분산할 수 있습니다 — 한 노드에서 Claude Code, 다른 노드에서 Codex, 세 번째 노드에서 Cursor CLI.
- 느리거나 바쁜 노드는 단순히 더 많은 작업을 가져가지 않습니다. 빠른 유휴 노드가 큐를 소진합니다.
- 코디네이터는 각 세션을 폴링하는 대신 완료/실패 이벤트를 감시합니다.
이것이 한 사람이 동시에 많은 에이전트를 조율할 수 있는 이유입니다: 목표를 태스크로 분해하고, 유휴 노드가 자체 할당하게 하고, 수렴을 검토합니다.
태스크 체이닝
대부분의 다단계 작업은 사전에 전부 계획되기보다 진행하면서 점진적으로 드러납니다 — 그래서 계획을 만드는 기본 방식은 태스크 하나를 큐에 넣고, 필요하다는 것을 알게 되면 그 다음 태스크를 depends_on으로 앞 태스크를 가리키게 하여 큐에 넣는 것입니다. 의존성 그래프는 이런 식으로, 한 번에 전부 선언되는 대신 한 번에 하나씩 링크가 늘어나며 자랍니다. 다른 태스크에 의존하는 태스크는 완료 시 선행 태스크가 보고한 내용의 짧은 요약을 자동으로 받으므로, 결과가 사람이 손으로 옮기지 않아도 앞으로 흘러갑니다.
이미 여러 태스크가 확정돼 있다면 mesh_enqueue_batch로 한 번의 원자적 호출에 함께 큐에 넣을 수 있습니다 — 같은 depends_on 연결을 한꺼번에 제출할 뿐, 별도의 엔진이 아닙니다.
다른 태스크가 의존하는 태스크가 실패하거나 취소되면, 의존하는 태스크는 막힌 채로 남고(대시보드에 의존성으로 막힘으로 표시) 코디네이터에게 알림이 갑니다. 메시 정책(onDependencyFailure: cancel)으로 하류 체인 전체를 대신 취소하게 할 수도 있습니다.
레포 중심 협업
Repo Mesh는 동일한 레포를 여러 곳에서 동시에 작업하는 것을 중심으로 구축되었습니다:
- 워크트리 격리 — 각 노드는 격리된 git 워크트리가 될 수 있으므로, 동일 레포의 병렬 에이전트가 서로의 작업 트리를 침범하지 않습니다.
- 자동 수렴 — Refinery가 완료된 워크트리 브랜치를 받아 베이스로 수렴합니다: 검증, 머지, 푸시, 정리.
- 브랜치 수렴 분류 — 모든 접촉된 노드/브랜치는 정확히 하나의 최종 상태로 착지합니다(main으로 머지됨, 푸시된 피처 브랜치 머지 필요, 검토에서 차단됨, 정리 후보, 또는 머지 불가) — 어떤 것도 조용히 방치된 브랜치에 남겨지지 않습니다.
- 안전한 서브모듈 처리 — 수렴은 서브모듈 도달 가능성을 고려합니다. 서브모듈 커밋이 서브모듈의 origin에서 아직 도달 불가능한 브랜치는 맹목적으로 머지하는 대신 검토 대기합니다.
유휴 워커 정리
유휴 상태가 된 위임 워커 세션(활성 작업 없음, 코디네이터 아님)은 기본적으로 30분 후 자동으로 중지됩니다 — 메시 하우스키핑 패스가 5분마다 확인합니다. 이는 여러 노드에 걸쳐 유휴 CLI 런타임이 쌓이는 것을 막습니다. 더 짧게, 더 길게, 또는 비활성화해야 한다면 TTL은 메시별 정책 설정(delegatedSessionIdleTtlMinutes)입니다.
교차 검증
별개의 태스크를 분할하는 것 외에도, 코디네이터는 동일한 읽기 전용 질문을 서로 다른 프로바이더의 워커 2~3개에 mesh_send_task로 보내고, 보고를 기다린 뒤 답을 직접 합성할 수 있습니다 — 합의와 불일치를 함께.
독립된 머신의 독립된 에이전트를 통해 동일한 질문을 실행하는 것은 단일 에이전트의 답변보다 더 신뢰할 수 있습니다: 합의가 답변을 표시하고, 불일치가 더 자세히 봐야 할 부분을 표시합니다.