Hacker News 2026.04.01 40

GitHub 가동률의 진짜 역사 — 우리가 겪은 장애들, 숫자로 보면 이렇습니다

가끔 GitHub 안 될 때 있잖아요

개발자라면 한 번쯤 경험해봤을 거예요. git push를 했는데 타임아웃이 나거나, GitHub 웹사이트가 느려지거나, 아예 접속이 안 되는 순간. 그때마다 "또?"라는 생각이 들죠. 누군가가 GitHub의 역사적 가동률(uptime) 데이터를 모아서 시각화한 프로젝트가 등장했어요. GitHub이 지금까지 얼마나 안정적이었는지 — 혹은 불안정했는지 — 숫자로 확인할 수 있게 된 거예요.

가동률이라는 게 뭐냐면, 서비스가 정상적으로 작동한 시간의 비율이에요. 예를 들어 한 달에 99.9%의 가동률이라면, 약 43분 정도 서비스가 중단됐다는 뜻이에요. 99.99%면 약 4분. 숫자가 비슷해 보이지만 실제 체감은 완전히 다르죠.

데이터가 보여주는 것

이 프로젝트는 GitHub의 공식 상태 페이지와 과거 인시던트 기록을 수집해서 연도별, 월별 가동률을 정리했어요. 흥미로운 건 GitHub의 안정성이 시간에 따라 어떻게 변해왔는지 추세를 볼 수 있다는 거예요.

GitHub은 2008년에 서비스를 시작한 이후로 여러 번의 대형 장애를 겪었어요. 특히 기억에 남는 건 2018년 10월의 대규모 장애인데, 네트워크 장비 교체 과정에서 데이터베이스 클러스터 간 연결이 끊기면서 24시간 넘게 서비스가 불안정했었어요. 당시 MySQL 복제 토폴로지가 꼬여서 데이터 정합성을 복구하는 데 상당한 시간이 걸렸거든요.

토폴로지가 뭐냐면, 쉽게 말해 데이터베이스 서버들이 서로 연결되어 데이터를 주고받는 구조예요. 마치 물이 흐르는 파이프 배관도처럼, 어디서 어디로 데이터가 복제되는지를 나타내는 구조도인 거죠. 이 배관이 한 군데 막히면 전체 흐름에 문제가 생기는 것과 같아요.

2020년대 들어서는 GitHub의 안정성이 전반적으로 개선되는 추세를 보이지만, 여전히 간간이 의미 있는 규모의 장애가 발생하고 있어요. 특히 GitHub Actions(CI/CD 파이프라인)과 관련된 장애가 최근 몇 년간 눈에 띄게 많아졌는데, 이건 서비스 사용량이 급격히 늘어난 것과 관련이 있어요.

"나인(9)"의 의미

업계에서 가동률을 이야기할 때 "나인이 몇 개냐"라는 표현을 자주 써요. "파이브 나인(99.999%)"이면 1년에 약 5분 정도만 서비스가 중단된다는 뜻이에요. 대부분의 클라우드 서비스가 SLA(Service Level Agreement, 서비스 수준 계약)로 99.9%에서 99.99% 사이를 약속하는데요, GitHub의 실제 가동률이 이 기준에 얼마나 부합하는지 보는 것도 의미가 있어요.

참고로 GitHub의 경쟁 서비스인 GitLab은 자체 호스팅 옵션이 있어서, 가동률을 직접 관리할 수 있다는 차이가 있고요. Bitbucket도 Atlassian의 클라우드 인프라 위에서 운영되면서 비슷한 가동률 이슈를 겪어왔어요. 결국 SaaS 형태의 Git 호스팅 서비스는 모두 이 "가동률과의 싸움"에서 자유로울 수 없는 거죠.

마이크로소프트 인수 이후의 변화

2018년 마이크로소프트가 GitHub을 인수한 이후, 인프라 측면에서 상당한 투자가 이뤄졌어요. Azure 인프라로의 마이그레이션이 점진적으로 진행되면서 전반적인 안정성이 개선됐다는 평가가 있어요. 하지만 동시에 GitHub Actions, Codespaces, Copilot 등 새로운 서비스가 빠르게 추가되면서, 전체 시스템의 복잡도가 높아진 것도 사실이에요.

이런 트레이드오프는 모든 성장하는 서비스가 겪는 문제예요. 새 기능을 빠르게 출시하면 사용자는 좋아하지만, 시스템 복잡도가 올라가면서 예상치 못한 장애의 가능성도 함께 높아지거든요.

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

한국에서 GitHub을 사용하는 개발자라면, 특히 CI/CD를 GitHub Actions에 의존하고 있다면 이 데이터를 한 번 살펴볼 가치가 있어요. 만약 여러분의 배포 파이프라인이 GitHub에 100% 의존하고 있다면, 장애 상황에 대한 폴백(fallback) 계획을 세워두는 게 좋아요.

실무적으로는 몇 가지를 고려해볼 수 있어요. 먼저, 중요한 릴리즈는 GitHub Status 페이지를 먼저 확인하는 습관을 들이세요. 그리고 GitHub Actions가 장애일 때 로컬에서 빌드하고 수동 배포할 수 있는 절차를 문서화해두면 급한 상황에서 도움이 돼요. 또한 git 리포지토리의 미러를 다른 서비스(GitLab 등)에 자동으로 유지하는 것도 비용 대비 효과가 좋은 보험이에요.

가동률 데이터를 직접 분석하는 이런 프로젝트는, SRE(Site Reliability Engineering) 관점에서 우리 서비스의 안정성을 어떻게 측정하고 공개할지에 대한 좋은 레퍼런스이기도 해요. 여러분의 팀에서도 인시던트 기록을 체계적으로 관리하고 사후 분석(포스트모템)을 작성하는 문화가 있다면, 장기적으로 서비스 안정성에 큰 도움이 돼요.