GitHub 또 흔들렸다: PR·이슈·Git 작업까지 멈춘 장애가 던지는 질문

무슨 일이 있었나요

또 한 번 GitHub가 흔들렸어요. 이번 장애는 단순히 "웹사이트가 좀 느렸다" 수준이 아니었습니다. 풀 리퀘스트(Pull Request) 생성·머지가 안 되고, 이슈도 못 열거나 못 닫고, git push·git pull 같은 가장 기본적인 Git 작업과 REST/GraphQL API 호출까지 영향을 받았어요. 한마디로 평소 우리가 GitHub에서 하는 일의 대부분이 한꺼번에 막힌 상황이었던 거죠.

이게 무서운 이유는 따로 있어요. GitHub는 단순한 코드 저장소가 아니거든요. CI/CD 파이프라인을 돌리는 GitHub Actions, 패키지 배포에 쓰는 GitHub Packages, 컨테이너 이미지를 받는 GHCR, 그리고 수많은 사내 봇과 자동화 스크립트가 전부 GitHub API를 두드리고 있어요. GitHub가 한 번 흔들리면 회사 내부의 빌드, 배포, 코드 리뷰, 릴리스까지 줄줄이 영향을 받는 구조죠.

왜 이런 일이 반복될까

GitHub 같은 거대한 서비스도 결국은 데이터베이스, 인증 시스템, 로드밸런서, 큐 같은 컴포넌트들의 조합이에요. 어느 한 곳에서 문제가 생기면 그 영향이 다른 시스템으로 번지는 "파급 장애(cascading failure)"가 자주 일어나요. 특히 PR·이슈·API가 동시에 영향받았다는 건, 이 기능들이 공통적으로 의존하는 내부 컴포넌트(예: 메타데이터 DB, 인증 게이트웨이, 권한 체크 서비스)가 흔들렸을 가능성이 높다는 신호예요.

GitHub는 사후 분석(post-mortem)을 비교적 투명하게 공개하는 편이라, 며칠 뒤 githubstatus.com이나 GitHub 엔지니어링 블로그에 자세한 원인 분석이 올라올 가능성이 큽니다. 과거 사례들을 보면 데이터베이스 마이그레이션 중 발생한 락(lock), 캐시 무효화 실수, 새 배포의 메모리 누수 같은 패턴이 반복돼요.

우리는 어떻게 대비해야 할까

이런 일이 한 번씩 터질 때마다 "GitHub 의존도 너무 높은 거 아닌가"라는 이야기가 나와요. 그렇다고 GitLab이나 Bitbucket, Codeberg로 당장 옮기자는 얘기는 현실적이지 않죠. 대신 현실적인 완충 장치를 마련하는 게 좋아요.

첫째, 로컬에 살아있는 원격 미러를 두는 습관입니다. git remote add backup 형태로 사내 GitLab이나 다른 호스팅에 정기 미러링만 걸어두어도, 장애 시간 동안 빠른 패치를 푸시할 수 있어요. 둘째, CI/CD가 GitHub Actions에만 묶여 있지 않게 하는 것도 중요해요. 핵심 배포 파이프라인은 외부 서비스(예: 자체 호스팅 러너, Buildkite, Jenkins)로 백업 경로를 만들어두면 안심이 됩니다. 셋째, GitHub API에 직접 의존하는 사내 자동화(슬랙 봇, 배포 알림 등)는 장애 시 우아하게 실패(graceful degradation)하도록 설계해야 해요. 재시도 폭주로 GitHub 복구를 더 어렵게 만드는 일도 피해야 하고요.

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

국내 많은 스타트업과 중견기업이 GitHub Enterprise 또는 Cloud를 쓰고 있어요. 특히 GitHub Actions로 배포 자동화를 통째로 옮긴 팀이라면, 이번 장애 같은 상황에서 "배포가 안 되어 핫픽스도 못 나가는" 시나리오를 한 번쯤 책상 위에서 시뮬레이션해볼 만해요. SRE나 DevOps 담당자라면 "GitHub 장애 런북"을 한 페이지라도 만들어 두면 좋습니다.