깃허브 떠나는 오픈소스 프로젝트들, Codeberg와 셀프호스팅으로 이동 중

• 깃허브는 숫자로만 보면 여전히 압도적인데, 표면 아래에서는 꽤 흥미로운 균열이 생기는 중임

  • 2025년에 거의 10억 건의 커밋이 올라왔고, 저장소도 6억 개 이상임
  • 신규 사용자는 1초에 1명꼴로 들어온다고 하니, 망해가는 플랫폼 얘기는 전혀 아님
  • 근데 일부 개발자와 프로젝트는 “여기서 계속 해야 하나?”를 진지하게 고민하기 시작함

• 가장 눈에 띄는 사례는 Ghostty, Zig, Tenacity 같은 프로젝트들이 깃허브를 떠난 거임

  • Ghostty는 Mitchell Hashimoto가 만든 크로스플랫폼 터미널 에뮬레이터인데, 2026년 4월 깃허브 이탈을 발표함
  • 단번에 끊는 건 아니고, 의존성을 단계적으로 제거하면서 기존 주소에는 읽기 전용 미러를 남기겠다는 방식임
  • Zig는 C의 정신적 후계자에 가까운 시스템 프로그래밍 언어인데, 2015년 첫 커밋 이후 쭉 깃허브에 있다가 2025년 11월 이탈을 발표함
  • Tenacity는 크로스플랫폼 오디오 편집기고, 2023년 레딧에서 이전을 알린 뒤 지금은 깃허브에 미러만 유지함

• 이탈 이유는 하나로 딱 정리되지 않고, 운영 품질·정치·AI가 섞여 있음

  • 가장 자주 나오는 불만은 장애임. IncidentHub 기준으로 2025년 5월 이후 1년 동안 “주요 장애” 48건, 총 112시간 다운타임이 기록됨
  • Ghostty와 Zig의 이전 배경에도 이런 장애 문제가 언급됨. 오픈소스 프로젝트 입장에서는 이슈, 릴리스, 기여 흐름이 멈추면 그냥 생산성이 박살남
  • Zig 창시자 Andrew Kelley는 깃허브와 미국 이민세관단속국의 관계도 언급함. 2019년에 깃허브가 해당 기관과 맺은 20만 달러 계약은 내부 직원들 사이에서도 비판받았던 사안임
  • AI도 갈등 포인트임. Copilot이 점점 깊게 통합되는 와중에, 2025년 깃허브 최고경영자가 “AI를 받아들이거나 이 커리어에서 나가라”는 식의 발언을 하면서 반감이 더 커짐

• Mitchell Hashimoto의 말이 분위기를 꽤 잘 요약함

  • 그는 깃허브가 더 이상 즐거운 곳이 아니고, 일을 하고 싶어도 플랫폼이 일을 못 하게 만드는 느낌이라고 말함
  • “소프트웨어를 배포하고 싶은데, 깃허브가 그걸 원하지 않는 것 같다”는 식의 표현까지 나옴
  • 이건 단순히 UI가 마음에 안 든다는 불만이 아니라, 개발 흐름 자체가 플랫폼 정책과 충돌한다는 얘기에 가까움

• 사실 깃허브를 애초에 쓰지 않았던 프로젝트들도 꽤 있음

  • 리눅스 커널은 깃허브에 읽기 전용 미러가 있긴 하지만, 메인 홈은 따로 있음
  • 그놈과 아파치의 수많은 소프트웨어도 자체 인프라나 별도 호스팅을 활용해왔음
  • GNU 프로젝트는 이념적으로 깃허브를 거부해왔고, 깃허브 사용에 비자유 소프트웨어인 자바스크립트가 필요하다는 점과 나쁜 라이선스 관행을 조장한다는 점을 문제 삼음

• 대안으로 가장 자주 언급되는 이름은 Codeberg임

  • Codeberg는 깃허브처럼 이슈 추적, 정적 페이지 호스팅, 지속적 통합과 지속적 배포를 제공함
  • 독일 베를린 기반의 비영리 운영이라는 점 때문에, 상업 플랫폼을 피하고 싶은 오픈소스 프로젝트에 매력적으로 보임
  • 기사에서는 Zig 같은 프로젝트가 깃허브를 떠나 선택한 대표적인 경쟁 서비스로 소개됨

• 물론 Codeberg만 있는 건 아님. 선택지는 꽤 넓어졌음

  • GitLab은 자체 호스팅 옵션이 있고, 깃 저장소뿐 아니라 지속적 통합과 지속적 배포, 보안 스캔, 프로젝트 관리까지 한 번에 묶는 쪽에 강함
  • Bitbucket은 깃허브와 비슷한 현대적 대안으로 여전히 쓰이고, 특히 Atlassian 생태계와 잘 붙음
  • Sourcehut은 완전한 오픈소스 서비스에 가깝고, 이메일 기반 워크플로를 강조함
  • 직접 운영하고 싶으면 Gitea나 Forgejo 같은 포지 소프트웨어로 자체 서버를 꾸릴 수도 있음

• 이 흐름이 당장 “깃허브 대탈출”까지 갈지는 아직 모름

  • 깃허브가 오픈소스 협업을 대중화한 공은 엄청 큼. 이건 부정하기 어려움
  • 하지만 거대한 플랫폼이 안정성, 정치적 신뢰, AI 전략에서 커뮤니티와 어긋나기 시작하면 대안 생태계가 힘을 받는 것도 자연스러움
  • 한국 개발자 입장에서도 회사나 오픈소스 프로젝트가 깃허브 하나에만 묶여 있어도 되는지, 미러·백업·자체 호스팅 전략을 한 번쯤 생각해볼 타이밍임

---

기술 맥락

• 여기서 중요한 선택은 “코드를 어디에 둘 것인가”예요. 저장소 호스팅은 단순 백업 공간이 아니라 이슈, 리뷰, 릴리스, 자동화가 다 붙는 개발 운영의 중심이거든요.

• Ghostty나 Zig가 깃허브를 바로 끊지 않고 읽기 전용 미러를 남기는 이유도 현실적인 마이그레이션 비용 때문이에요. 외부 기여자, 문서 링크, 자동화, 패키징 스크립트가 이미 깃허브 주소를 기준으로 굳어져 있으면 한 번에 옮기기 어렵거든요.

• Codeberg, Gitea, Forgejo 같은 선택지는 “플랫폼 회사의 정책을 얼마나 감수할 것인가”에 대한 답이에요. 운영을 맡기면 편하지만 종속성이 생기고, 직접 운영하면 통제권은 생기지만 장애 대응과 보안 패치 책임도 같이 따라와요.

• 팀에서 바로 적용할 만한 포인트는 미러 전략이에요. 메인 저장소를 어디에 두든, 최소한 릴리스와 이슈 트래킹, 지속적 통합 파이프라인이 특정 서비스 장애에 완전히 멈추지 않는지 점검할 이유가 있어요.