50개 레포 Spring Boot 버전업을 안전하게 자동화하는 시스템에서, Planner가 Nexus 아티팩트 의존성 선언을 파싱해 레포 간 DAG를 구축하고 변경 유형에 따라 전파 방향을 결정하는 방법을 설명하는 시리즈 2편. 같은 의존 그래프 위에서도 Spring Boot는 upstream-first, Kotlin은 downstream-first로 전파 방향이 정반대로 뒤집힌다.
핵심 포인트- Planner의 역할: Nexus 아티팩트 선언 파싱 → 레포 간 의존 그래프(DAG) 구축 → 변경 성격 판별 → Kahn's algorithm 위상 정렬로 Wave 실행 계획 생성
- Spring Boot vs Kotlin 전파 방향 정반대: Spring Boot = upstream-first (API/BOM 의존 방향), Kotlin = downstream-first (바이트코드 메타데이터 하위 호환)
- Wave 기반 병렬 처리: 50개 레포를 일렬로 세우면 50번 대기 → 의존 구조를 읽으면 Wave 3개로 압축, Wave 2의 40개 이상 서비스 레포는 병렬 처리
- DAG 필수 이유: 순환 의존이 하나라도 있으면 "무엇부터 올려야 하는가"에 교착 상태 발생 → 위상 정렬(topological sort) 자체가 불가능
- 버전 관리 플러그인이 전제 조건: 모든 레포에 동일한 의존성 선언 방식 강제 → 파싱 로직 하나로 전체 그래프 구축 가능
- Blast radius 정량화: gradle-plugins 변경 = 50개 이상 레포에 영향, 리프 노드 = 해당 레포만 영향 → 리뷰 정책과 PR 생성에 직접 활용
상세 정리- 레포 간 의존성은 기존에 비가시적: 각 레포 build.gradle.kts에 분산된 버전 선언을 파싱해야 전체 지형도 복원 가능
- 핵심 4단계 의존 체인: gradle-plugins → commons-core(40+ 레포 의존) → backend-commons(40+ 레포 의존) → 서비스 레포들(리프 노드)
- Kotlin downstream-first 이유: 상위 Kotlin으로 컴파일된 라이브러리를 하위 Kotlin 클라이언트가 읽으면 메타데이터 호환성 문제 발생 가능 — 서비스 레포가 먼저 올려야 안전
- 알고리즘 핵심 아이디어: 그래프 구조는 그대로 두고, downstream-first일 때만 간선을 뒤집은 뒤 동일한 Kahn's algorithm 적용 → 정렬 로직 한 벌로 두 방향 처리
- PropagationDirection 3종: UPSTREAM_FIRST(Spring, 라이브러리 API), DOWNSTREAM_FIRST(Kotlin, JVM), PARALLEL(보안 패치 긴급 모드)
- Wave 구조 예시(Spring Boot): Wave 0 = commons-core / Wave 1 = backend-commons / Wave 2 = 40+ 서비스 레포(병렬)
- "꼭 기다려야 하는 순간"만 골라냄: 4단계 깊이의 그래프라도 Wave 3개로 압축, 최대 병렬화 달성
- 일관된 DSL의 중요성: 레포마다 버전 선언 방식이 달랐다면(version catalog/직접선언/변수/BOM) 파서 유지보수 비용이 레포 수에 비례해 증가
- 같은 한 줄 변경도 gradle-plugins vs 리프 노드는 위험 무게가 전혀 다름 → 그래프가 그 차이를 정량적으로 제공하는 유일한 근거
왜 읽나다중 레포 환경에서 변경 유형별로 전파 방향이 달라지는 이유를 이해하고, 의존 그래프 + 위상 정렬 + Wave 병렬 처리로 안전한 자동 마이그레이션 계획을 수립하는 아이디어를 배울 수 있다.
flex·
Twilio Engineering·
포스타입·