# GitHub, 99.9% 가용성 유지에도 버거운 모습

> Clean Markdown view of GeekNews topic #27793. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27793](https://news.hada.io/topic?id=27793)
- GeekNews Markdown: [https://news.hada.io/topic/27793.md](https://news.hada.io/topic/27793.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-24T09:38:24+09:00
- Updated: 2026-03-24T09:38:24+09:00
- Original source: [theregister.com](https://www.theregister.com/2026/02/10/github_outages/)
- Points: 4
- Comments: 5

## Topic Body

- 최근 **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 등 핵심 기능의 불안정성**이 이어지며, **클라우드 기반 개발 플랫폼의 신뢰성 확보**가 중요한 과제로 부상  
- **다운타임 대비 전략 수립**의 필요성이 다시 강조됨

## Comments



### Comment 53847

- Author: elbanic
- Created: 2026-03-26T00:45:06+09:00
- Points: 2

github 무료 서비스인데 고가용성을 기대하는 거 자체가...

### Comment 53941

- Author: cosine20
- Created: 2026-03-27T10:52:15+09:00
- Points: 1
- Parent comment: 53847
- Depth: 1

카톡이 장애 나도 같은 말씀을 하실건지...

### Comment 53912

- Author: malkeu
- Created: 2026-03-26T23:31:34+09:00
- Points: 1

git reset --hard 하면될듯하네요

### Comment 53797

- Author: master6559
- Created: 2026-03-25T13:05:19+09:00
- Points: 1

깃헙 장애만 안나면 지금 이대로가 좋은데

### Comment 53690

- Author: neo
- Created: 2026-03-24T09:38:24+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47487584) 
- Github의 **가동률(uptime)** 문제는 분명 심각하지만, 모든 기능이 동시에 멈췄다고 해서 “Github 전체가 다운됐다”고 말하는 건 과하다고 생각함  
  나는 Copilot을 거의 쓰지 않기 때문에 그 서비스가 자주 멈춰도 신경 쓰지 않음  
  진짜 중요한 건 **Git, 웹사이트, API, Actions** 같은 핵심 기능들의 안정성임  
  - 동의함. 하지만 지난 90일 동안 어떤 개별 서비스도 **3x9(99.9%)** 가동률을 달성하지 못했음  
    GitHub의 [Enterprise SLA](https://github.com/customer-terms/github-online-services-sla)에 따르면 서비스별로 최소 99.9%를 보장해야 하는데, 실제 수치는 [여기](https://mrshu.github.io/github-statuses/)에서 확인 가능함  
  - “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의 [상태 페이지](https://mrshu.github.io/github-statuses)를 보면 실제로 **90.21%**, 즉 한 개의 9 수준임  
  과거 [2019년 아카이브](https://web.archive.org/web/20190510070456/https://www.githubstatus.com)에서는 한 달에 1~4건이던 장애가 지금은 하루 한 번꼴임  
  - 이 수치가 나쁜 이유는 단순한 다운타임뿐 아니라 **성능 저하(degraded performance)** 도 포함하기 때문임  
  - 그래도 Claude의 [status.claude.com](https://status.claude.com)보다는 낫다고 농담함  

- GitHub이 **AI 기능에 집착**하는 동안, 플랫폼의 보안은 무너지고 있음  
  최근 Aqua Security가 공격받아 여러 레포가 감염됐고, 이는 GitHub Actions의 **mutable reference 취약점**을 악용한 사례임  
  GitHub은 이 문제를 인지하고도 고치지 않았음  
  - 임시 방편으로는 Actions 버전을 **해시로 고정(pin)** 하는 게 좋음  
    예: `uses: actions/checkout@11bd7190...`  
    자동화 도구는 [mheap/pin-github-action](https://github.com/mheap/pin-github-action) 참고  
  - CI/CD가 **YAML 기반 복잡성**으로 인해 과도하게 꼬였다고 생각함  
    예전엔 Jenkins로 배포를, 간단한 테스트는 스크립트로 처리했는데 지금은 **분산된 YAML 지옥**이 되어버림  
  - “스위스 치즈보다 더 구멍이 많다”는 표현이 나올 정도로 GHA의 보안은 심각함  
  - 이런 문제를 수년째 방치한 [커뮤니티 토론](https://github.com/orgs/community/discussions/142308)도 있음  

- 90% 가동률은 모든 서비스를 포함한 수치라 실제 체감은 다를 수 있음  
  하지만 Copilot의 **96.47%** 조차 한 개의 9에 불과함  
  GitHub은 “모든 기능을 함께 쓰라”고 권장하지만, 그럴수록 **신뢰성이 급격히 떨어짐**  
  - 게다가 “느리지만 작동하는” 경우는 통계에 포함되지 않음  
    예를 들어 단순한 PR diff를 여는 데도 30초 이상 걸림  
  - 일부 장애는 공식적으로 **늦게 보고**되기도 함  
    CI/CD, git, PR 기능이 모두 멈췄던 사례도 있었음  
  - [2019년 데이터](https://web.archive.org/web/20190510070456/https://www.githubstatus.com)와 비교하면 지금은 **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의 보안 문서](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-security-settings/about-security-overview)를 보면 형식적인 수준에 불과함  
  - 감사 품질도 **아키텍처 수준과 비슷하게 형편없음**