개발자에게 깃허브(GitHub)는 단순한 코드 저장소를 넘어 배포 파이프라인, 이슈 관리, 패키지 레지스트리, 심지어 인증 흐름까지 얽혀 있는 핵심 인프라다. 그만큼 깃허브가 흔들리면 조직 전체의 개발 생산성이 멈춘다. 최근 등장한 'isgithubcooked.com'이라는 사이트는 바로 이 불안을 데이터로 환원해 보여준다. 이름은 다소 도발적이지만, 실제로 하는 일은 깃허브의 장애 이력을 수집해 실시간 통계와 다운타임 분석으로 정리하는 것이다.
제작자는 이 사이트를 만든 이유를 분명히 밝힌다. 자신이 만드는 제품에 영향을 주는 특정 서비스와 심각도(severity) 수준만 골라서 깃허브의 장애 이력을 걸러 보고 싶었다는 것이다. 깃허브 상태 페이지는 모든 장애를 뭉뚱그려 보여주지만, 실제로 Actions에 의존하는 팀과 Packages에만 의존하는 팀은 체감하는 안정성이 전혀 다르다. 이 사이트는 사용자가 관심 있는 서비스와 심각도를 직접 필터링하도록 해, 각자에게 맞는 가동률 그림을 그리게 한다.
'신뢰성 서사'는 각자의 함수다
사이트가 내세우는 핵심 문장은 곱씹을 만하다. 모든 신뢰성 서사는 자신이 의존하는 서비스와 자신이 기대하는 '나인(9)'의 개수에 따라 결정되는 함수라는 것이다. 여기서 '나인'은 가용성을 표현하는 업계 관행으로, 99.9%(three nines)나 99.99%(four nines)처럼 소수점 아래 9가 몇 개냐로 서비스 수준을 가른다. 같은 장애 이력을 두고도 누군가에게는 '충분히 안정적'이고 누군가에게는 '허용 불가'인 이유가 여기에 있다.
이 관점은 실무적으로 유용하다. 팀마다 필터 조건이 다르다는 사실을 인정하면, 서로 다른 기준을 가진 사람들이 '깃허브는 안정적이다/불안정하다'를 두고 헛되이 논쟁하는 상황을 피할 수 있다. 사이트는 이를 두고 '이제 당신의 필터를 선언하고 서로 엇갈려 말하는 일을 막을 수 있다'고 표현한다. 실제로 SLA 협상이나 인프라 의존성 검토 자리에서 '어떤 서비스, 어떤 심각도를 기준으로 이야기하는가'를 먼저 합의하는 것은 불필요한 소모를 줄이는 실용적 습관이다.
숫자가 말하는 것과 말하지 않는 것
사이트가 집계한 수치도 눈길을 끈다. 깃허브는 2016년 3월 이후 총 1,125건의 장애를 기록했고, 이는 월평균 약 24건의 장애 발생률에 해당한다. 다만 이 수치는 직전 3개월과 비교하면 5% 감소한 것으로, 최근 흐름은 오히려 개선 방향이라는 신호를 준다. 장애 없이 이어간 가장 긴 연속 기록은 8일로 2025년 12월 31일에 끝났고, 가장 나빴던 달은 37건이 몰린 2026년 2월이었다.
여기서 냉정하게 짚어야 할 대목이 있다. '장애 건수'는 그 자체로 서비스 품질을 온전히 대변하지 못한다. 수 분간 지속된 경미한 성능 저하와 수 시간짜리 전면 중단이 모두 '1건'으로 계산된다면, 단순 집계는 체감 영향과 어긋날 수 있다. 월평균 24건이라는 숫자도 깃허브가 상태 페이지에 얼마나 세밀하게 사건을 기록하느냐에 따라 달라진다. 보고 기준이 촘촘한 서비스일수록 건수는 많아 보이기 마련이므로, 절대값보다 추세와 필터링된 부분집합을 보는 편이 합리적이다.
결국 이 사이트의 진짜 가치는 '깃허브가 망했다'는 자극적 결론이 아니라, 신뢰성을 각자의 조건으로 환산해 보게 만든다는 데 있다. 자신의 서비스가 Actions 장애에 취약하다면 Actions만, 결제와 연동된 인증 흐름이 중요하다면 해당 심각도만 추려 자신의 리스크를 정량화할 수 있다. 한국의 실무자라면 이 도구를 참고 자료로 삼되, 깃허브 공식 상태 이력과 자체 모니터링 지표를 함께 대조하며 팀 고유의 '나인' 기대치를 명시적으로 정의하는 계기로 삼는 것이 바람직하다. 외부 집계는 논의의 출발점일 뿐, 최종 판단의 근거는 결국 각자의 의존성 지도에서 나온다.