GitHub, Git 기반 재구축: 5000개의 AI가 병렬로 작업하며, 단일 저장소에서 초당 7200회의 코드 푸시 처리

동찰 Beating AI 속보, GitHub가 코드명 Rubicon인 차세대 Git 스토리지 아키텍처를 공개했습니다. 내부 테스트에 따르면 5000개의 AI Agent가 동시에 하나의 코드 저장소에서 작업할 수 있으며, 초당 7200회의 코드 푸시를 완료하면서도 낮은 읽기 지연을 유지합니다.

과거 GitHub에서 가장 바쁜 코드 저장소도 초당 짧게 수십 회의 쓰기만 발생했습니다. 이제 대량의 AI Agent가 24시간 병렬로 개발하며 끊임없이 새 코드를 제출할 수 있습니다. 각 커밋은 자동 테스트를 촉발할 수 있고, 다른 Agent가 최신 버전을 다운로드하게 하여 저장소의 읽기/쓰기 부담이 증가합니다.

GitHub의 해결책은 「코드 저장」과 「브랜치 업데이트」를 분리 처리하는 것입니다.

Git은 코드를 푸시할 때마다 두 가지 작업을 완료해야 합니다. 첫 번째 단계는 새로 추가되거나 수정된 코드 내용을 저장하는 것입니다. Git은 이전 버전을 직접 덮어쓰지 않고 변경된 내용을 새 객체로 저장하며, 변경되지 않은 부분은 계속 재사용할 수 있습니다. 두 번째 단계는 브랜치 포인터를 업데이트하여 해당 브랜치가 현재 어떤 최신 버전을 가리키는지 기록하는 것입니다.

예를 들어 1000개의 Agent가 동시에 소프트웨어를 개발하며, 어떤 것은 로그인 기능을 수정하고 어떤 것은 결제 기능을 수정합니다. 서로 다른 브랜치에서 작업하는 한 새 코드는 동시에 저장될 수 있고 브랜치도 각자 업데이트될 수 있습니다. 두 Agent가 동시에 같은 브랜치를 업데이트하려고 경쟁할 때만 시스템이 누구의 업데이트가 먼저 성공할지 판단하면 됩니다.

GitHub는 처음에 모든 브랜치가 하나의 업데이트 기록을 공유하게 했습니다. 서로 다른 AI Agent가 서로 다른 브랜치를 수정하더라도 같은 파일을 업데이트하려고 경쟁해야 했기에 초당 수백 회의 푸시만 처리할 수 있었습니다. GitHub는 다시 기록을 여러份으로 나누어 서로 다른 브랜치가 동시에 업데이트하게 시도했습니다. 하지만 이렇게 하면 저장소에 변화가 있는지 확인할 때마다 각份을 하나씩 조회해야 해서 오히려 읽기 속도가 느려졌습니다.

결국 GitHub는 브랜치 업데이트를 전담 관리하는 Ref-CAS 서비스를 개발했습니다. 이는 서로 다른 브랜치가 동시에 업데이트되도록 허용하며, 같은 브랜치를 수정할 때만 충돌을 처리하면 됩니다. 동시에 전체 저장소에 통합 버전 번호를 유지합니다. 다른 프로그램은 이 버전 번호만 확인하면 저장소에 변화가 있는지 알 수 있어 모든 브랜치를 하나씩 조회할 필요가 없습니다.

GitHub는 또한 독립 머신을 배치하여 백그라운드에서 계속 축적되는 코드 데이터 패키지를 병합해, 데이터 패키지가 많아져 읽기 속도가 느려지는 것을 방지합니다. 새 아키텍처는 최종적으로 내부 테스트에서 초당 7200회 푸시를 달성했습니다.

GitHub의 Rubicon은 현재 제한된 비공개 테스트 단계에 있으며, 2027년 초에 출시를 확대할 계획입니다.