이런 바이브 코딩 밈 사이트가 올라올 때마다 실제 원인은 부하가 아니라 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보다 훨씬 작은 서비스를 운영하지만, 여러 제공업체와 여러 모델로 대체 경로를 마련해둠
이 그래프가 정확한지부터 의문임
“최소 한 건의 장애가 있었던 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일임
약관이 합법인 이유는 서비스 수준 계약상 가용성을 추적하고, 위반 시 크레딧을 요구해야 하는 주체가 고객이기 때문임
최근 일했던 곳에서 상태 페이지에 기록되지 않은 GitHub 장애를 많이 겪었고, Slack 검색으로 로그를 남겨뒀음
이후 비즈니스 담당자들이 GitHub 계정 담당자와 논쟁한 끝에 수백 달러 크레딧을 받았음
하지만 그 수백 달러 크레딧은 들인 시간에 비해 가치가 없다고 불평했고, 그래서 GitHub의 낮은 가동률은 계속되고 아무 일도 일어나지 않음
재미있게도 어제 문제가 터졌을 때 동료가 mrshu 페이지를 링크했는데, 공식 페이지는 Actions 문제를 표시하는 동안 그 페이지는 전부 초록색이었음
서비스 수준 계약은 GitHub의 일부 기능을 범위에 넣지 않을 가능성이 큼
반면 서드파티 페이지는 특정 모델 하나의 장애나 문제도 GitHub 문제로 보기 때문에 실제 사용과 차이가 날 수 있음
Hacker News 의견들
이런 바이브 코딩 밈 사이트가 올라올 때마다 실제 원인은 부하가 아니라 GitHub 팀, 기술 스택, Microsoft, Azure가 형편없어서라는 댓글이 끝없이 달림
공개 GitHub 상태 페이지와 Enterprise Cloud 페이지를 비교해보면 Enterprise 쪽 수치가 훨씬 좋고, 개인적으로도 일을 못 할 정도의 장애가 마지막으로 언제였는지 기억나지 않음
문제가 부하와 무관하다면 Enterprise 제품에서도 같은 가동률 문제가 보여야 한다고 봄
특히 여러 나라보다 많은 자원과 세계 최고 수준의 기술 인력을 가진 회사라면 시스템 비판은 충분히 가능함
GitHub의 기술 스택은 실제로 좋지 않고, 오랫동안 꽤 오만하게 방어해왔음
Azure는 끔찍한 플랫폼인데 팀에 강제로 밀어붙여지고 있으며, 관계형 데이터베이스 선택이나 프런트엔드 재작성에 대해서도 방어적인 태도를 본 적이 있음
사이트도 안정적으로 못 켜두면서 UI를 다시 쓰고 AI 도구를 밀어붙이는 건 시간 낭비임
엔지니어 개인을 공격하는 게 아니라, 네트워크 효과로 사실상 독점이 된 시스템이 핵심 제품보다 새 기능이나 소유주 만족을 우선하는 경영진의 선택을 비판하는 것임
상태 페이지가 회사에 불리한 증거로 쓰일 수 있어서, 비교 자체가 별 의미 없음
실제로는 장애여도 마케팅 언어로는 “성능 저하”라고 부르는 경우가 많고, 독립적으로 운영되는 상태 페이지가 훨씬 유용함
매일은 아니지만, 회사에서 장애를 우회하지 않고 일주일을 보낸 기억이 거의 없음
대부분의 경우 “일”은 계속할 수 있지만, 장애가 없었다면 같은 시간 안에 빌드되거나 배포됐을 작업이 늦어지므로 개인적으로는 최소 주 1회는 영향을 받음
아니면 적어도 상단에 “취미용으로만 사용” 경고를 크게 붙여야 함
기존 스레드에는 답글을 달 수 있지만 새로 만들 수는 없고, 상태 페이지에도 올라와 있음
이런 게 어떻게 통과됐는지 모르겠고, 왜 한 시간째 이어지는지도 이해하기 어려움
수정까지 앞으로 3~4시간 걸린다니 참 친절함
Gemini 2.5 Pro, Grok Code Fast 1 in Copilot, Claude Opus 4 같은 외부 모델 성능 저하까지 GitHub 탓으로 돌리는 건 공정하지 않아 보임
GitHub가 할 수 있는 게 없는 문제 아닌가 싶음
심각도를 지워버린 뒤 전부 “GitHub 장애”나 가동률 그래프로 축약함
GitHub의 최근 대형 장애에 불만은 있지만, 작은 서비스 저하와 전체 사이트 장애의 경계를 흐려서 더 극적으로 보이게 만들고 추천, 좋아요, 카르마, 관심을 모으는 관심 끌기용 사이트와 소셜 글이 늘어나는 건 보기 좋지 않음
차트를 최대한 빨갛게 만들고 싶었던 것처럼 보임
우리는 GitHub보다 훨씬 작은 서비스를 운영하지만, 여러 제공업체와 여러 모델로 대체 경로를 마련해둠
주말은 아직 개척되지 않은 프런티어임
아직 확장할 여지가 있음
장애는 평일의 62%, 주말의 11%에 걸쳐 있었고, Claude도 비슷하게 평일 92.5%, 주말 97.8%였음
화요일부터 목요일까지가 위험 구간이고, 일요일은 사실상 다른 서비스처럼 보임
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
이 그래프가 정확한지부터 의문임
“최소 한 건의 장애가 있었던 170일 · 최악의 날 2025년 11월 20일 목요일, 1.1일”이라고 나오는데, 하루 총합이 1.1일이라는 게 어떻게 가능한지 모르겠음
해당 날짜에 마우스를 올려도 내부 계산 방식이 보이지 않고, 단일 항목은 1.3시간으로 나옴
11월 19일에는 1.3일 장애 항목이 있는데 총합은 8.1시간으로 표시됨
그 날짜에는 24시간의 경미한 장애로 표시됨
이 사이트는 하루 동안 모든 서비스의 다운타임을 더하는 듯하고, 그러면 최악의 하루는 주요 범주별 하루 다운타임이 합쳐져 10일 다운타임까지 나올 수 있음
1: https://mrshu.github.io/github-statuses/
실제로 그날 다운타임이 있었는지는 확인하지 않았지만, 숫자가 맞다고 가정하면 7.8시간에 1일을 더한 값이 대략 1.3일임
공식 상태 페이지 [0]와 서드파티 상태 페이지 [1]의 차이가 너무 큼
실제 제품 사용 상황과 이렇게 다르다면 서비스 수준 계약 약관이 어떻게 합법인지 의문임
GitHub와 서비스를 좋아하지만, 실제로는 고장 났는데 상태 페이지가 초록색일 때마다 속에서 뭔가 소리침
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
최근 일했던 곳에서 상태 페이지에 기록되지 않은 GitHub 장애를 많이 겪었고, Slack 검색으로 로그를 남겨뒀음
이후 비즈니스 담당자들이 GitHub 계정 담당자와 논쟁한 끝에 수백 달러 크레딧을 받았음
하지만 그 수백 달러 크레딧은 들인 시간에 비해 가치가 없다고 불평했고, 그래서 GitHub의 낮은 가동률은 계속되고 아무 일도 일어나지 않음
반면 서드파티 페이지는 특정 모델 하나의 장애나 문제도 GitHub 문제로 보기 때문에 실제 사용과 차이가 날 수 있음
주말에는 장애가 훨씬 적음
어차피 그때는 일할 생각이 없었으니 완벽함
이 아이디어는 예전부터 있었음
1월에 장애 범주별로 가동률을 쪼개 보려고 이걸 만들었음
https://isgithubcooked.com
주말에 다운타임이 거의 없는 게 기여 그래프와 꽤 비슷하게 보여서 웃김