Git을 어떤 규모에서도 확장하는 법 - Cursor의 새 Git 저장 시스템 Continuity

Git은 로컬에서는 단순하지만 서버에서 대규모로 호스팅하면 packfile의 랜덤 접근 패턴, 강한 일관성 요구, 복제 비용 때문에 확장성과 운영 복잡도가 크게 올라감 GitHub의 Spokes는 로컬 NVMe에 실제 Git 저장소를 두고 여러 복제본을 3-phase commit으로 동기화하는 방식으로 업계 표준이 됐지만, 대형 monorepo에는 복제 수가 부족하고 수많은 작은 저장소에는 최소 3개 복제본이 과한 구조가 됨 Cursor가 만든 Continuity는 Git 저장소 자체가 아니라 S3의 Write-Ahead Log(WAL)를 진실의 원천으로 두고, 로컬 저장소는 필요할 때 언제든 다시 만들 수 있는 캐시처럼 취급함 모든 push는 WAL에 완전히 저장된 뒤에만 성공 처리되고 S3의 CAS로 직렬화되며, replica는 읽기 직전 WAL 상태를 확인해 합의 프로토콜 없이도 항상 일관된 저장소 뷰를 제공함 이 구조는 대형 monorepo에는 수백 개 replica를 붙이고, 에이전트가 만드는 수많은 작은 저장소에는 하나 또는 0개의 warm replica만 유지할 수 있어 AI 에이전트 시대의 Git 트래픽을 양방향으로 확장하는 것이 목표임 Git 서버가 어려운 이유는 Git의 분산 설계 자체에 있음 Git은 모든 저장소 복사본이 동등한 분산 버전 관리 시스템으로 설계됐지만, 실제 기업과 대부분의 오픈소스 프로젝트는 중앙 호스팅 서버에 크게 의존함 Git의 객체와 메타데이터는 packfile이라는 압축 바이너리 형식에 저장되고, push와 fetch 역시 packfile 단위로 전송됨 packfile은 로컬 디스크에서는 효율적이지만 서버에서 확장하기 어려움 객체가 Git DAG 순서대로 배치되지 않음 객체 대부분이 다른 객체에 대한 delta 형태로 저장됨 하나의 객체를 읽을 때 논리적 DAG 탐색과 물리적 packfile 탐색이 함께 발생함 이런 랜덤 접근 패턴 때문에 네트워크 파일시스템이나 원격 객체 저장소에서 객체 단위로 직접 읽는 방식은 성능이 급격히 나빠짐 Git 객체를 분산 Key-Value Store에 넣는 접근의 한계 Git 객체는 SHA-1을 키로 사용하는 Content-Addressable 구조라 처음에는 분산 Key-Value Store와 잘 맞아 보임 하지만 Git 작업은 객체 하나를 조회하는 것이 아니라 commit → tree → blob → parent commit 식으로 ...