오픈AI, 새 깃 백엔드 판도 공개

오픈AI가 사내 모노레포를 떠받치는 새 깃 백엔드 판도(Pando)를 11월 2일 엔지니어링 블로그에서 공개했다. 판도는 이제 오픈AI 모노레포의 모든 개발을 처리하며, 중간값 기준 푸시 지연을 80% 가까이 줄였고 하루 1페타바이트에 가까운 깃 데이터를 내보낸다. 엔지니어와 에이전트가 쓰던 깃 명령과 클라이언트는 그대로 두고 서버 쪽만 갈아끼운 것이 핵심이다. 오픈AI 개발자 계정은 11월 3일 X에서 "에이전트 사용량에 맞춰 깃 용량을 늘릴 수 있게 됐다"고 밝혔다.

출발점은 코덱스가 바꾼 일하는 방식이다. 에런 프리엘, 테일러 블라우, 테드 나이먼 오픈AI 기술 스태프는 글에서 "코덱스가 오픈AI의 개발 규모와 속도를 바꿨고, 엔지니어가 훨씬 많은 일을 병렬로 할 수 있게 됐다"고 썼다. 엔지니어 한 명이 여러 변경을 동시에 CI에 올리고, 푸시 한 번이 같은 커밋을 받아 가는 작업 여러 개를 깨운다. 오픈AI가 공개한 도표에 따르면 마스터 브랜치에 들어간 커밋 수는 2024년 1분기 대비 2026년 3분기에 1,378% 늘었고, 4분기 기본 추정치는 2,442% 증가다.

지난해 말부터 기존 시스템이 버티지 못했다. 페치와 푸시가 느려지고 병합이 실패했으며, 신뢰도가 한때 90% 밑으로 떨어졌다. 세 사람은 "깃 자체의 한계에 닿은 것인지, 우리가 모노레포를 서비스하는 방식의 한계인지"를 물었다고 적었다. 오픈AI는 20년 넘게 쌓인 깃 생태계를 버리지 않고 백엔드만 다시 짓는 길을 골랐다. 그래야 클라이언트 개선이 오픈AI 밖에서도 쓸모 있다고 판단했다.

판도가 내려놓은 것은 저장소 전체의 일관성이다. 기존 방식은 모든 브랜치 갱신을 한 줄로 세워, 서로 관계없는 브랜치에 대한 푸시도 서로를 기다렸다. 판도는 브랜치마다 따로 갱신을 조율하고, 같은 브랜치에 동시에 푸시할 때만 충돌로 본다. 들어온 팩파일은 블롭 스토리지에 바뀌지 않는 덩어리로 저장하고, 브랜치가 움직일 때마다 새 끝 커밋과 그 팩, 의존하는 이전 버전을 메타데이터 저장소에 기록한다. 오픈AI는 이를 인과적 일관성이라고 부르며, 사용자와 에이전트는 실제로 브랜치 하나의 갱신 순서에만 기댄다고 설명했다.

읽기 쪽 해법은 재사용이다. 일반 깃 서버는 페치 요청마다 그 클라이언트에 맞는 팩파일을 새로 만든다. 손님마다 주문서를 받아 도시락을 새로 싸는 식당과 같다. 판도는 푸시 때 받은 팩파일을 그대로 보관했다가 필요한 묶음을 골라 링크로 건넨다. 미리 싸 둔 도시락을 진열대에서 집어 주는 방식이라, 손님이 이미 가진 반찬이 조금 겹쳐도 주방은 거의 일하지 않는다.

이 링크 전달에는 깃 프로토콜에서 잘 쓰이지 않던 packfile-uri 기능을 썼다. 응답에는 빈 팩만 싣고, 실제 데이터는 지역별 캐시 서비스 익스프레스(Express)가 내려보낸다. 일관 해싱으로 요청을 나눠 캐시 적중률이 99%를 넘고, 일반 클라우드 가상머신만으로 클론과 페치가 10Gbps 회선을 가득 채웠다고 오픈AI는 밝혔다. 푸시 단계에서도 서버가 패를 덜 보여 준다. 세 사람은 기존 깃 서버를 "가진 패를 전부 보여 주는 포커 플레이어"에 빗댔다.

브랜치가 수백만 개면 서버가 알려 주는 브랜치 목록만 100MiB를 넘을 수 있다. 판도는 새 기능 브랜치를 푸시할 때 기본적으로 트렁크 브랜치 하나만 알려 준다. 그만큼 팩이 커질 수 있지만, 오픈AI 모노레포에서 이렇게 만들어진 팩파일의 중간값은 20KiB 미만, 99번째 백분위도 3MiB 미만이었다. 하루 수만 개씩 쌓이는 작은 팩은 로그 구조 병합 트리와 비슷한 압축으로 L0에서 L4까지 묶어, 뒤처진 클라이언트가 받아야 할 파일 수를 줄인다.

판도는 코덱스로 지었다. 착수부터 프로덕션까지 10주가 걸렸고, 핵심 설계는 엔지니어 한 명이, 구현은 에이전트 팀이, 배포는 엔지니어 몇 명이 맡았다. 실제 트래픽은 올해 4월부터 받았다. 레거시 의존성 없이 러스트로 새로 썼고, 에이전트가 표준 깃 동작과 견줘 볼 수 있도록 적합성 테스트 묶음을 만들었다. GPT-6 Astra를 쓴 에이전트는 Lean과 TLA+로 판도의 동작을 형식화해 버그를 찾고 시스템 성질을 증명했으며, 여러 세션이 수백 시간 동안 이어 돌며 경계 사례를 고쳤다.

이전은 멈춤 없이 진행됐다. 판도는 처음에 기존 소스 관리 시스템 앞에서 읽기와 쓰기를 통과시키는 프록시로 붙어 두 시스템을 맞춰 놓았고, 작업을 하나씩 옮겼다. 오픈AI는 자체 깃 배포판을 개발자 컴퓨터와 챗GPT 데스크톱 앱에 실었고, 레거시 API와 웹훅, 저장소 다운로드에 기대던 통합 수백 개를 함께 옮겼다. 개발자는 코덱스에 개발 환경 이전을 맡기면 됐다.

메탈이 확인한 오픈AI의 37개 평일 병합 인프라 일일 성공률 도표에서, 전환 전에는 성공률이 87%대까지 떨어진 날이 있었고 전환 뒤에는 100% 선에 붙었다. 오픈AI는 병합 후 신뢰도를 99.99%로 표시했다. 판도는 한 시간에 57테라바이트가 넘는 깃 팩을 내보낸 적이 있고, 그 바이트의 99% 이상이 로컬 디스크 캐시에서 나왔다. 하루 1페타바이트에 가까운 전송도 CPU 코어 몇 개로 처리한다는 것이 회사 측 설명이다.

오픈AI는 판도를 만들며 찾은 깃 클라이언트 개선을 상위 프로젝트에 돌려보내고 있다. 동시 다운로드와 중단된 전송 뒤 정리의 경계 사례를 고쳤고, packfile-uri 다운로드 추적과 브랜치의 현재 끝을 따로 알리는 명시적 haves 개념을 더했다. 일부는 이미 공식 깃에 들어갔다. 메탈은 오픈AI가 코덱스 하네스를 API로 연 소식을 보도한 바 있으며, 판도는 그 에이전트들이 쏟아내는 코드를 받아 내는 아래층이다.

세 사람은 "엔지니어와 에이전트가 더 많은 소프트웨어를 만들수록 오픈AI 밖의 더 많은 팀이 우리가 소스 관리에서 부딪힌 한계를 만나게 될 것"이라고 썼다. 오픈AI는 판도를 가능하게 한 기술을 사용자와 나누는 방법을 찾고 있고, 사내에서는 많은 에이전트가 하나의 깃 저장소에서 협업하는 작업에도 판도를 쓰는 방안을 살피고 있다. 코딩 에이전트 시대의 병목이 모델에서 그 아래 소스 관리 배관으로 내려왔다는 사실을 판도의 수치가 보여 줬다.