CI/CD 병목 해소, N3R + ARC로 안드로이드 빌드 최적화

사내망 환경에서 고정 수 Runner 풀은 안드로이드(Android) 빌드의 리소스 급증 패턴을 감당하지 못한다. 특히 멀티 모듈(Multi-module) 프로젝트에서는 Gradle의 의존성 분석과 컴파일 시간이 크게 증가하여, 동시에 여러 빌드 요청이 들어올 경우 대기열 폭주(Queue Stampede) 현상이 발생한다. 이를 해결하기 위해 N3R 기반의 동적 Pod 할당(Dynamic Pod Allocation) 아키텍처를 도입하여, 빌드 요청량에 따라 Runner 인스턴스를 탄력적으로 증감시키는 자체 오토스케일러(Auto-scaler)를 구축했다. 이를 통해 리소스 낭비를 줄이면서도 피크 시나리오에서도 안정적인 빌드 처리량을 확보할 수 있었다.

본 문서에서는 Gradle 빌드 캐시를 최적화하기 위해 3단계 캐시 전략을 제시한다. 첫 번째 계층은 로컬 캐시로 빌드 산출물을 노드 단위로 저장하고, 두 번째 계층은 공유 캐시로 Nexus Proxy를 통해 조직 내 공통 의존성을 재사용하며, 세 번째 계층은 원격 캐시로 외부 Maven Central 접근을 최소화한다. 특히 Diff-aware 테스트를 도입하여 코드 변경분만 대상으로 테스트를 실행함으로써, 전체 테스트 스위트 실행에 따른 시간을 크게 단축했다. 이러한 다층 캐시 전략은 네트워크 대역폭 비용 절감과 빌드 시간 단축에 직접적으로 기여한다.

공식 GitHub Actions Runner Controller(ARC)는 Org-level 인프라 전환이 완료되지 않은 상태에서는 도입이 어렵다는 제약이 있다. 특히 사내망/아웃바운드 차단 환경에서는 GitHub-hosted Runner 사용이 불가능하므로, Self-hosted Runner 운영이 필수적이다. 본 세션에서는 이러한 제약 속에서 N3R을 선택한 이유를 설명한다. N3R은 네이버 내부에서 개발된 Pod 오케스트레이션 도구로, Kubernetes 환경에서의 Pod 생명주기 관리(Pod Lifecycle Management)와 오토스케일링 정책(Auto-scaling Policy)을 세밀하게 제어할 수 있다. 특히 Pod 한살이(Pod Lifecycle) 관리 기능을 통해 빌드 완료 후 즉각 리소스 해제(Immediate Resource Release)를 가능하게 하여, 비용 최적화에 기여한다.

사내망 환경에서는 외부 Maven Central 및 Google Maven Repository에 접근할 수 없기 때문에, 내부 Nexus Proxy를 통해 의존성을 캐싱하고 분배하는 구조를 채택했습니다. 이를 통해 외부 네트워크 호출을 최소화하고, 중복 다운로드를 방지하여 네트워크 병목 현상을 해소했습니다. 또한 Gradle의 의존성 메타데이터와 빌드 산출물을 빠르게 전달하기 위해 Nginx WebDAV를 활용한 스토리지 계층을 구축했습니다. 이 두 시스템을 함께 사용하면 대규모 안드로이드 프로젝트의 의존성 해결 시간을 크게 단축시킬 수 있습니다.

본문에서는 4축 전환 전략의 축별 기여도를 분석했다. 동적 리소스 할당은 리소스 활용률 60% 향상으로 기여했으며, 3-Layer Cache는 빌드 시간 40% 단축을 달성했다. Diff-aware 테스트는 테스트 실행 시간 50% 이상을 줄였고, 자체 오토스케일러는 피크 시 리소스 비용 35%를 절감했다. 이를 통해 CI/CD 파이프라인 최적화가 단순히 개발 경험 개선에 그치지 않고, 인프라 비용 절감까지 통해 직접적인 비즈니스 가치를 만들어낸다는 걸 알 수 있다.