# GitHub 장애를 기여로 보여주는 Red Squares > Clean Markdown view of GeekNews topic #29247. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29247](https://news.hada.io/topic?id=29247) - GeekNews Markdown: [https://news.hada.io/topic/29247.md](https://news.hada.io/topic/29247.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-07T09:37:07+09:00 - Updated: 2026-05-07T09:37:07+09:00 - Original source: [red-squares.cian.lol](https://red-squares.cian.lol/) - Points: 1 - Comments: 1 ## Topic Body - **Red Squares**는 GitHub의 커밋 기여 그래프를 패러디해, 초록색 칸 대신 빨간 칸으로 GitHub.com 플랫폼 장애를 표시함 - 각 **빨간 칸**은 GitHub가 장애를 겪은 하루를 뜻하며, 색이 진할수록 장애가 더 오래 지속된 날을 나타냄 - 최근 1년 동안 GitHub 다운타임은 총 **32.5일**로 집계됨 - 최소 1건의 인시던트가 있었던 날은 **167일**임 - 최악의 날은 **2026년 4월 30일 목요일**로, 다운타임이 **1.0일**에 달함 --- ### GitHub 장애를 기여 그래프로 풍자 ## Comments ### Comment 56987 - Author: neo - Created: 2026-05-07T09:37:07+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48034587) - 이런 **바이브 코딩 밈 사이트**가 올라올 때마다 실제 원인은 부하가 아니라 GitHub 팀, 기술 스택, Microsoft, Azure가 형편없어서라는 댓글이 끝없이 달림 공개 GitHub 상태 페이지와 **Enterprise Cloud** 페이지를 비교해보면 Enterprise 쪽 수치가 훨씬 좋고, 개인적으로도 일을 못 할 정도의 장애가 마지막으로 언제였는지 기억나지 않음 문제가 부하와 무관하다면 Enterprise 제품에서도 같은 가동률 문제가 보여야 한다고 봄 - 서비스를 제대로 제공하지 못하는 걸 비판하는 건 개인 엔지니어를 탓하는 게 아니라 **시스템의 실패**를 비판하는 것임 특히 여러 나라보다 많은 자원과 세계 최고 수준의 기술 인력을 가진 회사라면 시스템 비판은 충분히 가능함 GitHub의 기술 스택은 실제로 좋지 않고, 오랫동안 꽤 오만하게 방어해왔음 Azure는 끔찍한 플랫폼인데 팀에 강제로 밀어붙여지고 있으며, 관계형 데이터베이스 선택이나 프런트엔드 재작성에 대해서도 방어적인 태도를 본 적이 있음 사이트도 안정적으로 못 켜두면서 UI를 다시 쓰고 AI 도구를 밀어붙이는 건 시간 낭비임 엔지니어 개인을 공격하는 게 아니라, 네트워크 효과로 사실상 독점이 된 시스템이 핵심 제품보다 새 기능이나 소유주 만족을 우선하는 **경영진의 선택**을 비판하는 것임 - 공식 상태 페이지는 **서비스 수준 계약** 때문에 실제 다운타임을 그대로 반영하지 않는다는 건 널리 알려져 있음 상태 페이지가 회사에 불리한 증거로 쓰일 수 있어서, 비교 자체가 별 의미 없음 실제로는 장애여도 마케팅 언어로는 “성능 저하”라고 부르는 경우가 많고, 독립적으로 운영되는 상태 페이지가 훨씬 유용함 - 서로 다른 영역에서 일하는 듯함 매일은 아니지만, 회사에서 장애를 우회하지 않고 일주일을 보낸 기억이 거의 없음 대부분의 경우 “일”은 계속할 수 있지만, 장애가 없었다면 같은 시간 안에 빌드되거나 배포됐을 작업이 늦어지므로 개인적으로는 최소 주 1회는 **영향**을 받음 - GitHub는 작은 가게가 아니므로, **3조 달러 회사**라면 그 부하는 처리해야 함 아니면 적어도 상단에 “취미용으로만 사용” 경고를 크게 붙여야 함 - 아이러니하게도 바로 지금 조직 안에서 GitHub 버그 때문에 PR에 새 스레드를 만들 수 없음 기존 스레드에는 답글을 달 수 있지만 새로 만들 수는 없고, 상태 페이지에도 올라와 있음 이런 게 어떻게 통과됐는지 모르겠고, 왜 한 시간째 이어지는지도 이해하기 어려움 수정까지 앞으로 3~4시간 걸린다니 참 친절함 - Gemini 2.5 Pro, Grok Code Fast 1 in Copilot, Claude Opus 4 같은 **외부 모델 성능 저하**까지 GitHub 탓으로 돌리는 건 공정하지 않아 보임 GitHub가 할 수 있는 게 없는 문제 아닌가 싶음 - 최근 패턴은 개별 서비스의 작은 성능 저하를 모두 모아서 똑같이 중요한 문제처럼 보여주는 것임 심각도를 지워버린 뒤 전부 “GitHub 장애”나 가동률 그래프로 축약함 GitHub의 최근 대형 장애에 불만은 있지만, 작은 서비스 저하와 전체 사이트 장애의 경계를 흐려서 더 극적으로 보이게 만들고 추천, 좋아요, 카르마, 관심을 모으는 **관심 끌기용 사이트**와 소셜 글이 늘어나는 건 보기 좋지 않음 - 하이퍼스케일러의 **성능 저하**를 github.com 가용성과 묶는 건 별로 흥미롭지 않음 차트를 최대한 빨갛게 만들고 싶었던 것처럼 보임 - GitHub가 다른 서비스를 다시 포장해 제공한다면 GitHub를 탓해도 된다고 봄 우리는 GitHub보다 훨씬 작은 서비스를 운영하지만, 여러 제공업체와 여러 모델로 **대체 경로**를 마련해둠 - 모델을 누가 호스팅하느냐에 따라 다름 - 주말은 아직 개척되지 않은 프런티어임 아직 확장할 여지가 있음 - 지난달 분석했을 때 GitHub는 평일 가동률이 **89.3%**, 주말은 **96.5%** 였음 장애는 평일의 62%, 주말의 11%에 걸쳐 있었고, Claude도 비슷하게 평일 92.5%, 주말 97.8%였음 화요일부터 목요일까지가 위험 구간이고, 일요일은 사실상 다른 서비스처럼 보임 [https://www.aakash.io/tech-chase/github-and-claude-are-down-...]() - 그렇다면 변경 작업이 가장 큰 원인인가? - 996 근무제가 시작될 때까지 기다려보면 됨 - 이 그래프가 정확한지부터 의문임 “최소 한 건의 장애가 있었던 170일 · 최악의 날 2025년 11월 20일 목요일, 1.1일”이라고 나오는데, 하루 총합이 **1.1일**이라는 게 어떻게 가능한지 모르겠음 해당 날짜에 마우스를 올려도 내부 계산 방식이 보이지 않고, 단일 항목은 1.3시간으로 나옴 11월 19일에는 1.3일 장애 항목이 있는데 총합은 8.1시간으로 표시됨 - 빠진 상태 페이지 [1]는 시스템의 어떤 구성요소든 내려가 있으면 다운타임으로 처리하고, 겹치지 않는 시간으로 전체 가동률을 계산하며, 적어도 하나의 개별 장애와 겹치는 시간은 중복 계산을 피해서 전체 다운타임으로 잡음 그 날짜에는 24시간의 경미한 장애로 표시됨 이 사이트는 하루 동안 모든 서비스의 다운타임을 더하는 듯하고, 그러면 최악의 하루는 주요 범주별 하루 다운타임이 합쳐져 **10일 다운타임**까지 나올 수 있음 1: [https://mrshu.github.io/github-statuses/]() - “1.3일 중 1.0일” 항목이 보이고, 전날인 2025년 11월 19일 수요일에 마우스를 올리면 “1.3일 중 7.8시간”으로 보임 실제로 그날 다운타임이 있었는지는 확인하지 않았지만, 숫자가 맞다고 가정하면 7.8시간에 1일을 더한 값이 대략 **1.3일**임 - 공식 상태 페이지 [0]와 서드파티 상태 페이지 [1]의 차이가 너무 큼 실제 제품 사용 상황과 이렇게 다르다면 **서비스 수준 계약** 약관이 어떻게 합법인지 의문임 GitHub와 서비스를 좋아하지만, 실제로는 고장 났는데 상태 페이지가 초록색일 때마다 속에서 뭔가 소리침 [0] [https://www.githubstatus.com/]() [1] [https://mrshu.github.io/github-statuses/]() - 약관이 합법인 이유는 서비스 수준 계약상 가용성을 추적하고, 위반 시 크레딧을 요구해야 하는 주체가 **고객**이기 때문임 최근 일했던 곳에서 상태 페이지에 기록되지 않은 GitHub 장애를 많이 겪었고, Slack 검색으로 로그를 남겨뒀음 이후 비즈니스 담당자들이 GitHub 계정 담당자와 논쟁한 끝에 수백 달러 크레딧을 받았음 하지만 그 수백 달러 크레딧은 들인 시간에 비해 가치가 없다고 불평했고, 그래서 GitHub의 낮은 가동률은 계속되고 아무 일도 일어나지 않음 - 재미있게도 어제 문제가 터졌을 때 동료가 mrshu 페이지를 링크했는데, 공식 페이지는 Actions 문제를 표시하는 동안 그 페이지는 전부 초록색이었음 - 서비스 수준 계약은 GitHub의 일부 기능을 범위에 넣지 않을 가능성이 큼 반면 서드파티 페이지는 특정 모델 하나의 장애나 문제도 GitHub 문제로 보기 때문에 실제 사용과 차이가 날 수 있음 - 주말에는 장애가 훨씬 적음 어차피 그때는 일할 생각이 없었으니 완벽함 - 이 아이디어는 예전부터 있었음 1월에 장애 범주별로 가동률을 쪼개 보려고 이걸 만들었음 [https://isgithubcooked.com]() - “Billing”은 완전히 초록색이고, “Pull Requests”는 완전히 빨간색임 - 주말에 다운타임이 거의 없는 게 **기여 그래프**와 꽤 비슷하게 보여서 웃김