챕터별 상세
문제 정의: 빌드 무게와 고정 Runner Pool의 한계
안드로이드 빌드는 멀티 모듈, Kotlin 컴파일, R8/Shrinker 등으로 인해 리소스 소모가 크다. PR 및 야간 빌드 등 높은 빈도로 인해 고정된 Runner Pool 환경에서는 유휴 리소스 낭비와 대기 시간 문제가 발생한다. 이를 해결하기 위해 동적 할당이 가능한 인프라로의 전환이 필요했다.
Runner Pool은 CI/CD 파이프라인에서 작업을 수행하는 서버 그룹을 의미한다.
다층 전략: 4축 동시 전환과 한 Pod 구성 방어
빌드 속도 개선을 위해 네트워크, 캐시, 테스트, 오케스트레이션의 4개 레이어를 동시에 최적화했다. 특히 비용 절감을 위해 여러 서버를 하나의 Pod에 구성하는 방식을 채택했다. 이는 리소스 공유를 통한 비용 효율성을 극대화하기 위한 전략이다.
네트워크 최적화: Nexus Proxy와 Nginx WebDAV
사내망 환경에서 외부 의존성 접근 문제를 해결하기 위해 Nexus Proxy를 도입하여 17개 저장소를 1개 URL로 통합했다. 또한 Gradle Remote Cache를 위해 Nginx WebDAV를 구축하여 빌드 결과물을 공유했다. 이를 통해 외부 의존성 다운로드 시간을 단축했다.
WebDAV는 웹 서버를 파일 서버처럼 사용할 수 있게 해주는 프로토콜이다.
캐시 및 테스트 최적화: 3-Layer Cache와 Diff-aware 테스트
Pod Local, MinIO 기반 Gradle Remote Cache, WebDAV 기반 Remote Cache로 구성된 3-Layer Cache를 구축했다. 또한 모든 테스트를 수행하는 대신 변경된 모듈만 테스트하는 Diff-aware 테스트를 적용하여 빌드 시간을 단축했다. 이를 통해 불필요한 테스트 실행을 방지했다.
Diff-aware 테스트는 코드 변경 사항을 분석하여 영향받은 모듈만 테스트하는 기법이다.
오케스트레이션: N3R과 자체 Autoscaler
GitHub ARC의 제약을 극복하기 위해 N3R과 FastAPI 기반 자체 Autoscaler를 구축했다. 이를 통해 Pod의 생명주기를 직접 관리하며 리소스를 동적으로 할당하고 회수한다. Pod가 생성되고 러너가 등록되는 시간을 14초 내외로 단축했다.
ARC(Actions Runner Controller)는 쿠버네티스에서 GitHub Actions 러너를 관리하는 도구이다.
결과 및 회고
시스템 도입 후 러너 큐 대기 시간은 0으로 수렴했으며, 빌드 p50 시간은 9.7분으로 단축되었다. 비용 측면에서는 기존 대비 97.7% 절감 효과를 거두었다. 운영 과정에서 발생한 Pod 랜덤 종료, Webhook 부하 등의 문제를 해결하며 시스템을 안정화했다.
언급된 리소스
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 06. 09.수집 2026. 06. 09.출처 타입 YOUTUBE
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
