GitHub이 또 멈췄다 - 우리는 무엇을 GitHub에 맡기고 있나

8월 17일 GitHub.com에 다시 장애가 발생함 웹과 API 트래픽의 약 20%, 아카이브와 Raw 콘텐츠 다운로드의 약 50%에서 오류가 발생했고 Pull Request/Issues/Actions/Webhooks까지 영향을 받음 복구된 뒤에도 Pull Request에 접근할 수 없는데 공식 상태 페이지는 모두 정상으로 표시되는 상황이 이어짐 그리고 몇 시간 지나지 않아 GitHub의 대안은 무엇인가, 이제는 다른 서비스로 옮기는 것이 합리적인가라는 질문이 나란히 올라옴 GitHub가 멈출 때마다 장애 신고가 이주 상담으로 이어지는 익숙한 흐름이 보임 하지만 어디로 옮길지 이야기하기 전에 먼저 봐야 할 것이 있음 GitHub가 멈췄을 때 우리에게서 정확히 무엇이 멈추는가 GitHub 장애는 오래됐지만 멈추는 범위가 달라짐 GitHub 장애가 새로운 일은 아님 2023년에도 GitHub.com 서비스 중단이 있었고, 당시에도 상태 페이지와 실제 상황이 다르다는 지적과 오픈소스를 한곳에 모으는 것이 안전한가라는 질문이 나옴 최근에는 장애가 더 자주 보일 뿐 아니라 서로 다른 작업을 연달아 막음 Pull Request 검색 결과가 누락돼 전체 인덱스를 다시 구축한 장애 GitHub Actions와 Pages가 6시간 넘게 영향을 받은 장애 Issues/PR/API/Webhooks/Actions가 함께 영향을 받은 이번 장애 상태 페이지에는 정상으로 표시되지만 실제 PR에는 접근할 수 없었던 후속 문제까지 특히 GitHub Actions와 Pages가 6시간 넘게 영향을 받은 장애에서는 자체 호스팅 러너도 작업을 받지 못함 컴퓨팅 자원은 자기 서버에 있는데도, 작업을 배정하는 제어면(Control Plane) 은 GitHub에 남아 있기 때문 Git 저장소만 GitHub에 둔다고 생각했지만 실제로는 리뷰 / 자동화 / 릴리스 / 프로젝트 운영을 함께 맡기고 있었던 것 최근 장애의 원인을 하나로 설명하기는 어려움 AI 에이전트가 만드는 커밋과 PR, Actions 작업이 급증했다는 설명도 있고 Azure 인프라 이전이나 오래된 내부 구조를 지적하는 의견도 있음 원인은 갈리지만 부하가 커졌다는 사실 자체는 확인됨 GitHub COO Kyle Daigle이 공개한 수치에 따르면 GitHub Actions 실행 시간은 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 2026년 4월 초에는 그 주 누적...