깃허브, 커밋 5배 급증에 깃 저장소 재구축

깃허브의 수석 소프트웨어 엔지니어 브라이언 셀렌자(Brian Celenza)는 10월 6일 공식 엔지니어링 블로그에 깃 저장소 계층을 재구축하고 있다고 밝혔다. 이유는 명확하다. AI 에이전트가 쓰기 트래픽을 기존 아키텍처의 한계까지 밀어붙였기 때문이다. 내부 벤치마크에서 새 아키텍처는 쓰기 처리량을 최대 35배까지 끌어올렸다.

이 글은 지난 1년간의 성장 수치를 다음과 같이 제시했다.

지표최신 수치전년 대비
월간 깃 이벤트4733억 건(2026년 8월)약 2.2배
월간 푸시33억 5000만 건4.9배
월간 커밋73억 8000만 건(2026년 9월)5배 이상
월간 Actions 실행32억 6000만 건(2026년 9월)4배 이상
PR 머지절대값 미공개약 4배

가장 부하가 큰 단일 저장소는 8월 한 달 동안 약 10억 건의 요청을 받았다. 에이전트의 쓰기 습관에 대해 글은 다음과 같이 묘사했다.

"An agent in a tight loop commits or checkpoints after nearly every action"

(반복 루프를 도는 에이전트는 거의 모든 동작 뒤에 커밋이나 체크포인트를 남긴다)

기존 아키텍처, 쓰기 작업에서 한계에 도달

깃허브의 기존 저장소 스토리지 시스템은 '스포크스(Spokes)'라 불린다. 각 저장소는 기본적으로 여러 파일 서버의 로컬 디스크에 완전한 복제본을 두며, 총 5개의 복제본을 유지한다. 푸시로 참조를 업데이트할 때는 다수결 기반의 3단계 커밋 프로토콜을 사용해 CI, 웹사이트, API 클라이언트가 일관된 저장소 상태를 보도록 한다.

이 설계에서 복제본은 데이터 손실 방지와 읽기 트래픽 분산이라는 두 가지 역할을 동시에 맡는다. 문제는 모든 복제본이 모든 쓰기에 참여해야 한다는 점이다. 복제본을 늘려 읽기 처리량을 키우면 쓰기는 오히려 느려진다. 인간 개발자가 주도하던 시절, 읽기가 쓰기보다 훨씬 많을 때는 이 절충이 문제가 되지 않았다. 하지만 에이전트가 쓰기 빈도를 끌어올리자 복제본 수 자체가 쓰기의 병목이 됐다.

새 아키텍처는 세 부분으로 나뉜다

첫 번째는 조율을 최소화하는 것이다. 여러 주체 간 합의가 필요한 작업은 참조 업데이트뿐이고, 객체 스토리지, 검증, 보안 스캔은 병렬로 처리하도록 바꿨다.

두 번째는 스토리지와 컴퓨트의 분리다. 영속성은 애저 블롭 스토리지(Azure Blob Storage)에 맡기고, 읽기 요청은 경량 워커 프로세스 집합이 처리한다. 글은 이렇게 설명한다.

"Separating the two lets us scale each one independently"

(둘을 분리하면 각각을 독립적으로 확장할 수 있다)

세 번째는 백그라운드 유지 보수를 독립시킨 것이다. 압축과 가비지 컬렉션은 별도의 워커 프로세스에서 실행돼 실시간 요청과 자원을 다투지 않는다. 브랜치 보호, 필수 리뷰, 감사 로그, 관찰 가능성 관련 제어 기능은 그대로 유지된다.

쓰기 부하를 대략 계산해 보면

한 달을 30일로 잡으면, 월간 커밋 73억 8000만 건은 초당 약 2850건, 월간 푸시 33억 5000만 건은 초당 약 1290건에 해당한다. 1년 전에는 초당 약 270건이었다. 푸시마다 5개의 복제본이 참여해야 한다고 가정하면, 기존 아키텍처는 초당 약 6500건의 복제본 쓰기를 처리해야 했던 셈이다(재시도와 유지 보수 작업은 제외한 대략적인 추정치다).

35배의 처리량 향상은 연간 4.9배인 푸시 증가 속도에 비춰보면 계산상 몇 년의 여유를 남긴다. 다만 이는 에이전트 트래픽의 증가 곡선이 더 가파르게 꺾이지 않는다는 전제에서다. 깃허브도 이 부분에 대한 전망은 내놓지 않았다.

글이 밝히지 않은 부분

새 아키텍처로 몇 개의 저장소가 이미 옮겨갔는지, 전면 전환은 언제인지에 대한 일정은 제시되지 않았다. 35배라는 벤치마크가 어떤 규모의 저장소, 어떤 동시성 조건에서 측정됐는지도 설명이 없다. 속도 제한 조정 여부 등 사용자에게 미칠 영향에 대해서도 글은 언급하지 않았다.

깃허브는 올해 몇 차례 장시간 서비스 장애를 겪었지만, 글은 이런 사고들을 다루지 않았고 새 아키텍처가 비슷한 상황을 막을 수 있는지도 말하지 않았다. 셀렌자는 이 시리즈의 다음 글에서 향후 아키텍처와 이번 개편의 배경을 더 자세히 다루겠다고 예고하며 글을 마쳤다.

참고 출처: 깃허브 공식 엔지니어링 블로그, CocoLoop; 월간 커밋·푸시·Actions 실행 수치는 깃허브 공식 데이터로 검증.