Github의 가동률(uptime) 문제는 분명 심각하지만, 모든 기능이 동시에 멈췄다고 해서 “Github 전체가 다운됐다”고 말하는 건 과하다고 생각함
나는 Copilot을 거의 쓰지 않기 때문에 그 서비스가 자주 멈춰도 신경 쓰지 않음
진짜 중요한 건 Git, 웹사이트, API, Actions 같은 핵심 기능들의 안정성임
동의함. 하지만 지난 90일 동안 어떤 개별 서비스도 3x9(99.9%) 가동률을 달성하지 못했음
GitHub의 Enterprise SLA에 따르면 서비스별로 최소 99.9%를 보장해야 하는데, 실제 수치는 여기에서 확인 가능함
“Github이 다운됐다”는 표현이 과장된 건 맞지만, 실제로 API조차 99.69%, 즉 두 개의 9밖에 안 됨
Copilot은 한 개의 9 수준이고, 핵심 서비스인 Git과 Actions도 마찬가지임
이 회사는 1조 달러 규모의 글로벌 기업의 포트폴리오에 속함
이런 자원을 가진 회사가 고객을 방치하는 건 변명의 여지가 없음
요즘 대기업들이 말하는 “5 nines”는 거의 허상임
실제로는 에러 응답만 해도 “정상 작동”으로 계산함
네트워크 업계처럼 진짜로 99.999%를 달성하는 경우는 드물고, 대부분은 데이터 슬라이싱 트릭으로 상태 페이지를 초록색으로 유지하는 수준임
2025년 GitHub CTO가 “Azure로 전면 이전해 안정성을 높이겠다”고 발표했을 때부터 불안했음
예전엔 커뮤니티가 “새 기능을 더 빨리 추가하라”고 외쳤지만, 지금은 안정성과 신뢰성이 더 절실함
그래도 GitHub은 새 기능 추가 속도도 여전히 느림
대형 플랫폼만 쓰는 게 아니라면, 작고 지루할 정도로 안정적인 대안들도 존재함
나는 그 시기에 합류했는데, 단순히 내 레포를 공개적으로 공유할 수 있다는 게 신기했음
전반적으로는 업계 전체의 안정성이 좋아졌지만, 지금은 수많은 의존성이 얽혀 있어서 한 곳만 문제여도 전체가 흔들림
Azure로 완전히 전환할 때 IPv6 접근을 깜빡 잊어버리길 바라는 마음임
GitHub은 지금 Azure 이전, AI 기반 인프라 변경, AI 트래픽 폭증이라는 삼중고를 겪고 있음
인기 프로젝트는 이슈 등록 몇 분 만에 AI가 만든 수십 개의 PR이 몰려듦
이런 부하를 감당하기 어렵고, AI 이전의 “N 9s”와 이후의 “N 9s”는 완전히 다른 난이도임
맞음. GitHub은 원래 이런 AI 에이전트 폭주 환경을 전제로 설계되지 않았음
GitHub의 상태 페이지를 보면 실제로 90.21%, 즉 한 개의 9 수준임
과거 2019년 아카이브에서는 한 달에 1~4건이던 장애가 지금은 하루 한 번꼴임
이 수치가 나쁜 이유는 단순한 다운타임뿐 아니라 성능 저하(degraded performance) 도 포함하기 때문임
GitHub이 AI 기능에 집착하는 동안, 플랫폼의 보안은 무너지고 있음
최근 Aqua Security가 공격받아 여러 레포가 감염됐고, 이는 GitHub Actions의 mutable reference 취약점을 악용한 사례임
GitHub은 이 문제를 인지하고도 고치지 않았음
임시 방편으로는 Actions 버전을 해시로 고정(pin) 하는 게 좋음
예: uses: actions/checkout@11bd7190...
자동화 도구는 mheap/pin-github-action 참고
CI/CD가 YAML 기반 복잡성으로 인해 과도하게 꼬였다고 생각함
예전엔 Jenkins로 배포를, 간단한 테스트는 스크립트로 처리했는데 지금은 분산된 YAML 지옥이 되어버림
GitHub Enterprise Server를 직접 운영해본 입장에서는 이런 문제들이 놀랍지 않음 Active-active 미지원, 다운타임 없는 업그레이드 불가, 롤백 불가 등 기본적인 고가용성 요건을 충족하지 못함
버그가 있으면 백업 복원 외엔 방법이 없고, 그 과정에서 데이터 손실이 발생함
이런 제품을 고가 고객에게 판매한다는 건 가용성에 대한 무관심의 증거임
우리 회사도 결국 GHES를 포기하고 GHEC로 마이그레이션했음
Microsoft는 좋은 제품을 망가뜨리는 재능이 있음
Skype가 대표적이고, Windows와 Notepad, Explorer도 마찬가지임
Office → Office 365 → Microsoft 365 → Copilot 365로 이어지는 브랜딩 혼란도 심함
“GitHub for Business”가 나올 날도 머지않았을 듯함
우리 회사는 PR마다 GitHub Actions로 보안 스캔을 돌림
GitHub이 멈추면 보안 게이트도 멈추고, 개발자들이 검증 없이 머지함
이런 상황에서 취약 코드가 유입됨에도, GitHub은 Copilot에만 인력을 쏟고 있음
이에 대한 공개 사례가 있는지 묻는 사람도 있었음
IPv6 무시는 GitHub의 기술 부주의를 상징함
더 큰 문제는 왜 이런 상태에서도 보안 감사를 통과하는가임 GitHub의 보안 문서를 보면 형식적인 수준에 불과함
Hacker News 의견들
Github의 가동률(uptime) 문제는 분명 심각하지만, 모든 기능이 동시에 멈췄다고 해서 “Github 전체가 다운됐다”고 말하는 건 과하다고 생각함
나는 Copilot을 거의 쓰지 않기 때문에 그 서비스가 자주 멈춰도 신경 쓰지 않음
진짜 중요한 건 Git, 웹사이트, API, Actions 같은 핵심 기능들의 안정성임
GitHub의 Enterprise SLA에 따르면 서비스별로 최소 99.9%를 보장해야 하는데, 실제 수치는 여기에서 확인 가능함
Copilot은 한 개의 9 수준이고, 핵심 서비스인 Git과 Actions도 마찬가지임
이런 자원을 가진 회사가 고객을 방치하는 건 변명의 여지가 없음
실제로는 에러 응답만 해도 “정상 작동”으로 계산함
네트워크 업계처럼 진짜로 99.999%를 달성하는 경우는 드물고, 대부분은 데이터 슬라이싱 트릭으로 상태 페이지를 초록색으로 유지하는 수준임
2025년 GitHub CTO가 “Azure로 전면 이전해 안정성을 높이겠다”고 발표했을 때부터 불안했음
예전엔 커뮤니티가 “새 기능을 더 빨리 추가하라”고 외쳤지만, 지금은 안정성과 신뢰성이 더 절실함
GitHub은 지금 Azure 이전, AI 기반 인프라 변경, AI 트래픽 폭증이라는 삼중고를 겪고 있음
인기 프로젝트는 이슈 등록 몇 분 만에 AI가 만든 수십 개의 PR이 몰려듦
이런 부하를 감당하기 어렵고, AI 이전의 “N 9s”와 이후의 “N 9s”는 완전히 다른 난이도임
GitHub의 상태 페이지를 보면 실제로 90.21%, 즉 한 개의 9 수준임
과거 2019년 아카이브에서는 한 달에 1~4건이던 장애가 지금은 하루 한 번꼴임
GitHub이 AI 기능에 집착하는 동안, 플랫폼의 보안은 무너지고 있음
최근 Aqua Security가 공격받아 여러 레포가 감염됐고, 이는 GitHub Actions의 mutable reference 취약점을 악용한 사례임
GitHub은 이 문제를 인지하고도 고치지 않았음
예:
uses: actions/checkout@11bd7190...자동화 도구는 mheap/pin-github-action 참고
예전엔 Jenkins로 배포를, 간단한 테스트는 스크립트로 처리했는데 지금은 분산된 YAML 지옥이 되어버림
90% 가동률은 모든 서비스를 포함한 수치라 실제 체감은 다를 수 있음
하지만 Copilot의 96.47% 조차 한 개의 9에 불과함
GitHub은 “모든 기능을 함께 쓰라”고 권장하지만, 그럴수록 신뢰성이 급격히 떨어짐
예를 들어 단순한 PR diff를 여는 데도 30초 이상 걸림
CI/CD, git, PR 기능이 모두 멈췄던 사례도 있었음
GitHub Enterprise Server를 직접 운영해본 입장에서는 이런 문제들이 놀랍지 않음
Active-active 미지원, 다운타임 없는 업그레이드 불가, 롤백 불가 등 기본적인 고가용성 요건을 충족하지 못함
버그가 있으면 백업 복원 외엔 방법이 없고, 그 과정에서 데이터 손실이 발생함
이런 제품을 고가 고객에게 판매한다는 건 가용성에 대한 무관심의 증거임
Microsoft는 좋은 제품을 망가뜨리는 재능이 있음
Skype가 대표적이고, Windows와 Notepad, Explorer도 마찬가지임
Office → Office 365 → Microsoft 365 → Copilot 365로 이어지는 브랜딩 혼란도 심함
우리 회사는 PR마다 GitHub Actions로 보안 스캔을 돌림
GitHub이 멈추면 보안 게이트도 멈추고, 개발자들이 검증 없이 머지함
이런 상황에서 취약 코드가 유입됨에도, GitHub은 Copilot에만 인력을 쏟고 있음
IPv6 무시는 GitHub의 기술 부주의를 상징함
더 큰 문제는 왜 이런 상태에서도 보안 감사를 통과하는가임
GitHub의 보안 문서를 보면 형식적인 수준에 불과함