💻 computer science

Beyond the YAML File: Understanding Real-World GitHub Actions Workflow Adoption

이 논문은 25 만 건 이상의 GitHub Actions 실행 기록과 21 개 리포지토리의 심층 분석을 통해 개발자의 워크플로우 실패 대응 패턴, 사용 강도와 실패율 간의 상관관계, 그리고 구성 파일과 실제 사용 사이의 격차를 규명하고 프로젝트 특성과 활용 패턴 간의 관계를 탐구합니다.

원저자: Ali Khatami, Carolin Brandt, Andy Zaidman

게시일 2026-04-21

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Ali Khatami, Carolin Brandt, Andy Zaidman

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

이 논문은 **"GitHub Actions(깃허브 액션스)"**라는 도구가 실제로 어떻게 쓰이고 있는지, 특히 실수가 났을 때 개발자들이 어떻게 반응하는지를 조사한 연구입니다.

기존 연구들은 대부분 "설정 파일 (YAML) 이 있나?"만 확인했지만, 이 연구는 **"실제로 실행 기록이 남았나? 그리고 실패했을 때 사람들이 뭐라고 했나?"**를 파고들었습니다.

이 복잡한 내용을 일상적인 비유로 쉽게 설명해 드릴게요.

🏭 비유: 거대한 자동화 공장 (GitHub Actions)

개발 프로젝트는 거대한 공장을 운영한다고 상상해 보세요.

GitHub Actions는 공장에 설치된 자동화 로봇들입니다.
개발자가 코드를 수정하면, 이 로봇들이 자동으로 "이게 잘 작동할까? 버그는 없을까?"를 검사합니다.
과거 연구자들은 **"공장 설계도 (설정 파일) 가 있나?"**만 확인했습니다. 하지만 설계도가 있어도 로봇이 고장 나거나, 아예 작동 안 하고 있을 수도 있죠.

이 연구팀은 설계도를 버리고, **실제 로봇들의 작동 기록 (로그)**을 25 만 건이나 분석했습니다.

🔍 주요 발견 3 가지

1. "바쁠수록 잘 돌아간다" (활용도 vs 실패율)

현상: 로봇을 자주 쓰는 공장일수록 (활발한 프로젝트), 고장 나는 비율이 오히려 낮아졌습니다.
이유: 로봇을 자주 쓰면 개발자들이 고장 난 부분을 바로바로 고치고, 로봇이 더 똑똑해지기 때문입니다.
반면: 로봇을 거의 안 쓰거나, 가끔씩만 켜는 공장은 고장 나면 그냥 방치하거나, "아, 또 고장 났네" 하며 실패율이 매우 들쑥날쑥했습니다.
비유: 매일 아침마다 차를 타고 출근하는 사람은 차 고장 나면 바로 정비소에 가지만, 일 년에 한 번만 차를 끄는 사람은 고장 나면 "차 아예 안 타야지"라고 생각하며 버리는 경향이 있습니다.

2. 실수 (실패) 에 대한 3 가지 반응 패턴

로봇이 "에이, 고장 났어요!"라고 알람을 보냈을 때, 공장 관리자 (개발자) 들은 세 가지 방식으로 반응했습니다.

🚑 즉각 치료 (Immediate Fixing):
- "아! 고장 났네? 지금 당장 고친다!"
- 가장 흔한 반응 (약 76%) 입니다. PR(코드 제안) 이 거절당하기 전에 바로 고쳐서 다시 제출합니다.
⏳ 나중 치료 (Deferred Fixing):
- "지금 당장은 바빠서 나중에 고치자. 일단은 넘어가자."
- 중요한 건 아니거나, 고치느라 시간이 너무 걸릴 때 사용합니다. "내일 고치면 돼"라고 생각하며 며칠, 혹은 몇 달을 버팁니다.
- 위험: 나중에 다른 사람이 이 고장 난 상태를 보고 "내가 고장 낸 건가?"라고 오해할 수 있습니다.
🗑️ 그냥 버리기 (Ignore/Abandon):
- "이 로봇은 아예 고장 난 거 같으니 끄자."
- 고쳐도 안 되거나, 그 기능이 필요 없어진 경우 로봇을 아예 끄거나 설정을 지워버립니다.

3. 팀의 크기와 스타일이 중요함

팀이 크면 (여러 명의 관리자): 고장 나면 바로 고치는 경향이 강합니다. 서로 감시하고 도와주기 때문입니다.
혼자 일하면 (솔로 개발자): 고장 나면 "나중에 고치자"거나, 아예 무시하는 경우가 더 많았습니다.
코드 리뷰 방식: 코드를 바로 합치는 것보다, 다른 사람이 검토 (PR) 를 거치는 방식이 고장 나더라도 바로 고쳐서 해결하는 경향이 더 뚜렷했습니다.

💡 이 연구가 우리에게 주는 교훈

설계도만 믿지 마세요: "자동화 설정 파일이 있다"는 건 "자동화가 잘 되고 있다"는 뜻이 아닙니다. 실제로 작동하는지, 사람들이 어떻게 반응하는지 봐야 합니다.
일관성이 생명입니다: 로봇을 꾸준히 쓰면 시스템이 안정화됩니다. 가끔씩만 쓰면 실패가 쌓여 결국 시스템을 포기하게 됩니다.
지연된 치료는 독이 될 수 있습니다: "나중에 고치자"는 태도가 쌓이면, 나중에 고치기 더 어려워지고 팀원들이 혼란을 겪을 수 있습니다.

🎯 결론

이 논문은 **"자동화 도구 (GitHub Actions) 는 단순히 설치한다고 끝이 아니다. 사람들이 어떻게 쓰느냐, 실패했을 때 어떻게 대처하느냐에 따라 성공과 실패가 갈린다"**는 것을 보여줍니다.

마치 **새로운 요리 레시피 (자동화 도구)**를 사서 냉장고에 넣어두는 것과, 매일 그 레시피로 요리를 해보고 실패하면 맛을 보고 고쳐나가는 것은 완전히 다르다는 이야기입니다. 연구팀은 후자가 훨씬 더 중요하다고 말합니다.

1. 연구 배경 및 문제 제기 (Problem)

현재 상황: CI/CD (지속적 통합/배포) 는 현대 소프트웨어 개발의 핵심이며, GitHub Actions (GHA) 는 가장 널리 채택된 자동화 플랫폼 중 하나입니다.
기존 연구의 한계: 대부분의 기존 연구는 GHA 의 정적 설정 파일 (YAML) 존재 여부만을 분석하여 '채택'을 판단했습니다.
문제점: 설정 파일이 존재한다고 해서 실제 워크플로우가 실행되거나, 개발자들이 그 결과를 유의미하게 활용하는 것은 아닙니다. 설정 파일과 실제 사용 사이에는 '설정 - 사용 간극 (Configuration-Usage Gap)' 이 존재하며, 이는 자동화 기술이 개발 프로세스에 미치는 실제 영향을 왜곡하여 보여줄 수 있습니다.
연구 목표: 단순한 설정 파일 분석을 넘어, 실제 실행 기록 (Workflow Run Data) 과 개발자의 반응 (커밋, PR 토론 등) 을 분석하여 GHA 가 실제 개발 현장에서 어떻게 작동하는지 이해하는 것.

2. 연구 방법론 (Methodology)

이 연구는 혼합 방법론 (Mixed-Methods) 을 사용하여 정량적 분석과 정성적 분석을 결합했습니다.

데이터 수집:
- 기존 데이터셋 (952 개 리포지토리) 을 기반으로 GitHub API 를 통해 최신 실행 기록을 수집.
- 총 258,300 개의 워크플로우 실행 기록을 765 개의 리포지토리에서 분석 (RQ1).
- 실행 기록, 트리거 이벤트, 상태 (성공/실패), 연관된 PR/커밋, 사용자 반응 등을 포함.
샘플링 전략:
- 765 개 리포지토리를 인기 (Stars+Forks), 워크플로우 실행 횟수, 실패율의 3 가지 차원에 따라 8 개 그룹으로 분류.
- 각 그룹의 다양성을 반영하기 위해 21 개의 리포지토리를 목적적 표본 추출 (Purposive Sampling) 하여 선정.
분석 방법:
- 정량적 분석 (RQ1): 765 개 리포지토리의 실행 빈도, 실패율, 트리거 패턴 분석.
- 정성적 분석 (RQ2, RQ3): 선정된 21 개 리포지토리에 대한 심층 분석. 워크플로우 설정 파일, 실행 기록, PR 코멘트, 커밋 메시지 등을 수동으로 코딩 (Qualitative Coding) 하여 개발자의 대응 패턴과 프로젝트 특성의 관계를 규명.

3. 주요 연구 질문 및 결과 (Key Contributions & Results)

RQ1: 관찰된 GitHub Actions 활용 패턴은 무엇인가?

사용 강도와 실패율의 역상관 관계: 워크플로우 실행 횟수가 많을수록 실패율이 낮아지는 통계적으로 유의미한 음의 상관관계 ( $r = -0.230$ $r = - 0.230$ ) 를 발견.
- 고사용 (High-Usage): 실행 횟수가 많을수록 실패율이 안정적임 (2.7% ~ 20.5%).
- 저사용 (Low-Usage): 실행 횟수가 적을수록 실패율 변동이 극심함 (0% ~ 86.7%).
트리거 패턴:
- 개발 중심 이벤트 (push, pull_request) 가 전체 실행의 71.8% 를 차지.
- 고사용 리포지토리는 다양한 트리거 이벤트 조합을 사용하는 반면, 저사용 리포지토리는 단일 트리거에 의존하는 경향이 있음.
발견: 지속적인 워크플로우 사용은 더 안정적인 자동화 (낮은 실패율) 와 포괄적인 채택 (다양한 트리거) 과 연관됨.

RQ2: 개발자는 GitHub Actions 워크플로우 실패에 어떻게 반응하는가?

21 개 리포지토리의 정성적 분석을 통해 실패 대응의 3 가지 주요 패턴을 도출:

즉시 수정 (Immediate Fixing, 76%): 실패 발생 후 수 분~수 시간 내 (PR 병합 전 또는 메인 브랜치에 즉시 푸시) 에 문제를 해결. 가장 흔한 패턴으로, CI 통과에 대한 높은 헌신을 반영.
연기된 수정 (Deferred Fixing): 메인 브랜치에서의 실패를 일시적으로 허용하고, 향후 커밋 (수 일~수 개월 후) 에서 해결. 개발 속도 (Velocity) 를 우선시하여 일시적인 실패를 감수하는 전략.
무시/폐기 (Ignore/Abandon): 실패에 대한 대응이 없거나, 환경별 문제라고 판단하여 무시하거나, 아예 워크플로우를 비활성화/삭제하는 경우.

RQ3: 프로젝트 특성과 GHA 활용 패턴 간 관계는 무엇인가?

정성적 분석을 통해 향후 검증을 위한 5 가지 가설을 제시:

H1: Pull-based 개발 방식이 Direct push 방식보다 워크플로우 실패율이 낮음.
H2: 워크플로우 설정 변경이 빈번할수록 실패율이 높음 (기술 부채 증가).
H3: 팀 규모 (멀티 메인테이너) 가 클수록 실패율이 낮음.
H4: 워크플로우 변경이 빈번한 프로젝트는 '연기된 수정'이나 '무시' 전략을 더 많이 사용 (선택적 대응).
H5: 여러 메인테이너가 있는 프로젝트가 단일 메인테이너 프로젝트보다 '즉시 수정' 전략을 더 많이 사용.

4. 논의 및 시사점 (Discussion & Significance)

설정 - 사용 간극 (Configuration-Usage Gap): 많은 프로젝트가 설정 파일은 존재하지만 실제로는 실행되지 않거나 비활성화된 워크플로우를 가지고 있음. 따라서 설정 파일 분석만으로는 실제 채택 현황을 과대평가할 수 있음.
협력적 수정 vs 직접 수정: 메인테이너가 외부 기여자의 실수를 직접 고쳐주는지, 아니면 가이드를 제공하는지에 따라 지식 전수와 기여자 유지에 영향을 미침.
지역적 최적화 vs 집단적 비용: '연기된 수정' 전략은 팀 내부에서는 합리적일 수 있으나, 후속 기여자에게는 디버깅 비용과 혼란을 야기할 수 있음 (실패 오염).
향후 개선 방향:
- 지능형 실패 컨텍스트: 실패 원인을 자동으로 추적하고 이전 기록과 비교하는 기능 필요.
- 적응형 멘토링: 워크플로우 실패에 대한 프로젝트별 자동 가이드 생성.
- 사용 기반 분석: 설정 파일이 아닌 실제 실행 데이터에 기반한 인사이트 제공.

5. 결론

이 연구는 GitHub Actions 의 실제 운영 데이터를 분석함으로써, 단순한 설정 파일 존재 여부를 넘어 개발자가 자동화 도구를 어떻게 실제로 활용하고 실패에 대응하는지에 대한 심층적인 통찰을 제공했습니다. 연구 결과는 워크플로우 사용 강도와 실패율 간의 관계, 개발자의 다양한 대응 전략, 그리고 프로젝트 특성에 따른 차이를 규명하여, 향후 CI/CD 연구와 도구 개발에 중요한 기초 데이터를 제공했습니다.