# GitHub 무장애 일수 카운터 > Clean Markdown view of GeekNews topic #29199. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29199](https://news.hada.io/topic?id=29199) - GeekNews Markdown: [https://news.hada.io/topic/29199.md](https://news.hada.io/topic/29199.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T05:40:36+09:00 - Updated: 2026-05-06T05:40:36+09:00 - Original source: [dayswithoutgithubincident.com](https://www.dayswithoutgithubincident.com/) - Points: 1 - Comments: 1 ## Topic Body - **Days Without GitHub Incidents**는 GitHub이 장애 없이 유지된 일수를 보여주는 페이지 - 최고 기록은 2026년 4월 2일 ~ 4월 9일까지의 **6일** - 현재는 5월 5일 발생한 SSH Git Operations 장애로 인해 다시 0일부터 시작 - GitHub Status History를 기반으로 만든 일종의 “**무장애 일수 카운터**” 사이트 - 데이터는 https://www.githubstatus.com/history 를 참고 ## Comments ### Comment 56892 - Author: neo - Created: 2026-05-06T05:40:36+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48012022) - 최근 모든 프로젝트를 **자체 호스팅 Forgejo** 인스턴스로 옮겼고, 지금까지 꽤 만족스럽다. 속도도 빠름 GitHub 대안을 찾고 있다면 한번 살펴볼 만하고, 선택지는 있음 - 이제 유행은 아니지만, 자체 호스팅 가능한 GitHub 대안으로 **Phabricator**도 명예롭게 언급할 만함 오히려 “낡은” UI가 요즘 다른 것들이 워낙 나빠진 상황에서는 장점처럼 느껴짐 - GitHub에는 늘 거부감이 있었지만, git은 처음 접한 직후부터 인상적이었음 개인 프로젝트를 오래된 Gitea 인스턴스에서 **Forgejo**로 옮겼고 매우 만족하고 있음 - **Gitea**는 어떤가? - 플랫폼 전체를 숫자 하나로 합치는 건 공정하지 않다고 봄. **AWS 전체**를 숫자 하나로 더하는 것과 비슷함 - 반대로 어느 정도 복잡한 배포를 운영하면 CPU, 메모리, 입출력, 애플리케이션 지표, 가입자, 활성 사용자/세션 같은 대시보드에 쉽게 파묻힘 그래서 전체 시스템 상태를 **단일 숫자**로 표현하는 방법을 생각해보는 건 유용함. 예를 들어 활성 사용자 세션을 데이터베이스 연결 수로 나누고 메모리 용량으로 보정할 수 있음 한 자리 숫자라면 정상 범위에 익숙해지고 눈에 잘 띄는 곳에 항상 둘 수 있음. 세부 사항은 못 보여주지만, 값이 변하면 구체 지표를 보러 가면 되니 기본적인 “정상인가?” 확인용 축약으로는 잘 작동할 수 있음 - 상태 페이지를 지금처럼 쪼개서, `git push`와 `git pull` 장애를 따로 추적한다고 해도 과장이 조금 섞인 농담에 그칠 정도라면, 그건 **눈속임이자 SLA 부풀리기**에 가깝고 봐줘서는 안 됨 거의 모두가 쓰는 Git, 이슈, 풀 리퀘스트, Actions 같은 핵심 영역이 있고, 그중 하나라도 깨지면 사이트가 깨진 것임. 상태 페이지는 이런 일이 얼마나 자주 생기는지 보여줘야 함 - 이건 명백히 밈 사이트고, 숫자가 높지 않을수록 밈이 더 웃김 실제로 정확한 정보를 찾는 사람은 공식 상태 페이지로 갈 것임 - S3, EC2, EKS, RDB만 놓고도 지금 GitHub 전체와 비슷한 가동률이었다면 모두가 알았을 것임 저장소 위키, 커밋 통계, gist에 이런 문제가 생기는 건 그다지 중요하지 않음. 중요한 건 PR, Actions, Discussions처럼 함께 쓰이고 서로 의존하는 서비스들의 조합임 두 시스템의 각 구성요소마다 단일 백분율을 만들어도 **GitHub가 여전히 밀릴 것**임. 장애 없는 날이 며칠 더 있을 수는 있어도, 이건 단순 비교가 아님 - 사용자 관점에서는 이런 계산이 말이 됨. 하지만 MSFT나 GitHub 입장에서는 이 숫자가 꽤 **민망한 지표**임 플랫폼의 모든 기능을 사용하게 만들고 강한 종속성을 만들고 싶을 텐데, 일부가 계속 고장 난다면 사용자가 더 많은 기능을 채택할 자신감을 얻기 어렵다 쓰는 것이 많아질수록 그중 하나가 문제를 일으킬 확률은 커지지만, 이런 회사들에게는 이제 안정성이 목표가 아닌 것처럼 보임 - 우리에게는 실제 **사업 연속성** 문제임. GitHub Enterprise에 어느 정도 묶여 있지만, 이런 상태가 계속되면 클라우드에서 온프레미스로 옮겨야 할 수도 있음 - 그 방향으로 간다면 필요한 **Actions를 모두 로컬에 캐시**해두는 게 좋음. 그렇지 않으면 크게 나아지지 않음 - 지금 tangled.org에서 쓰려고 자체 호스팅 **Knot**을 설정 중임 주된 이유는 AtProto가 멋지고 자체 호스팅이 재미있어서지만, 내 프로젝트를 호스팅하는 인프라를 직접 소유하는 방향으로 가고 싶기 때문이기도 함 Tangled의 Knot 시스템은 이 점에서 강한 추상화처럼 느껴짐. 데이터는 AtProto Repository에 호스팅하되, 이를 세상에 보여주는 AtProto Application의 호스팅과 관리는 제3자에게 맡길 수 있음 Tangled가 사라져도 AtProto 로그인을 다른 플랫폼으로 가져가 내 Knot을 가리키면 되고, 호스팅 설정은 그대로 유지 가능함. 인터넷 한구석에 고립된 웹앱 전체를 직접 호스팅하는 것보다 훨씬 편리함 - 여기에는 GitHub를 변호하는 말이 많음. **수십억 달러짜리 회사**를 변호하는 것도 좀 이상한데, 특히 오픈소스 소프트웨어의 압도적 다수를 맡고 있는 회사라면 더 그렇다 호의가 작동하는 걸 수도 있음. 하지만 사랑하는 프로젝트에 참여하려면 큰 회사의 내부 정치와 관행을 받아들여야 한다는 점은 늘 삼키기 어려운 알약이었음. GitHub에 빚졌다는 느낌은 없음 특히 그들이 거래의 자기 몫을 지키지 못한다면 더 그렇다. Azure 크레딧 한가득이라는 거액을 대가로 전 세계 소프트웨어 저장소에 자유롭게 접근하는 셈임 - 질문을 반대로 해보면, 운영을 유지하려 애쓰는 동료 인간들이 최소한의 **친절과 존중**조차 받을 자격이 없다고 볼 만큼 GitHub에 반대하는 이유가 무엇인가? 사업체와 그 뒤에서 열심히 일하는 사람들을 분리해서 볼 수 없는가? 그들도 우리 같은 사람들이 자신들에게 의존한다는 걸 모르는 게 아님. 자신들의 서비스가 전 세계 소프트웨어 개발 역량의 “발신음”이라는 걸 알고 있고, 영향도 예민하게 인식하고 있음 #hugops는 어디로 갔나? 그 사람들이 마음에 안 드는 회사에서 일한다는 이유로 바로 사라지는 건가? - 정확히는 Microsoft라는 **수조 달러짜리 회사**를 변호하는 것임 - 돈을 내고 쓰는지에 달렸다고 봄. 돈을 낸다면 강한 기대를 갖고 책임을 물어야 함 무료 서비스를 받는다면 화가 나는 것도 합리적이지만, 동시에 지불한 만큼 받는 셈이기도 함 - 인수 이후에도 **GitHub에 대한 인식**이 별로 바뀌지 않은 것이 놀라움 WSL과 맞물리면서 많은 사람들에게 균형이 맞춰졌고, Microsoft를 다시 “일단 믿어보자” 쪽에 올려놓은 듯했음 이번 일은 운영 비용뿐 아니라 그동안의 호의를 많이 되돌리고 있음. 갑자기 나쁜 보도가 더 잘 보이고 무시하기 어려워짐 - **수십억 달러짜리 회사**를 목숨 걸고 변호하는 두 집단은 HN 사용자와 Nintendo 팬임 - GitHub의 커밋이 전년 대비 **14배** 늘었다고 함 - AI 에이전트들이 스팸처럼 밀어 넣는 건가? - 커밋인가, 푸시인가? 부하 측정 관점에서 **커밋 수**는 그다지 의미 있는 기준이 아님 - 14배는 미친 수준임. 특히 현실 세계 소프트웨어의 품질과 양은 거의 움직이지 않았는데 더 그렇다 새로 얻은 에이전트식 코딩 능력으로 실제 가치를 만들고 품질을 개선하길 바랄 수도 있었음. 하지만 보이는 건 **엔시티피케이션**과 정체임. 이 모든 토큰으로 대체 뭘 하고 있는 건가? - GitHub의 커밋이 전년 대비 14배 늘었다고 해서, 그래서 뭐? **Microsoft가 확장**하지 못하면 누가 할 수 있나? 서비스를 제공할 수 없다면 가능해질 때까지 판매를 멈춰야 함 이건 90년대 중반 AOL 전화접속 통화중 신호 fiasco의 반복임. 다만 이번에는 사람들이 화를 내는 대신, 불쌍하고 시달리는 조 단위 회사에 변명을 해주고 있음 - 이게 AI 커밋 때문이고 전부 트래픽 양 탓이라는 말을 정말 이해하기 어렵다 한 자릿수 규모의 증가, 즉 14배 정도의 **부하 증가**가 이런 수준의 장애로 이어져서는 안 됨 GitHub가 하는 일과 그 처리량을 소셜 미디어 회사, 결제 회사, 동영상 플랫폼 등과 비교하면 단순한 부하 문제라는 설명은 맞지 않아 보임 이미 기본적인 문제가 있던 플랫폼에 증가한 부하가 겹쳐 증폭된 것에 훨씬 가까워 보임 - 이 농담이 먹히는 이유는 모두가 편의성을 위해 상당한 **집중 리스크**를 조용히 받아들였기 때문임 - [https://repo.autonoma.ca/treetrek]() 내가 만든 무료 오픈소스, 최소 기능, 캐시 없음, 의존성 없음, 인증·인가 없음의 순수 PHP **원시 Git 뷰어**임 GitList가 캐시 버그 때문에 공유 호스팅의 디스크 공간과 메모리를 터뜨렸고, GitHub·BitBucket·GitLab 저장소를 통합하려고 만들었음 자체 호스팅을 하고 제3자의 변덕에 휘둘리지 않는 데는 보람이 있음 - 대부분 **바이브 코딩 앱**일 이 앱도 GitHub를 내려가게 만드는 바이브 코딩 앱 공세에 기여했을 가능성이 큼 침몰하는 배를 어떻게든 띄우려는 GitHub 직원들이 안쓰럽고, Microsoft는 자기 배를 가라앉히기 위해 할 수 있는 모든 일을 하는 것처럼 보임