Title: GitHub Actions 복구되었으나 수동 조치 필요
GitHub Actions는 8월 7일 02:04 UTC에 정상화되었습니다. 이번 장애로 인해 실행되지 않은 push 및 pull-request 이벤트들이 남게 되었으므로, 개발자는 해당 실행 건들을 수동으로 다시 실행해야 합니다.
상태 페이지는 현재 정상(green)으로 표시되지만, 장애 시간 동안 시작되었어야 할 워크플로우는 실행되지 않은 채로 남아 있습니다. GitHub은 누락된 트리거를 자동으로 다시 실행할 수 없으므로, 팀은 새로운 커밋을 푸시하거나, pull request를 업데이트하거나, UI에서 Re-run jobs를 클릭해야 합니다. 오픈 소스인 Actions Runner Controller 사용자 또한 runner pod가 유휴(idle) 상태로 멈춰 있지 않은지 확인해야 합니다.
무엇이 문제였으며 왜 중요한가
GitHub Actions는 수백만 개의 저장소(repo)에서 CI 파이프라인을 구동합니다. 서비스가 중단되면 코드 변경 사항은 대기 상태로 남고, 테스트 스위트는 실행되지 않으며, 배포가 지연됩니다. 8월 7일, 서비스는 가장 일반적인 두 가지 CI 트리거인 push 이벤트(새 커밋)와 pull-request 이벤트(리뷰 업데이트) 처리를 모두 중단했습니다.
파이프라인 복구 방법
- 새 커밋 푸시 – 브랜치에 변경 사항을 추가하면 push 트리거가 다시 발생합니다.
- pull request 업데이트 – 댓글을 달거나, 제목을 변경하거나, 추가 커밋을 푸시하여 PR 워크플로우를 다시 트리거합니다.
- 워크플로우 수동 재실행 – Actions UI에서 실패한 각 실행 건에 대해 “Re-run jobs” 버튼을 사용할 수 있습니다.
Actions Runner Controller를 통해 self-hosted runner를 운영 중이라면 runner pod를 점검하십시오. 서비스가 복구된 후에도 일부 pod가 유휴 상태로 남아 있을 수 있으므로, 재시작하거나 재배포해야 합니다.
팀이 직면한 리스크
- 생산성 저하 – 평소 몇 분 내에 도착하던 피드백을 기다리느라 개발 시간이 낭비됩니다.
- 배포 지연 – 배포를 제어하는 파이프라인에 문제가 생기면 출시 일정이 뒤로 밀릴 수 있습니다.
- 운영 오버헤드 – 팀은 최근 실행 기록을 감사하고, 누락된 부분을 찾아내어 위의 수동 단계를 수행해야 하며, 이 과정에서 기능 개발에 투입할 시간이 줄어듭니다.
시사점: 이번 장애는 성숙한 CI 서비스라 할지라도 작업이 누락될 수 있으며, 자동 재실행이 보장되지 않는다는 점을 보여줍니다. 사고 대응 플레이북(incident-response playbook)에 수동 복구 단계를 포함시키고, 더욱 탄력적인 이벤트 처리를 향한 GitHub의 향후 행보를 주목하십시오.