GitHub 다수 서비스 장애 발생 - 개발자들이 멈춘 몇 시간의 기록

또다시 찾아온 GitHub 먹통의 하루

개발자라면 누구나 한 번쯤 겪어봤을 거예요. 코드 푸시하려는데 갑자기 안 되고, Actions 빌드가 멈춰 있고, 슬랙에서 동료가 "혹시 PR 리뷰 댓글 사라진 거 나만 그래?"라고 물어오는 순간. 이번에 2026년 4월에 GitHub에서 또 이런 일이 벌어졌어요. GitHub Status 페이지에 "Incident with multiple GitHub services"라는 제목으로 장애 공지가 올라왔고, Actions, Pull Requests, API Requests, Webhooks, Copilot 같은 여러 서비스가 동시에 불안정해졌거든요.

GitHub이 이제는 단순한 코드 호스팅 사이트가 아니라 전 세계 개발 워크플로우의 중앙 허브 역할을 하다 보니, 한 번 장애가 나면 피해 범위가 상상 이상으로 커져요. 회사의 CI/CD 파이프라인, 배포, 문서 빌드, 심지어 AI 코드 어시스턴트까지 전부 멈추는 거죠. 오늘은 이번 장애가 어떤 양상이었는지, 구조적으로 왜 이런 일이 반복되는지, 그리고 우리 팀은 어떻게 대비할 수 있는지 찬찬히 풀어볼게요.

무엇이 얼마나 망가졌나

이번 incident는 한 가지 기능만 깨진 게 아니라 여러 서비스가 연쇄적으로 불안정해진 형태였어요. GitHub Status 페이지에 따르면 Actions의 워크플로우 실행 지연, Webhooks 이벤트 전달 실패, Pull Request 페이지 로딩 오류, API 요청의 간헐적 5xx 응답 등이 한 타임라인에 몰려 나타났어요. 사용자 입장에서는 어떤 건 되고 어떤 건 안 되는 애매한 상태가 가장 힘들죠. "GitHub이 완전히 죽었다"면 차라리 그냥 점심 먹으러 나가겠는데, "푸시는 되는데 Actions는 안 돌아간다"면 일을 계속 해야 할지 말아야 할지 판단이 안 서거든요.

이런 복합 장애는 보통 공유 인프라(shared infrastructure)에서 문제가 생겼을 때 나타나요. 예를 들면 내부 메시지 큐, 데이터베이스 프록시, 인증 서비스, 메타데이터 저장소 같은 것들이요. GitHub은 수년간 모놀리식 Rails 앱에서 여러 마이크로서비스로 쪼개는 작업을 해왔는데, 그 과정에서 공통으로 쓰는 의존성이 장애 파급의 통로가 되기도 해요. 한 팀이 배포한 변경 하나가 공유 라이브러리를 통해 다른 팀 서비스까지 쓰러뜨리는 식이죠.

왜 이런 장애가 반복될까

솔직히 말하면 GitHub만의 문제는 아니에요. AWS, Cloudflare, Google Cloud도 비슷한 대형 장애를 주기적으로 겪어요. 이유는 크게 세 가지예요.

첫째는 규모의 복잡성이에요. 매일 수억 건의 git push, 수천만 건의 Actions 실행, 수십억 건의 API 호출이 돌아가는 시스템에서는 드물게 나타나는 엣지 케이스가 매일 발생하거든요. 평소에는 1만 번에 한 번 터지는 버그도, 초당 10만 요청이 들어오면 1초에 10번씩 터져요. 둘째는 의존성의 연쇄예요. 현대 클라우드 서비스는 내부적으로 수백 개의 서비스가 서로 호출하는데, 한 곳의 지연이 호출 체인을 따라 눈덩이처럼 불어나는 cascading failure가 흔해요. 셋째는 배포 속도와 안정성의 긴장 관계예요. 기능을 빨리 내려면 자주 배포해야 하는데, 자주 배포하면 사고 확률도 올라가요. 그렇다고 배포를 미루면 한 번에 쌓인 변경이 커져서 사고가 나면 원인 찾기가 더 어려워지고요.

업계 맥락 - 단일 벤더 의존의 위험

요즘 업계에서 조용히 논의되는 주제가 "우리가 GitHub에 너무 많이 의존하고 있는 것 아닌가"예요. 코드 저장소뿐 아니라 이슈 트래커, CI, 패키지 레지스트리(npm, Container Registry), 배포 환경(Pages, Codespaces), AI 어시스턴트(Copilot)까지 한 벤더에 묶여 있거든요. GitLab, Gitea, Forgejo 같은 대안이 있긴 하지만 네트워크 효과 때문에 옮기기가 쉽지 않죠.

이번 같은 장애가 터질 때마다 GitLab 셀프호스팅, 혹은 AWS CodeCommit/CodeBuild로의 이전 논의가 잠깐 올라왔다가 가라앉아요. 왜냐하면 현실적으로 GitHub의 생태계, Actions 마켓플레이스, 오픈소스 기여 문화를 대체하기가 어렵거든요. 대신 부분적 이중화를 택하는 팀이 늘고 있어요. 예를 들어 코드는 GitHub에 두되, 배포 파이프라인은 자체 Jenkins나 Buildkite로 돌리는 식이요.

한국 개발자에게 주는 시사점

실무 관점에서 몇 가지 챙겨갈 수 있어요. 첫째, 중요한 배포 파이프라인은 GitHub Actions 하나에만 의존하지 마세요. 긴급 핫픽스를 배포해야 하는데 Actions가 죽어 있으면 정말 속수무책이에요. 로컬에서도 돌릴 수 있는 배포 스크립트를 하나 만들어두거나, 대체 runner를 준비해두는 게 좋아요. 둘째, git 자체는 분산 시스템이라는 걸 기억하세요. GitHub이 죽어도 각자 로컬에 전체 히스토리가 있으니, 급하면 임시로 다른 원격에 푸시해서 협업할 수 있어요. 셋째, Status 페이지 구독과 알림은 미리 설정해두세요. 장애를 빠르게 인지하는 것만으로도 팀의 혼란을 줄일 수 있어요. 넷째, 사후에 올라오는 post-mortem을 꼭 읽어보세요. GitHub은 대부분 몇 주 안에 상세한 장애 원인 분석을 공개하는데, 이게 시스템 설계를 배우는 최고의 교재거든요.

마무리

클라우드 시대의 역설은, 우리가 편해진 만큼 한 벤더의 장애에 취약해졌다는 거예요. GitHub이 멈추면 전 세계 개발자의 생산성이 동시에 멈추는 시대에 살고 있는 거죠. 여러분 팀은 GitHub이 하루 종일 죽었을 때 얼마나 버틸 수 있는 구조인가요? 그리고 이번 장애 때 여러분은 무엇을 하며 시간을 보내셨나요?