flex의 Evergreen 파이프라인 4번째 편으로, 의존성 변경을 50개 이상 레포에 실제로 전파하는 Distributer 컴포넌트를 다룬다. Updater가 코드를 변환한 이후, Distributer가 PR 생성 → CI 검증 → 리뷰 → 머지까지의 과정을 레포 간 의존 순서를 지키며 자동화하는 방법을 설명한다.
핵심 포인트- Wave 기반 전파 모델: Planner가 위상 정렬(Topological Sort)로 의존 순서 정의 → Distributer가 "현재 Wave의 모든 PR이 머지되어야 다음 Wave PR을 생성" 원칙 강제
- 자동 머지 조건: CI 통과 + 승인 + Wave 선행 조건 + 충돌 없음 → 4가지 조건 모두 충족 시에만 자동 머지
- Flaky 테스트 구분: 30일 이력 분석으로 진짜 실패와 간헐적 오류를 구분 → 자동화 불필요 재시도 방지
- PR 구조 분리: 결정론적 recipe 변경과 AI 기반 수정을 구분해 리뷰어가 고위험 영역에 집중
- 실측 결과: Wave 2(40개 이상 독립 서비스)에서 42개 중 39개 자동 머지, 3개만 수동 개입 필요
- Escalation 프로토콜: 자동화 불가 시 "어떤 결정이 필요한가"를 특정해 에스컬레이션 — 전체 변경 검토가 아닌 타겟 판단 포인트
상세 정리- Wave 전파 원리: 상위 레포가 새 버전을 퍼블리시하기 전에 하위 레포가 참조하면 빌드 깨짐 → Wave 직렬화로 방지
- Wave 1 예시: 공통 라이브러리(단일 레포, 빠름) → Wave 2: 해당 라이브러리를 의존하는 40개 서비스(병렬 실행)
- Wave 2 병렬 처리: 같은 Wave 내 독립 서비스들은 동시에 PR 생성·CI·머지 진행 → 순차 대비 시간 대폭 단축
- CI 추적: 모든 레포 상태를 중앙에서 폴링, 각 PR의 CI 상태를 Wave 진행 판단에 반영
- Flaky 기준: 최근 30일 동일 테스트의 실패 패턴 분석 → 재현율 낮으면 Flaky로 분류 후 재시도 허용
- 자동 머지 안전장치: 4가지 조건 중 하나라도 미충족 시 자동 머지 중단 → 인간 개입 요청
- PR 리뷰 최소화: recipe 변경 부분(코드 자동 변환)은 diff만 확인, AI 변경 부분은 집중 리뷰 안내
- 수동 개입 3건 원인: 테스트 로직 변경 필요 / 의존성 호환 이슈 / 빌드 스크립트 수정 필요
- 결과 리포트: 자동 성공/수동 개입/개선 기회를 정량 수치로 제공 → 다음 마이그레이션에 활용
왜 읽나50개 레포 전반에 의존성 업그레이드를 자동 전파하는 시스템을 구축할 때, Wave 직렬화와 Flaky 테스트 구분으로 자동화 신뢰도를 높이는 설계 패턴을 구체적으로 확인할 수 있다.