Skip to content

Repo Mesh

클라우드 전용

Repo Mesh는 클라우드 버전에서만 사용 가능합니다. 동일 계정의 여러 데몬을 조율하며, 셀프호스트 단일 머신 설정에서는 제공하지 않습니다.

대시보드는 에이전트 하나씩 보여줍니다. Repo Mesh는 연결된 데몬들을 하나의 컨트롤 플레인 아래 둡니다: 하나의 코디네이터 세션이 여러 머신 — 또는 동일 머신의 여러 격리된 git 워크트리 — 에서 실행 중인 에이전트들에 작업을 넘기고 결과를 수렴합니다. 작업을 분할하고, 유휴 노드가 가져가게 하고, 머지를 착지시키세요.

클라우드 대시보드는 Repo Mesh 페이지(/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 순으로 이동.
  • — 유휴 노드가 자율적으로 가져가는 대기 태스크의 데몬 로컬 목록. 큐는 로컬 우선으로 권위 있습니다. Cloud/D1은 경량 멤버십과 시그널링 메타데이터만 보유합니다.
  • 레저 — 노드 간에 이미 일어난 일의 추가 전용 메시 감사 로그(히스토리, 할 일 목록이 아님). 제한된 P2P 레저 슬라이스를 통해 데몬 간에 조정됩니다.
  • Refinery — 워크트리 브랜치를 베이스로 다시 수렴하는 프로세스: 검증 → 머지 → 푸시 → 정리.

오케스트레이션: pull 기반 태스크 큐

특정 머신에 태스크를 push하고 기다리지 않습니다. 미션에 대해 태스크를 큐에 넣으면, 유휴 노드가 로컬 우선 큐에서 자율적으로 작업을 가져갑니다. 즉:

  • 머신과 프로바이더에 걸쳐 동시에 작업을 분산할 수 있습니다 — 한 노드에서 Claude Code, 다른 노드에서 Codex, 세 번째 노드에서 Gemini.
  • 느리거나 바쁜 노드는 단순히 더 많은 작업을 가져가지 않습니다. 빠른 유휴 노드가 큐를 소진합니다.
  • 코디네이터는 각 세션을 폴링하는 대신 완료/실패 이벤트를 감시합니다.

이것이 한 사람이 동시에 많은 에이전트를 조율할 수 있는 이유입니다: 목표를 태스크로 분해하고, 유휴 노드가 자체 할당하게 하고, 수렴을 검토합니다.

레포 중심 협업

Repo Mesh는 동일한 레포를 여러 곳에서 동시에 작업하는 것을 중심으로 구축되었습니다:

  • 워크트리 격리 — 각 노드는 격리된 git 워크트리가 될 수 있으므로, 동일 레포의 병렬 에이전트가 서로의 작업 트리를 침범하지 않습니다.
  • 자동 수렴 — Refinery가 완료된 워크트리 브랜치를 받아 베이스로 수렴합니다: 검증, 머지, 푸시, 정리.
  • 브랜치 수렴 분류 — 모든 접촉된 노드/브랜치는 정확히 하나의 최종 상태로 착지합니다(main으로 머지됨, 푸시된 피처 브랜치 머지 필요, 검토에서 차단됨, 정리 후보, 또는 머지 불가) — 어떤 것도 조용히 방치된 브랜치에 남겨지지 않습니다.
  • 안전한 서브모듈 처리 — 수렴은 서브모듈 도달 가능성을 고려합니다. 서브모듈 커밋이 서브모듈의 origin에서 아직 도달 불가능한 브랜치는 맹목적으로 머지하는 대신 검토 대기합니다.

교차 검증 (MAGI)

별개의 태스크를 분할하는 것 외에도, Repo Mesh는 동일한 읽기 전용 조사를 여러 머신 × 프로바이더 레플리카에 보내고 결과를 합성할 수 있습니다 — 합의와 불일치를 함께(MAGI).

독립된 머신의 독립된 에이전트를 통해 동일한 질문을 실행하는 것은 단일 에이전트의 답변보다 더 신뢰할 수 있습니다: 합의가 답변을 표시하고, 불일치가 더 자세히 봐야 할 부분을 표시합니다.

다음 단계

호스팅 클라우드 문서는 여기에 있습니다. 오픈소스 및 셀프호스트 문서는 OSS 레포지토리에 있습니다.