GitHub 의존 리스크와 대안 Git Forge
핵심 요약
이 글의 주장은 단순하다. GitHub가 점점 불안정하고 신뢰하기 어려운 플랫폼이 되고 있으므로, GitHub을 Git 자체와 동일시하지 말고 탈출 계획을 가져야 한다는 것이다.
핵심 문제는 네 가지다.
- Microsoft 인수 이후 GitHub 가용성에 대한 불만이 커지고 있다.
- Copilot과 AI 생성 코드 범람으로 플랫폼 품질과 신뢰가 흔들린다.
- 봇, 가짜 스타, slop 프로젝트가 GitHub의 사회적 신호를 훼손한다.
- Git은 분산 버전 관리 시스템이므로 GitHub 없이도 동작한다.
결론은 “당장 모든 것을 버리라”가 아니라, GitHub를 단일 장애점으로 두지 말라에 가깝다.
GitHub의 문제
가용성 악화
글쓴이는 Microsoft 인수 이후 GitHub의 uptime과 사용 경험이 악화되었다고 본다. 공식 상태 페이지도 우려스러운 수치를 보여주고, 비공식 상태 추적은 더 나쁜 그림을 제시한다고 주장한다.
GitHub는 전 세계 오픈소스와 기업 개발 워크플로우의 중심에 있기 때문에, 작은 장애도 광범위한 개발 중단으로 이어진다. 저장소 접근, 이슈, PR, Actions, Packages, Releases가 모두 한 플랫폼에 묶여 있으면 장애 범위가 커진다.
Copilot과 AI slop
GitHub는 Copilot과 AI 기능을 적극적으로 밀고 있다. 문제는 AI 생성 저품질 코드, 자동화 봇, 가짜 프로젝트, 가짜 스타 경제가 플랫폼의 신호 품질을 떨어뜨린다는 점이다.
GitHub star는 원래 프로젝트 신뢰도와 인기도를 나타내는 사회적 신호였지만, 봇과 마케팅용 star farming이 늘어나면 지표로서의 의미가 줄어든다.
GitHub Actions 리스크
GitHub Actions는 편리하지만, CI/CD까지 GitHub에 묶이게 만든다.
문제는 다음과 같다.
- 저장소, 이슈, PR, CI가 한 플랫폼 장애에 동시에 영향을 받는다.
- 복잡한 YAML 파이프라인이 유지보수 부담을 만든다.
- GitHub 정책이나 과금 변화에 직접 노출된다.
- 다른 포지로 이전할 때 Actions가 가장 큰 마이그레이션 비용이 될 수 있다.
이는 AWS를 떠나는 이유에서 다룬 벤더 락인 문제와 비슷하다. 편의 기능이 많을수록 플랫폼 이탈 비용이 커진다.
Git은 GitHub가 아니다
가장 중요한 구분은 Git과 GitHub가 다르다는 점이다.
- Git: 오픈소스 분산 버전 관리 시스템.
- GitHub: Git 저장소를 호스팅하고 이슈, PR, Actions, Releases 같은 협업 기능을 제공하는 중앙화 포지.
Git은 중앙 서버 없이도 동작한다. 모든 clone은 원칙적으로 완전한 저장소 사본이다. SSH만으로도 저장소를 주고받을 수 있다.
예시는 다음과 같다.
git clone user@192.168.1.67:/path/to/repoGitHub은 Git 위에 올라간 사회적·협업적 편의 계층이다. 유용하지만 대체 불가능한 것은 아니다.
대안 Git Forge
Codeberg
Codeberg는 비영리·커뮤니티 주도 Git 포지다. Forgejo 기반 대표 인스턴스이며, GitHub를 떠나는 개인/오픈소스 프로젝트의 현실적인 대안으로 자주 언급된다.
장점은 커뮤니티 중심성과 비영리 구조다. 단점은 GitHub만큼 거대한 네트워크 효과와 엔터프라이즈 통합을 기대하기 어렵다는 점이다.
Forgejo
Forgejo는 자체 호스팅에 적합한 Git 포지다. Gitea에서 갈라진 커뮤니티 중심 프로젝트로, GitHub 대체를 직접 운영하고 싶을 때 유력한 선택지다.
자체 호스팅 Forgejo는 다음에 적합하다.
- 조직 내부 Git 포지.
- 개인/팀 프로젝트 미러.
- GitHub 장애나 정책 변화에 대비한 백업.
- 공개 협업은 Codeberg에, 내부 운영은 Forgejo에 두는 하이브리드 구성.
Gitea
Gitea는 가볍고 오래된 오픈소스 Git 포지다. Forgejo와 Codeberg의 역사적 기반이기도 하다. 자체 호스팅과 관리형 서비스를 모두 고려할 수 있다.
GitLab
GitLab은 엔터프라이즈급 대안이다. 기능은 풍부하지만 무겁고 복잡하다. 조직 의사결정, 보안 정책, 사내 CI/CD 통합이 필요한 경우에는 현실적인 선택지가 될 수 있다.
Tangled
Tangled는 알파 단계의 Git 포지로, AT Protocol 통합이 특징이다. 아직 성숙한 대안이라기보다는 작은 개인 프로젝트나 실험적 분산 소셜 개발 흐름을 탐색할 때 관심을 가질 만하다.
기타
추가 후보는 다음과 같다.
- Sourcehut.
- Radicle.
- Game of Trees.
- Bitbucket.
Bitbucket은 적극 추천되는 대안은 아니지만, “GitHub가 아닌 중앙화 Git 포지”라는 선택지에는 들어간다.
마이그레이션 전략
GitHub 탈출은 한 번에 할 필요가 없다. 현실적인 전략은 단계적 이전이다.
- GitHub 저장소를 다른 포지에 미러링한다.
- 새 upstream remote를 추가한다.
- 이슈와 PR이 필요한 프로젝트부터 포지 기능을 검토한다.
- GitHub Actions 의존 파이프라인을 분리한다.
- Releases, Packages, Pages 같은 부가 기능을 대체한다.
- 핵심 프로젝트는 GitHub 외부를 primary로 전환한다.
이슈와 PR 이력은 완벽히 이전하기 어렵다. 일부 프로젝트는 GitHub 이슈를 읽기 전용 아카이브로 남기고, 새 포지에서 새 이슈를 받는 방식을 택할 수 있다.
자체 호스팅의 현실
자체 호스팅은 자유도를 주지만 운영 책임도 가져온다.
필요한 운영 요소는 다음과 같다.
- 백업.
- 업그레이드.
- 사용자 관리.
- 스팸 방어.
- CI/CD runner.
- 릴리스 파일 저장소.
- 보안 패치.
- 도메인과 TLS.
따라서 작은 개인 프로젝트는 Codeberg 같은 관리형 커뮤니티 포지가 더 현실적일 수 있고, 조직 내부 프로젝트는 Forgejo/GitLab 자체 호스팅이 맞을 수 있다.
시사점
GitHub 의존 리스크의 본질은 GitHub가 나쁘다는 것이 아니다. 너무 많은 개발 인프라가 하나의 중앙화 플랫폼에 집중되어 있다는 점이다.
GitHub에 묶이는 것은 단순 저장소 호스팅 이상의 의존이다.
- 이슈 관리.
- 코드 리뷰.
- CI/CD.
- 패키지 배포.
- 릴리스 배포.
- 프로젝트 신뢰도 지표.
- 오픈소스 커뮤니티 발견성.
이 모든 것이 한 플랫폼에 집중되면, 플랫폼 장애·정책 변화·AI slop·계정 제한·과금 변화가 개발 생태계 전체의 리스크가 된다.
결론
Git은 분산형이지만 GitHub 사용 방식은 중앙집중형이다. 이 모순을 줄이려면 적어도 중요한 프로젝트는 GitHub 밖에 미러를 두고, CI/CD와 릴리스 배포를 GitHub에만 묶지 않는 구조를 만들어야 한다.
GitHub를 당장 버릴 필요는 없지만, GitHub 없이도 프로젝트가 살아남을 수 있어야 한다.