Entire은 지역 복제본으로 에이전트용 Git 저장소를 분산한다

Entire은 에이전트와 개발자가 함께 쓰는 Git 포지 Entire을 공개했다. Git과 호환되는 저장소 서버 EntireDB는 여러 지역에 저장소 전체 복제본을 두고, 에이전트의 복제(clone)와 가져오기(fetch) 요청을 해당 지역에서 처리하도록 설계됐다. Entire은 공개 벤치마크에서 푸시 처리량이 GitHub 등 주요 포지보다 최대 89배 높았다고 밝혔지만, 이는 Entire이 제시한 비교 결과다.

에이전트는 작업마다 폐기 가능한 작업 공간을 사용한다. 개발자가 로컬에서 실행하는 에이전트는 이미 저장소 사본을 가질 수 있지만, 새 클라우드 작업자는 저장소를 처음부터 복제해야 한다. Entire은 여러 회사와 저장소에서 이런 작업이 늘면 중앙 저장소에 복제 요청이 집중된다고 설명한다. 이에 따라 저장소를 접근하는 컴퓨터 가까이에 둘 수 있도록 Git 서버의 저장 구조를 바꾸는 것이 필요하다는 주장이다.

Entire이 공개한 벤치마크의 초당 푸시 수는 다음과 같다.

Entire은 이 결과를 오픈소스 벤치마크에 근거해 제시했다. 다만 원문은 비교 조건이나 실험 환경을 구체적으로 설명하지 않는다.

저장소 복제와 쓰기 처리 방식

Entire은 다른 두 설계와 차이를 강조한다. GitHub의 Spokes는 저장소마다 최소 세 개의 복제본을 두고, 엄격한 다수결 조건을 충족해야 푸시를 승인한다. 복제본을 더 늘리면 쓰기 조정 비용이 커질 수 있다. 다만 투표에 참여하지 않는 복제본을 추가해 지역 읽기를 처리할 수 있다.

Cursor의 Continuity는 S3 호환 저장소에 쓰기 전 로그(WAL)를 두고 이를 원본으로 삼는다. 푸시는 로그에 기록되면 내구성을 확보하지만, 저장소의 참조(ref)가 WAL에 원자적으로 반영돼야 변경 사항이 보인다. 이 구조에서는 푸시가 로컬 저장소 하나에만 적용되지만, 모든 가져오기와 복제 요청은 S3에 최신 상태인지 확인해야 한다. 노드는 WAL에서 복구할 수 있어 복제본을 교체하기 쉽다는 설명이다. 관련 내용은 Cursor의 설명에 있다.

EntireDB는 저장소를 셀(cell)이라는 단위로 관리한다. 각 셀에는 참조를 보관하는 PostgreSQL 데이터베이스 하나와 객체 및 팩파일을 보관하는 노드들이 있다. 저장소는 한 셀에 배정되며, 객체는 저장소 ID를 기준으로 같은 제공 노드들에 배치된다. 참조는 변경 가능한 정보이므로 데이터베이스에 두고, 커밋·트리·블롭 같은 객체는 불변이며 콘텐츠 주소를 사용하므로 노드들이 병렬로 받을 수 있다는 설계다.

푸시를 받는 노드는 조정자 역할을 한다. 팩파일을 셀 내 다른 노드로 동시에 전송하고 각 노드의 임시 영역에 저장한다. 서로 다른 가용성 영역에 있는 노드 두 곳 이상이 저장을 확인해야 하며, 객체 검증과 저장 단계가 끝난 뒤 PostgreSQL에서 참조를 이전 상태와 비교해 갱신한다. 이 갱신이 성공해야 푸시가 보인다.

가져오기 요청은 선택된 노드가 PostgreSQL에서 참조를 읽고, 로컬 디스크의 객체로 팩파일을 만들어 클라이언트에 직접 전송한다. 필요한 객체가 해당 노드에 없으면 셀 안의 다른 노드에서 가져온다. Entire은 저장소 제공에 셀 외부의 시스템을 사용하지 않는다고 설명한다.

지역 배치와 일관성의 한계

Entire은 현재 미국, 유럽, 인도, 호주에 셀을 운영한다고 밝혔다. 지역은 데이터 거주 경계이며, 사용자가 저장소를 다른 지역에 명시적으로 복제하지 않으면 저장소는 생성된 지역에 남는다.

현재 대부분의 저장소는 GitHub 저장소의 미러다. EntireDB에 들어온 푸시는 셀에 저장된 뒤 GitHub로 전달되며, GitHub가 승인해야 로컬 참조도 갱신된다. refs/heads/entire/unmirrored/ 아래 브랜치는 예외로, GitHub로 푸시하지 않으며 GitHub 동기화도 이 브랜치에 영향을 주지 않는다. GitHub 미러가 아닌 저장소는 기본 셀을 기준으로 다른 지역의 미러와 동기화한다. 동기화에는 Entire이 개발한 오픈소스 프로젝트 git-sync를 사용한다.

셀 안에서는 모든 노드가 같은 PostgreSQL 데이터베이스에서 참조를 읽기 때문에 참조의 일관성이 강하게 유지된다. 반면 객체 복제는 비동기다. 서로 다른 가용성 영역의 노드 두 곳에 객체가 저장되고 참조 갱신이 성공하면 푸시를 승인할 수 있으며, 나머지 노드는 뒤이어 따라잡는다. 새 참조를 알린 노드에 해당 객체가 아직 없으면 셀 내 다른 노드에서 가져온다.

지역 간 복제도 비동기이므로 미러가 원본 변경을 반영하기까지 지연될 수 있다. 한 셀 안에서는 쓰기 후 읽기 일관성을 제공하지만, 여러 셀에서 동시에 쓰기를 허용하는 충돌 해결 방식은 현재 제공하지 않는다고 Entire은 밝혔다.

Entire은 Git 서버를 go-git으로 구현했으며, 변경 사항을 Antithesis의 결정론적 시뮬레이션 테스트로 점검한다고 설명한다. 테스트는 네트워크 분할, 노드 중단과 종료, 시계 오차 등을 시뮬레이션한다. Entire은 이 과정에서 가져오기가 일부만 작성된 팩파일을 반환할 수 있는 사례를 발견해 수정했다고 밝혔다. 또 참조를 알린 노드는 전체 객체 그래프를 전달하거나 오류를 반환해야 하며, 부분 데이터는 반환하지 않는다는 불변 조건을 검사한다고 설명했다.

Entire은 향후 EntireDB를 오픈소스로 공개할 계획이라고 밝혔다. 앤스로픽이 만든 Git 대체 시스템 Scion은 일반적인 용도의 Git 대체재가 아니라고 밝힌 사례도 들며, Git 자체를 대체하기보다 분산이라는 Git의 특성을 저장소 운영에도 적용해야 한다고 주장한다.