GitHub, 새 Git 저장소 아키텍처 Rubicon 공개: 수천 개 AI 에이전트가 같은 저장소에 동시에 푸시

무슨 일이 있었나

GitHub는 공식 엔지니어링 블로그에서 지난주 GitHub Universe에서 새로운 Git 저장소 아키텍처를 발표했다고 밝혔습니다. GitHub에 따르면 이 아키텍처는 초당 수천 건의 쓰기를 처리할 수 있고, 읽기 용량은 필요에 따라 확장할 수 있습니다. 저장소는 프로젝트의 코드와 변경 이력을 보관하는 곳이고, 푸시(push)는 로컬의 코드 변경 사항을 GitHub에 올리는 것입니다. GitHub는 내부 테스트에서 새 아키텍처가 하나의 저장소에서 5,000개 에이전트가 동시에 작업하며 초당 7,200회 푸시하는 것을 지원했고, 읽기 지연 시간도 안정적으로 낮게 유지됐다고 말했습니다. 이 수치는 모두 GitHub가 직접 공개한 테스트 결과입니다.

GitHub는 구조를 바꾼 이유도 설명했습니다. 현재 GitHub.com에서 가장 바쁜 저장소도 초당 쓰기가 최대 수십 건 수준이며, 보통 짧은 시간의 폭발적 증가로 나타납니다. 에이전트가 병렬로 24시간 일하게 되면 1년 안에 이런 폭증이 지속적인 고부하 쓰기로 바뀔 것으로 GitHub는 예상합니다. 또 푸시 한 번마다 읽기가 더 발생합니다. 예를 들어 자동 테스트와 배포 시스템이 새 커밋을 가져갑니다. 그래서 GitHub는 현재보다 최소 100배(10의 2제곱) 이상의 규모를 목표로 잡았습니다.

새 아키텍처의 동작 방식

GitHub는 설계의 핵심 관찰을 이렇게 설명했습니다. Git 객체(파일 내용, 커밋 기록 등의 데이터)는 한 번 쓰이면 바뀌지 않고 내용으로 이름이 정해지므로, 여러 작성자가 서로 조율하지 않고 동시에 저장할 수 있습니다. 조율이 필요한 것은 참조(ref) 갱신뿐입니다. 참조는 '어떤 브랜치가 현재 어느 커밋을 가리키는가' 같은 포인터입니다. 조율이 필요한 것이 참조뿐이므로 데이터 저장, 요청 처리, 저장소 유지 관리를 각각 독립적으로 확장할 수 있습니다.

• 객체: GitHub에 따르면 pack(Git이 여러 객체를 하나로 묶은 파일)과 읽기를 돕는 가속 데이터는 클라우드 객체 저장소인 Azure Blob Storage에 보관됩니다.
• 참조: 참조와 pack 목록은 Ref-CAS라는 복제 로그 서비스에 저장됩니다. Ref-CAS는 Reference Compare-and-Swap의 약자로, 참조가 작성자가 예상한 값 그대로일 때만 갱신한다는 뜻입니다. 각 갱신은 과반수 복제본이 기록한 뒤에야 효력이 생깁니다.
• 가상 복제본: 언제든 교체할 수 있는 컴퓨팅 자원으로 읽기와 쓰기를 처리합니다. 로컬 디스크는 다시 만들 수 있는 캐시일 뿐이며, 저장소가 바빠지면 복제본을 늘립니다.
• 압축 노드: 여기서 '압축'(compaction)은 내용을 줄이는 것이 아니라 파일을 합치는 것을 뜻합니다. 압축 노드는 백그라운드에서 저장소 서비스에 직접 작업하며 많은 작은 pack을 더 적고 큰 pack으로 합칩니다. 모든 객체는 보존되고, 요청을 처리하는 복제본의 자원도 쓰지 않습니다.

일반 독자와 개발자에게 미치는 실제 영향

GitHub는 개발자에게 Git은 여전히 Git이라고 말했습니다. 푸시, 페치(fetch, 최신 변경 사항 내려받기), 브랜치 생성 방식은 모두 같고 보호 기능도 유지됩니다. GitHub의 목표는 개인 소규모 프로젝트부터 가장 바쁜 대형 저장소까지 모든 저장소를 특별한 처리 없이 같은 아키텍처에서 운영하는 것입니다.

출시 일정과 관련해 GitHub는 현재 제한적 비공개 프리뷰만 열려 있고 내년 초 더 폭넓게 출시할 예정이라고 밝혔습니다. 따라서 대부분의 사용자는 단기간에 직접적인 변화를 느끼지 못할 것입니다. GitHub는 후속 계획으로 필요한 데이터만 읽기, 부분 복제본, 글로벌 복제본, 원자적 커밋 API(여러 파일의 변경을 한 번에 보내 전부 성공하거나 전체가 취소되는 방식), 이벤트 스트리밍 등을 제시했으며, 이는 아직 모두 계획 단계입니다.

자주 묻는 질문

이 주제의 최신 뉴스 보기

• 테크 뉴스