AI가 코드를 대신 짜면, 왜 Git과 CI가 먼저 바빠질까?
난이도: 중급 — Git의 브랜치와 코드 변경 요청(PR)을 알고 있으면 읽기 쉽습니다.
세 줄 요약
- OpenAI는 2026년 11월 2일, Codex가 늘린 동시 개발 작업을 처리하기 위해 Git 저장소 백엔드 Pando를 구축하고 자사 모노레포에 적용했다고 발표했습니다.[1]
- 회사가 설명한 문제는 코드 작성만이 아닙니다. 브랜치·push·merge가 늘고, 각 push가 여러 CI 작업의 fetch를 일으키면서 저장소를 읽고 쓰는 부담도 함께 커졌습니다.[1]
- 분석: 작은 팀이 가져올 교훈은 “우리도 Git 서버를 새로 만들자”가 아닙니다. 코드 생성 이후의 대기 시간을 나눠 측정하고, 검증 용량에 맞게 동시 작업과 통합 방식을 조절하자는 것입니다.
자료 확인: 2026년 11월 5일(KST). OpenAI의 기술 발표와 GitHub 공식 문서를 바탕으로 작성했습니다. Pando의 성능 수치는 회사 자체 발표이며 이 글에서 독립 재현하지 않았습니다. GitHub 문서는 기능 동작의 근거일 뿐, Pando 성과를 교차 입증하는 자료가 아닙니다. 아래 실무 제안은 별도 표시한 분석이며 직접 실험한 리뷰가 아닙니다.
1. 코드가 빨리 나와도, 통합이 빨라지는 것은 아닙니다
OpenAI는 Codex 덕분에 엔지니어가 더 많은 작업을 병렬로 진행하게 됐으며, 그 결과 개발 환경·연구 작업·CI에서 브랜치와 push, merge, fetch와 clone이 늘었다고 설명했습니다.[1] 특히 한 엔지니어가 여러 변경을 동시에 CI에 올리고, 한 번의 push가 같은 commit을 가져오는 여러 작업을 촉발한다는 점을 강조했습니다.[1]
분석: 부하는 인원수보다 동시에 제출되는 변경의 수와 변경당 검증 작업량으로 살펴볼 필요가 있습니다. CI는 빌드·테스트 등의 자동 검증을 뜻하며, 다음 단계들을 나눠 확인하는 방식을 제안합니다.
변경 작성 → push → 검증 작업 배정 → checkout·환경 준비 → 빌드·테스트 → 리뷰·통합 → 배포 확인
이는 실무 분해이지 Pando의 전체 처리 단계를 재현한 도식은 아닙니다. 작성 시간 단축만으로 나머지 단계의 개선까지 판단할 수는 없습니다.
2. Pando는 Git을 버린 것이 아니라, 뒤쪽을 바꿨습니다
OpenAI가 소개한 Pando는 Git 저장소를 제공하는 새로운 백엔드입니다.[1] 회사는 Git 프로토콜과 클라이언트의 호환성을 유지하면서, 여러 브랜치에 대한 동시 쓰기와 많은 클라이언트에 대한 읽기 처리량을 높이는 것을 목표로 삼았다고 설명했습니다.[1]
발표에서 눈여겨볼 설계는 두 가지입니다.
쓰기: 관련 없는 브랜치끼리 덜 기다리게 합니다
Pando는 각 브랜치의 갱신을 독립적으로 조정해, 서로 관련 없는 브랜치의 업데이트가 병렬로 진행될 수 있게 설계됐습니다.[1] 개별 ref의 갱신 순서는 보장하지만, 여러 브랜치를 읽은 결과가 저장소 전체의 동일한 한 시점을 나타낸다고 가정할 수는 없습니다.[1]
분석: 모든 잠금을 없앤 것이 아니라 순서 보장과 독립 실행의 경계를 정한 것입니다. 브랜치에 빨리 push하는 것과 변경을 안전하게 합치는 것은 별개 문제입니다.
읽기: 같은 데이터를 매번 새로 포장하지 않습니다
Git의 packfile은 여러 객체를 압축해 담는 형식입니다.[1] Pando는 각 클라이언트의 fetch마다 별도 packfile을 만드는 대신 packfile을 재사용해, 같은 바이트를 많은 클라이언트에 적은 서버 연산으로 제공하는 방식을 택했습니다.[1] 그 대신 클라이언트가 이미 가진 객체를 일부 다시 내려받을 수 있다는 절충이 있습니다.[1]
분석: 전송량 최소화보다 결과물 재사용에 무게를 둔 절충으로 읽을 수 있습니다. OpenAI의 선택이 작은 저장소에도 유리하다는 결론은 아닙니다.
3. ‘push 지연 약 80% 감소’를 CI 전체 속도로 읽으면 안 됩니다
OpenAI는 Pando 전환으로 merge 신뢰성이 개선됐으며 push 지연의 중앙값이 거의 80% 줄었다고 밝혔습니다.[1] 이는 회사의 운영 결과 주장이지, 외부에서 같은 조건으로 재현한 벤치마크 결과는 아닙니다.
측정 범위를 나누면 과장을 피할 수 있습니다.
| 발표에서 확인되는 내용 | 여기서 바로 결론 내릴 수 없는 내용 |
|---|---|
| push 지연 중앙값이 거의 80% 감소했다는 회사 설명[1] | 빌드·테스트·리뷰·배포까지 포함한 전체 개발 시간이 같은 비율로 줄었다는 결론 |
| merge 신뢰성이 개선됐다는 회사 설명[1] | 생성된 코드의 기능적 정확성이나 보안성이 자동 보장됐다는 결론 |
| packfile 재사용으로 다수의 읽기를 처리한다는 설계 설명[1] | 모든 크기의 저장소에서 운영비와 성능이 더 좋다는 결론 |
| 원문 비교 시뮬레이션이 교육용 합성 모델이라는 명시[1] | 시뮬레이션을 실제 운영 벤치마크로 취급하는 결론 |
원문은 비교 시뮬레이션을 운영 벤치마크가 아닌 교육용 합성 모델이라고 명시하고, 그 안의 push-to-fetch 지표에는 빌드와 테스트를 포함하지 않는다고 설명했습니다.[1] 운영 성과 주장과 시뮬레이션의 조건을 섞지 않는 것이 중요합니다.
분석: 이 발표는 CI의 저장소 읽기 부하 증가를 설명하지만, 작은 팀의 대기 시간이나 전체 테스트 개선 폭까지 입증하지는 않습니다.
4. 에이전트가 구현해도, 검증 설계는 사라지지 않았습니다
OpenAI는 Pando가 착수부터 운영 적용까지 10주 걸렸고, 핵심을 한 엔지니어가 설계하고 에이전트 팀이 구현했으며 소수의 엔지니어가 배포했다고 설명했습니다.[1] 같은 발표에는 표준 Git 동작과 비교하는 적합성 테스트, 불변조건과 경쟁 상태를 확인하기 위한 결정론적 시뮬레이션 테스트도 등장합니다.[1]
또한 처음부터 기존 시스템을 끊어낸 것이 아니라, 읽기·쓰기 프록시로 두 시스템을 동기화하면서 트래픽을 옮겼다고 밝혔습니다.[1] 구현 속도에 관한 이야기와 호환성 검증·이행 방식에 관한 이야기가 함께 있는 셈입니다.
분석: “AI가 만들었으니 검사가 줄어든다”보다 산출물을 받아들일 조건이 무엇인가를 물어야 합니다. 기존 동작과 동시 갱신의 불변조건, 변경별 검증 결과, 안전한 이행 기준을 먼저 정의하자는 제안입니다.
5. 작은 팀은 무엇부터 바꾸면 좋을까요?
이 절은 분석과 제안입니다. 아래 항목을 적용해 성능 향상을 직접 확인한 실험 결과는 아닙니다.
먼저, 기다리는 위치부터 찾습니다
저장소를 가져오는 데 시간이 많이 걸리는지, 실행할 CI 작업이 순서를 기다리는지, 테스트 자체가 긴지, 사람이 변경을 검토하는 데 밀리는지를 나눠 기록하는 편이 좋습니다. checkout이 빠른데 리뷰가 밀린다면 저장소 백엔드를 바꾸는 것이 첫 해결책이 되기는 어렵습니다.
동시 에이전트 수보다, 동시에 통합할 변경 수를 관리합니다
변경의 책임 범위를 작게 나누고, 동일 파일·설정·공유 인터페이스를 여러 작업이 동시에 수정하는지 먼저 살펴보는 방식입니다. 모든 작업을 직렬화하자는 뜻은 아닙니다. 작성은 병렬로 하되, 충돌하는 변경의 통합 순서와 최종 검증 책임은 명확히 두자는 제안입니다.
오래된 검증을 취소할 때도 목적을 구분합니다
GitHub Actions는 concurrency group으로 동시 실행을 제어할 수 있고, cancel-in-progress: true로 같은 그룹에서 실행 중인 작업도 취소할 수 있다고 안내합니다.[2] 기본 대기 정책에서는 같은 그룹의 기존 pending 작업이 새 작업으로 대체될 수도 있습니다.[2]
분석: 오래된 개발 브랜치 검증을 취소하는 방식은 검토할 수 있지만, 배포·데이터 이행에 같은 설정을 무심코 복사해서는 안 됩니다. 취소를 성공으로 집계하지 말고 끝까지 검증된 commit을 남겨야 합니다. 실제 설정 적용은 하지 않았습니다.
개별 PR 통과와 합친 상태의 통과를 구분합니다
GitHub의 merge queue는 최신 대상 브랜치와 대기열 앞선 PR의 변경을 함께 적용했을 때 필수 상태 검사를 통과하는지 확인하는 방식입니다.[3] GitHub Actions를 사용하는 경우에는 merge_group 이벤트를 처리하도록 CI 구성을 맞춰야 하며, 이 기능의 제공 범위에도 조직 소유 저장소와 요금제 조건이 있습니다.[3]
분석: 모든 팀에 merge queue를 권하는 것은 아닙니다. 이용 조건과 CI 지원을 확인하고, 통합량이 적다면 순차 통합과 재검증부터 고려할 수 있습니다. 핵심은 검사한 조합과 실제 합칠 조합의 일치입니다.
6. ‘더 많이 생성했는가’ 대신 살펴볼 기록
분석: 개선 여부를 판단할 때는 다음 기록을 함께 보는 방식을 제안합니다. 고정 합격선이나 업계 평균을 제시하는 표는 아닙니다.
| 기록할 항목 | 확인하려는 질문 |
|---|---|
| 변경 준비부터 CI 시작까지의 대기 | 실행 용량 부족인지, 제출량 급증인지 구분할 수 있습니까? |
| checkout·환경 준비·빌드·테스트의 단계별 시간 | Git 전송과 테스트 실행 중 어디가 느립니까? |
| 검증 완료 commit과 실제 통합 commit | 오래된 검증 결과로 새 변경을 승인하지 않았습니까? |
| 취소·실패·재실행의 원인 | 낭비를 줄인 것인지, 실패를 숨긴 것인지 설명할 수 있습니까? |
| 리뷰 대기와 통합 후 결함 | 생성량 증가가 검토 부담이나 품질 저하로 이동하지 않았습니까? |
비교할 때는 변경의 크기, 실행 환경, 테스트 범위가 달라졌는지도 함께 남겨야 합니다. 검사를 줄여 얻은 짧은 실행 시간을 같은 품질 조건의 개선으로 취급하지 않는 것이 핵심입니다.
결론: 코드 생성 다음의 길도 넓어야 합니다
Pando 발표에서 확인할 수 있는 것은 OpenAI가 자사의 대규모 병렬 개발을 위해 Git 호환 백엔드를 설계하고 운영 결과를 공개했다는 점입니다.[1] 그 결과의 독립 재현, 작은 팀에 대한 비용 대비 효과, 전체 CI·배포 시간 개선 폭은 이 글에서 확인하지 않았습니다.
분석: 작은 팀이 먼저 가져올 것은 Pando라는 인프라보다 문제를 나누는 관점입니다. “얼마나 빨리 생성했습니까?” 다음에 “어느 버전을 무엇으로 검증하고, 어떤 조합으로 통합했습니까?”를 물어야 합니다. 생성량 증가와 검증된 변경의 안전한 전달은 같은 목표가 아닙니다.
Sources
[1] OpenAI · Scaling Git at OpenAI
[2] GitHub Docs · Control the concurrency of workflows and jobs