깃허브(GitHub)가 서비스 내 전체 소스코드 저장소의 99.99999%를 자체 데이터센터에서 마이크로소프트 애저(Microsoft Azure) 클라우드로 인프라를 이전했다고 공개했다.
남은 0.00001%는 전체 플랫폼에서 가장 트래픽이 몰리는 대형 저장소들이다. 지리적으로 떨어진 클라우드 데이터센터 간의 물리적 지연시간 문제로 이전이 지연되자, 깃허브는 스토리지 아키텍처 자체를 뜯어고치는 정면돌파를 택했다.
깃허브는 지난 2025년 8월 미국 중부(Azure Central US) 리전에 첫 번째 저장소 복제본을 배치한 이후 순차적으로 인프라를 넓혀왔다. 현재 대부분의 저장소는 총 5개의 복제본 중 2개를 애저에 두고 있으며, 전체 Git 트래픽의 절반가량을 애저 환경에서 소화하는 상태다. 마이그레이션 과정에서 발생할 수 있는 장애 위험을 낮추기 위해 서비스 데이터와 제반 시스템을 먼저 옮긴 뒤 스토리지 구조를 개편하는 단계적 접근을 적용했다.
문제는 아직 이전하지 못한 최상위 핵심 저장소들이었다. 기존 깃허브의 핵심 스토리지 엔진인 '스포크(Spokes)' 쿼럼 시스템은 쓰기 작업을 확정할 때 전체 정상 복제본의 응답을 모두 대기하는 구조였다. 쓰기 작업이 진행되는 동안 저장소 전체에 잠금(Lock)이 걸리면서 가장 응답이 느린 복제본이 전체 시스템의 속도를 결정지었다. 기존 데이터센터와 애저 리전 사이의 거리는 약 1,000마일(약 1,600km)로, 한번 네트워크를 오가는 데만 약 25밀리초(ms)가 걸린다. 트래픽이 미친 듯이 몰리는 대형 저장소에서는 수 밀리초의 지연이 병목 현상으로 직결됐다.
이를 해결하기 위해 깃허브 엔지니어링 팀은 잠금 단위를 저장소 전체에서 개별 '레퍼런스(Reference, 브랜치나 태그 등)'로 쪼개는 방식을 도입했다.
과거에는 누군가 메인 브랜치에 코드를 올리면 작업이 끝날 때까지 다른 사용자가 별도의 개발 브랜치에 코드를 푸시하는 것조차 줄을 서서 기다려야 했다. 앞으로는 같은 브랜치에 대한 쓰기 작업만 대기열에 들어가고, 서로 다른 브랜치에 대한 작업은 병렬로 동시 처리된다. AI 개발 에이전트들이 각자 할당된 독립 브랜치로 수많은 커밋을 쏟아내는 최근 개발 환경에 맞춰 인프라 구조를 체질 개선한 셈이다. 내부 테스트 결과, 지연시간이 줄어들면서 독립적인 레퍼런스에 대한 쓰기 처리량이 기존 대비 3~4배나 뛰어올랐다.
읽기와 쓰기 성능을 독립적으로 확장하는 아키텍처 개편도 함께 추진된다. 일반적인 코드 저장소는 쓰기 1건당 무려 100~1,000건의 읽기 작업이 들어온다. 기존에는 동일한 복제본 서버가 읽기와 쓰기를 동시에 받다 보니 메모리와 컴퓨팅 자원을 두고 매번 내부 경합이 벌어졌다.
깃허브는 객체 스토리지인 '애저 블롭 스토리지(Azure Blob Storage)'를 쿼럼의 가상 복제본(Virtual Replica)으로 편입시키는 아이디어를 냈다.
가상 쓰기 복제본은 들어오는 쓰기 데이터를 블롭 스토리지로 직접 보낸 뒤 무결성을 확보하고 승인 신호를 남긴다. 이 과정에서 독립된 레퍼런스의 여러 트랜잭션을 하나의 네트워크 입출력 패킷으로 묶어 효율을 극대화한다. 데이터 저장이 완료되면 읽기 트래픽만을 전담하는 가상 읽기 복제본을 필요한 만큼 늘려 데이터를 캐싱하고 독립적으로 트래픽을 분산 처리하는 방식이다.
스포크 엔진은 현재 하루 1,000억 건이 넘는 대규모 저장소 데이터를 다루고 있다. 깃허브는 이번 개편 작업을 바탕으로 수억 개의 신규 저장소와 AI 에이전트 기반 개발 환경을 무리 없이 수용할 수 있는 초고성능 클라우드 인프라 기반을 계속 넓혀갈 계획이다.
