GitHub는 2026년 10월 6일 공식 엔지니어링 블로그를 통해 전 세계 코드 호스팅을 떠받치는 Git 인프라를 재구축하고 있다고 발표했다. 이유는 단순하다. 코드를 쓰는 주체가 달라졌기 때문이다. 지난 1년간 GitHub에서 에이전트와 개발자가 만들어 낸 커밋, 푸시, 병합은 몇 배로 늘었고, 사람의 속도에 맞춰 설계된 스토리지 구조는 쓰기 병목에 먼저 부딪혔다.
숫자부터 보자: 푸시, 월 33.5억 회로
GitHub가 제시한 규모의 변화는 가파르다. 2026년 8월 플랫폼의 Git 이벤트는 4733억 회에 달해 1년 전의 두 배를 넘었고, 2026년 9월 커밋은 73.8억 회로 1년 전의 다섯 배를 웃돌았다. 푸시는 월 6.9억 회에서 33.5억 회로 늘어 전년 대비 4.9배가 됐고, 풀 리퀘스트 병합은 1년 전의 거의 네 배, GitHub Actions의 9월 실행 횟수도 32.6억 회로 네 배를 넘었다.
에이전트의 작업 방식은 쓰기 하나하나를 증폭시킨다. 수천 개의 에이전트가 하나의 저장소에서 각자 다른 브랜치로 병렬 작업하면 지속적인 쓰기가 결국 트렁크라는 한 지점으로 수렴한다. 병합은 하나의 참조를 놓고 경쟁하고, 트렁크 기반 개발, 릴리스 트레인, 병합 큐는 모든 작업을 병합 전부를 삼켜야 하는 단일 참조로 몰아넣는다. 푸시 하나는 수천 번의 읽기로도 퍼진다. CI와 코드 스캔이 같은 브랜치 끝을 분당 수천 번 클론하거나 가져오기 때문이다.
읽기는 늘리기 쉽고 쓰기는 어렵다: 기존 구조의 결합 지점
현재 스토리지 계층인 Spokes는 각 저장소의 전체 복사본을 여러 파일 서버의 로컬 디스크에 보관한다(기본값 5부). 푸시로 참조가 갱신될 때는 3단계 커밋 프로토콜과 정족수로 웹, API, CI가 일관된 상태를 보게 한다. 이 조합이 오늘날 10억 규모의 저장소를 지탱한다.
문제는 내구성과 확장성이 같은 장치라는 점이다. 디스크 위 복사본은 진실의 원천이자 읽기 용량의 원천이다. 읽기 용량을 늘리려면 내구 복제본을 하나 더 추가해야 하고, 모든 복제본이 모든 쓰기에 참여하므로 푸시 속도는 가장 느린 복제본에 끌려간다. 읽기를 위해 복제본을 늘리면 쓰기가 느려지고, 복제본을 잃으면 읽기 용량이 줄며, 정족수를 잃으면 쓰기가 멈춘다. 대부분의 저장소에서는 이 절충이 성립하지만, 활동량이 가장 높은 저장소에서는 천장이 된다.
재구축의 방향: 내구성과 확장을 분리한다
새 아키텍처의 방향은 내구성과 확장성을 분리하되 세 가지 선을 지키는 것이다. 워크플로는 바꾸지 않는다. 브랜치, 리뷰, 병합, 히스토리처럼 팀이 이미 신뢰하는 방식은 새 인프라 위에서도 그대로 동작해 사용자의 습관을 바꿀 필요가 없다. 신뢰성을 최우선으로 삼아 모든 절충을 그 기준으로 잰다. 그리고 통제권은 사람의 손에 남긴다. 브랜치 보호, 필수 리뷰, 감사 로그, 저장소 가시성 같은 거버넌스는 유지되며, 에이전트가 아무리 많이 일해도 코드의 리뷰와 승인은 소유자가 맡는다. 공학적으로는 조율 최소화가 강조된다. 푸시가 잦은 저장소는 단계마다 전체 합의를 기다리는 대신 업데이트를 빠르게 받아 공개할 수 있어야 한다. 재구축 전체는 플랫폼을 멈추지 않은 채 진행되며, 전 세계의 코드가 멈추는 점검 시간은 없다.
이 소식의 의미는 한 회사를 넘어선다. 에이전트의 산출물이 수십억 커밋 단위로 세어지기 시작하면 병목은 모델 능력에서 인프라로 옮겨 간다. 사람의 속도에 맞춰 지어진 저장소, 리뷰, CI를 기계의 속도에 맞게 다시 지어야 한다. 이 사이트는 앞서 GitHub가 실제 PR 219개로 AI 코드 리뷰를 검증한 ReviewBench 평가를 소개한 바 있다. 그쪽이 묻는 것이 '에이전트가 쓴 코드를 믿을 수 있는가'라면, 이번 재구축은 그 반대편, '플랫폼 자체가 에이전트가 쓰는 속도를 받아 낼 수 있는가'에 답한다. 프로그래밍 에이전트를 무겁게 쓰는 팀이라면 앞으로 1~2년, 코드 플랫폼의 쓰기 처리량, 병합 대기열, 감사 능력은 모델 자체만큼이나 지켜볼 가치가 있다.
