# GitHub이 침몰하고 있다 > Clean Markdown view of GeekNews topic #29405. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29405](https://news.hada.io/topic?id=29405) - GeekNews Markdown: [https://news.hada.io/topic/29405.md](https://news.hada.io/topic/29405.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-12T08:33:52+09:00 - Updated: 2026-05-12T08:33:52+09:00 - Original source: [dbushell.com](https://dbushell.com/2026/04/29/github-is-sinking/) - Points: 2 - Comments: 2 ## Topic Body - Microsoft 인수 이후 GitHub의 **가용성(uptime)** 이 눈에 띄게 악화되고 있으며, 공식 상태 페이지조차 우려스러운 수치를 보여주고, 비공식 상태 페이지는 더 심각한 상황을 전달 - Copilot 남발과 AI 생성 저품질 코드(**슬롭**)의 범람으로 GitHub이 스스로를 DDoS하는 상황이 벌어지고 있으며, 봇과 가짜 스타 경제가 플랫폼 신뢰를 훼손 - Git은 오픈소스 **분산형 버전 관리 시스템**이며 GitHub 없이도 동작하므로, GitHub을 Git 자체와 동일시하는 인식에서 벗어나야 함 - Codeberg, Tangled, Gitea, GitLab, 셀프호스팅 Forgejo 등 다양한 **대안 Git 포지(forge)** 가 존재하며, 마이그레이션을 즉시 시작해야 함 - 여러 저명 개발자들이 GitHub 이탈을 선언하는 글을 잇달아 게시하며, GitHub 의존에서 벗어나는 것이 **생태계 전체의 과제**로 부상 --- ### GitHub를 떠나야 하는 이유 - GitHub는 Microsoft 인수 이후 가동률과 사용 경험이 나빠졌다는 비판을 받고 있으며, 공식 가동률보다 [누락된 상태 페이지](https://mrshu.github.io/github-statuses/)가 더 나쁜 흐름을 드러낸다고 봄 - [GitHub’s Historic Uptime](https://damrnelson.github.io/github-historical-uptime/) 차트는 Microsoft 인수 이후 월별 평균 가동률이 불안정해진 모습을 보여주는 자료로 쓰임 - Microsoft는 GitHub 인수 뒤 [Copilot 관련 제품군](https://teybannerman.com/strategy/2026/03/31/how-many-microsoft-copilot-are-there.html)을 늘렸고, GitHub는 자체적으로 [가용성 문제 업데이트](https://github.blog/news-insights/company-news/an-update-on-github-availability/)를 내놓을 만큼 “slop”에 시달리는 상태임 - 최근 GitHub를 떠나거나 GitHub 이전의 개발 방식을 돌아보는 글들이 이어지고 있음 - [Ditching GitHub - Lonami](https://lonami.dev/blog/ditching-github/) - [Ghostty Is Leaving GitHub - Mitchell Hashimoto](https://mitchellh.com/writing/ghostty-leaving-github) - [Before GitHub - Armin Ronacher](https://lucumr.pocoo.org/2026/4/28/before-github/) - [From GitHub to Codeberg/Forgejo - Jonas Hietala](https://www.jonashietala.se/blog/2026/04/28/from_github_to_codebergforgejo/) - [GitHub is dead, What’s next? - Alex Hyett](https://www.alexhyett.com/newsletter/github-is-dead-whats-next/) ### Git ≠ GitHub - GitHub이 "소스 관리"와 동의어가 되었지만, 너무 많은 사용자가 **Git이 GitHub이 아니라는 사실**을 모르고 있음 - Git과 GitHub는 같은 것이 아니며, Git의 핵심 기술은 **오픈소스**이며 분산형이므로, 모든 저장소가 동등하고 중앙 집중 서비스 없이도 동작 가능 - 중앙화된 서비스는 사회적 편의의 산물이며, GitHub은 원래 유용한 부가 도구에 불과했으나 Microsoft가 이를 **비싼 부채**로 전환함 - 네트워크 효과는 강하지만, GitHub의 [가짜 스타 경제](https://awesomeagents.ai/news/github-fake-stars-investigation/)는 가치가 없고 봇과 [slop](https://www.theregister.com/2026/02/18/godot_maintainers_struggle_with_draining/)이 넘치는 상태임 - GitHub Actions는 과도하게 복잡한 CI 파이프라인의 일부. 다른 해결책을 찾는 일은 번거롭긴 하지만, GitHub의 **안정성을 신뢰할 수 있는지** 자문해야 함 - [GitHub Actions are killing your team](https://www.iankduncan.com/engineering/2026-02-05-github-actions-killing-your-team/) - [GitHub Actions is the weakest link](https://nesbitt.io/2026/04/28/github-actions-is-the-weakest-link.html) - 배가 침몰하고 있으므로, 한 번에 모든 것을 옮기지 않더라도 **이전 과정을 즉시 시작**해야 함 ### 대안과 이전 방식 - 가장 가까운 탈출 경로는 **다른 중앙화된 Git 포지**로 이동하는 것이며, 가입 후 저장소를 새 업스트림으로 푸시하면 됨 - 일부 서비스는 마이그레이션을 자동화하고 이슈 가져오기도 지원할 수 있지만, GitHub의 이슈를 그대로 남겨두는 선택도 가능함 - 아래 대안들은 모두 완벽한 선택지는 아니며, 공통점은 **GitHub가 아니라는 것**뿐임 - ## 중앙화된 Git 포지 대안 - [Codeberg](https://codeberg.org/) — 비영리·커뮤니티 주도 프로젝트이며, 검증된 기록이 있는 안전한 대안. [Forgejo](https://forgejo.org/)의 대표 인스턴스임 - [Tangled](https://tangled.org/) — 알파 단계 스타트업이며, [AT protocol](https://dbushell.com/2026/03/10/building-on-at-protocol/) 통합이 흥미로운 선택지. 작은 개인 프로젝트에 고려할 만함 - [Gitea](https://about.gitea.com/) — 클라우드 관리형 Git 호스팅을 제공하며, Codeberg/Forgejo가 갈라져 나온 원래 오픈소스 프로젝트 - [GitLab](https://about.gitlab.com/) — 엔터프라이즈급이라 무겁고 혼란스럽지만, 조직 내 의사결정에 어울릴 수 있는 선택지 - [Bitbucket](https://bitbucket.org/) — 권장되지는 않지만 “GitHub가 아닌 것”이라는 범주에는 들어감 - [Game of Trees](https://gothub.org/), [Radicle](https://radicle.dev/), [Sourcehut](https://sr.ht/) — 추가 대안이며, 직접 조사 필요 - ## 자체 호스팅 - 조직이나 개인은 Git 포지를 자체 호스팅할 수 있으며, [actions](https://dbushell.com/2025/08/15/self-hosted-forgejo-actions-runner/)와 [releases](https://dbushell.com/2025/08/25/self-hosted-forgejo-actions-releases/)도 운영 가능함 - 추천 자체 호스팅 선택지는 [Forgejo](https://forgejo.org/)임 - Forgejo 인스턴스 간 [연합](https://codeberg.org/forgejo-contrib/federation) 논의가 있고, Tangled도 [연합 관련 글](https://blog.tangled.org/federation/)을 냈지만 가까운 시일 안에 실현되지는 않을 것 같음 - 공개 협업이 필요하면 Codeberg에 사본을 푸시하는 방식 사용 가능 - Gitea와 GitLab도 자체 호스팅 옵션을 제공하지만, GitLab은 상대적으로 훨씬 무거움 - GitHub뿐 아니라 다른 포지도 Git 자체와는 별개이며, 포지의 부가 기능이 꼭 필요한지 따져볼 수 있음 - Git은 SSH만으로도 직접 사용할 수 있음 ```bash git clone user@192.168.1.67:/path/to/repo ``` - 협업 방식은 별도 문제지만, **Linux가 이메일 메일링 리스트로 패치를 주고받으며 유지**될 수 있다면 규모 문제만으로 불가능하다고 단정하기 어려움 - 중앙화된 Git 포지는 현실적인 절충안일 수 있지만, GitHub처럼 무너질 가능성을 염두에 두고 항상 **탈출 계획**을 가져야 함 ## Comments ### Comment 57280 - Author: kimjoin2 - Created: 2026-05-12T10:54:49+09:00 - Points: 2 제공하는 기능들을 생각하면 99% 이상 뽑아주고있는게 놀라울정도인대 ### Comment 57257 - Author: neo - Created: 2026-05-12T08:33:52+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48085095) - 모두가 이걸 **Microsoft 인수**나 무능 탓으로 돌리고 싶어 하지만, GitHub가 공개한 자료를 보면 AI 때문에 GitHub에 커밋되는 코드량이 10배로 늘었고 그 여파가 CI, Actions, 코드 수집 등 전반에 퍼진 게 꽤 명확해 보임 글쓴이는 MS Copilot 같은 이상한 요소를 원인으로 잡는데, 인과관계라기보다 싫어하는 것들을 나열한 느낌임 정작 방 안의 코끼리인 **AI발 코드 폭증**은 무시하고 있음 - 본문 그래프를 보면 다운타임 패턴은 **2020년 1월**부터 시작됨 OpenAI가 GPT-3.5를 낸 건 2022년 11월, 사실상 12월이고, 설명한 식의 대규모 언어 모델/에이전트 코딩은 2024년에야 본격화됐고 실제로는 2025년에 더 가까움 그렇다면 AI 얘기가 시작되기 전, 인수 이후 약 4년 동안의 나쁜 가용성은 어떻게 설명할 수 있나? - 글을 읽고 나도 정확히 같은 반응이었음 Microsoft 비판에 올라타는 건 좋지만, 방 안의 코끼리를 놓치면 안 됨 내일 완벽한 GitHub 대체제가 생긴다 해도, 수백만 줄의 **AI 생성 코드**가 그곳의 인프라를 망가뜨리는 걸 무엇이 막을 수 있나? 중앙집중식 코드 호스팅은 AI 때문에 거의 죽게 될 것 같음. 소셜 미디어에서 벌어지는 일과 비슷함 - GitHub는 인수 이후 긍정적으로 바뀐 게 없음 10년은 긴 시간이고, 그 결과가 드러남 GitHub Actions, Copilot, 그리고 끌 수도 없는 못생긴 AI 검색. Azure로의 이전까지 Microsoft가 **네트워크 효과**를 망치는 데 성공했고, 장애는 낙타 등을 부러뜨린 마지막 지푸라기임 - 설령 그게 사실이어도 Microsoft는 **클라우드 플랫폼 전체**를 가진 회사임 자체적으로 거대한 코드베이스가 있고 직원도 약 20만 명임 특히 비공개 저장소 무료화 같은 결정을 의식적으로 내렸기 때문에, 이건 변명이 되기 어려움 - Microsoft가 GitHub를 Azure 클라우드의 Windows 위에서 돌리고 있다고 상상하곤 함 GitHub가 내려갈 때마다 “누가 GH가 도는 Windows Server를 업데이트해서 전부 재부팅해야 했나 보다”라고 생각함 99% 사실이 아니라고 확신하지만, 그렇게 생각하면 마음이 편하고 장애가 날 때마다 조금 웃기기도 함 - 오늘 GitHub에서 저장소를 보려고 했음 “xxx commits” 링크를 눌러 커밋 기록을 보려 했더니 **secondary rate limit**에 걸렸으니 기다리라는 메시지가 나옴 이 네트워크에서 GitHub를 볼 사람은 나뿐이고, 연결도 CGN이 아닌 전용 IP임 - 사이트를 제대로 탐색하는 유일한 방법은 **로그인한 상태**로 보는 것임 - 나도 정확히 똑같고, 꽤 자주 겪음 - Slack에 있는 정상 링크를 눌렀는데 나한테는 404가 뜨고 다른 사람들에게는 잘 열리는 일이 자주 있음 - 데스크톱이라면 **Ctrl + Shift + R**로 페이지 캐시를 새로고침하면 됨 그러면 페이지가 정상적으로 로드됨 - 이건 전형적인 테크브로식 가스라이팅임 실제로는 몇 년째 rate limit이 아니라 기본 거부에 가까운데, 문구를 현실에 맞게 바꾸길 거부하고 있음 - “GitLab - 엔터프라이즈급이라는 뜻은 비대하고 헷갈리지만 상사에게는 인상적으로 보인다는 말이다. 선택하는 데 회의가 여러 번 필요하다면 이걸 고르면 된다.” 웃김 - 회사에서 GitLab을 쓰는데 솔직히 실망스러움 가장 단순한 일을 하려 해도 UI가 너무 복잡함. 예를 들어 MR을 승인하려면 사실상 메뉴인 버튼을 눌러야 하고, diff는 읽기 어렵고, ‘To-do list’에는 이미 병합된 MR도 들어가 있음. 그게 어떻게 실행 가능한 할 일인가? 이미 병합된 MR이 ‘To-do list’에 남는 문제는 몇 년 전에 올라왔는데도 개선이 빠르지 않아 보임 반대로 Bitbucket에 대한 반발은 좀 놀랍다. UI가 매우 단순하고 명확하고, 새로 합류한 사람들도 그렇게 느낌. Script Runner를 쓰면 꽤 놀라운 일도 가능하고, 거대한 저장소도 잘 처리함 - 웃기긴 하지만 사실은 아님 GitLab이 GitHub보다 특별히 더 비대하거나 헷갈리지는 않음 진짜 **엔터프라이즈급 소프트웨어**라고 보기도 어려움. 그런 걸 원하면 Jira나 Microsoft가 만드는 아무거나 보면 됨 - 피식했음 우리는 자체 호스팅 GitLab을 쓰는데, git과 **컨테이너 레지스트리**가 있어서 내가 골랐음 웹 UI를 자주 쓰지 않는다면 인터페이스가 확실히 헷갈릴 수 있음 - 월 5달러면 서버 하나를 호스팅해서 여러 프로젝트를 올릴 수 있음 저장소에 별이 백만 개 달리는 건 아니지만, 내 필요에는 충분히 동작하고 원하는 사람에게 접근 권한도 줄 수 있음 - 그래프를 어떻게 봐야 할지 잘 모르겠음 한편으로는 GitHub 인수 때문에 **가용성**이 나빠졌을 수도 있음 다른 한편으로는 인수 전 가용성이 100.00%로 나오는 게 수상하고, 단순히 상태 페이지가 더 잘 업데이트되기 시작한 건 아닌가 싶음 최근 GitHub 가용성 문제가 있다는 건 알지만, 그래프상 문제는 2020년에 시작되고 크게 악화되는 것처럼 보이지는 않음 - 주요 오픈소스 저장소는 결국 가만히 두기가 불가능한 것처럼 느껴짐 SourceForge가 망가져 가던 걸 기억하는데, GitHub에서도 같은 일이 벌어지는 걸 보는 건 정말 안타까움 덧붙이면 URL을 “dBus hell”로 읽었음. 다들 한 번쯤 겪어봤잖아 - 아니, dBu 단위 기반의 nushell이라서 **dBu Shell**임 - 내가 회사를 운영한다면 어떻게 할지 자주 생각함 모든 코드 리뷰를 **이메일**로 하면 어떨지 정말 보고 싶음 저장소는 git 전용 SSH 접근만 되는 단순한 VPS식 서버면 되고, 리뷰 대상 코드를 위한 `for-review/` 브랜치 네임스페이스를 두고, CI는 브랜치가 나타나길 기다리는 봇으로 만들어 ref에 주석이나 태그를 달아 통과 여부를 표시하면 됨. 결과를 이메일 스레드에 답장할 수도 있음 메일링 리스트에는 당연히 웹 아카이브 뷰어를 붙이면 예전 리뷰를 볼 수 있음. 이미 이런 해법은 많고, 그냥 HTML임 채팅은 IRC로 하고 봇이 채널을 보관하면 됨. 엄청 쉬움 전체 시스템은, 더 강한 하드웨어가 필요한 CI 실행기를 제외하면 아주 싼 서버에서 돌릴 수 있음 GitHub는 소프트웨어 프로젝트 운영에 필요한 것보다 훨씬 과하게 설계되어 있음. Linux 커널을 보면 단순한 메일링 리스트를 쓰는데, 역대 가장 성공적인 소프트웨어 프로젝트라고 해도 논쟁의 여지가 크지 않음 다만 이슈/버그 추적은 좀 더 무서움. 직접 해법을 만들겠다고 삽질하다가 회사가 하는 일보다 거기에 더 빠질 것 같기 때문임. 어쩌면 버그 추적 소프트웨어 회사가 되면 되려나? - 이상적으로는 코드 리뷰도 **버전 관리**되고 쉽게 접근 가능한 기록이 있으면 좋겠음 즉 코멘트가 정확히 어떤 줄에 붙어 있었는지, 그 줄이 언제 바뀌었는지 보고 앞뒤로 전환하고 싶음 이메일은 이 데이터를 교환하는 프로토콜로는 충분할 수 있지만, 이메일 클라이언트는 그걸 보기 좋은 방식은 아니라고 봄 어쩌면 분산형 코드 리뷰 시스템도 필요할지 모름 - 동유럽에 사는 데도 장점이 있음 시간대 덕분에 큰 GitHub 장애를 거의 알아차리지 못함 무료 호스팅과 Actions를 꽤 후하게 제공하는 점에도 만족함 - 집 서버에 **Forgejo**를 설치한 뒤로는 돌아보지 않았음 유일한 문제는 DigitalOcean App Platform이나 Vercel 등에 앱을 호스팅할 때인데, 이들은 GitHub에만 연결됨 - `DigitalOcean App Platform`은 GitHub뿐 아니라 GitLab에서도 배포를 지원함 다만 자체 호스팅 GitLab 인스턴스가 아니라 gitlab.com 호스팅 인스턴스를 써야 함 이미 자체 호스팅 forge를 배포했다면 gitlab.com을 다리처럼 써서 DigitalOcean App Platform에 연결할 수 있음. gitlab.com 계정을 한 번 만들고, 자체 호스팅 forge가 gitlab.com으로 복제본을 보내게 하면 됨. 실제로 GitLab을 쓸 필요는 별로 없음 그렇다 해도 DigitalOcean이 IaaS/PaaS를 파는 회사인데, 자기 인프라에서 돌아가는 자체 호스팅 Forgejo 같은 것에 연결하게 해주지 않는 건 말이 안 됨 사실 자체 forge를 호스팅하고 싶은 사람은 많지만 직접 설정하고 운영하고 싶은 사람은 적다는 걸 생각하면, DigitalOcean이 Forgejo나 대안을 집어 와서 연 20달러 같은 큰 할인 가격의 준관리형 원클릭 배포 옵션을 제공하고 App Platform 연결을 1급으로 지원하지 않는 것도 이상함 - GitHub를 피해야 하는 모든 이유는 **DigitalOcean App Platform**과 Vercel을 피해야 하는 이유이기도 함 DigitalOcean은 쓰지만 VPS만 씀 이런 중간 계층에 벤더 종속되지 말고, 통제권을 유지하면서 가능한 한 보편적인 스택 계층을 목표로 해야 함 - 비슷한 처지임 Forgejo 포크 이전인 몇 년 전부터 Gitea로 갈아탔고 후회 없음 GitHub가 필요한 경우에는 저장소를 거기로 미러링해서 동작하게 만들 수 있었음. 다만 코드를 동기화하는 건 귀찮음 - Apple의 **Xcode Cloud**도 비슷한 상황임 - GitHub가 힘들어하는 건 AI로 강화된 코딩 때문에 지난 1년간 커밋 수가 **14배** 늘었고, 그 속도가 아직도 가속 중이기 때문임 사이트가 따라잡기 힘들어하고 있음 GitHub COO가 여기서 확인해 줌: [https://x.com/kdaigle/status/2040164759836778878]() 플랫폼 활동이 급증 중임. 2025년에 커밋 10억 개가 있었는데, 이제는 주당 2억 7,500만 개라서 성장이 선형으로만 유지돼도 올해 140억 개 페이스임. 물론 선형으로 끝나진 않을 것임 GitHub Actions는 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 이번 주는 현재까지 이미 21억 분임 그래서 더 많은 CPU, 서비스 확장, GitHub 핵심 기능 강화에 엄청나게 밀어붙이고 있음