▲

GitHub, 99.9% 가용성 유지에도 어려움 겪는 중

 (theregister.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 최근 GitHub의 잦은 서비스 장애가 이어지며, 업계 표준인 ‘5 nines(99.999%)’ 는커녕 ‘3 nines(99.9%)’ 달성도 어려운 상황
  • 2월 9일에는 Actions, Pull Request, 알림, Copilot 등 주요 기능이 동시 장애를 겪었고, 일부 서비스는 수 시간 이상 지연 발생
  • Copilot 정책 전파 문제로 인해 일부 사용자는 2월 10일 오전까지 모델 표시 오류를 경험
  • GitHub가 상태 페이지 구조를 변경하면서 최근 90일간의 가용성 추적이 어려워졌고, 비공식 데이터에서는 가용성 90% 이하 시점도 확인됨
  • Enterprise Cloud SLA가 99.9% 업타임을 명시하지만, 실제로는 모든 사용자에게 보장되지 않아 다운타임 대비 운영 전략의 필요성이 커짐

GitHub의 가용성 저하와 잦은 서비스 장애

  • 클라우드 서비스의 잦은 장애가 일반화되는 가운데, GitHub 역시 안정성 문제를 겪고 있음
    • “하루라도 장애 없는 날이 드물다”는 표현이 등장하며, ‘5 nines(99.999%)’ 는커녕 ‘1 nine(90%)’ 도 어려운 상황으로 언급됨
  • 2월 9일(UTC 기준) GitHub의 주요 기능인 Actions, Pull Request, 알림, Copilot이 모두 장애를 겪음
    • GitHub는 15시 54분경 “일부 서비스에 문제가 있다”고 공지했고, 알림 지연이 약 50분에 달한다고 발표
    • 17시 57분에는 지연이 약 30분으로 줄었으며, 19시 29분에 정상화되었다고 알림
  • Copilot 관련 장애는 더 길게 지속됨
    • 2월 9일 16시 29분부터 2월 10일 9시 57분까지 일부 사용자에게 Copilot 정책 전파 문제가 발생
    • 이로 인해 새로 활성화된 모델이 사용자에게 표시되지 않는 현상이 보고됨
  • GitHub는 상태 페이지 구조를 변경해 최근 90일간의 가용성 추적이 어려워짐
    • 세부 정보는 제공되지만, 전체적인 업타임 추세를 시각적으로 파악하기 어려운 형태로 바뀜
    • 비공식 복원 페이지(mrshu.github.io/github-statuses/)의 데이터에서는 2025년 한때 가용성이 90% 이하로 하락한 시점이 확인됨
  • GitHub의 Enterprise Cloud SLA는 99.9% 업타임을 명시하지만, 모든 사용자에게 이를 보장하지 않음
    • 업계에서는 ‘5 nines’가 이상적 기준으로 여겨지지만, 일부 업체는 90% 유지조차 어려운 현실로 평가됨
    • 이러한 상황은 고객이 다운타임을 전제로 한 운영 계획을 마련해야 함을 시사

관련 맥락 및 사례

  • GitHub는 최근 AI 기능과 정책 변화로 여러 논란을 겪음
    • Pull Request에 대한 AI 코드 차단용 ‘킬 스위치’ 검토

    • 자체 호스팅 러너 요금제 계획 철회

      • Zig 언어 프로젝트가 Microsoft의 AI 중심 정책을 이유로 GitHub를 떠난 사례 존재
      • 이러한 사건들과 함께 서비스 안정성 저하가 개발자 커뮤니티의 불만을 키우는 요인으로 작용

결론

  • GitHub의 최근 장애는 ‘세 개의 9(99.9%)’조차 달성하기 어려운 가용성 문제를 드러냄
  • Copilot 등 핵심 기능의 불안정성이 이어지며, 클라우드 기반 개발 플랫폼의 신뢰성 확보가 중요한 과제로 부상
  • 다운타임 대비 전략 수립의 필요성이 다시 강조됨
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 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) 도 포함하기 때문임
    • 그래도 Claude의 status.claude.com보다는 낫다고 농담함

  • GitHub이 AI 기능에 집착하는 동안, 플랫폼의 보안은 무너지고 있음
    최근 Aqua Security가 공격받아 여러 레포가 감염됐고, 이는 GitHub Actions의 mutable reference 취약점을 악용한 사례임
    GitHub은 이 문제를 인지하고도 고치지 않았음

    • 임시 방편으로는 Actions 버전을 해시로 고정(pin) 하는 게 좋음
      예: uses: actions/checkout@11bd7190...
      자동화 도구는 mheap/pin-github-action 참고
    • CI/CD가 YAML 기반 복잡성으로 인해 과도하게 꼬였다고 생각함
      예전엔 Jenkins로 배포를, 간단한 테스트는 스크립트로 처리했는데 지금은 분산된 YAML 지옥이 되어버림
    • “스위스 치즈보다 더 구멍이 많다”는 표현이 나올 정도로 GHA의 보안은 심각함
    • 이런 문제를 수년째 방치한 커뮤니티 토론도 있음

  • 90% 가동률은 모든 서비스를 포함한 수치라 실제 체감은 다를 수 있음
    하지만 Copilot의 96.47% 조차 한 개의 9에 불과함
    GitHub은 “모든 기능을 함께 쓰라”고 권장하지만, 그럴수록 신뢰성이 급격히 떨어짐

    • 게다가 “느리지만 작동하는” 경우는 통계에 포함되지 않음
      예를 들어 단순한 PR diff를 여는 데도 30초 이상 걸림
    • 일부 장애는 공식적으로 늦게 보고되기도 함
      CI/CD, git, PR 기능이 모두 멈췄던 사례도 있었음
    • 2019년 데이터와 비교하면 지금은 10배 이상 악화됨
    • 96%는 정말 끔찍한 수치임

  • 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의 보안 문서를 보면 형식적인 수준에 불과함

    • 감사 품질도 아키텍처 수준과 비슷하게 형편없음
답변달기