깃허브, AI 에이전트 5000개 동시 작업…초당 7200회 푸시 시험

깃허브(GitHub)가 단일 저장소에서 AI 에이전트 5000개가 동시에 작업하는 조건으로 초당 7200회의 푸시를 처리하는 내부 시험을 했다. 푸시는 수정한 코드를 원격 저장소에 보내는 작업이다. 깃허브는 이때 읽기 요청도 낮은 지연으로 처리했다고 밝혔다.

깃허브는 5일 공식 기술 블로그에서 새 Git 저장 구조의 이름을 '루비콘(Rubicon)'이라고 공개했다. 설계 작업은 2026년 5월 초기 애저(Azure) 이전 직후 시작됐다.

깃허브가 제시한 사례에서 한 저장소의 하루 평균 요청량은 2026년 3월 4400만건에서 5월 1억8100만건으로 늘었다. 약 4배 증가한 규모다.

깃허브는 현재 가장 바쁜 저장소도 짧은 시간 동안 초당 수십 건의 쓰기를 받는 수준이라고 설명했다. 5일 기술 설명에서 에이전트가 병렬로 상시 작업하면 앞으로 1년 안에 이런 집중이 지속적인 쓰기 수요로 바뀔 수 있다고 내다봤다.

푸시가 늘면 쓰기 요청만 증가하는 것은 아니다. 자동 테스트와 배포 시스템이 새 코드를 가져가고 다른 에이전트도 작업 맥락을 위해 최신 버전을 읽으면서 저장소의 읽기 요청이 함께 늘어난다.

깃허브는 앞서 여러 저장소의 에이전트 작업을 조정하는 코파일럿 프로젝트(Copilot Projects)를 공개 시험판으로 선보였다. 이번 기술 설명은 에이전트 작업을 뒷받침할 저장소의 쓰기·읽기 구조에 초점을 맞췄다.

Git은 코드 내용을 기존 기록에 덮어쓰지 않고 새 객체로 저장한다. 푸시 과정에서 별도로 필요한 작업은 각 분기가 어느 버전을 가리키는지 최신 상태를 갱신하는 일이다.

루비콘은 코드 데이터와 분기 정보를 서로 다른 곳에서 관리한다. 코드 데이터 묶음은 애저 블롭 스토리지(Azure Blob Storage)에 저장하고, 분기 정보와 저장된 데이터 묶음의 목록은 별도 서비스인 Ref-CAS가 맡는다.

Ref-CAS는 각 작업이 바꾸려는 분기만 확인해 갱신한다. 서로 다른 분기의 변경은 동시에 처리할 수 있지만, 같은 분기를 두 작업이 함께 바꾸려 하면 충돌을 조정해야 한다.

코드를 푸시할 때 가상 복제본은 먼저 새 데이터 묶음을 처리해 블롭 스토리지에 올린다. 그 뒤 Ref-CAS에 데이터 묶음 목록과 분기 정보를 함께 갱신하는 거래를 기록한다.

읽기 요청을 받은 가상 복제본은 Ref-CAS에서 분기 정보의 버전을 확인하고 필요한 데이터 묶음을 불러온다. 버전이 바뀌지 않았다면 분기 목록 전체를 다시 가져오지 않고 한 번의 비교로 요청을 처리할 수 있다.

읽기와 쓰기를 맡는 가상 복제본은 다시 만들 수 있는 캐시를 둔다. 저장소에 요청이 몰리면 깃허브는 가상 복제본을 늘려 대응할 수 있도록 설계했다.

새 푸시가 쌓여 데이터 묶음이 많아지면 별도 노드가 백그라운드에서 묶음을 합친다. 가상 복제본의 처리 자원을 정리 작업과 분리해 읽기·쓰기 요청에 쓰도록 했으며, 참조되지 않는 객체를 정리하는 가비지 컬렉션도 전용 작업자가 담당한다.

깃허브는 처음에 모든 분기 변경을 하나의 기록으로 처리하는 방식을 시험했지만 쓰기량은 초당 수백 건에 머물렀다. 기록을 여러 부분으로 나누자 쓰기는 늘었지만, 저장소 변경 여부를 확인할 때 각 부분을 조회해야 해 읽기가 느려졌다.

깃허브는 참조 상태 갱신만 놓고 보면 새 방식으로 초당 수만 건의 작업을 처리할 수 있다고 설명했다. 루비콘은 현재 제한된 비공개 시험 단계이며 깃허브는 2027년 초 적용 범위를 넓힐 계획이다.