GitHub Git 스토리지 아키텍처 Project Rubicon

Overview

GitHub은 에이전트 기반 개발의 급증을 지원하기 위해 내부적으로 "Project Rubicon"이라는 코드명으로 불리는 새로운 Git 스토리지 아키텍처를 도입했습니다. 이 시스템은 낮은 지연 시간의 읽기 성능을 유지하면서 단일 저장소에서 초당 수천 건의 쓰기 작업을 처리하도록 설계되었습니다. GitHub은 스토리지와 컴퓨팅을 분리하고 조정 요구 사항을 최소화함으로써, 자율 에이전트 활동의 증가에 대비해 저장소 용량을 두 자릿수 규모로 확장하는 것을 목표로 합니다.

핵심 아키텍처: 분리 및 조정

Rubicon 아키텍처는 기존의 모놀리식 Git 스토리지에서 벗어나, 조정 최소화와 스토리지-컴퓨팅 분리라는 두 가지 주요 설계 원칙을 기반으로 하는 분산 모델로 전환합니다.

Ref-CAS: 참조 상태 관리

Git 객체는 불변(immutable)이므로 복잡한 조정이 필요하지 않습니다. 그러나 참조 업데이트(예: 브랜치 포인터)는 조정이 필요합니다. GitHub은 이러한 업데이트를 처리하기 위해 Ref-CAS(Reference Compare-and-Swap)라는 전용 서비스를 개발했습니다. 기존의 합의 그룹(consensus groups)과 달리, Ref-CAS는 실제 객체 데이터를 저장하거나 검증하지 않으며, 포인터와 로그 시퀀스 번호만 저장합니다. 이를 통해 시스템은 트랜잭션에 관련된 특정 참조만 잠금으로써 초당 수만 건의 참조 업데이트를 처리할 수 있습니다.

가상 복제본 및 Blob 스토리지

모든 영구적인 Git 객체 데이터는 높은 총 처리량을 제공하는 Azure Blob Storage로 오프로드됩니다. 트래픽은 "Spokes"를 통해 일회성 가상 복제본(virtual replicas) 집합으로 라우팅됩니다. 이 복제본들은 캐싱 계층 역할을 하며, 필요에 따라 Blob Storage에서 필요한 팩 데이터를 가져옵니다. 가상 복제본은 권한 있는 상태를 보유하지 않으므로, 저장소의 정확성에 영향을 주지 않고 수평적으로 확장하거나 교체할 수 있습니다.

백그라운드 압축

쓰기 볼륨이 증가함에 따라 읽기 성능을 유지하기 위해, GitHub은 압축 및 가비지 컬렉션을 백그라운드 프로세스로 옮겼습니다. 전용 압축 노드는 Blob Storage 및 Ref-CAS에 대해 직접 작동합니다. 임대(leases)를 사용하여 특정 저장소 샤드에 대한 소유권을 주장함으로써, 이 노드들은 가상 복제본과 독립적으로 팩을 병합하고 도달할 수 없는 객체를 제거하여 복제본의 컴퓨팅 자원이 사용자 요청 처리에 전념할 수 있도록 합니다.

업계 맥락 및 커뮤니티 토론

이번 발표는 이러한 고처리량 인프라의 필요성에 대해 상당한 논의를 불러일으켰습니다. GitHub은 이를 AI 기반 코딩의 미래를 위한 선제적 조치로 내세우고 있지만, 일부 커뮤니티 구성원들은 아키텍처적 영향에 대해 의문을 제기했습니다.

  • 확장성 vs. 속도 제한: 비평가들은 초당 수천 건의 푸시를 지원하는 것이 비효율적인 에이전트 동작을 조장할 수 있다고 주장합니다. 댓글 작성자들은 플랫폼이 대규모 쓰기 볼륨을 위한 인프라를 구축하기보다는, 결국 속도 제한을 시행하거나 에이전트가 변경 사항을 로컬에서 집계한 후 푸시하도록 장려해야 할 수도 있다고 제안했습니다.
  • 다른 시스템과의 비교: 관찰자들은 이 접근 방식이 Cursor의 "Continuity"나 enroute.sh와 같은 독립적인 프로젝트 등 Git 확장을 위해 객체 스토리지를 활용하는 다른 업계 노력과 유사하다는 점을 지적했습니다.
  • VCS 대안: 일부 개발자들은 Git이 고동시성 에이전트 스웜(swarms)을 위한 최적의 도구인지 의문을 제기했습니다. 제안된 대안으로는 Git의 낙관적 동시성 모델보다 대규모 자동화 협업 관리에 더 적합할 수 있는 독점적 파일 잠금 기능을 제공하는 Perforce와 같은 시스템으로의 전환이 포함되었습니다.

GitHub은 새로운 아키텍처가 현재 제한된 비공개 미리보기 상태이며, 내년 초에 더 광범위하게 출시될 예정이라고 밝혔습니다. 회사는 이 기반이 "클론 없는 작업(work without a clone)", 원자적 커밋 API, 부분 및 얕은 클론에 대한 향상된 지원과 같은 미래 기능을 가능하게 할 것이라고 강조합니다.

Sources