AI Writes Code Faster Than Uber Can Merge It - Preetam Dwivedi & Manjari Akella, Uber

한 줄 핵심

Uber는 AI로 PR 생성 속도가 급증하자 merge queue를 더 공격적으로 최적화하고, 일부 검증을 post-merge로 옮기는 하이브리드 방식으로 trunk 안정성과 처리량을 동시에 끌어올렸다.

시간별 요약

1. 0:04
   문제 설정과 merge queue의 기본 원리 대규모 monorepo에서는 개별 PR이 CI에서 green이어도 다른 PR과 합쳐진 뒤 trunk가 깨질 수 있어, 여러 변경을 순서와 조합까지 고려해 머지하는 merge queue가 필요하다. Uber는 target analysis, probabilistic speculation, large change bypass로 병목을 줄이며 trunk를 green으로 유지해 왔다.
2. 6:01
   AI로 인한 폭증과 기존 방식의 한계 AI-generated change가 늘면서 요청량은 90건/시간에서 130건/시간으로 약 44% 증가했고, P95 land time은 30분에서 3~4시간으로 악화됐다. trunk는 계속 green이었지만, 개발자는 머지 대기 때문에 생산성이 크게 떨어졌다.
3. 7:01
   처리량을 늘리기 위한 세 가지 개입 admission gating으로 peak hour의 expensive change를 차단해 20% 이상 throughput을 올리고, deferrals로 거절 대신 재시도 대기열에 보관해 개발자 경험을 개선했다. 이어 conflict relaxation에서 Jaccard scoring으로 충돌 강도를 정량화해 약한 간선을 제거함으로써 병렬성을 회복했다.
4. 18:01
   검증을 나중으로 미루는 대신 사후 보강 충돌 완화를 과감하게 적용한 결과 처리량은 최대 250건/시간 수준까지 늘었지만, 일부 조합은 사전 검증되지 않은 채 trunk에 들어가게 됐다. 이를 보완하기 위해 post-merge validation 시스템인 stowpipe가 landed commit을 지속 검증하고, 실패 시 on-call이 revert 또는 fix를 수행하는 구조를 만들었다.
5. 24:01
   성과와 다음 단계 이 하이브리드 접근으로 peak 시 약 300 lands/hour와 30분 P95 land time을 달성하며, January 대비 233% 수준의 개선을 얻었다. 다음 과제는 관련 변경 배치, service 단위로 더 세분화된 green 판정, 그리고 broken trunk 복구 자동화다.

실무 인사이트

• AI로 변경 생성 속도가 빨라질수록, 병목은 코드 작성이 아니라 머지와 검증이라는 사실을 전제로 워크플로를 다시 설계해야 한다.
• 처리량을 늘리려면 모든 변경을 동일하게 다루기보다, 비용이 큰 변경만 골라 더 강하게 제어하는 정책이 효과적이다.
• 사전 검증을 전부 고집하기보다 일부를 post-merge로 옮기고, 대신 사후 검증·복구 체계를 자동화하는 하이브리드 전략이 현실적인 균형점이 될 수 있다.