OpenAI, 내부 Git 시스템 Pando 소개…여러 AI가 만든 코드는 어떻게 모일까

‘최종’, ‘최종 수정’, ‘진짜 최종’ 파일을 따로 복사하다 보면 어떤 것이 시험한 버전인지 헷갈립니다. Git의 버전 관리는 파일 묶음의 상태와 그 앞뒤 이력을 남깁니다. 저장된 한 시점이 commit이고, 한 수정 흐름을 가리키는 이름이 branch입니다. branch를 나누면 서로 다른 수정안을 진행한 뒤 어떤 결과를 합칠지 검토할 수 있습니다. Git의 버전 관리 설명 · branch의 기본 원리

다음은 두 수정안을 따로 다루는 가상 사례입니다. 저장소에 코드를 보냈다는 사실은 서비스를 공개했다는 뜻까지 포함하지 않습니다.

push는 내 수정 이력을 공유 저장소로 보내는 일입니다. fetch·clone은 다른 작업 환경이 필요한 코드 이력을 받아 오는 일입니다. 자동 시험 시스템인 CI도 코드를 받아야 시험을 시작합니다. 여러 AI가 동시에 수정안을 만들면, 보내는 요청뿐 아니라 같은 버전을 받아 가는 시험 작업도 늘어납니다.

OpenAI는 서로 다른 branch의 업데이트를 독립적으로 처리하고, 여러 독자가 쓸 수 있는 압축 묶음을 재사용하는 방식을 설명합니다. 압축 묶음은 이력 데이터를 모아 전송하는 파일입니다. 가까운 서버에 같은 묶음을 남기는 캐시는, 같은 물건을 매번 새로 포장하는 수고를 줄입니다.

서로 다른 branch를 읽은 결과가 저장소 전체의 정확히 같은 순간을 보여 준다고 가정할 수는 없습니다. 같은 branch를 동시에 바꾸는 작업은 여전히 서로 조정해야 합니다. 이 방식은 필요한 코드 이력을 전달하면서, 관계없는 작업까지 한 줄로 기다리는 부담을 줄이는 선택입니다.

%% 코드 전달에서 바뀐 부분 · OpenAI가 설명한 Pando 구조를 단순화
flowchart TD
  A["개발자·AI 작업<br/>각 branch의 수정 전송"] --> B["Pando<br/>서로 다른 branch를 독립 처리"]
  B --> C["저장된 압축 묶음·캐시<br/>여러 읽기 요청에 재사용"]
  C --> D["다른 개발 환경·자동 시험<br/>필요한 코드 이력 받기"]

OpenAI는 시작부터 운영 적용까지 10주가 걸렸다고 설명합니다. 핵심 설계는 엔지니어 한 명이, 구현은 여러 AI 에이전트 팀이, 배포는 소수의 엔지니어가 맡았다고 밝혔습니다. 이를 ‘AI가 혼자 시스템을 완성했다’는 이야기로 줄이면 설계와 실제 운영 결정이 빠집니다.

회사는 기존 Git 동작과 맞는지 검사하는 시험과, 실행 상황을 재현해 순서가 꼬이는 오류를 찾는 시험을 설명합니다. 이것은 자사 개발 과정의 설명입니다. 본지가 Pando를 설치하거나 시험한 결과는 없습니다.

발표의 지표는 push 요청의 중앙 지연시간입니다. 중앙값은 측정값을 순서대로 놓았을 때 가운데 값으로, 오래 걸린 모든 요청을 대표하는 최대 시간이 아닙니다.

개발팀이 AI 작업을 늘릴 때는 어느 단계에서 기다리는지부터 나눠 볼 수 있습니다. 코드를 쓰는 시간, 전송 대기, 시험 대기, 검토 시간이 다르기 때문입니다. 저장소 전송이 빨라져도 시험이나 검토가 다음 대기 지점으로 남을 수 있습니다.

공개된 OpenAI의 Git 저장소는 Git 자체의 개선 작업입니다. 이를 내부 서비스 Pando 전체의 공개 소스나 누구나 지금 쓸 수 있는 호스팅 상품으로 읽으면 안 됩니다. 실제 웹서비스 제작에서 사람의 준비와 AI 작업을 나눈 HackerTube 해설도 이런 역할·완료 근거의 문제로 이어집니다.

아래는 발표의 약 80% 감소를 같은 기준으로 읽기 위한 환산입니다. 실제 초 단위 측정값이 아닙니다.