▲

GitHub이 침몰하고 있다

 (dbushell.com)
2P by GN⁺ 4시간전 | ★ favorite | 댓글 2개
  • Microsoft 인수 이후 GitHub의 가용성(uptime) 이 눈에 띄게 악화되고 있으며, 공식 상태 페이지조차 우려스러운 수치를 보여주고, 비공식 상태 페이지는 더 심각한 상황을 전달
  • Copilot 남발과 AI 생성 저품질 코드(슬롭)의 범람으로 GitHub이 스스로를 DDoS하는 상황이 벌어지고 있으며, 봇과 가짜 스타 경제가 플랫폼 신뢰를 훼손
  • Git은 오픈소스 분산형 버전 관리 시스템이며 GitHub 없이도 동작하므로, GitHub을 Git 자체와 동일시하는 인식에서 벗어나야 함
  • Codeberg, Tangled, Gitea, GitLab, 셀프호스팅 Forgejo 등 다양한 대안 Git 포지(forge) 가 존재하며, 마이그레이션을 즉시 시작해야 함
  • 여러 저명 개발자들이 GitHub 이탈을 선언하는 글을 잇달아 게시하며, GitHub 의존에서 벗어나는 것이 생태계 전체의 과제로 부상

GitHub를 떠나야 하는 이유

Git ≠ GitHub

  • GitHub이 "소스 관리"와 동의어가 되었지만, 너무 많은 사용자가 Git이 GitHub이 아니라는 사실을 모르고 있음
  • Git과 GitHub는 같은 것이 아니며, Git의 핵심 기술은 오픈소스이며 분산형이므로, 모든 저장소가 동등하고 중앙 집중 서비스 없이도 동작 가능
  • 중앙화된 서비스는 사회적 편의의 산물이며, GitHub은 원래 유용한 부가 도구에 불과했으나 Microsoft가 이를 비싼 부채로 전환함
  • 네트워크 효과는 강하지만, GitHub의 가짜 스타 경제는 가치가 없고 봇과 slop이 넘치는 상태임
  • GitHub Actions는 과도하게 복잡한 CI 파이프라인의 일부. 다른 해결책을 찾는 일은 번거롭긴 하지만, GitHub의 안정성을 신뢰할 수 있는지 자문해야 함
  • 배가 침몰하고 있으므로, 한 번에 모든 것을 옮기지 않더라도 이전 과정을 즉시 시작해야 함

대안과 이전 방식

  • 가장 가까운 탈출 경로는 다른 중앙화된 Git 포지로 이동하는 것이며, 가입 후 저장소를 새 업스트림으로 푸시하면 됨
  • 일부 서비스는 마이그레이션을 자동화하고 이슈 가져오기도 지원할 수 있지만, GitHub의 이슈를 그대로 남겨두는 선택도 가능함
  • 아래 대안들은 모두 완벽한 선택지는 아니며, 공통점은 GitHub가 아니라는 것뿐임

  • 중앙화된 Git 포지 대안

    • Codeberg — 비영리·커뮤니티 주도 프로젝트이며, 검증된 기록이 있는 안전한 대안. Forgejo의 대표 인스턴스임
    • Tangled — 알파 단계 스타트업이며, AT protocol 통합이 흥미로운 선택지. 작은 개인 프로젝트에 고려할 만함
    • Gitea — 클라우드 관리형 Git 호스팅을 제공하며, Codeberg/Forgejo가 갈라져 나온 원래 오픈소스 프로젝트
    • GitLab — 엔터프라이즈급이라 무겁고 혼란스럽지만, 조직 내 의사결정에 어울릴 수 있는 선택지
    • Bitbucket — 권장되지는 않지만 “GitHub가 아닌 것”이라는 범주에는 들어감
    • Game of Trees, Radicle, Sourcehut — 추가 대안이며, 직접 조사 필요

  • 자체 호스팅

    • 조직이나 개인은 Git 포지를 자체 호스팅할 수 있으며, actions와 releases도 운영 가능함
    • 추천 자체 호스팅 선택지는 Forgejo임
      • Forgejo 인스턴스 간 연합 논의가 있고, Tangled도 연합 관련 글을 냈지만 가까운 시일 안에 실현되지는 않을 것 같음
    • 공개 협업이 필요하면 Codeberg에 사본을 푸시하는 방식 사용 가능
    • Gitea와 GitLab도 자체 호스팅 옵션을 제공하지만, GitLab은 상대적으로 훨씬 무거움
    • GitHub뿐 아니라 다른 포지도 Git 자체와는 별개이며, 포지의 부가 기능이 꼭 필요한지 따져볼 수 있음
    • Git은 SSH만으로도 직접 사용할 수 있음 
      git clone user@192.168.1.67:/path/to/repo
  • 협업 방식은 별도 문제지만, Linux가 이메일 메일링 리스트로 패치를 주고받으며 유지될 수 있다면 규모 문제만으로 불가능하다고 단정하기 어려움
  • 중앙화된 Git 포지는 현실적인 절충안일 수 있지만, GitHub처럼 무너질 가능성을 염두에 두고 항상 탈출 계획을 가져야 함

함께 보면 좋은 글 β

▲
kimjoin2 1시간전  [-]

제공하는 기능들을 생각하면 99% 이상 뽑아주고있는게 놀라울정도인대

답변달기
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 모두가 이걸 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 핵심 기능 강화에 엄청나게 밀어붙이고 있음

답변달기