Scaling Git at OpenAI
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
OpenAI는 Git 호환성을 유지하면서 브랜치별 쓰기 조정과 팩파일 재사용으로 확장성을 높인 Pando를 구축해, 모노레포의 중앙값 푸시 지연을 기존의 거의 5분의 1로 줄이고 하루 거의 1페타바이트의 Git 데이터를 제공한다.
📌 핵심 요약
- Codex로 병렬 개발이 늘면서 브랜치·푸시·병합·페치·클론 수요가 함께 증가했고, 기존 모노레포 지원 시스템에서는 느린 페치와 푸시, 병합 실패가 발생하며 신뢰성이 때때로 90% 아래로 떨어졌다.
- Pando는 서로 다른 브랜치에 대한 동시 푸시를 수평 확장하고, 클라이언트가 가용 네트워크 대역폭을 충분히 사용할 수 있도록 읽기 처리량을 높이는 것을 목표로 한다. 현재 OpenAI 모노레포의 모든 개발을 지원하며, 중앙값 푸시 지연을 기존의 거의 5분의 1로 줄이고 하루 거의 1페타바이트의 Git 데이터를 제공한다.
- OpenAI는 엔지니어링 작업을 중단하거나 팀의 Git 사용 방식을 바꾸지 않고 Pando를 도입했다. Git 프로토콜과 클라이언트 호환성을 유지했으며, 자체 Git 사본의 클라이언트 개선을 업스트림에 기여해 더 넓은 커뮤니티와 공유하려 한다.
- Pando는 브랜치별 업데이트를 독립적으로 조정하고, 여러 페치에서 팩파일을 재사용한다. 그 대가로 여러 브랜치를 읽을 때 서로 다른 시점의 상태가 보일 수 있고, 클라이언트가 이미 가진 객체를 일부 다시 다운로드할 수 있다.
- 검토한 3PC 설계는 복제본 간 조정과 왕복 통신이, WAL 설계는 공유 매니페스트 갱신 경쟁이 쓰기 확장의 제약이었다. Pando는 저장소 전체의 단일 시점 일관성 대신 인과적 일관성을 채택하고, 불변 팩파일과 의존성을 기록한 ref 버전을 사용하지만, 제공된 원문은 이 일관성 설명 도중에 끝난다.
🧩 주요 포인트
- Codex의 병렬 작업이 쓰기와 후속 읽기를 함께 증폭 → 소스 관리 시스템은 동시 푸시와 동일 이력의 대량 배포를 함께 확장해야 한다.
- 검토한 3PC는 저장소 전체의 일관된 ref 상태를 제공하고 WAL은 공유 매니페스트로 업데이트 순서를 정함 → 서로 다른 브랜치의 푸시도 공통 조정 지점에 묶여 확장에 제약을 받는다.
- 브랜치별 조정과 팩파일 재사용으로 조정·계산 비용을 줄임 → Pando는 처리량을 높이는 대신 브랜치 간 시점 일치와 중복 객체 전송 최소화 요구를 완화한다.
🧠 상세 정리
1. Codex가 키운 병렬 개발과 기존 시스템의 한계
OpenAI는 지난 1년 동안 모노레포의 규모와 요구량이 매우 빠르게 증가했으며, Codex가 가능하게 한 동시 작업 수준에 맞춰 소스 관리 시스템을 개편할 필요가 분명해졌다고 설명한다. 엔지니어가 더 많은 작업을 병렬로 수행하면서 브랜치와 푸시, 병합이 늘었고, 개발 환경·연구 작업·CI에서 발생하는 페치와 클론도 함께 증가했다. 한 엔지니어가 여러 변경을 동시에 CI에 보낼 수 있고 각각의 푸시가 동일 커밋을 가져오는 여러 작업을 실행할 수 있어 수요는 중첩됐다. 원문 기준 지난해 말 무렵부터 기존 시스템은 이를 따라가기 어려워졌고, 느린 페치와 푸시뿐 아니라 병합 실패가 발생하며 신뢰성이 때때로 90% 아래로 떨어졌다. 이 상황은 Git 자체의 한계에 도달한 것인지, 모노레포를 제공하던 방식의 한계인지 구분해야 한다는 문제를 제기했다.
2. Git 호환성을 유지한 Pando의 목표와 성과
OpenAI는 익숙한 Git 작업 흐름을 유지하면서 백엔드를 다시 구축하는 방향을 선택했고, 그 결과 새로운 Git 저장소 백엔드인 Pando를 개발했다. 핵심 목표는 여러 브랜치에 대한 동시 푸시에 최적화된 수평 확장 쓰기와, 클라이언트가 가용 네트워크 대역폭을 충분히 사용할 수 있을 만큼 높은 읽기 처리량이었다. Pando는 엔지니어링 작업을 중단하거나 팀의 Git 사용 방식을 바꾸지 않고 도입됐으며, Git 프로토콜과 클라이언트 호환성 덕분에 엔지니어와 에이전트가 기존 작업 흐름에서 사용할 수 있었다. 현재 OpenAI 모노레포의 모든 개발을 지원하고, 운영 환경에서 중앙값 푸시 지연을 기존의 거의 5분의 1로 줄였으며 하루 거의 1페타바이트의 Git 데이터를 제공한다. Git을 기반으로 삼은 데에는 오랜 기간 축적된 도구와 작업 방식을 이어가려는 의도도 있었고, OpenAI는 자체 Git 사본의 클라이언트 개선을 업스트림에 기여해 커뮤니티와 공유하려 한다.
3. Git 객체와 참조가 저장소를 구성하는 방식
Git 저장소를 확장하려면 객체와 참조라는 두 부분을 함께 이해해야 하며, 객체는 파일의 스냅샷과 그 사이의 이력을 그래프로 표현한다. 객체 유형에는 blob, tree, commit, tag가 있고, blob은 개별 파일의 내용을 담으며 tree는 이름을 blob이나 다른 tree에 연결해 디렉터리 구조를 만든다. commit은 루트 tree와 0개 이상의 부모 commit을 가리켜 이력을 구성하고, 객체는 유형과 내용의 해시로 식별되며 생성 뒤에는 변경되지 않는다. 따라서 파일이 바뀌면 새 blob이 만들어지지만 바뀌지 않은 파일과 디렉터리의 객체는 재사용할 수 있고, 브랜치와 태그인 ref는 commit을 가리키며 브랜치에 커밋하면 해당 ref가 새 commit으로 이동한다. 객체는 개별 파일인 loose 상태나 여러 객체를 묶은 packed 상태로 저장되며, 팩파일에서는 유사한 객체를 서로의 차이인 델타로 표현할 수 있어 객체 재사용과 압축이 저장 및 전송 구조의 기반이 된다.
4. 페치·푸시·복제에서 객체와 ref를 함께 맞추는 문제
페치에서 클라이언트는 원하는 commit과 이미 가진 commit을 서버에 알리고, 서버는 원하는 commit에서 도달 가능한 객체 중 클라이언트가 가진 것으로 파악한 객체를 제외해 팩파일로 보낸다. 전체 클론은 객체가 없는 상태에서 시작하므로 복제 대상 이력에서 도달 가능한 모든 객체가 필요하며, 이때 도달 가능성이란 commit의 부모와 tree, blob 연결을 따라 객체를 찾을 수 있다는 뜻이다. 반대로 푸시는 객체를 서버로 보내면서 하나 이상의 ref 갱신을 요청하고, 클라이언트는 서버가 알린 ref를 이용해 서버에 이미 있는 객체의 전송을 피한다. 그 결과 푸시된 팩파일은 기존 객체에 의존할 수 있어 팩파일 하나만으로 새 이력을 재구성할 수 있다고 보장할 수 없다. 저장소를 여러 서버에 복제할 때는 새 ref 값을 제공하기 전에 그 값에서 도달 가능한 객체도 제공할 수 있어야 하며, 같은 브랜치를 같은 이전 끝점에서 서로 다른 commit으로 옮기려는 경쟁 업데이트도 조정해야 한다. 모든 쓰기에 하나의 순서를 부여하면 이러한 조정은 단순해지지만 서로 무관한 브랜치의 푸시도 기다리게 될 수 있다.
5. 검토한 3PC 설계의 일관성과 조정 비용
OpenAI가 모델링한 3단계 커밋인 3PC 설계에서는 여러 복제본이 저장소 전체를 보유하고, 푸시를 받은 서버가 유입된 팩파일을 모든 복제본에 병렬로 전달한다. 조정자는 ref 업데이트를 게시하기 위해 과반수 복제본의 수락을 받아야 하며, 각 복제본은 해당 ref를 잠그고 클라이언트가 예상한 commit을 여전히 가리키는지 확인한다. 이후 수락한 복제본에 사전 커밋 메시지를 보내고 과반수의 응답을 받으면 실제 업데이트를 수행하도록 지시하므로, 조정자와 복제본 사이에 여러 차례 왕복 통신이 필요하다. 완전한 복제본은 로컬 읽기를 가능하게 하고 어느 복제본을 선택해도 모든 ref의 일관된 상태를 제공하지만, 설명된 설계에서는 ref가 한 번에 하나씩 갱신된다. 이 때문에 푸시는 정족수를 기다리는 동안 복제본의 디스크 성능과 통신 지연에 영향을 받으며, 쓰기량이 커질수록 복제본은 읽기 트래픽과 새 팩파일 수신을 동시에 감당해야 한다.
6. 검토한 WAL 설계의 공유 매니페스트 병목
OpenAI가 모델링한 WAL 설계에서는 서버가 푸시로 받은 팩파일을 blob 저장소에 올리고 로컬 저장소에서 ref 업데이트를 준비한 뒤, ref 변경과 팩파일 위치를 기록한 항목을 공유 매니페스트에 추가한다. 매니페스트는 비교 후 교환인 compare-and-swap으로 원자적으로 교체하며, 그사이 다른 작성자가 갱신했다면 중간 항목을 읽고 자신의 ref 변경이 여전히 유효한지 확인한 다음 이미 업로드한 팩파일을 이용해 재시도한다. 팩파일 업로드는 병렬로 진행할 수 있지만 서로 다른 브랜치의 푸시도 같은 매니페스트를 갱신해야 하므로, 성공적인 교환에 필요한 왕복 시간이 게시 빈도를 제한한다. 낮은 지연의 blob 저장소는 이 단계를 빠르게 하고 일괄 처리는 여러 ref를 한 번에 반영할 수 있지만, 일괄 처리에는 대기열과 지연 증가라는 비용이 따른다. blob 저장소 용량만 늘려도 공유 매니페스트 경쟁은 해소되지 않으며, 각 복제본이 팩파일을 읽고 인덱싱하는 속도보다 쓰기가 빠르면 복제본이 뒤처져 새 commit의 페치도 늦어진다.
7. Pando가 완화한 두 가지 요구와 그 대가
Pando는 Git 호환성을 유지하면서도 일반적인 Git 서비스가 요구사항으로 간주하는 저장소 전체의 일관성과 클라이언트마다 고유한 팩파일 생성이라는 두 조건을 재검토했다. 모든 ref에 대해 단일 시점의 일관된 스냅샷을 제공하려면 저장소 전체의 조정이 필요하므로, Pando는 각 브랜치의 업데이트를 독립적으로 조정해 서로 무관한 브랜치의 쓰기가 병렬로 진행되도록 한다. 이때 특정 브랜치를 페치하는 독자는 해당 리비전에 필요한 이력을 얻지만, 여러 브랜치를 함께 살펴보면 서로 다른 시점의 상태를 볼 수 있다는 절충이 생긴다. 읽기에서는 로컬 이력이 서로 다른 클라이언트마다 중복 객체를 제외한 새 팩파일을 만드는 대신, 여러 페치에 같은 팩파일을 재사용해 CPU와 디스크 입출력 부담을 줄인다. 클라이언트가 이미 가진 객체 일부를 다시 받을 수 있지만 서버는 적은 계산으로 동일한 바이트를 여러 클라이언트에 제공할 수 있고, 이러한 선택이 브랜치 간 쓰기 확장과 캐시를 통한 읽기 제공을 뒷받침한다.
8. 인과적 일관성을 위한 ref 버전과 설명의 범위
Pando는 쓰기를 확장하기 위해 완화된 일관성 모델인 인과적 일관성을 채택하고, 클라이언트가 브랜치에 푸시하면 유입된 팩파일을 blob 저장소의 불변 blob으로 보관한다. 브랜치가 이동할 때마다 메타데이터 저장소에는 새 끝점, 이를 제공한 팩파일, 해당 팩파일이 의존하는 이전 ref 버전을 포함하는 새로운 ref 버전이 기록된다. 원문은 blob 저장소와 메타데이터 저장소가 모두 수평 확장 가능하다고 설명하며, 객체를 담는 팩파일과 그 의존관계를 기록한 ref 버전을 연결해 이력을 재구성하는 구조를 제시한다. Pando에서 commit이나 ref를 페치하려면 일련의 ref 버전에 해당하는 팩파일을 클라이언트에 재생해, 페치 대상 ref 버전을 만든 클라이언트의 상태를 재구성해야 한다. 다만 제공된 원문은 이것이 저장소 전체에 더 약한 형태의 일관성을 제공한다는 설명 도중에 끝나므로, 이후의 구체적인 보장이나 구현 세부사항은 이 자료만으로 확인할 수 없다.
🧾 핵심 주장 / 시사점
- Codex로 늘어난 푸시는 후속 CI 페치까지 증폭시키므로, 쓰기 처리량만 개선해서는 모노레포가 받는 전체 부하를 해결하기 어렵다는 구조가 드러난다.
- 검토한 3PC와 WAL의 제약은 서로 다른 브랜치의 업데이트도 공통 조정 경로를 거친다는 점에 있다. Pando의 접근은 이 조정 범위를 브랜치별로 나누는 데 초점을 둔다.
- Pando는 브랜치 간 시점 일치와 중복 전송 최소화 요구를 완화해 확장성을 얻으면서도, Git 호환성을 유지해 기존 작업 흐름의 연속성과 클라이언트 개선의 공유 가능성을 확보했다.
✅ 액션 아이템
- Codex의 병렬 작업이 동시 푸시와 후속 페치 수요에 미치는 영향을 함께 검토.
- Pando의 브랜치별 업데이트 조정이 제공하는 확장성과 여러 브랜치의 서로 다른 시점 상태가 갖는 영향을 검토.
- 팩파일 재사용에 따른 읽기 처리량 개선과 이미 가진 객체의 일부 재다운로드 사이의 절충을 평가.
❓ 열린 질문
- Codex의 병렬 작업이 더 늘어날 때 Pando의 동시 푸시와 읽기 처리량은 각각 어디까지 확장될 수 있는가?
- 여러 브랜치가 서로 다른 시점의 상태로 보일 수 있다는 Pando의 특성은 실제 작업 흐름에 어떤 영향을 미치는가?
- 설명이 중단된 인과적 일관성은 ref 버전과 그 의존성에 대해 구체적으로 어떤 보장을 제공하는가?
