기업의 코딩 에이전트가 대규모로 브랜치를 열고 작업을 병렬로 돌리기 시작하면, 아무도 신경 쓰지 않는 도구 사슬의 조용한 부분, 즉 버전 관리가 깨지는 곳이 됩니다. OpenAI는 바로 그 일이 자사 Git 서비스에 일어났다고 하며, 그 답은 새 백엔드를 처음부터 짓는 것이었습니다. 여기서 유용한 신호는 도구 자체가 아니라 부하 패턴이며, 자신의 지속적 통합과 버전 관리에서 에이전트를 키우는 어느 팀이든 이를 마주하게 됩니다.
압력은 Codex에서 왔습니다. Codex 덕분에 OpenAI의 엔지니어들은 한 번에 훨씬 많은 작업을 할 수 있었습니다. 더 많은 브랜치, 더 많은 push, 개발 환경과 연구 작업과 CI에서의 더 많은 fetch입니다. 지난해 말부터 모노레포를 떠받치는 시스템이 힘겨워졌고, 신뢰성이 때때로 90% 아래로 떨어지면서 push와 merge가 느려지거나 실패했습니다. Git을 버리는 대신, OpenAI는 익숙한 작업 흐름을 유지하고 그 아래 백엔드를 다시 지었으며, 그 결과를 Pando라 이름 붙였습니다. 설계 목표는 많은 브랜치로의 쓰기를 동시에 확장하고, 같은 이력을 많은 읽는 이에게 캐시에서 제공하는 것이었습니다.
보고된 결과는 상당합니다. Pando는 중앙값 push의 지연을 거의 80% 줄였고, 이제 하루에 1페타바이트 가까운 Git 데이터를 제공하며, 한 시간에 57테라바이트 넘게, 그 바이트의 99% 넘게가 로컬 디스크 캐시에서 옵니다. OpenAI는 이를 레거시 의존성 없이 Rust로 지었고, 착수에서 운영까지 약 10주 걸렸으며, Codex 자체와 여러 모델이 작업의 상당 부분을 했다고 밝힙니다. 4월에 운영 트래픽을 처리하기 시작했습니다.
나머지 우리에게의 의미는 제품이 아니라 패턴입니다. Pando는 오픈소스가 아니므로 대부분의 팀은 채택할 수 없습니다. 공개된 것은 OpenAI가 Git에 되돌려준 클라이언트 쪽 개선뿐이며, 자 사의 fork를 통해서입니다. 즉 이것은 도구라기보다 경고로 읽힙니다. Git을 둘러싼 시스템은 20년간의 사람 작업 흐름으로 빚어졌고, 에이전트 떼는 그 도구들이 상정하지 않은 방식으로 그것들을 밀어붙입니다.
솔직한 단서는 공급자의 엔지니어링 글에 흔한 것들입니다. 신뢰성과 지연 수치는 OpenAI 자체 자료이며 독립적으로 검증되지 않았고, 하나의 아주 큰 모노레포에 맞춘 백엔드는 더 작거나 형태가 다른 저장소에는 옮겨지지 않을 수 있습니다. 그래도 더 많은 팀이 자기 코드베이스에 에이전트를 겨누면서, 병렬 기계 작업이 CI와 버전 관리를 새로운 방식으로 압박한다는 교훈은 자신의 merge 실패로 나타나기 전에 진지하게 받아들일 가치가 있습니다. 저희는 애초에 이 부하를 만든 에이전트인 OpenAI Codex를 리뷰합니다.