GitHub Actions에서 발생하는 플레이키 빌드의 실태와 자동 탐지 기법

초록

본 논문은 1,960개의 오픈소스 Java 프로젝트(총 4.86 백만 빌드)에서 GitHub Actions의 재실행 데이터를 분석해 플레이키 빌드의 빈도와 원인을 규명하고, 작업 수준에서 플레이키 실패를 예측하는 머신러닝 모델을 제시한다. 전체 빌드의 3.2%가 재실행되었으며, 그 중 67.73%가 플레이키 빌드로 확인돼 절반 이상의 프로젝트에 영향을 미친다. 15가지 실패 카테고리를 도출했으며, 플레이키 테스트, 네트워크 문제, 의존성 해결 오류가 가장 흔했다. 제안 모델은 기존 최첨단 방법 대비 F1 점수를 최대 20.3% 향상시킨다.

상세 분석

이 연구는 GitHub Actions의 재실행 메커니즘을 활용해 플레이키 빌드(재실행 후 결과가 변하는 빌드)를 정량적으로 파악하고, 그 원인을 체계적으로 분류한다. 프로젝트 선정 단계에서는 SEART GitHub Search Engine을 이용해 1,543,046개의 레포지토리 중 스타 150개·커밋 250개 이상인 Java 프로젝트를 추려 1,960개의 최종 대상 레포지토리를 확보하였다. 데이터 수집 기간은 2023년 9월부터 2024년 8월까지이며, 각 빌드와 작업(job)의 메타데이터와 로그를 JSON 형태로 저장해 4,861,768개의 빌드와 15,382,267개의 작업을 확보했다.

재실행 빌드는 run_attempt 필드가 1을 초과하는 경우로 정의했고, 플레이키 작업은 동일 빌드 내에서 성공과 실패가 모두 관찰된 작업으로 규정하였다. 이를 통해 전체 빌드 중 155,488건(3.2%)이 재실행되었으며, 그 중 105,000건 이상이 플레이키 작업을 포함해 플레이키 빌드로 분류되었다. 즉, 1,055개의 프로젝트(전체의 51.28%)가 플레이키 현상을 경험했다는 점은 CI 신뢰성에 심각한 위협이 있음을 시사한다.

실패 원인 분석에서는 로그에서 추출한 오류 메시지를 정규표현식 기반 패턴으로 일반화하고, 유사 패턴을 그룹화해 15개의 상위 카테고리를 정의하였다. 가장 빈번한 카테고리는 (1) 플레이키 테스트(예: 테스트 코드가 비결정적 상태에 의존) (2) 네트워크 이슈(다운로드 실패, 연결 타임아웃) (3) 의존성 해결 오류(패키지 버전 충돌, 레포지토리 접근 실패)였다. 이 외에도 파일 시스템 권한, 캐시 손상, 가상 머신 이미지 업데이트 등 다양한 환경적 요인이 포함되었다.

플레이키 실패를 사전에 탐지하기 위해 저자들은 작업 수준의 메타데이터(실행 시간, OS, 러너 이미지, 이전 성공/실패 기록 등)와 로그 기반 텍스트 특징을 결합한 머신러닝 파이프라인을 구축했다. 모델은 Gradient Boosting Decision Tree를 기본으로 하며, 클래스 불균형을 완화하기 위해 SMOTE와 비용 민감 학습을 적용하였다. 비교 대상은 최신 연구에서 제시한 베이스라인(특히 의존성 오류와 테스트 실패를 규칙 기반으로 탐지하는 방법)이며, 제안 모델은 F1 점수에서 최대 20.3% 향상을 달성했다. 이는 플레이키 빌드가 CI 파이프라인에 미치는 비용(대기 시간, 컴퓨팅 자원) 감소와 개발자 생산성 향상에 직접적인 기여를 의미한다.

한계점으로는 데이터가 Java 프로젝트에 국한돼 다른 언어(예: Python, JavaScript)에서의 플레이키 현상 일반화가 어려우며, GitHub Actions의 3개월 로그 보관 정책으로 인해 오래된 빌드 데이터가 누락될 가능성이 있다. 또한, 머신러닝 모델은 레이블링 품질에 크게 의존하므로, 자동 패턴 추출 과정에서 발생할 수 있는 오분류가 성능에 영향을 미칠 수 있다. 향후 연구에서는 다언어 환경 확대, 실시간 플레이키 탐지 플러그인 구현, 그리고 개발자 피드백을 통한 라벨링 자동화 방안을 모색할 필요가 있다.