GitHub 또 다운 — 우리가 GitHub 장애에서 배워야 할 것들

무슨 일이 있었나요

GitHub에 또 장애가 발생했어요. GitHub Status 페이지에 인시던트가 올라왔고, 많은 개발자들이 push, pull은 물론이고 GitHub Actions 같은 CI/CD 파이프라인까지 멈추는 상황을 겪었어요. "또"라는 표현을 쓴 이유가 있는데, 최근 몇 달 사이에 GitHub에서 크고 작은 장애가 반복적으로 발생하고 있기 때문이에요. 전 세계 개발자들의 코드 저장소이자 협업 허브인 GitHub이 멈추면 그 파급력이 정말 어마어마하거든요.

생각해보면, 현대 소프트웨어 개발에서 GitHub이 차지하는 비중은 단순한 Git 호스팅을 넘어서요. CI/CD, 패키지 레지스트리(npm, Docker 이미지 등), 프로젝트 관리, 코드 리뷰, 심지어 인증(GitHub OAuth)까지 — 개발 워크플로우의 거의 모든 단계가 GitHub에 의존하고 있어요. 그래서 GitHub이 다운되면 코드를 못 올리는 것뿐만 아니라, 배포가 멈추고, 로그인이 안 되고, 의존성 설치가 실패하는 연쇄 반응이 일어나요.

왜 이렇게 자주 장애가 나는 걸까

GitHub의 인프라 규모를 생각하면 장애가 완전히 없기란 사실상 불가능해요. GitHub에는 수억 개의 리포지토리가 있고, 하루에도 수천만 건의 Git 오퍼레이션이 발생하거든요. 데이터베이스, 스토리지, 네트워크 어느 한 곳에서 병목이 생겨도 전체 서비스에 영향을 줄 수 있어요.

GitHub은 2018년에 Microsoft에 인수된 이후로 인프라를 꾸준히 개선해왔는데, 그래도 단일 장애점(Single Point of Failure, 이게 뭐냐면 하나가 고장 나면 전체가 멈추는 구조를 말해요)을 완전히 제거하는 건 쉽지 않아요. 특히 GitHub처럼 데이터 일관성이 중요한 서비스는 분산 처리와 일관성 사이에서 항상 트레이드오프가 있거든요.

최근에는 GitHub의 데이터베이스 레이어에서 문제가 발생하는 경우가 많았어요. GitHub은 MySQL 기반의 대규모 데이터베이스를 운영하는데, 수평 확장(샤딩)을 하면서 생기는 복잡성이 장애의 원인이 되기도 해요. Git 데이터 자체는 분산되어 있지만, 이슈, PR, Actions 같은 메타데이터는 관계형 DB에 의존하니까요.

실무에서 GitHub 장애에 대비하는 방법

"GitHub이 안 되면 일을 못 하겠다"는 얘기를 반쯤 농담으로 하지만, 사실 대비책을 마련해둘 수 있어요.

로컬 Git은 살아있다는 걸 기억하세요. Git 자체가 분산 버전관리 시스템이라서, 로컬 리포지토리에는 전체 히스토리가 있어요. GitHub이 다운되어도 커밋, 브랜치 생성, 로컬 머지 같은 작업은 문제없이 할 수 있어요. push만 나중에 하면 돼요.

미러 리포지토리를 운영하는 것도 방법이에요. 중요한 프로젝트라면 GitLab이나 Bitbucket에 미러를 만들어두면, GitHub 장애 시에도 코드 접근이 가능해요. git remote add mirror 명령어로 리모트를 하나 더 추가하고 주기적으로 push하는 스크립트를 cron에 걸어두면 간단하게 구현할 수 있어요.

CI/CD 파이프라인의 GitHub 의존도를 점검해보세요. GitHub Actions만 쓰고 있다면, 장애 시 배포가 완전히 멈춰요. 핫픽스를 긴급 배포해야 하는 상황에서 GitHub이 다운되면 정말 난감하거든요. Jenkins, GitLab CI, 또는 CircleCI 같은 대안 파이프라인을 백업으로 준비해두면 리스크를 분산할 수 있어요.

GitHub OAuth로 로그인하는 서비스가 있다면 대체 인증 수단을 마련해두는 게 좋아요. 이메일/비밀번호 로그인이나 다른 OAuth 제공자를 추가로 지원하면, 인증 서비스 하나가 죽어도 사용자가 서비스를 이용할 수 있어요.

더 큰 그림에서 보면

이 이슈는 단순히 "GitHub이 또 죽었다"를 넘어서, 우리 업계의 인프라 집중 문제를 보여줘요. AWS에 장애가 나면 인터넷의 절반이 멈추고, GitHub이 죽으면 전 세계 개발자가 손을 놓게 되는 구조가 건강한 건지 한번 생각해볼 필요가 있어요.

최근에는 자체 호스팅 Git 솔루션에 대한 관심도 다시 높아지고 있어요. Gitea나 Forgejo 같은 경량 Git 서버는 작은 팀이 직접 운영하기에 충분히 좋은 수준까지 올라왔고, GitLab Self-Managed도 꾸준히 쓰이고 있어요. 물론 직접 운영하면 그 나름의 부담이 있지만, 적어도 외부 서비스 장애에 의한 업무 중단은 피할 수 있죠.

정리

GitHub 장애는 피할 수 없지만, 대비는 할 수 있어요. 핵심은 "GitHub에 대한 의존도를 파악하고, 장애 시 대안이 있는지 점검하는 것"이에요. 여러분 팀은 GitHub이 갑자기 몇 시간 동안 다운되면 어떤 영향을 받나요? 비상 대책이 있나요? 한번 점검해보면 좋겠어요.