▲

여러 GitHub 서비스 장애 사고

 (githubstatus.com)
1P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 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는 준비되는 대로 공유될 예정임

참고 링크

함께 보면 좋은 글 β

▲
GN⁺ 19시간전  [-]
Hacker News 의견들

  • 집에서 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/를 보면 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
    • GitHub가 Azure 이전을 우선하기 시작한 것과 상관관계가 있는지 궁금함
      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시간쯤 더 필요할 것 같음

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

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

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

  • 오늘 또 아주 심각한 사고가 있었음: 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/

    • tangled.org는 어떨까 싶음

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

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.