▲

GitHub에서 Issues, Actions 및 Git 작업 관련 장애 발생

 (githubstatus.com)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • GitHub의 Actions, Issues, Git 작업 등 주요 서비스에서 성능 저하 및 오류가 보고됨
  • 영향 범위는 Webhooks, Pull Requests, Packages, Pages, Codespaces 등으로 확산됨
  • GitHub은 완화 조치(mitigation) 를 적용해 점진적 복구를 확인했으며, 이후 모든 서비스가 정상화됨
  • 장애는 Dependabot, Copilot 등 일부 서비스에도 영향을 미쳤으나, 최종적으로 정상 처리 상태로 복귀함
  • GitHub은 근본 원인 분석(RCA) 을 추후 공개할 예정이며, 사용자에게 인내와 협조에 감사를 표함

장애 개요

  • GitHub은 Actions, Git Operations, Issues에서 성능 저하 보고를 조사 중이라고 발표
    • 초기 단계에서 느린 응답 및 실패 요청, 지연된 Actions 작업이 관찰됨
    • 장애는 2026년 2월 9일 19:01 UTC에 처음 보고됨

영향받은 서비스

  • 영향을 받은 구성 요소는 Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
    • 이후 Dependabot과 Copilot에서도 문제가 확인됨
    • 각 서비스는 “degraded performance(성능 저하)” 상태로 표시됨

대응 및 복구 과정

  • GitHub은 완화 조치를 적용한 후 복구 신호를 관찰했다고 보고
    • 19:29 UTC 이후 점진적 회복이 진행됨
    • 19:54 UTC에는 다수의 서비스가 복구되었으나 일부는 여전히 조사 중이었음
  • 20:08 UTC에는 “모든 서비스가 정상 처리 중”으로 보고됨
    • 20:09 UTC에 장애 해결(Resolved) 상태로 전환됨

최종 상태 및 후속 조치

  • GitHub은 모든 서비스가 정상 운영 상태로 돌아왔다고 명시
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, Webhooks 모두 정상화
  • 근본 원인 분석(Root Cause Analysis) 은 준비되는 대로 공유 예정
  • 사용자에게 인내와 이해에 감사를 표명

요약

  • 이번 장애는 GitHub 핵심 개발 워크플로우 전반에 영향을 미친 사건
  • 복구 완료 후 RCA 공개 예정으로, 향후 유사 장애 방지를 위한 개선이 예상됨
  • 동일 날짜에 또 다른 장애가 보고된 점에서 안정성 관리 중요성이 부각됨
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • GitHub의 지속적인 부분 장애 때문에 회사 전체를 다른 벤더로 옮길까 고민 중임
    예전엔 잘 작동하던 기능들이 이제는 느리고, Actions도 제때 실행되지 않음
    Copilot도 좋지만, 결국 git forge가 제대로 작동하지 않으면 떠날 수밖에 없음

    • 완전 공감함. 예전엔 훌륭했는데 이제는 기본 기능조차 불안정함
      단순한 PR diff를 여는 데도 15초 이상 걸리고, UI가 멈춘 듯한 상태가 반복됨
      이런 비정상적인 성능 저하를 당연하게 받아들이는 게 놀라움
    • “Copilot을 즐긴다”는 말이 농담처럼 들림
    • 아이러니하게도 Linus Torvalds는 중앙화 없는 구조를 위해 git을 설계했음
      결국 로컬에서도 CI 파이프라인을 돌릴 수 있는 게 git의 본질임
      나는 GH를 단순히 동기화용으로만 사용함
    • 예전엔 GitHub가 postmortem을 자주 공개했는데, 최근엔 거의 없음
      예전 글을 보면 SQL DB의 스케일링 한계에 부딪히고 있었음
      OpenAI의 Postgres 확장 사례와 비슷하지만, GitHub는 그만큼 잘 대응하지 못하는 듯함
    • “신뢰성 있는 제품을 기대하는 건 무리”라며 Microsoft의 문제로 봄

  • GitHub의 잦은 장애가 오히려 배포 파이프라인 복원력을 점검하는 계기가 됨
    대부분의 팀이 GitHub에 완전히 의존해 있어서 장애 시 배포가 멈춤
    그래서 다음과 같은 대안을 시도함

    1. 중요 repo를 GitLab이나 Gitea에 미러링
    2. 빌드 실패 방지를 위한 의존성 캐싱
    3. GitHub Actions 없이 수동 배포 가능한 런북(runbook) 마련
      공식 상태 페이지는 항상 늦게 업데이트되어, 이제는 “eventually consistent” 한 정보로만 취급함

  • GitHub가 자동화된 개발 워크플로우 폭증으로 인한 부하를 받고 있을지도 모름
    개인 repo의 커밋이 폭발적으로 늘었지만 유료 전환은 거의 없음

    • 문제는 Microsoft 인수 이후 이미 시작되었음
      2019년 비공개 repo 무료화로 인해 수익화 기회를 놓쳤다고 봄
    • 실제로는 AWS에서 Azure로의 마이그레이션 중이라 장애가 잦음
      그리고 다운타임에 대한 책임 의식이 부족함
    • 결국 스케일링 한계에 부딪힌 상황임
    • AI 코드 생성으로 인해 repo와 커밋, 데이터셋이 폭발적으로 증가함
    • “AI Agent 붐에 살고, AI Agent 붕괴에 죽는다”는 말로 요약함

  • GitLab이 대안이라고 주장함
    GitHub는 이제 AI 중심 전략에만 몰두하고, 플랫폼 자체는 뒷전임
    Copilot 채택률도 낮고, 기업들은 Claude를 더 많이 사용함
    Microsoft가 방향을 바꾸면 상황이 더 악화될 것임

    • Copilot이 자체 모델인지 묻는 질문이 나옴
    • 하지만 GitLab도 완벽하지 않음
      기능이 반쯤 완성된 상태로 출시되고, 속도도 느림
      오픈코어 모델의 장점도 이제는 희미함
    • GitLab 역시 AI 중심으로 변함
      Dev → DevOps → DevSecOps → AI DevSecOps로 진화했지만
      각 단계마다 완성도가 떨어지고, 라이선스 업그레이드가 필수라 불편함

  • CI/CD와 코드 호스팅을 하나로 묶는 구조 자체가 문제라고 봄
    완벽히 작동하더라도 결국 벤더 종속(lock-in) 을 피할 수 없음
    원래는 remote만 바꾸면 끝나야 하지만, 이제는 PR, wiki 등으로 얽혀버림

    • 사실 이건 실수가 아니라 의도된 락인 전략이라고 생각함
    • 오픈소스 솔루션인 forgejo처럼 독립적인 CI 시스템을 쓰면 좀 낫다고 봄

  • 이제 GitHub의 장애는 단순 SaaS 문제가 아니라 클라우드 수준의 장애로 느껴짐
    그래서 많은 팀이 자체 호스팅 GitLab/Gitea로 전환 중임

    • 두 스타트업에서 GitLab을 성공적으로 사용했음
      대기업은 보안상 이유로 온프레미스 GitLab Enterprise를 사용했고,
      개인 프로젝트는 Forgejo로 운영 중임
      Git, 이슈, 보드, 위키 모두 잘 작동하며, scoped 라벨은 무료임
    • Gitea 자가 호스팅도 괜찮음. 백업 관리만 잘하면 됨
    • GitLab 풀 버전 자가 호스팅은 비용 대비 충분히 가치 있음
    • GitLab 자가 호스팅은 확실히 만족스러움

  • GitHub의 다중 장애 기록을 시각화한 페이지가 있음
    mrshu.github.io/github-statuses에서 확인 가능함

    • updog.ai/status/github도 Datadog 데이터를 기반으로 함
    • 다만 업데이트가 멈춘 듯 보임 (마지막은 2월 6일)

  • “GitHub 팀, 천천히 해도 괜찮다”는 농담 섞인 코멘트도 있음

  • GitHub를 떠나고 싶지만, 안정적인 CI와 컨테이너 레지스트리가 필요함
    “그냥 잘 작동하는” 솔루션이라면 비용을 지불할 의향이 있음

    • Forgejo + Firecracker VM 기반 CI를 제공하는 Lithus.eu를 추천함
      대규모 워크로드에 적합하지만 초기 비용이 높음
    • GitLab CI는 단순하면서도 강력함
      레지스트리 권한 관리가 약간 복잡하지만 전체 통합이 잘 되어 있음
    • repo가 CI를 책임져야 하는지 의문임
      유닉스 철학처럼 단일 목적 도구로 돌아가야 한다고 봄
    • nix-ci.com을 추천하는 사람도 있음
    • CircleCI도 여전히 잘 작동하는 대안임

  • AI 도입률과 장애 빈도의 상관관계를 그래프로 보면 흥미로울 것 같음

    • 물론 다른 요인들도 함께 작용하고 있을 것임
답변달기