오픈스택 생태계의 교차 프로젝트 플라키 테스트 현상 분석

초록

본 연구는 OpenStack 649개 프로젝트에서 1,535개의 교차 프로젝트 플라키 테스트와 1,105개의 일관성 없는 플라키 테스트를 식별하고, 이 현상이 전체 프로젝트의 55%에 영향을 미쳐 리뷰 시간과 CI 비용을 크게 증가시킴을 보여준다. 주요 원인으로는 CI 레이스 컨디션, 빌드 설정 불일치, 의존성 충돌이 제시된다.

상세 분석

이 논문은 테스트 플라키성(flaky test)이 단일 프로젝트를 넘어 생태계 전체에 파급되는 현상을 최초로 정량화한다. 649개의 OpenStack 프로젝트(총 13 MLOC, 12 k 개발자)에서 1년간 Gerrit API와 CI 로그를 수집해 29 k개의 폐쇄 리뷰와 73 k개의 패치셋을 분석하였다. 교차 프로젝트 플라키성은 동일 테스트가 여러 프로젝트에서 동시에 불안정하게 동작하는 경우를 의미하며, 일관성 없는 플라키성은 동일 테스트가 일부 프로젝트에서는 안정적이지만 다른 프로젝트에서는 플라키하게 나타나는 현상을 말한다.

연구 결과는 다음과 같다. 첫째, 교차 프로젝트 플라키 테스트는 전체 프로젝트의 55%에 존재하며, 연도별 증가 추세를 보인다. 이는 플라키성이 누적되어 생태계 전반에 부정적 영향을 확대한다는 점을 시사한다. 둘째, 테스트 스코프별 분석에서 유닛 테스트가 70%에 달하는 높은 비율로 교차 플라키성을 보였으며, API 테스트(64%)와 시나리오 테스트(41%)도 상당히 높은 전파성을 나타냈다. 이는 전통적으로 격리된 것으로 여겨졌던 유닛 테스트조차도 공유 라이브러리, 공통 CI 잡 정의, 그리고 동일한 가상 환경에 의존함으로써 다른 프로젝트에 영향을 미칠 수 있음을 보여준다. 셋째, 일관성 없는 플라키성의 근본 원인으로는 CI 파이프라인 내 레이스 컨디션이 89%를 차지했고, 빌드 설정 불일치와 의존성 관리 문제는 각각 21%씩 기여하였다. 이러한 원인은 동일 코드베이스라도 프로젝트마다 서로 다른 환경 변수, 파이프라인 트리거 시점, 혹은 라이브러리 버전 차이로 인해 테스트 결과가 달라지는 상황을 만든다.

정성적 설문(15명) 결과, 개발자들은 플라키 테스트가 리뷰 지연과 리소스 낭비를 초래한다는 점에 동의했으며, “재검사(recheck)만으로는 근본 해결이 어려우니 초기 단계에서 플라키 테스트를 식별·제거”하고, “CI 설정 표준화와 의존성 버전 고정”을 제안하였다. 논문은 또한 재현성을 위해 원시 데이터와 라벨링, 설문 응답, 분석 스크립트를 공개함으로써 후속 연구의 기반을 마련한다.

이 연구는 플라키 테스트가 단순히 개별 프로젝트의 품질 문제를 넘어, 복잡한 오픈소스 생태계에서 협업 효율성과 인프라 비용에 직접적인 영향을 미친다는 중요한 교훈을 제공한다. 따라서 테스트 격리, 의존성 관리 자동화, CI 파이프라인의 동시성 제어와 같은 시스템 수준의 방어 메커니즘이 필요함을 강조한다.