▲

Issues와 Webhooks 장애 – 해결됨

 (githubstatus.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • GitHub는 Issues와 Webhooks 성능 저하를 조사한 뒤 2026년 5월 4일 16:40 UTC에 장애를 해결됨 상태로 전환함
  • 이번 장애는 Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces에 영향을 줌
  • 15:45 UTC에 Issues와 Webhooks 성능 저하 조사가 시작됐고, 15:48 UTC에는 여러 GitHub 서비스의 지연 증가와 타임아웃 조사로 확대됨
  • 16:25 UTC부터 Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces, Webhooks가 차례로 정상화되거나 완화됨
  • GitHub는 서비스 전반의 지연 시간이 정상화됐으며, 재발 방지와 근본 원인 분석을 계속 진행해 준비되는 대로 공유하겠다고 밝힘

장애 개요

  • GitHub는 Issues와 Webhooks 성능 저하 보고를 조사한 뒤 장애가 해결됐다고 공지함
  • 장애는 Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces에 영향을 줌
  • GitHub는 문제 처리 동안 기다려 준 사용자에게 감사를 전했으며, 상세한 근본 원인 분석은 준비되는 대로 공유하겠다고 밝힘

진행 경과

  • 조사 시작

    • 2026년 5월 4일 15:45 UTC에 Issues와 Webhooks 성능 저하 보고를 조사 중이라고 공지됨
    • 15:48 UTC에는 여러 GitHub 서비스에서 지연 증가와 타임아웃을 조사 중이라고 확대 공지됨

  • 영향 서비스 확대

    • 15:48 UTC에 Git Operations가 성능 저하를 겪고 있다고 공지됨
    • 15:50 UTC에 Packages가 성능 저하를 겪고 있다고 공지됨
    • 15:51 UTC에 Actions가 성능 저하를 겪고 있다고 공지됨
    • 15:51 UTC에 Pull Requests가 가용성 저하를 겪고 있다고 공지됨
    • 15:56 UTC에 Pull Requests가 성능 저하를 겪고 있다고 공지됨
    • 16:05 UTC에 Codespaces가 성능 저하를 겪고 있다고 공지됨
    • 16:06 UTC에 Pages가 성능 저하를 겪고 있다고 공지됨

  • 정상화와 완화

    • 16:25 UTC에 Git Operations가 정상 동작한다고 공지됨
    • 16:28 UTC에 Actions와 Packages가 정상 동작한다고 공지됨
    • 16:29 UTC에 Pages가 정상 동작한다고 공지됨
    • 16:29 UTC에 서비스 전반의 지연 시간이 정상화됐으며, 근본 원인 조사와 재발 방지를 계속 진행 중이라고 공지됨
    • 16:32 UTC에 Pull Requests가 정상 동작한다고 공지됨
    • 16:34 UTC에 Issues에 영향을 준 성능 저하가 완화됐고 안정성 확인을 위해 모니터링 중이라고 공지됨
    • 16:35 UTC에 Codespaces에 영향을 준 성능 저하가 완화됐고 안정성 확인을 위해 모니터링 중이라고 공지됨
    • 16:35 UTC에 Webhooks가 정상 동작한다고 공지됨

  • 해결

    • 16:36 UTC에 성능 저하가 완화됐으며 안정성 확인을 위해 모니터링 중이라고 공지됨
    • 16:40 UTC에 장애가 해결됨 상태로 전환됨
    • 상세한 근본 원인 분석은 제공 가능해지는 즉시 공유될 예정임

함께 보면 좋은 글 β

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

  • GitHub가 에이전트형 코딩 증가 때문이라며 놀라운 사용량 증가 수치를 공개했는데, 결국 어느 시점에는 속도 제한을 바꾸거나 무료 티어 사용량을 줄이거나 부하를 낮출 다른 방법을 찾아야 할 것 같음
    인프라가 이 증가세를 따라가지 못하는 게 분명해 보이고, 늘어난 비용을 GitHub가 그대로 떠안지는 않을 가능성이 큼. 앞으로 GitHub가 어떻게 될지 궁금함

    • 4월 3일 GitHub COO가 이미 플랫폼 활동이 급증 중이라고 밝혔음
      2025년에 커밋이 10억 개였는데, 지금은 주당 2억 7,500만 개로 선형 증가만 해도 올해 140억 개 페이스라고 함. GitHub Actions도 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 이번 주에는 이미 21억 분에 도달함
      CPU 추가, 서비스 확장, GitHub 핵심 기능 강화에 매우 강하게 밀어붙이고 있다고 함
      https://x.com/kdaigle/status/2040164759836778878
      가용성 관련 최근 블로그 글도 있음: https://github.blog/news-insights/company-news/an-update-on-...
      GitHub 엔지니어들이 겪는 확장성 문제는 정말 만만치 않아 보임
    • 수십 년 동안 관찰해 보면, 각 작업을 싸게 만드는 시스템과 열심히 수평 확장하는 시스템이 있는데 전자가 후자를 크게 이기는 경우가 많았음
      예를 들어 GitHub는 저장소의 /pulls 페이지를 검색 쿼리처럼 구현한 것 같고, 미리 채워진 검색창이 그 힌트였으며 지난주 검색 백엔드 장애 때 풀 리퀘스트가 로드되지 않으면서 거의 확인됐음. 하지만 열린 풀 리퀘스트만 불러오는 평범한 API 호출로도 구현할 수 있었고, 그 API는 존재하며 장애가 나지 않았음
      GitHub가 페이지 로드와 그에 딸린 API 호출 같은 상위 95% 수준의 작업을 찾아 효율화하는 데 집중하면, 단순화만으로도 백엔드 부하를 5배 이상 줄일 수 있을 것 같음
      diff 뷰어도 개선 여지가 많아 보임. 끔찍한 비효율의 상당 부분은 백엔드를 직접 로드하지 않는 프런트엔드 쪽이겠지만, 평범한 git 명령줄 기능은 매우 빠름
    • 이제 돌아올 수 없는 지점에 가까워진 것 같음. 무료와 유료 인프라를 분리하지 않는 한, 스스로 판 구덩이를 수평 확장만으로 빠져나올 수 있을지 모르겠음
      누군가가 제품을 바꾸게 하려면 10배 더 좋아야 하는 것처럼, 기존 제품이 10배 나빠지면 경쟁자는 가만히 있어도 공짜로 10배 이득을 얻음
    • 일주일 전 GitHub가 블로그에 이런 내용을 올리고, 하루 뒤 GitHub 임원들이 HN 댓글에서 반복하자, 2019년 이후 이어진 신뢰성 하락이 2019년 Microsoft 통합 때문이 아니라 2023년에야 등장한 무언가 때문이라는 게 순식간에 상식처럼 굳어졌음
      PR은 효과가 있음. GitHub가 안 되는 이유가 너무 잘나가기 때문이라는 결론이 됐음
    • LinkedIn 서버 용량을 전부 GitHub로 재배치하는 데 강하게 찬성해 왔음

  • https://mrshu.github.io/github-statuses에 따르면 GitHub의 최근 90일 가동률이 84.92% 임
    이게 어떻게 조금이라도 받아들일 만한 수준인지 모르겠음

    • 그 사이트는 중단 시간을 과다 집계하는 것 같음. HN 첫 페이지에 오를 만한 major와 critical 장애만 필터링해도 여전히 나쁘지만, 84.92%만큼 나쁘지는 않음
      https://isgithubcooked.com/?severities=major.critical
    • 받아들일 만하지 않음. 요즘 받아들일 수 없는 일이 많이 벌어지는데 모두가 별문제 없이 받아들이는 것처럼 보임
    • three nines는커녕 two eights도 못 맞추고 있음

  • 이제 성능이 받아들이기 어려운 수준까지 왔음. GitHub 때문에 업무가 끊기지 않는 주가 없음

    • AI 에이전트가 사실상 인터넷 전체의 확장성 특성을 바꿔 놓았음
      예전에는 GitHub가 제한된 수의 사람이 사람다운 방식과 관찰 가능한 패턴으로 플랫폼을 사용한다고 가정할 수 있었고, 그 패턴에 맞춰 확장하고 UI/UX 병목을 최적화했을 것임
      하지만 이제는 모두가 24시간 돌아가는 봇을 하나씩, 때로는 여러 개씩 두고 있어서 많은 서비스가 과부하에 걸리고 있음. 특히 요즘의 GitHub처럼 에이전트 중심이 된 서비스가 더 그렇다
    • 몇 달 전부터 이미 받아들일 수 없는 수준이었고, 이제는 대안을 적극적으로 찾아야 할 단계에 가까움
    • 일주일이 아니라 장애 없이 하루만 지나도 기뻐해야 할 수준임
      태평양 표준시 기준 월요일 아침마다 몇 번째 반복인지도 이제 모르겠음
    • 유럽에서는 훨씬 나은 편임. 이번 장애가 시작되기 몇 시간 전에 일을 끝냈고, 지난 몇 달 동안 업무를 멈출 정도의 큰 장애는 잘 기억나지 않음
      최근 저녁에 취미 프로젝트를 하려다 영향을 받은 적은 한 번 있었음
    • 받아들일 수 없는 수준은 이미 한참 지났다고 봄

  • 이제 HN 첫 페이지에서 GitHub 다운 글이 매주 새로운 LLM 과장 글과 경쟁하는 수준이 됐음
    개인 프로젝트는 전부 Codeberg로 옮기는 걸 고려 중임. GitHub 안정성도 이유지만, 빅테크 회사에 엄격히 묶이지 않은 대안이라는 점도 마음에 듦

    • Claude Code가 거의 마법이라는 식의 스팸이 가장 심했는데, 잠시 GitHub 상태 글에 밀린 것 같음. 지금은 Claude 광고가 잠잠한 시기일 수도 있음
    • 그런데도 아직 옮기지 않았다는 게 지배적 플랫폼의 문제임. 약간의 불편함과 관성만으로도 아무도 떠나지 않게 만들기에 충분함
      독점적 남용이 없어도 그렇고, 여기서는 Microsoft를 말하는 것임

  • 웃기게도 Copilot을 제외한 거의 모든 게 성능 저하 상태로 보임. 농담이 저절로 만들어지는 상황임

    • 지금 성능 저하 중인 기능들에 비하면 Copilot의 전체 기능은 유용성이 일부에 불과함
    • Copilot은 GitHub의 코드 저장소 쪽과 완전히 독립적이라, Rails 모놀리스에 강한 의존성이 없는 전혀 다른 인프라에서 돌고 있을 것 같음

  • GitHub에 서비스 장애가 날 때를 감지하는 육감이 생기기 시작한 것 같아 이상하고 좀 슬픔
    한 시간쯤 전 풀 리퀘스트에서 “Resolve Conversation”을 눌렀더니 몇 번 실패했고, 페이지 아래쪽 화면 밖에 오류 메시지가 떠서 처음에는 보이지 않았음. 몇 번 작업할 때마다 페이지를 새로고침해야 서버가 새 동작을 반영했음
    동료에게 GitHub가 다른 서비스에서 문제가 생겼고 그게 PR 댓글 쪽으로 번진 것 같다고, 더 큰 장애로 굴러갈 수도 있겠다고 말했음

    • 방금 PR 리뷰 댓글에서도 똑같은 신호를 봤음. 상태 페이지를 확인했더니 초록색이었고, 오래가지는 않겠다고 짐작했는데 맞았음

  • 무료 티어를 줄여야 함
    지난 2.5개월 동안 커밋을 4,000개 했고, 그것도 main 기준임. 회귀 테스트용 산출물도 매일 잔뜩 올림
    비용은 0달러임

    • 솔직히 이런 SaaS 제품의 무료 티어가 싫음
      예전에 Google이 아주 잠깐 GCP에서 종량제 Git 서비스를 제공했을 때 그걸 썼음. 내 것을 내가 소유하고 싶었기 때문임. 그런데 모두가 “무료” GitHub를 썼고, 많은 다른 Google 서비스처럼 그 서비스도 종료된 것 같음
      그래서 지금은 GitHub를 무료로 쓰고 있지만, 차라리 큰 클라우드 제공자에게 저장소와 사용량 비용을 내고 싶음
    • 그렇게 하면 아직 떠나지 않은 오픈소스 프로젝트들이 이주할 것임
    • 저장소 쪽만 보면 그건 CPU 사용량 2분 정도에 가까움
    • GitHub는 잡코드 세금을 붙여야 함. Claude와 공동 작성? 돈 내라. 댓글에 em dash가 많다? 돈 내라. 짧은 시간에 코드가 많이 작성됐다? 돈 내라

  • 정말 우스꽝스러운 수준까지 가고 있음. 상태 페이지가 Copilot까지 포함해서 “빠졌다”고 가끔 무시되지만, 풀 리퀘스트 가용성은 95.5% 로 Copilot의 96.4%보다도 낮다는 점을 봐야 함
    PR에 접근조차 못 하는데 어떻게 “LGTM” 댓글을 달라는 건지 모르겠음

  • 적어도 사람들이 git remote 명령 사용법은 익히고 있음

답변달기