GitHub는 올해 들어서만도 수십 차례 장애를 냈고, 작년보다도 가용성과 신뢰성이 눈에 띄게 나빠졌음
이 정도면 대시보드와 히트맵이 돌 정도로 심각하고, HN이나 Reddit 같은 곳에서 GitHub 불안정성이 밈이 될 수준까지 왔다고 봄
그런데도 우선순위가 "availability, capacity, new features"라고 말하는 건 현실 인식이 너무 느슨함
지금 우선순위는 1, 2, 3 전부 availability여야 하고, 최소 6개월은 다른 얘기 꺼내지 말고 그것만 고쳐야 함
6개월 전에는 Azure 이전이 최우선이라며 기능 개발을 미루겠다고 하더니, 지금은 또 가용성이 최우선이라고 하니 앞뒤가 잘 안 맞음
당시엔 AI와 Copilot 수요 때문에 버지니아 데이터센터 용량 제약이 "existential"하다고 했는데, 아직도 같은 문제로 비틀거리는 걸 보면 더 황당함
기능 개발이 미뤄졌다면서도 매주 새 기능과 UI 변경은 계속 나오고, 얼마 전에도 이슈 단일 뷰를 바꿨음
Microsoft 정도 자원을 가진 회사가 이렇게 계속 같은 데서 발목 잡히는 건 믿기 어려울 정도고, 인기 있는 개발자 서비스를 사들여 전부 같은 플랫폼으로 옮기는 전략도 불안해 보임
이건 너무 악의적으로 해석하는 느낌도 있음
큰 엔지니어링 조직에서는 우선순위가 배타적이지 않고, 핵심 우선순위에 직접 기여하지 못하는 팀은 다른 기능 작업을 계속할 수도 있음
Azure 이전이 오히려 가용성 문제를 더 악화시켰을 가능성도 충분함
전용 하드웨어가 클라우드보다 예측 가능성이 높고, "Azure로 가지 말고 랙 몇 개 더 사자" 같은 판단은 GitHub 경영진 선에서 결정할 수 없는 일이었을 수도 있음
지난 5년간 기능 변경이 전혀 없었어도 아무도 화내지 않았을 텐데, 굳이 계속 뜯어고치고 있음
GitHub는 5분마다 재설계할 사이트가 아니고, 관리자들이 자기 존재 이유를 증명하려고 새 기능을 위한 새 기능을 밀어붙이는 것처럼 보일 때가 있음
그 결과 더 많이 망가뜨릴수록 오히려 사용자를 끌어들이는 데 역효과가 남
검색도 크게 너프됐고, Google 검색이나 YouTube처럼 왜 멀쩡하던 검색을 다들 계속 망가뜨리는지 모르겠음
게다가 Microsoft는 거의 버려진 듯한 Azure DevOps도 있고 GitHub도 있는데, 둘 다 특히 티켓 시스템이 싫음
Jira 프로젝트마다 설정이 제각각이라 질렸는데도, 이제는 "차라리 Jira가 그립다"는 말까지 나오게 됨
저 글은 정색하고 읽기 어렵다는 느낌임
숫자만 크게 올려놓은 라벨 없는 그래프, 실제 체감과 맞지 않는 우선순위, 그리고 지난 12개월의 끔찍한 업타임을 제대로 인정하지 않는 태도가 너무 거슬림
그래프가 아주 최악은 아님
왼쪽 아래 축 라벨이 없긴 해도, 2023→2024→2025→2026으로 성장 속도가 매우 빠르다는 핵심은 전달됨
2026 초·말쯤에는 이전 3년을 합친 것보다 더 큰 성장을 말하는 것처럼 읽히고, 축 숫자를 몰라도 대략의 추세는 볼 수 있음
선형 그래프라는 가정은 필요하지만, 문맥상 그 정도 가정은 무리 없어 보임
계획보다 훨씬 큰 성장을 겪는 회사라면 용량 문제가 생길 수밖에 없고, 이제는 하드웨어만 더 넣는 수준을 넘어 백엔드 효율화가 필요해 보임
적어놓은 목표들도 대체로 그쪽을 겨냥하고 있음
"multi cloud 경로를 시작했다"는 문장을 보면, Microsoft가 Azure만으로는 원하는 수준의 신뢰성을 못 뽑는다고 사실상 인정한 것처럼 들림
꽤 치명적인 시그널처럼 보이고, Azure를 써본 입장에선 충분히 납득도 감
이건 다운타임 때 돈을 잃는 엔터프라이즈 고객을 겨냥한 대응 같기도 함
유지율 방어에는 도움이 될 수 있음
저 정도 규모의 복잡한 시스템이라면 단일 공급자 의존을 피하는 게 상식적이기도 함
예전에 여기서 Dave Cutler의 Azure 비전이 우선순위, 압박, 관리 때문에 훼손됐다는 글을 본 기억이 있음
원래는 사람 개입이 거의 없는 운영을 지향했는데, 지금은 누가 랙이나 VM에 시리얼 붙여 직접 건드리는 식이 일상적인 절차라는 얘기였음
지금은 링크를 못 찾겠지만
Show HN은 올리는 시간대가 생각보다 중요함
월~목 오전 9~11시 Pacific에 가장 적극적인 독자가 많고, 주말은 경쟁은 적지만 참여도도 낮음
GitHub CTO가 Codepath.org 이사회에도 있고, 거기 설명이 "첫 번째 AI-native 세대의 엔지니어, CTO, 창업자를 만든다"는 식이라면, 어디가 문제인지 대충 감이 옴
체감상 GitHub 안정성이 많이 나빴고, 최근엔 웹에서 보여주는 데이터조차 믿기 어려움
어제부터 나와 동료 몇 명이 여러 저장소에서 PR 목록이 불완전하게 보이는 걸 확인했음
예를 들어 https://github.com/gap-system/gap/pulls에서는 탭엔 "Pull requests 78"이라고 나오는데, 목록 뷰에는 "35 open"만 보임
78이 맞는 숫자인 건 gh pr list로도 확인되는데도 https://www.githubstatus.com은 여전히 "all systems operational"이라고 표시함
내 프로젝트들 중 상당수는 최근 6일간 닫힌 PR이 하나도 안 보임
CLI로는 목록이 나오는데, 검색을 거치는 웹 경로에서는 전부 사라짐
지원팀도 이 이슈를 인정하긴 했지만 그 뒤로 조용하고, 상태 페이지에도 27일의 아마 관련 있어 보이는 이슈 말고는 아무것도 없음
일부 저장소에서는 중간에 해결된 듯하지만, 여전히 여러 org와 repo에서 계속 재현됨 https://github.com/orgs/community/discussions/193388
나도 같은 현상을 봤고, status page에는 여전히 안 올라와 있음
빠진 PR은 브랜치 페이지를 뒤져서 겨우 찾았음
이건 확장성 때문에 추정 쿼리를 써서 100% 정확하지 않은 결과를 반환하게 만든 해킹일 가능성이 커 보임
완전한 버그라기보다, 인프라 부하를 줄이려고 제품 관점에서 아주 나쁜 선택을 했을 수도 있음
지난 몇 년간의 새 repo/issues/commits 데이터를 공개한 건 그래도 흥미로웠음
다들 바깥에서 짐작하던 대로, 에이전트들이 GitHub에 갑작스럽고 큰 추가 부하를 주고 있다는 걸 확인시켜 줌
이미 거대한 사용자 기반을 서비스하면서도 스타트업처럼 지수 성장하는 셈이라 표적이 될 수밖에 없고, 조직이 빠르게 움직이기도 쉽지 않을 것 같음
반대로 인재, 인프라, 자금은 스타트업보다 훨씬 많다는 점도 있음
무슨 데이터를 말하는지 모르겠음
라벨 없는 그래프 하나와 현재 피크 숫자만 있을 뿐임
저 그래프들은 도대체 뭘 해놓은 건지 모르겠고, 거의 아티스트의 인상화처럼 보임
커밋 그래프를 보면 왜 큰 계단이 생긴 뒤 완만하게 꺼지는지, 왜 그 계단이 일정한 지점에서 발생하지 않는지, 왜 더 큰 점프가 때로는 더 작은 기울기를 가지는지 설명이 안 됨
다른 그래프들은 또 전혀 다른 형태로 움직여서 더 이상함
전형적인 PowerPoint 그래프라서 그럼
실제 데이터나 데이터의 의미를 보여주기보다 그냥 "뭔가가 오른다"만 전달하는 용도임
federated forges가 결국 미래라고 봄
저장소는 각자 sovereign infra에 호스팅하고, 전역 ID와 federated metadata 이슈·PR 등을 얹는 구조가 맞아 보임
이런 전역 인덱스는 띄우기도 쉬워서 가용성이 큰 걱정거리가 아니게 만들 수 있고, 우리도 그 방향으로 작업 중임
아이디어는 귀엽지만, 대부분은 직접 호스팅하고 싶어 하지 않음
결국 제3자 호스팅을 쓰게 되면 1~3개의 큰 사업자가 다시 등장할 가능성이 큼
그리고 가용성 문제를 피하려고 셀프호스팅해도, 의존성이 GitHub 같은 대형 서비스에 걸려 있으면 그쪽 장애는 여전히 피할 수 없음
그래서 현실적 해법은 지금과 마찬가지로 쓰는 걸 전부 프록시하거나 미러링하는 쪽임
사실 이미 그렇게 할 수는 있음
GitHub, Codeberg, 셀프호스트에 같은 repo를 두고 메인 브랜치 일관성만 관리하면 됨
그다음부터는 어디서든 업데이트할 수 있고, README에 링크만 잘 걸어두면 됨
코딩 에이전트들이 깊은 VCS 통합을 할 때 GitHub를 기본값으로 두지 않았으면 좋겠음
decent API나 webhook만 제공하는 다른 forge를 연결해서 같은 편의성을 얻을 수 있다면 전부 셀프호스트로 가고 싶음
에이전트 쪽에서도 인터페이스를 열어줘야겠지만, 플러그인 구조라면 GitHub 의존성을 떼어내고 나머지는 MCP나 skills로 처리할 수 있을 것 같음
좋은 아이디어고, 우리 사이트의 LLM 생성 콘텐츠도 이것으로 대체하고 싶음
나는 큰 러너는 셀프호스팅해도 괜찮아서 최근 Codeberg로 옮겼고, 작은 cron 작업은 Codeberg가 제공하는 러너를 씀
거긴 이런 용도로 lazy runner까지 있음
Hacker News 의견들
GitHub는 올해 들어서만도 수십 차례 장애를 냈고, 작년보다도 가용성과 신뢰성이 눈에 띄게 나빠졌음
이 정도면 대시보드와 히트맵이 돌 정도로 심각하고, HN이나 Reddit 같은 곳에서 GitHub 불안정성이 밈이 될 수준까지 왔다고 봄
그런데도 우선순위가 "availability, capacity, new features"라고 말하는 건 현실 인식이 너무 느슨함
지금 우선순위는 1, 2, 3 전부 availability여야 하고, 최소 6개월은 다른 얘기 꺼내지 말고 그것만 고쳐야 함
6개월 전에는 Azure 이전이 최우선이라며 기능 개발을 미루겠다고 하더니, 지금은 또 가용성이 최우선이라고 하니 앞뒤가 잘 안 맞음
당시엔 AI와 Copilot 수요 때문에 버지니아 데이터센터 용량 제약이 "existential"하다고 했는데, 아직도 같은 문제로 비틀거리는 걸 보면 더 황당함
기능 개발이 미뤄졌다면서도 매주 새 기능과 UI 변경은 계속 나오고, 얼마 전에도 이슈 단일 뷰를 바꿨음
Microsoft 정도 자원을 가진 회사가 이렇게 계속 같은 데서 발목 잡히는 건 믿기 어려울 정도고, 인기 있는 개발자 서비스를 사들여 전부 같은 플랫폼으로 옮기는 전략도 불안해 보임
큰 엔지니어링 조직에서는 우선순위가 배타적이지 않고, 핵심 우선순위에 직접 기여하지 못하는 팀은 다른 기능 작업을 계속할 수도 있음
https://news.ycombinator.com/item?id=47912521
전용 하드웨어가 클라우드보다 예측 가능성이 높고, "Azure로 가지 말고 랙 몇 개 더 사자" 같은 판단은 GitHub 경영진 선에서 결정할 수 없는 일이었을 수도 있음
GitHub는 5분마다 재설계할 사이트가 아니고, 관리자들이 자기 존재 이유를 증명하려고 새 기능을 위한 새 기능을 밀어붙이는 것처럼 보일 때가 있음
그 결과 더 많이 망가뜨릴수록 오히려 사용자를 끌어들이는 데 역효과가 남
검색도 크게 너프됐고, Google 검색이나 YouTube처럼 왜 멀쩡하던 검색을 다들 계속 망가뜨리는지 모르겠음
게다가 Microsoft는 거의 버려진 듯한 Azure DevOps도 있고 GitHub도 있는데, 둘 다 특히 티켓 시스템이 싫음
Jira 프로젝트마다 설정이 제각각이라 질렸는데도, 이제는 "차라리 Jira가 그립다"는 말까지 나오게 됨
저 글은 정색하고 읽기 어렵다는 느낌임
숫자만 크게 올려놓은 라벨 없는 그래프, 실제 체감과 맞지 않는 우선순위, 그리고 지난 12개월의 끔찍한 업타임을 제대로 인정하지 않는 태도가 너무 거슬림
왼쪽 아래 축 라벨이 없긴 해도, 2023→2024→2025→2026으로 성장 속도가 매우 빠르다는 핵심은 전달됨
2026 초·말쯤에는 이전 3년을 합친 것보다 더 큰 성장을 말하는 것처럼 읽히고, 축 숫자를 몰라도 대략의 추세는 볼 수 있음
선형 그래프라는 가정은 필요하지만, 문맥상 그 정도 가정은 무리 없어 보임
계획보다 훨씬 큰 성장을 겪는 회사라면 용량 문제가 생길 수밖에 없고, 이제는 하드웨어만 더 넣는 수준을 넘어 백엔드 효율화가 필요해 보임
적어놓은 목표들도 대체로 그쪽을 겨냥하고 있음
https://x.com/kdaigle/status/2040164759836778878
지금 성장이 지수적이라는 걸 못 믿는 건지, 아니면 연간 10배 성장도 별로 안 어렵다고 보는 건지 모르겠음
https://damrnelson.github.io/github-historical-uptime/
"multi cloud 경로를 시작했다"는 문장을 보면, Microsoft가 Azure만으로는 원하는 수준의 신뢰성을 못 뽑는다고 사실상 인정한 것처럼 들림
유지율 방어에는 도움이 될 수 있음
원래는 사람 개입이 거의 없는 운영을 지향했는데, 지금은 누가 랙이나 VM에 시리얼 붙여 직접 건드리는 식이 일상적인 절차라는 얘기였음
지금은 링크를 못 찾겠지만
월~목 오전 9~11시 Pacific에 가장 적극적인 독자가 많고, 주말은 경쟁은 적지만 참여도도 낮음
GitHub CTO가 Codepath.org 이사회에도 있고, 거기 설명이 "첫 번째 AI-native 세대의 엔지니어, CTO, 창업자를 만든다"는 식이라면, 어디가 문제인지 대충 감이 옴
체감상 GitHub 안정성이 많이 나빴고, 최근엔 웹에서 보여주는 데이터조차 믿기 어려움
어제부터 나와 동료 몇 명이 여러 저장소에서 PR 목록이 불완전하게 보이는 걸 확인했음
예를 들어 https://github.com/gap-system/gap/pulls에서는 탭엔 "Pull requests 78"이라고 나오는데, 목록 뷰에는 "35 open"만 보임
78이 맞는 숫자인 건
gh pr list로도 확인되는데도 https://www.githubstatus.com은 여전히 "all systems operational"이라고 표시함CLI로는 목록이 나오는데, 검색을 거치는 웹 경로에서는 전부 사라짐
지원팀도 이 이슈를 인정하긴 했지만 그 뒤로 조용하고, 상태 페이지에도 27일의 아마 관련 있어 보이는 이슈 말고는 아무것도 없음
일부 저장소에서는 중간에 해결된 듯하지만, 여전히 여러 org와 repo에서 계속 재현됨
https://github.com/orgs/community/discussions/193388
빠진 PR은 브랜치 페이지를 뒤져서 겨우 찾았음
완전한 버그라기보다, 인프라 부하를 줄이려고 제품 관점에서 아주 나쁜 선택을 했을 수도 있음
지난 몇 년간의 새 repo/issues/commits 데이터를 공개한 건 그래도 흥미로웠음
다들 바깥에서 짐작하던 대로, 에이전트들이 GitHub에 갑작스럽고 큰 추가 부하를 주고 있다는 걸 확인시켜 줌
이미 거대한 사용자 기반을 서비스하면서도 스타트업처럼 지수 성장하는 셈이라 표적이 될 수밖에 없고, 조직이 빠르게 움직이기도 쉽지 않을 것 같음
반대로 인재, 인프라, 자금은 스타트업보다 훨씬 많다는 점도 있음
라벨 없는 그래프 하나와 현재 피크 숫자만 있을 뿐임
저 그래프들은 도대체 뭘 해놓은 건지 모르겠고, 거의 아티스트의 인상화처럼 보임
커밋 그래프를 보면 왜 큰 계단이 생긴 뒤 완만하게 꺼지는지, 왜 그 계단이 일정한 지점에서 발생하지 않는지, 왜 더 큰 점프가 때로는 더 작은 기울기를 가지는지 설명이 안 됨
다른 그래프들은 또 전혀 다른 형태로 움직여서 더 이상함
실제 데이터나 데이터의 의미를 보여주기보다 그냥 "뭔가가 오른다"만 전달하는 용도임
federated forges가 결국 미래라고 봄
저장소는 각자 sovereign infra에 호스팅하고, 전역 ID와 federated metadata 이슈·PR 등을 얹는 구조가 맞아 보임
이런 전역 인덱스는 띄우기도 쉬워서 가용성이 큰 걱정거리가 아니게 만들 수 있고, 우리도 그 방향으로 작업 중임
결국 제3자 호스팅을 쓰게 되면 1~3개의 큰 사업자가 다시 등장할 가능성이 큼
그리고 가용성 문제를 피하려고 셀프호스팅해도, 의존성이 GitHub 같은 대형 서비스에 걸려 있으면 그쪽 장애는 여전히 피할 수 없음
그래서 현실적 해법은 지금과 마찬가지로 쓰는 걸 전부 프록시하거나 미러링하는 쪽임
GitHub, Codeberg, 셀프호스트에 같은 repo를 두고 메인 브랜치 일관성만 관리하면 됨
그다음부터는 어디서든 업데이트할 수 있고, README에 링크만 잘 걸어두면 됨
decent API나 webhook만 제공하는 다른 forge를 연결해서 같은 편의성을 얻을 수 있다면 전부 셀프호스트로 가고 싶음
에이전트 쪽에서도 인터페이스를 열어줘야겠지만, 플러그인 구조라면 GitHub 의존성을 떼어내고 나머지는 MCP나 skills로 처리할 수 있을 것 같음
나는 큰 러너는 셀프호스팅해도 괜찮아서 최근 Codeberg로 옮겼고, 작은 cron 작업은 Codeberg가 제공하는 러너를 씀
거긴 이런 용도로 lazy runner까지 있음
지금 하는 일은 이거처럼 보임
토큰 보조금은 충분한 학습 데이터를 빨아들였고 agentic junkies 비즈니스도 이제 플라이휠을 굴릴 만큼 커졌으니 끊고, 손실 유도 상품은 정리하겠다는 것 같음
https://news.ycombinator.com/item?id=47923357