OpenAI, Git 백엔드 Pando 모노레포 도입 푸시 지연 중앙값 거의 5배 단축

OpenAI가 대규모 모노레포를 위한 Git 저장소 백엔드 Pando를 만들어 모노레포의 모든 개발에 쓰고 있다고 2026년 11월 2일(현지시간) 엔지니어링 블로그에서 밝혔다. Git 프로토콜과 클라이언트를 그대로 지원해서 엔지니어와 에이전트가 기존 작업 방식을 바꾸지 않아도 되며, 회사는 운영 환경에서 푸시 지연 시간 중앙값이 거의 5배 줄었다고 설명했다.

Pando는 여러 브랜치에 동시에 푸시하는 쓰기를 수평으로 확장하고, 클라이언트가 네트워크 대역폭을 가득 채울 만큼 읽기 처리량을 끌어올리도록 설계됐다. 현재 하루에 거의 1페타바이트의 Git 데이터를 내려보낸다. 외부 사용자에게 어떻게 제공할지는 검토 중이다.

새 백엔드가 필요했던 이유

Codex 덕에 엔지니어 한 사람이 병렬로 처리하는 일이 크게 늘었다. 브랜치와 푸시, 병합이 많아졌고 개발 환경·연구 작업·CI에서 오는 fetch와 clone도 함께 늘었다. 변경 하나를 푸시할 때마다 여러 작업이 같은 커밋을 내려받는 구조라 부담이 겹쳤다.

지난해 말쯤부터 모노레포를 받치던 시스템이 따라가지 못했다. fetch와 푸시가 느려졌고 병합이 실패했으며, 신뢰도가 때때로 90% 미만으로 내려갔다. OpenAI는 한계가 Git 자체에 있는지 서비스 방식에 있는지 따져 본 끝에, Git 워크플로를 유지하고 백엔드만 다시 만들기로 했다. 클라이언트 개선을 upstream에 기여할 수 있다는 점도 이유였다.

Pando의 작동 방식

OpenAI는 기존 방식으로 3단계 커밋(3PC)과 blob 저장소의 공유 매니페스트에 쓰기 전 로그(WAL)를 두는 방식을 모델링해 비교했다. 3PC는 복제본 과반의 합의가 푸시 경로에 들어가 디스크 성능과 통신 지연이 쓰기를 좌우한다. WAL 방식은 관련 없는 브랜치 푸시도 같은 매니페스트를 갱신해야 해서 병목이 생긴다.

Pando는 저장소 전체의 일관성과 클라이언트별 팩파일 생성이라는 두 전제를 포기했다. 푸시가 들어오면 팩파일을 변경 불가능한 blob으로 저장하고, 브랜치가 움직일 때마다 새 끝점과 팩, 의존하는 이전 ref 버전을 메타데이터 저장소에 기록한다. 같은 ref를 동시에 푸시할 때만 충돌한다. 저장소 전체에는 더 약한 형태인 인과 일관성을 적용하고, 개별 ref의 갱신에는 직렬성을 제공한다.

대신 여러 브랜치를 읽는 클라이언트는 그 상태가 한 시점이라고 가정할 수 없다. 전체 클론 중 foo와 bar가 함께 갱신되면 클라이언트마다 서로 다른 버전 조합을 볼 수 있다. OpenAI는 실제로 사용자와 에이전트가 ref 전체의 순서가 아니라 단일 ref의 갱신 순서에 의존한다고 설명했다.

푸시 서버는 팩을 로컬 저장소에 풀지 않고 검증하면서 blob 저장소로 스트리밍한다. 단일 패스 디코딩 뒤 다중 키 트랜잭션으로 ref 버전을 기록하고 ref 포인터를 원자적으로 바꾸므로, 쓴 내용을 바로 읽을 수 있다. 메타데이터 읽기·쓰기 횟수는 푸시 크기와 무관하게 상수(O(1))이고, 매우 큰 푸시는 일부 커밋만 동기로 기록한다.

푸시할 때 Pando는 모든 브랜치를 알리지 않고 기본적으로 지정된 trunk 브랜치만 알린다. 브랜치가 수백만 개면 ref 목록만 100MiB를 넘을 수 있고, 알리는 ref가 적을수록 클라이언트가 만드는 팩이 다른 클라이언트에도 재사용되기 쉽다. 같은 브랜치에 여러 번 푸시하거나 브랜치를 겹쳐 쌓으면 trunk 밖의 내용을 다시 보내야 해 대역폭을 더 쓴다. OpenAI 모노레포에서 이렇게 만든 팩파일은 중앙값이 20KiB 미만, 99번째 백분위수가 3MiB 미만이었다.

fetch에서는 클라이언트의 have와 want를 ref 버전으로 대응시켜 이미 저장된 팩을 고르고, Git의 packfile-uri 기능으로 팩 내려받기 주소만 돌려준다. 팩은 지역별 캐시를 둔 전송 서비스 Express가 제공하며, 팩 요청은 일관된 해싱으로 Express 서버에 나누고 캐시 적중률은 99%를 넘는다. 일반 클라우드 VM만으로 clone과 fetch가 10Gbps 네트워크 링크를 가득 채우는 것을 확인했다. OpenAI는 packfile-uri를 위한 개선 여러 건을 upstream에 기여했다.

푸시마다 만들어지는 L0 팩파일은 백그라운드에서 합쳐진다. 로그 구조 병합 트리의 컴팩션과 비슷한 설계로, 팩을 레벨별 묶음으로 만들어 압축률을 높이고 fetch 계획을 로그 시간에 세운다. 현재 모노레포는 L4 묶음까지 쓴다. 푸시마다 팩 주소를 따로 보내면 하루 기준으로 클라이언트가 trunk를 따라잡는 데 수만 개의 팩을 내려받아야 해서 이 작업이 필요하다. 모든 레벨의 팩을 지우지 않고 유지한다.

성과와 개발·이전 과정

Pando로 옮긴 뒤 병합 신뢰도가 좋아졌다. 소수의 CPU 코어만으로 하루 1페타바이트의 Git 데이터를 전달할 수 있으며, 한 시간에 57테라바이트 넘는 팩을 제공한 적이 있고 그중 99% 넘는 바이트가 로컬 디스크 캐시에서 나갔다.

OpenAI는 Pando를 Codex로 착수부터 운영까지 10주 만에 만들었다고 밝혔다. 핵심 설계는 엔지니어 한 명이 하고 구현은 에이전트 팀이, 배포는 소수의 엔지니어가 맡았다. 4월부터 운영 트래픽을 처리했고 Rust로 새로 작성했으며, 표준 Git 동작과 대조하는 적합성 테스트와 결정론적 시뮬레이션 테스트로 경합 상태와 협상·팩 계획의 회귀를 찾았다.

GPT-6 Astra를 쓴 에이전트는 Lean과 TLA+로 Pando의 이론을 형식화해 버그를 찾고 시스템 속성을 증명했다. 수백 시간 이어진 세션도 있었다. 에이전트를 하루 종일 돌려 Daybreak 대응 모델로 Git과 Pando를 레드팀 방식으로 점검하기도 한다.

배포는 기존 소스 관리 시스템 앞에 읽기·쓰기 통과 프록시로 Pando를 두어 두 시스템을 동기화한 채 중단 없이 트래픽을 옮겼다. 이전한 워크로드의 푸시가 캐시를 채워 기존 백엔드의 안정성도 높아졌다. 클라이언트는 사내 Git CLI 래퍼로 단계별 이전했고, 개발자 PC와 ChatGPT 데스크톱 앱에 OpenAI의 Git 배포판을 넣었다. 레거시 API와 웹훅, 저장소 다운로드에 의존하던 연동 수백 개도 옮겼다. 개발자는 Codex에 환경과 서비스 이전을 맡기면 됐다.

Git 기여와 이후 계획

재사용 팩을 클라이언트에 직접 주면서 동시 다운로드, 중단된 전송 뒤 정리, 이미 끝난 다운로드의 재개에서 예외 상황이 드러났다. OpenAI는 이를 고치고 기존 팩을 받아들일 때의 검증도 추가해 upstream에 보냈다. packfile-uri 다운로드 추적과 팩 생성 바이트 수 집계도 넣어 느린 fetch가 생성 탓인지 전송 탓인지 구분할 수 있게 했다.

OpenAI의 Git 빌드는 독립 팩을 병렬로 내려받고 색인한다. 서버가 브랜치 끝점을 푸시 클라이언트가 팩에서 뺄 수 있는 이력과 따로 알리는 '명시적 have'도 추가했다. Pando에서는 --force-with-lease로 브랜치가 움직이지 않았는지 확인하면서 trunk만 기준으로 팩을 만들 수 있고, trunk 이력을 가진 누구나 같은 팩으로 그 브랜치를 받는다. 이 개선 일부는 이미 upstream Git에 들어갔고 나머지는 공개 저장소와 패치 트래커에서 볼 수 있다.

OpenAI는 모노레포 밖에서도 많은 에이전트가 공유 Git 저장소에서 협업하는 워크로드 등 다른 용도를 살피고 있다. 소프트웨어 생산량이 늘면 다른 팀도 같은 한계를 만날 것으로 보고, Pando를 가능케 한 기술을 사용자에게 공유할 방법을 검토 중이라고 밝혔다.