# 여러 GitHub 서비스 장애 사고

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28860](https://news.hada.io/topic?id=28860)
- GeekNews Markdown: [https://news.hada.io/topic/28860.md](https://news.hada.io/topic/28860.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-25T06:33:08+09:00
- Updated: 2026-04-25T06:33:08+09:00
- Original source: [githubstatus.com](https://www.githubstatus.com/incidents/myrbk7jvvs6p)
- Points: 1
- Comments: 1

## Topic Body

- **Webhooks, Actions, Copilot**을 포함한 여러 GitHub 서비스에서 가용성 저하와 이용 불가가 함께 발생함
- 초기에는 **Copilot과 Webhooks**의 가용성 저하를 조사했고, 이후 여러 서비스 장애로 조사 범위가 확대됨
- **Actions**는 별도로 성능 저하를 겪었고, 근본 문제가 확인된 뒤 완화 작업이 진행됨
- Actions와 Copilot의 저하가 완화된 뒤 안정성 모니터링과 남은 서비스들에 대한 **검증 작업**이 이어졌고, Webhooks도 정상 동작으로 복구됨
- 이번 장애는 최종적으로 **해결 완료** 상태로 종료됐고, 상세한 root cause analysis는 준비되는 대로 공유될 예정임

---

### 장애 경과
- GitHub의 **여러 서비스 장애**가 발생했고, 영향 범위에는 **Webhooks, Actions, Copilot**이 포함됨
- 초기에는 Copilot과 Webhooks의 **가용성 저하**를 조사하기 시작함
- 이후 여러 서비스가 **이용 불가 상태**를 보이며 조사 범위가 확대됨
- Actions는 별도로 **성능 저하**를 겪었고, 원인 파악이 계속 진행됨
- 근본 문제가 확인된 뒤 **완화 작업**이 진행됨
- Actions와 Copilot에 영향을 준 저하는 완화됐고, 안정성 유지를 위한 모니터링이 이어짐
- 많은 서비스에 대한 완화가 진행된 뒤 남은 서비스들에 대한 **검증 작업**도 이어짐
- Webhooks도 정상 동작으로 복구됨
- 최종적으로 이번 장애는 **해결 완료** 상태로 종료됐고, 상세한 root cause analysis는 준비되는 대로 공유될 예정임

### 참고 링크
- [GitHub Status 메인 페이지](https://www.githubstatus.com/)
- [현재 상태](https://www.githubstatus.com/)
- [지원 사이트](https://github.com/support)

## Comments



### Comment 56259

- Author: neo
- Created: 2026-04-25T06:33:09+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47877644) 
- 집에서 **self-hosting**으로 이것저것 옮기는 중이었고, 어제 드디어 집 안에 **Forgejo 인스턴스**를 완성했음  
  Linux, Windows는 VM으로, macOS는 Mac Mini로 CI/CD runner까지 붙여서 이제 소스 코드와 Actions, 실제 인프라가 전부 진짜로 집 안에 있게 됐음  
  보통 self-hosting으로 옮기고 나서 만족감이 오기까지 한두 달 걸리는데, 이번엔 마이그레이션 끝난 바로 다음 날부터 이 선택이 옳았다는 확신이 들어서 꽤 기분 좋았음
  - **homelab** 아이디어는 늘 끌리는데, 막상 만들기 시작하면 금방 지침  
    하루 종일 회사에서 망가진 시스템 고치고 나면 집에 와서 내 **개인 sysadmin** 역할까지 맡고 싶지는 않음  
    크리스마스에 산 괜찮고 성능 좋은 Minisforum도 책상 위에 있지만 아직 전원조차 안 켰음
  - self-hosting을 시작하면 **현대 웹**이 얼마나 느린지 바로 체감하게 됨  
    Forgejo를 NUC 한 대와 Proxmox 위의 여러 서비스와 함께 돌리는데 페이지 로드가 **6ms** 정도임  
    Immich는 그만큼 빠르진 않아도 여전히 Google Photos보다 훨씬 빠름
  - 한동안 **개인 Forgejo**를 운영하면서 사적인 사이드 프로젝트를 전부 거기에 올려두고 있음  
    UI는 대체로 비슷한데도 **GitHub보다 훨씬 쾌적**함. 이유가 uptime이 90%를 넘는다는 것만으로도 충분할 정도임  
    요즘 GitHub 관련 이슈는 너무 자주 겪고 있고, 사이트를 그냥 둘러보는 것조차 느리거나 아예 멈춰버릴 때가 많음
  - 나도 최근에 이렇게 옮겼는데, 제일 놀란 건 **Actions 속도**가 GitHub보다 훨씬 빠르다는 점이었음  
    Linux와 macOS는 Mac Mini와 Claude가 생성한 Ansible task file로 세팅했지만, **Windows VM** 구성은 꽤 고통스러워 보였음  
    혹시 배포 과정을 단순화할 방법을 찾았는지 궁금함
  - 어제 여기서 **gitea** 얘기 보고 조금 찾아본 뒤, 나도 바로 self-hosting으로 옮겨서 개인 프로젝트를 전부 **Forgejo**로 이전했음  
    다만 공개 프로젝트는 취업 시장과 GitHub의 네트워크 효과 때문에 옮기기 어렵더라  
    지금은 필요한 것들 때문에 로컬 서비스 20개쯤 굴리면서 시스템 관리자 놀이를 하는 기분이고, 가장 중요한 건 이제 데이터 유실을 막는 책임이 내게 있으니 **정기 백업**을 꼭 갖추는 일임

- [https://mrshu.github.io/github-statuses/](<https://mrshu.github.io/github-statuses/>)를 보면 uptime이 **88.15%** 까지 내려감  
  개별 컴포넌트 기준으로 봐도 최고가 **99.78%** 라서 겨우 two nines 수준임
  - 다뤄야 하는 **성장 규모**가 말이 안 될 정도로 큼  
    2025년에는 10억 커밋이었는데 이제 주당 2억 7500만 커밋이고, 선형 성장만 가정해도 올해 140억 커밋 페이스라고 함  
    GitHub Actions도 2023년 주당 5억 분에서 2025년 10억 분으로 늘었고, 이번 주는 현재까지 **21억 분**이라고 함  
    출처는 GitHub COO의 2026-04-03 게시물임 [https://x.com/kdaigle/status/2040164759836778878](<https://x.com/kdaigle/status/2040164759836778878>)
  - GitHub가 **Azure 이전**을 우선하기 시작한 것과 상관관계가 있는지 궁금함  
    [https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/](<https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/>)
  - Microsoft가 밀어붙이는 **AI**가 self-hoster와 Linux 애호가들한테는 정말 큰 도움을 주는 셈임

- 이런 장애가 반복돼도 GitHub가 **유의미한 비즈니스 손실**을 실제로 보고 있는지 궁금함  
  업계에서는 오랫동안 신뢰성과 브랜드 가치가 핵심이라고 했는데, 요즘은 그걸 거의 신경 안 쓰는 듯 보임  
  내 인식이 틀렸다면 기꺼이 바로잡고 싶음
  - 불과 2~3년 전만 해도 소프트웨어를 안정적이고 안전하게 배포하려면 **repeatable builds**, 검증된 chain of custody, 감사 가능한 bill of materials가 필수라고 거의 모두가 동의했음  
    그런데 **LLM**이 좀 좋아지자 그 얘기는 통째로 사라져버린 느낌임
  - GitHub는 이미 너무 **뿌리내린 플랫폼**이라 이런 장애도 그냥 사업 비용으로 처리되는 분위기임  
    대기업은 내부 인스턴스로 어느 정도 방어돼 있고, 나머지는 그렇게까지 치명적이지 않거나 자체 솔루션을 만들거나 옮길 자원이 없음
  - **GitHub에서 GitLab**로 가는 건 프라이팬에서 나와 불 속으로 들어가는 격일 수도 있음  
    규모 있게 쓰는 사람들에게 정말 괜찮은 대안이 있으면 좋겠음

- 90일 롤링 기간 기준으로 **two nines** 아래로 떨어지려면 추가 장애가 대략 **16시간**쯤 더 필요할 것 같음
  - [https://mrshu.github.io/github-statuses/](<https://mrshu.github.io/github-statuses/>)를 보면 합산 uptime은 **1 nine**도 못 채우는 듯함
  - 이 속도면 GitHub는 **eight 8’s**를 노리는 셈임

- 걱정할 필요 없다고 해야 하나, status page는 여전히 **초록불 100% 정상**이라고 말함  
  정적 페이지 하나에도 접근이 안 되는데도 말임

- 이제는 GitHub 서비스에 **문제가 없는 날**이 올라올 때마다 HN 글이 하나씩 떠야 할 지경임  
  아니면 그게 그냥 평소 상태라는 뜻이 됨

- 예전에 Bitbucket 쪽에서 여러 repo에 걸쳐 **git history 하루치**를 날린 적이 있었음  
  장애라기보다 그쪽 데이터 문제였고, 로컬 clone 덕분에 대부분은 살렸지만 그 시간대의 이슈와 PR은 그냥 사라졌음  
  그래서 사이드 프로젝트로 **gitbacker**를 만들기 시작했음  
  repo 자체를 백업하는 건 쉬운데, 진짜 흥미로운 부분은 **metadata** 백업임

- 오늘 또 아주 심각한 사고가 있었음: [https://www.githubstatus.com/incidents/zsg1lk7w13cf](<https://www.githubstatus.com/incidents/zsg1lk7w13cf>)  
  merge queue를 squash merge나 rebase와 함께 쓸 때 생긴 회귀 때문에, 2026-04-23 16:05-20:43 UTC 사이 일부 PR이 잘못 merge됐다고 함  
  우리 쪽은 그 시간 동안 기본 브랜치에서 **커밋 8개 정도가 통째로 되돌려졌음**  
  GitHub incident 중에서도 이렇게 심각한 건 처음 봤음
  - **다운타임**은 한 가지 문제지만, 기본 브랜치의 커밋을 조용히 되돌리는 건 완전히 다른 차원의 실패임
  - 우리도 비슷했음  
    원래 merge conflict를 막으라고 있는 도구가 오히려 **메인라인 브랜치**에 엉망이 된 커밋을 직접 써넣고 있었으니 아이러니함
  - 우리도 main에서 **커밋 여러 개가 사라졌는데**, PR 상태는 계속 merged로 남아 있었음  
    정말 스트레스가 컸음
  - 우리도 여러 repo에서 **PR들이 되돌려졌음**  
    다운타임도 문제지만 PR을 되돌리는 건 한 단계 더 심각한 실패임
  - 우리도 영향받은 커밋 목록과 복구 방법이 담긴 **PDF 첨부 이메일**을 받았음  
    정말 난장판이었음

- 우리 요구사항은 **git repos + actions** 정도로 단순한 편이고, 가끔 있는 다운타임도 계속 커밋하고 배포하는 팀이 아니라서 아주 치명적이진 않음  
  그래도 이제는 대안을 진지하게 찾는 중임  
  마침 대안을 찾으려는 사람들이 몰렸는지 **SourceHut**도 내려갔더라. 글 쓸 당시엔 다운이었고 지금은 다시 올라옴  
  [https://sr.ht/](<https://sr.ht/>)
  - **tangled.org**는 어떨까 싶음

- 오늘만 해도 incident가 **세 번**, 각각 거의 1시간 이상 있었는데 일일 상태는 전부 초록색이고 **기록된 다운타임 없음**으로 나옴  
  예전 빨간 막대가 찍히던 incident들과 본질적으로 달라 보이지도 않고, 길이가 몇 시간은 아니었다는 정도만 차이인 듯함  
  그럼 저 초록 막대는 대체 뭘 뜻하는지 모르겠음  
  사람들이 충분히 불평해야 나중에 비초록으로 바뀌는 건지, 아니면 당일 incident는 툴팁에만 잠깐 보였다가 나중에 슬쩍 잊히는 건지 의심스러움  
  지금까지의 초록색 날짜들은 툴팁에 incident가 하나도 안 뜨는데 오늘만 여러 개가 보이는 걸 보면, 어느 쪽이든 **의도적으로 오해를 부르는 표시**처럼 느껴짐
