OpenAI, Git 백엔드 Pando 공개: 인과 일관성으로 브랜치별 쓰기 확장, 자체 보고 푸시 지연 중앙값 약 80% 감소, 다만 시뮬레이션은 교육용 모델이며 Pando의 외부 제공은 언급 없음
2026년 11월 2일 OpenAI 엔지니어들은 Git 프로토콜과 클라이언트를 바꾸지 않고 모노레포를 제공하며 지금은 OpenAI 모노레포 안의 모든 개발을 뒷받침하는 새 백엔드 Pando를 설명했습니다. Pando는 푸시마다 packfile을 불변 blob과 ref 버전으로 저장하고, 관련 없는 브랜치를 독립적으로 쓰게 하며, 읽기는 저장된 팩을 재사용해 지역 캐시로 제공합니다. OpenAI는 병합 신뢰도 향상, 푸시 지연 중앙값 약 80% 감소(도입부는 약 5배), 하루 1페타바이트 가까운 전달, 한 시간 57TB(99% 이상 로컬 캐시)를 자체 보고합니다. 대가는 브랜치 간 시점 뷰가 없는 인과 일관성뿐이라는 점과, 기본적으로 트렁크만 알리므로 반복 푸시가 데이터를 다시 보낸다는 점입니다. 1,000클라이언트 시뮬레이션은 교육용 모델로 표시되며 글은 Pando의 외부 제공을 말하지 않습니다.
2026년 11월 2일 OpenAI 엔지니어 세 명, Aaron Friel, Taylor Blau, Ted Nyman이 「Scaling Git at OpenAI(OpenAI에서 Git 확장하기)」를 공개했습니다. 글은 Git 저장소를 제공하는 새 백엔드 Pando를 소개하며, Pando는 이제 OpenAI 모노레포의 모든 개발을 뒷받침합니다. 이유는 Codex라고 합니다. 엔지니어가 훨씬 많은 작업을 병렬로 하게 되면서 개발 환경, 연구 작업, 지속적 통합에서 나오는 브랜치, 푸시, 병합, 페치, 클론이 늘었습니다. 작년 말쯤부터 기존 시스템이 버거워 페치와 푸시가 느려지고 병합이 실패했으며 신뢰도가 때때로 90% 아래로 떨어졌습니다.
Pando는 Git 프로토콜과 클라이언트를 유지하므로 엔지니어와 에이전트의 작업 방식은 바뀌지 않았습니다. 목표는 두 가지로, 많은 브랜치에 걸쳐 수평으로 확장되는 쓰기와 클라이언트의 네트워크를 가득 채울 만큼 빠른 읽기입니다. 쓰기에서는 들어온 packfile을 불변 blob으로 저장하고 메타데이터 저장소에 'ref 버전'을 기록합니다. 서로 관련 없는 브랜치의 갱신은 독립적으로 진행되고, 같은 ref로의 푸시만 충돌합니다. 읽기에서는 클라이언트마다 새 팩을 만드는 대신 저장된 packfile을 재사용하고, 지역 캐시에서 제공하는 packfile URI를 클라이언트에 돌려줍니다.
저자들은 이를 자신들이 모델링한 두 가지 흔한 설계와 비교합니다. 하나는 완전한 복제본 사이의 3단계 커밋으로, 푸시마다 여러 번의 왕복이 필요하고 복제본 디스크가 쓰기 경로에 놓입니다. 다른 하나는 객체 저장소의 공유 선행 기록 로그로, 모든 푸시가 하나의 매니페스트 갱신을 두고 경쟁합니다. 클라이언트 1,000개의 대화형 시뮬레이션에서 앞의 것은 부하 시 쓰기가 느려지고 뒤의 것은 읽기가 느려집니다. 다만 페이지는 이 시뮬레이션을 '합성 교육용 모델이며 운영 벤치마크가 아니다'라고 표시하므로, 설계를 설명할 뿐 운영 수치를 입증하지는 않습니다.
운영에 관한 주장은 구체적입니다. Pando로 바꾸자 병합 신뢰도가 좋아지고 푸시 지연 중앙값이 80% 가까이 줄었으며, 도입부에서는 이를 약 5배로 표현합니다. Pando는 하루 1페타바이트에 가까운 Git 데이터를 전달하고, 한 시간에 57테라바이트가 넘는 팩을 제공했으며 그 바이트의 99% 넘게가 로컬 디스크 캐시에서 나왔고, 검증에서 표준 클라우드 가상 머신으로 10Gbps 링크를 포화시켰습니다. 팩 전달 서비스 Express는 캐시 적중률 99% 이상을 보고합니다. 이는 OpenAI가 자사 모노레포 하나에 대해 밝힌 수치이며, 독립적인 측정이나 운영 환경에서 다른 시스템과의 비교는 글에 없습니다.
글은 트레이드오프도 솔직하게 말합니다. Pando가 제공하는 것은 인과 일관성이지, 모든 ref의 시점 스냅샷이 아닙니다. 클론 중 두 클라이언트가 두 브랜치를 서로 다른 버전으로 볼 수 있고, 단일 ref에 대한 갱신은 직렬화 가능한 상태로 유지됩니다. 팩을 재사용할 수 있게 하려고 Pando는 푸시 때 기본적으로 지정한 트렁크 브랜치만 알리므로, 같은 기능 브랜치에 반복해서 푸시하거나 브랜치를 쌓으면 더 많은 데이터를 다시 보냅니다. OpenAI의 모노레포에서 이렇게 만들어진 팩의 중앙값은 20KiB 미만, 99번째 백분위수는 3MiB 미만이었습니다. Pando는 각 압축 수준에서도 팩을 유지하며 L4까지 사용해, 페치 계획이 수천 개의 작은 다운로드 대신 로그 시간에 이뤄지게 합니다.
구축에 관해 저자들은 Pando가 착수부터 운영까지 10주가 걸렸고 4월부터 운영 트래픽을 처리했으며, 핵심은 엔지니어 한 명이 설계하고 에이전트 팀이 구현하고 소수의 엔지니어가 배포했다고 말합니다. Rust로 작성했고 적합성 테스트 모음과 결정론적 시뮬레이션 테스트가 있으며, GPT-6 Astra 에이전트가 Lean과 TLA+ 모델을 작성해 버그를 찾았습니다. 배포는 Pando를 기존 시스템에 대한 읽기·쓰기 통과 프록시로 시작해 중단 없이 트래픽을 옮겼습니다. 글은 Pando를 OpenAI 밖에서 쓸 수 있다고는 말하지 않습니다.
OpenAI는 Git 자체에도 기여합니다. 동시 팩 다운로드, 중단된 전송 후 정리, 완료된 다운로드의 재개와 관련한 경계 사례를 고쳤고, packfile-uri 다운로드 추적을 추가했으며, 푸시하는 클라이언트가 --force-with-lease를 써서 트렁크만 기준으로 팩을 만들 수 있게 'explicit haves'를 더했습니다. 일부 변경은 업스트림 Git에 들어갔고 나머지는 OpenAI의 공개 포크에 있습니다. 수집 시점에 GitHub의 그 포크는 git/git의 공개 포크였고 codex 브랜치는 git/git master보다 115 커밋 앞서고 522 커밋 뒤처져 있었으며, packfile-uri 재사용을 이름으로 한 최근 병합이 있었습니다. 큰 모노레포를 운영하는 팀이 얻을 교훈은 이 트레이드오프입니다. 브랜치 간 일관성을 느슨하게 해서 쓰기 확장을 얻었고, 사용자와 에이전트가 의존하는 것이 전역 순서가 아니라 단일 ref의 갱신 순서였기에 여기서는 통했습니다.
Sources
FAQ
Pando는 왜 일관성을 느슨하게 하나요?
관련 없는 브랜치를 병렬로 쓸 수 있게 하기 위해서입니다. Pando는 단일 ref의 갱신은 직렬화 가능하게 유지하지만 브랜치 사이에는 인과 일관성만 제공하므로, 클론 중 두 클라이언트가 두 브랜치를 다른 버전으로 볼 수 있습니다. OpenAI는 사용자와 에이전트가 전역 순서가 아니라 단일 ref의 갱신 순서에 의존한다고 판단합니다.
'약 80%'와 '약 5배'는 서로 다른 개선인가요?
아닙니다. 도입부는 푸시 지연 중앙값이 약 5배 줄었다고 하고 배포 부분은 약 80% 줄었다고 하는데, 거의 같은 변화입니다. 약 5분의 1로 떨어지면 약 80% 감소입니다. 둘 다 OpenAI가 자사 모노레포에 대해 밝힌 자체 보고 수치이며 독립적 측정이 아닙니다.
1,000 클라이언트 시뮬레이션이 운영 성능을 입증하나요?
입증하지 않습니다. 페이지는 이를 합성 교육용 모델이며 운영 벤치마크가 아니라고 표시하고, 3단계 커밋, 선행 기록 로그, Pando의 차이를 설명하는 데 씁니다. 운영 주장은 OpenAI 자체 수치에 기대고 있으며 Pando의 외부 제공 여부도 글에 없습니다.