GitHub Actions 러너 배정 지연 장애, Actions와 Pages 포함 3시간 40분 만에 복구

GH Actions 문제가 워낙 자주 터져서 이제 뉴스도 아님. 상태 페이지에 안 뜨는 것도 많고, 수동으로 취소하고 다시 돌리면 풀리는 경우도 많음.

그럼 오히려 180일 동안 문제 없이 돌아간 게 헤드라인이 되겠다. "GitHub Actions 180일 연속 정상"이면 확실히 클릭함.

GitHub이 살아있을 때도 업데이트를 올려주면 노이즈가 훨씬 줄 텐데.

us, au, eu, jp 엔터프라이즈 클라우드 인스턴스가 전부 같은 장애를 겪더라. 데이터 레지던시로 분리했다면서 단일 장애점이면 그 분리가 무슨 의미인지 모르겠음.

그 분리의 목적은 엔터프라이즈 고객에게 더 많이 청구하는 것임.

2026년 들어 이런 장애가 일상이 됐으니, CI를 프라이빗 SaaS로 제공하는 경쟁자한테는 시장 빈틈임.

그럼 GitLab 쓰면 되지 않나. Gitea도 있고.

그래도 회사들은 계속 GitHub를 씀. 장애가 선택에 영향을 준다는 데이터는 잘 못 봄.

규모가 커지면 다른 플랫폼도 같은 문제를 겪음. 결국 마이크로소프트가 하이퍼스케일러라서 언젠가 정리할 거라고 믿는 거고, GitLab에 걸면 같은 문제를 더 약한 회사에서 겪는 셈임.

무료 GitHub Actions 2000분을 왜 계속 주는지가 더 궁금함.

나는 CI 러너를 Bunny로 옮겼는데 더 싸고 더 빠름.

우리 회사는 러너를 다른 업체로 바꿨는데도 작업이 안 뜸. GH Actions가 러너에 요청을 보내는 구조라 액션 자체가 죽으면 대안 업체도 같이 죽음.

요즘 장애는 AI가 만든 지나치게 복잡한 CI 파이프라인 탓도 큰 것 같음. 테스트에 sleep을 넣거나 100MB 파일을 받게 해서 CI가 10~20분씩 걸리고, 바이브 코더는 그걸 안 봄.

AI한테 물어보면 GitHub Actions의 한계를 우회하는 방식으로 답을 줌. 되는 건 되는데 그 한계는 원래 이유가 있어서 쓰기 찝찝함.

속도보다 볼륨 문제임. AI 도입 후 커밋과 CI 작업이 10~30배 늘었음.

나는 CI/CD를 오래 다룬 전문 엔지니어인데도 예전보다 30배는 더 GitHub를 두드림. 병렬로 작업을 돌리고, 속도가 올라가도 품질 확인을 CI로 하니까 비전문가만 탓하는 건 과함.