---
title: "깃허브 떠나는 오픈소스 프로젝트들, Codeberg와 셀프호스팅으로 이동 중"
published: 2026-07-09T08:22:52.000Z
canonical: https://jeff.news/article/4864
---
# 깃허브 떠나는 오픈소스 프로젝트들, Codeberg와 셀프호스팅으로 이동 중

깃허브는 여전히 초대형 플랫폼이지만, 일부 오픈소스 프로젝트는 장애, AI 통합, 정치적 이슈 때문에 다른 곳으로 옮기고 있어. Ghostty, Zig, Tenacity 같은 프로젝트가 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를 받아들이거나 이 커리어에서 나가라”는 식의 발언을 하면서 반감이 더 커짐

> [!IMPORTANT]
> 깃허브 탈출의 핵심은 “깃허브가 작아졌다”가 아니라 “오픈소스 인프라를 한 회사에 너무 의존해도 되나”라는 질문이 다시 커졌다는 점임.

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

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

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

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

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

---

## 기술 맥락

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

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

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

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

## 핵심 포인트

- 깃허브는 2025년에 6억 개 이상 저장소와 거의 10억 건의 커밋을 기록할 만큼 여전히 거대함
- Ghostty, Zig, Tenacity, Dillo, Hare 같은 프로젝트가 깃허브를 떠났거나 처음부터 피함
- 주요 불만은 잦은 장애, Copilot 중심의 AI 전략, 정치적 논란, 비자유 소프트웨어 의존성임
- 대안으로 Codeberg, GitLab, Bitbucket, Sourcehut, Gitea, Forgejo 같은 선택지가 부상 중

## 인사이트

깃허브 탈출이 당장 대세가 됐다고 보긴 어렵지만, 유명 프로젝트가 움직이기 시작했다는 게 포인트야. 오픈소스 인프라도 결국 신뢰, 거버넌스, 운영 안정성의 문제라는 걸 다시 보여주는 사례임.