오픈AI(OpenAI)가 코덱스(Codex) 도입으로 늘어난 동시 개발 작업을 처리하기 위해 Git 저장소 백엔드 ‘판도(Pando)’를 구축하고, 자사 모노레포의 모든 개발에 적용했다. 오픈AI는 11월 3일 블로그에서 판도 도입 뒤 푸시 지연 시간 중앙값이 기존의 거의 5분의 1 수준으로 줄었고, 하루에 거의 페타바이트 규모의 Git 데이터를 제공한다고 밝혔다.
코덱스가 키운 동시 개발 수요
회사는 코덱스가 개발자가 작업을 병렬로 진행할 수 있게 하면서 브랜치 생성과 푸시, 병합, 가져오기(fetch)와 복제(clone)가 함께 늘었다고 설명했다. 한 개발자에게는 여러 변경 사항이 동시에 CI에 올릴 준비가 돼 있었고, 각 푸시로 여러 작업이 같은 커밋을 가져올 수 있어 수요가 겹쳤다는 것이다. 지난해 말부터 모노레포를 지원하던 시스템에서 푸시와 가져오기가 느려지고 병합이 실패했으며, 당시 안정성이 한때 90% 아래로 떨어졌다고 회사는 전했다.
판도는 Git 프로토콜과 기존 클라이언트 호환성을 유지하면서 쓰기와 읽기를 각각 확장하도록 설계됐다. 서로 관련 없는 브랜치의 업데이트는 브랜치별로 따로 처리해 동시에 진행할 수 있다. 읽기에서는 여러 클라이언트에 보낼 때마다 새 데이터 묶음(packfile)을 만드는 대신 기존 묶음을 재사용한다. 이 방식은 서버의 계산 부담을 줄이고 캐시를 활용해 같은 데이터를 여러 사용자에게 제공한다.
브랜치별 쓰기와 데이터 묶음 재사용
Git 저장소는 파일 내용과 디렉터리 구조, 커밋 이력을 객체로 저장하고, 브랜치와 태그는 커밋을 가리키는 참조(ref)로 관리한다. 가져오기를 요청한 클라이언트는 원하는 커밋과 이미 보유한 커밋을 서버에 알린다. 서버는 필요한 객체를 추려 packfile로 보내며, 판도는 이 데이터 전달 과정에서 여러 가져오기 요청에 같은 packfile을 재사용한다. 클라이언트가 이미 가진 객체 일부를 다시 받을 수 있지만, 서버가 매번 사용자별 데이터를 새로 계산하는 일을 줄이는 구조다.
브랜치별 업데이트를 독립적으로 처리하는 데에는 한계도 있다. 여러 브랜치를 한꺼번에 살펴보는 사용자는 각 브랜치가 서로 다른 시점의 상태로 보일 수 있다. 따라서 판도의 읽기·쓰기 확장 방식은 모든 브랜치의 상태를 한 시점으로 맞추는 대신, 서로 관련 없는 브랜치의 업데이트를 병렬로 처리하고 같은 이력을 여러 사용자에게 효율적으로 제공하는 데 초점을 둔다.
오픈AI는 기존 Git 사용 방식과 프로토콜을 바꾸지 않아 엔지니어뿐 아니라 에이전트도 기존 작업 흐름에서 판도를 이용할 수 있다고 밝혔다. 모노레포 전체 개발을 판도로 옮겼지만 엔지니어의 작업 방식을 바꾸거나 개발을 중단할 필요는 없었다는 설명이다. 회사는 Git을 기반으로 삼으면 클라이언트 개선 사항을 오픈AI 밖에서도 활용할 수 있다며, 자체 Git 변경 사항을 상류 프로젝트에 기여해 에이전트 규모의 작업을 지원하겠다고 덧붙였다.
