[Paper] GitHub Actions 언어에 대하여: 사용, 진화, 그리고 워크플로우 신뢰성

Source: arXiv - 2605.26825v1

Overview

GitHub Actions는 CI/CD 파이프라인을 자동화하는 사실상의 표준이 되었지만, 여전히 많은 개발자들이 불안정하거나 유지 관리가 어려운 워크플로 파일과 씨름하고 있습니다. 이 논문은 지금까지 가장 큰 실증 연구로, 6년 동안 49 K 저장소에서 260 K 워크플로를 조사하여 언어 구성 요소가 어떻게 진화하고 신뢰성 및 유지 관리성에 어떤 영향을 미치는지 밝힙니다.

주요 기여

• 197개의 개별 GitHub Actions 언어 구성 요소를 14개의 기능적 특징(예: 트리거, 작업 매트릭스, 환경 변수)으로 그룹화한 포괄적인 분류 체계.
• 2019년 7월부터 2025년 8월까지 워크플로우 진화를 장기적으로 분석하여 채택 추세와 “성숙도” 패턴을 밝혀냄.
• 신뢰성 상관관계를 제시하여 규모가 크고 기능이 풍부한 워크플로우가 실패율이 현저히 높다는 점을 입증.
• 유지보수성 신호를 식별, 동적 matrix나 복잡한 if 표현식과 같은 특정 구성 요소가 유지보수 노력 증가와 연관됨을 보여줌.
• 실무 체크리스트를 제공, 개발자와 툴링 팀이 워크플로우 건강성을 개선할 때 집중해야 할 고위험 기능들을 제시.

방법론

1. 데이터 수집 – 저자들은 공개 GitHub 저장소를 크롤링하고, 최소 하나의 .github/workflows/*.yml 파일을 포함하는 저장소만 필터링했습니다. 이를 통해 49 K 프로젝트에서 260 K 워크플로 파일을 확보했습니다.
2. 구성 요소 추출 – 맞춤 파서를 사용해 모든 언어 요소(키워드, 액션, 표현식)를 식별하고, 이를 14개의 사전 정의된 특징 카테고리 중 하나에 매핑했습니다.
3. 시간 슬라이싱 – 워크플로를 커밋 날짜별로 구분해 시간이 흐름에 따라 구성 요소가 도입, 성장, 혹은 퇴출되는 과정을 추적했습니다.
4. 신뢰도 측정 – GitHub 공개 API에서 수집한 실행 로그를 집계해 워크플로별 및 특징 사용별 실패율을 계산했습니다.
5. 유지보수성 대리 지표 – 연구에서는 라인 수, 잡 수, 중첩된 if/needs 문장의 깊이, 파일 변경 빈도 등을 유지보수 노력의 대리 변수로 사용했습니다.
6. 통계 분석 – 상관관계 및 회귀 모델을 적용해 특징 사용과 실패율 및 변경 빈도 지표 간의 관계를 정량화했습니다.

결과 및 발견

• 왜곡된 사용 – 197개의 구문 중 약 12 %에 해당하는 아주 작은 부분이 전체 발생 횟수의 > 80 %를 차지한다; 가장 흔한 것은 on: push/pull_request, runs-on, 그리고 uses:(액션 호출)이다.
• 기능 집중 – “트리거”와 “작업 정의” 기능이 주를 이루며, strategy.matrix, needs, environment와 같은 고급 기능은 워크플로의 < 15 %에서 사용된다.
• 성장 패턴 – permissions, concurrency 등 최신 구문의 도입 이후 채택이 가속화되었지만 초기 도입자가 포화되면서 정체되었다.
• 신뢰성 패널티 – 작업이 > 5 개이거나 동적 매트릭스 전략을 사용하는 워크플로는 최소 워크플로에 비해 실패 확률이 1.8× 높다.
• 유지보수 비용 – 월 2 회 이상 변경되는 파일은 복잡한 if 표현식과 중첩된 needs 체인을 포함하는 경우가 많아 이러한 구문이 변경 빈도를 높이는 것으로 보인다.
• 위험 핫스팟 – 연구에서는 strategy.matrix, 쉘 보간이 포함된 if 조건문, 그리고 사용자 정의 Docker 컨테이너 사양을 신뢰성 사고와 가장 강하게 연관된 상위 세 가지 기능으로 지정한다.

실용적 시사점

• For developers – 워크플로를 단순하게 유지하세요: 작업 수를 제한하고, 과도하게 동적인 매트릭스를 피하며, 정적 needs 그래프를 선호합니다. 복잡성이 불가피할 경우, 위험한 섹션을 별도의 재사용 가능한 워크플로 파일로 분리하세요.
• For CI/CD tooling vendors – 식별된 고위험 구조를 드러내고, 리팩터링을 제안하며, 모범 사례 템플릿을 강제하는 린터 또는 정적 분석 플러그인을 구축하세요.
• For platform engineers – 가장 많이 사용되는 구조(트리거, runs-on, 액션 버전 관리)의 안정성 향상을 우선시하고, “위험 구역”(매트릭스, 동시성) 주변에 더 명확한 문서를 제공하세요.
• For DevOps teams – 논문의 체크리스트를 사용해 기존 파이프라인을 감사하고, 식별된 임계값을 초과하는 워크플로(예: > 5개의 작업, 깊은 if 중첩)의 리팩터링을 우선순위에 두세요.
• For open‑source maintainers – 새로운 워크플로를 기여할 때, 하위 사용자들의 CI 파손 가능성을 줄이기 위해 권장되는 최소 기능 세트를 채택하세요.

제한 사항 및 향후 작업

• Public‑repo bias – 데이터셋은 비공개 저장소를 제외하며, 이는 다른 사용 패턴(예: 더 많은 기업 전용 구조)을 가질 수 있습니다.
• Failure definition – 연구에서는 0이 아닌 모든 종료 코드를 실패로 간주하며, 플레이키 테스트, 인프라 문제, 실제 버그를 구분하지 않습니다.
• Maintainability proxies – 코드 라인 수와 변경 빈도는 개발자 노력의 불완전한 대리 지표이며, 정성적 설문조사가 결과를 풍부하게 할 수 있습니다.
• Future directions – 분석을 비공개/기업용 GitHub 설치로 확장하고, 개발자 감성(이슈 댓글, PR 토론)을 포함하며, 식별된 위험 특징을 기반으로 자동 복구 도구를 구축하는 것.

저자

• Aref Talebzadeh Bardsiri
• Alexandre Decan
• Tom Mens

논문 정보

• arXiv ID: 2605.26825v1
• 분류: cs.SE
• 출판일: 2026년 5월 26일
• PDF: PDF 다운로드