가라앉는 배: GitHub가 슬롭 묘지가 되고 있나요?
10년 넘게 GitHub는 오픈소스 우주의 확고한 중심지였습니다. Git을 기술 도구에서 소셜 네트워크로 변모시켜 전 세계 코드가 모여 있는 중앙 허브를 만들었습니다. 그러나 점점 더 많은 개발자들이 이 플랫폼이 "sinking"이라고 경고하고 있습니다. 신뢰성 감소, AI가 생성한 잡음의 급증, 그리고 Microsoft에 인수된 이후 느껴지는 "enshittification"을 이유로 들고 있습니다.
이 변화는 단순히 미적 선호의 문제가 아니라 기술적 부채가 되고 있습니다. 플랫폼이 가동 시간과 성능에 어려움을 겪으면서, 커뮤니티는 근본적인 진실을 다시 깨닫고 있습니다: Git은 GitHub가 아닙니다.
안정성 위기와 "Slop" 급증
최근 데이터와 사용자 경험은 GitHub의 신뢰성이 흔들리고 있음을 시사합니다. 공식 상태 페이지가 종종 긍정적인 모습을 보여주는 반면, 독립적인 추적과 사용자 보고서는 잦은 중단과 제한적인 속도 제한이라는 다른 이야기를 전합니다.
이 하락에 대한 가장 도발적인 이론 중 하나는 "slop" 효과입니다. GitHub Copilot과 같은 AI 도구의 통합은 플랫폼의 활동량을 근본적으로 변화시켰습니다. GitHub 자체 리더십이 인용한 데이터에 따르면, 플랫폼 활동이 기하급수적으로 급증했습니다:
- Commit Volume: 2025년에 10억 커밋에서 연간 약 140억 커밋으로 추정됩니다.
- CI/CD Load:
GitHub Actions는 2023년에 주당 5억 분에서 최근에는 주당 21억 분 이상으로 성장했습니다.
이 활동 폭발이 반드시 인간 생산성 증가의 신호는 아니며, 오히려 "sleepless always-on agents"가 대량의 저품질 AI 생성 코드를 커밋한 결과입니다. 한 댓글자는 GitHub가 사실상 "DDoSing themselves with slop"라고 지적했습니다.
개발자 경험의 "Enshittification"
수치적인 측면을 넘어, 플랫폼의 엔지니어링과 거버넌스 품질이 쇠퇴하고 있다는 인식이 있습니다. 비평가들은 몇 가지 주요 불만 영역을 지적합니다:
1. 가짜 스타 경제
GitHub의 "star" 시스템은 한때 프로젝트 품질과 인기도를 나타내는 대리 지표였지만, 봇 조작과 AI 기반 인플레이션으로 인해 점점 쓸모없어지고 있습니다. 이는 진정하고 고품질인 프로젝트를 찾는 것을 그 어느 때보다 어렵게 만듭니다.
2. 과도하게 설계된 CI/CD
GitHub Actions는 강력하지만, 일부 개발자는 이를 '혐오스러운'—비대하고 복잡한 시스템으로, 중요한 배포의 단일 실패 지점이 되었다고 봅니다.
3. 기업적 부피
Microsoft가 한때 민첩했던 도구에 기업적인 마찰 층을 추가했다는 여운이 남아 있습니다. Copilot에 대한 사용량 기반 청구부터, 심지어 개인 개발자에게도 영향을 미치는 제한적인 API 한도까지, 플랫폼은 커뮤니티 자원보다는 기업 제품에 가까워지고 있습니다.
대이동: 어디로 갈까?
GitHub에 대한 신뢰가 약해지면서, 개발자들은 "lifeboats"를 찾고 있습니다. 이 움직임은 다른 중앙화된 서비스를 찾는 사람들과 분산 버전 관리의 뿌리로 돌아가는 사람들로 나뉩니다.
중앙화된 대안
- Codeberg / Forgejo: 비영리, 커뮤니티 주도 대안.
Codeberg는 기업 소유권을 벗어나고자 하는 이들에게 "safe" 선택으로 자주 언급됩니다. - GitLab: 주요 기업 경쟁자. 일부는 "bloated and confusing"이라고 묘사하지만, 세밀한 권한과 통합 Docker 호스팅이 필요한 복잡한 팀에게는 여전히 견고한 선택입니다.
- Tangled: AT 프로토콜을 통합한 알파 단계 프로젝트로, 탈중앙화된 소셜 구조에 관심 있는 이들에게 매력적입니다.
자체 호스팅 경로
전체 제어를 원하는 이들에게 자체 호스팅 Git 포지는 점점 실현 가능해지고 있습니다. Forgejo와 Gitea와 같은 도구를 사용하면 개발자는 VPS에서 월 몇 달러로 자체 인프라를 운영할 수 있습니다.
일부 순수주의자들은 더 나아가 "Linux model"로의 복귀를 주장합니다: SSH를 통한 순수 Git과 이메일 메일링 리스트를 통한 코드 리뷰. 한 개발자는 이러한 시스템이 "doesn't work at scale"이라는 주장은 종종 "skill issue"라고 주장했으며, 이는 역사상 가장 성공적인 프로젝트인 Linux 커널이 바로 이런 방식으로 구축되었기 때문입니다.
반론: 공황이 정당한가?
모두가 GitHub가 죽음의 나선에 빠졌다고 동의하는 것은 아닙니다. 일부는 현재의 불안정이 전례 없는 성장 규모의 자연스러운 성장통이라고 주장합니다. 그들은 GitHub가 수년간 수백만 명에게 무료 인프라를 제공했으며, 현재의 "slop" 문제는 Microsoft에만 국한된 것이 아니라 업계 전반의 문제라고 지적합니다.
게다가 "network effect"는 여전히 강력한 힘입니다. 많은 사람들에게 모든 협업자, 의존성, 그리고 Vercel이나 DigitalOcean 같은 서드파티 통합이 이미 GitHub에 연결되어 있는 편리함이 가끔 발생하는 중단 위험보다 더 큰 장점으로 작용합니다.
결론: 퇴출 계획의 필요성
GitHub가 실제로 "sinking"인지 아니면 AI 시대의 무게 아래 단순히 진화하고 있는지는 별개로, 현재 상황은 중요한 경고를 제공합니다: 당신의 코드는 단일 독점 사일로에 갇혀서는 안 됩니다.
Git은 분산형으로 설계되었습니다. 모든 개발자와 조직에게 가장 회복력 있는 전략은 퇴출 계획을 유지하는 것입니다—레포지토리를 보조 포지에 복제하거나 자체 호스팅 인프라에 투자하는 것이든 말이죠. "slop"과 기업 통합의 시대에 마찰 없이 작업을 이전할 수 있는 능력이 궁극적인 기술 주권의 형태입니다.