# GitHub에서 Codeberg로 이전하기, 게으른 사람들을 위한 방법

> Clean Markdown view of GeekNews topic #27904. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27904](https://news.hada.io/topic?id=27904)
- GeekNews Markdown: [https://news.hada.io/topic/27904.md](https://news.hada.io/topic/27904.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-27T09:49:33+09:00
- Updated: 2026-03-27T09:49:33+09:00
- Original source: [unterwaditzer.net](https://unterwaditzer.net/2025/codeberg.html)
- Points: 1
- Comments: 1

## Topic Body

- 일부 프로젝트를 **GitHub에서 Codeberg로 옮기며**, 최소한의 노력으로 이전을 시작하는 방법을 정리
- Codeberg의 **저장소 가져오기 기능**을 통해 이슈·PR·릴리스까지 포함한 완전한 이전이 가능하며, **UI와 워크플로가 GitHub과 유사**
- **정적 페이지 호스팅**은 codeberg.page로 대체할 수 있고, **grebedoc.dev**나 **statichost.eu** 같은 대안도 존재
- 가장 큰 어려움은 **CI 환경 구축**으로, GitHub의 macOS 러너와 무료 실행 용량을 포기해야 하며 **Forgejo Actions**나 **Woodpecker CI**로 대체 가능
- 이전 후에는 GitHub 저장소를 **읽기 전용 아카이브로 유지하거나 미러링**해, 오픈소스 생태계와의 연결을 완전히 끊지 않는 방식이 제시됨

---

### GitHub에서 Codeberg로의 이전 과정
- 일부 저장소를 **GitHub에서 Codeberg로 이전**하기 시작한 경험을 기반으로, 실제 마이그레이션 과정의 난이도와 편의성을 설명
  - Codeberg가 충분히 준비되지 않았다고 생각해 미뤄왔지만, 프로젝트에 따라 이전이 의외로 간단할 수 있음
  - 목표는 완벽한 설정이 아니라 **가장 쉽게 이전을 시작할 수 있는 방법**을 찾는 것에 있음
- ## 저장소 및 이슈 이전
  - Codeberg는 **GitHub 저장소 가져오기(import)** 기능을 제공하며, 이슈·PR·릴리스와 그 아티팩트를 함께 이전 가능
    - 이 과정에서 **이슈 번호, 라벨, 작성자 정보**가 그대로 유지됨
    - Codeberg의 UI는 GitHub과 거의 동일하며, 다른 이슈 트래커에서 GitHub로 옮길 때 필요한 복잡한 절차보다 훨씬 간단한 경험 제공
- ## 정적 페이지 호스팅
  - GitHub Pages를 사용하던 경우 **codeberg.page**를 대체로 사용할 수 있음
    - 공식적인 **가용성 보장(SLO)** 은 없지만, 실제로는 다운타임을 경험하지 않았다고 언급
    - HTML을 브랜치에 푸시하는 방식으로, **GitHub Pages와 유사한 구조**
    - 대안으로 **grebedoc.dev** 또는 **statichost.eu**도 사용 가능
- ## CI(지속적 통합) 환경의 어려움
  - 마이그레이션 중 가장 까다로운 부분은 **CI 환경 구축**
    - GitHub는 **무료 macOS 러너**와 **공개 저장소 무제한 실행 용량**을 제공하지만, Codeberg에서는 이를 포기해야 함
    - 해결책으로 **언어별 크로스 컴파일**과 **Forgejo Actions 러너의 셀프 호스팅**을 활용 가능
  - ### Forgejo Actions vs Woodpecker CI
    - Codeberg에서는 **Woodpecker CI가 더 안정적**이지만, **Forgejo Actions**가 GitHub Actions 사용자에게 더 익숙한 환경 제공
    - UI와 **YAML 문법이 거의 동일**하며, 기존 GitHub Actions 워크플로 대부분이 그대로 작동
    - 예시로 GitHub Actions에서 `uses: dtolnay/rust-toolchain`을 사용하던 부분을
      Forgejo Actions에서는 `uses: https://github.com/dtolnay/rust-toolchain`으로 변경하면 됨
    - 현재 Codeberg의 Forgejo Actions 문서는 **최신 상태가 아니며**, 관련 PR이 존재함
  - ### macOS 러너가 필요한 경우
    - macOS 빌드가 꼭 필요하다면 **GitHub Actions을 계속 사용**하고, Codeberg 저장소에서 GitHub로 커밋을 미러링하는 방법 가능
    - Forgejo Actions가 GitHub API를 폴링하여 **CI 상태를 Codeberg로 동기화**하도록 설정 가능
    - 다른 macOS 빌드 제공 CI 서비스도 시도했으나, Codeberg와의 통합이 GitHub Actions보다 단순하지 않음
- ## GitHub 저장소의 처리 방식
  - 이전 후 **GitHub 저장소는 README를 수정하고 아카이브 처리**
    - Codeberg에서 GitHub로 커밋을 푸시하도록 설정할 수도 있지만, 이 경우 사용자가 여전히 **PR 작성 및 이슈 코멘트** 가능
    - 일부는 GitHub 저장소의 **이슈 기능을 비활성화**하지만, 이 경우 모든 이슈가 404로 사라지고 **PR은 비활성화 불가**
    - 예시로 `libvirt/libvirt` 저장소는 **모든 PR을 자동으로 닫는 GitHub Action**을 사용
  - 이러한 접근은 **자체 호스팅 및 오픈소스 생태계 전반에 부정적 영향**을 줄 수 있음
    - 사용자가 빌드 최적화나 릴리스 파일 다운로드 빈도를 개선할 동기를 잃게 됨
    - 전환기 동안에는 **읽기 전용 미러 유지**나 **GitHub Pages·Actions 병행 사용**도 고려 가능

## Comments



### Comment 53933

- Author: neo
- Created: 2026-03-27T09:49:33+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47530330) 
- Codeberg 자체는 싫지 않지만, **GitHub의 완전한 대체재**는 아님  
  개인용 코드 저장소나 실험용 스크립트를 올리기엔 제약이 많고, **비공개 저장소**는 100MB로 제한되어 있음  
  GitHub Pages처럼 홈페이지를 호스팅할 수도 없음. 이런 용도라면 직접 **Forgejo**를 셀프호스팅하는 게 현실적인 대안임  
  관련 내용은 [Codeberg FAQ](https://docs.codeberg.org/getting-started/faq/)에 잘 정리되어 있음
  - Codeberg에서도 [Codeberg Pages](https://docs.codeberg.org/codeberg-pages/) 기능을 통해 홈페이지를 호스팅할 수 있음
  - 나도 내 웹사이트를 Codeberg Pages에 올려서 운영 중임. 위 정보는 잘못된 내용임 → [Codeberg Pages 문서](https://docs.codeberg.org/codeberg-pages/)
  - “직접 git 서버를 돌리는 건 부담스럽다”는 말에 동의하기 어려움. 단순히 **코드를 푸시할 공간**만 원한다면 SSH 서버 하나면 충분함
  - Pierre가 만든 [Code Storage](https://code.storage/) 프로젝트가 이런 **운영 부담을 줄이는 API형 git 서버**로 흥미로움
  - (홍보 겸) 나는 **Monohub**라는 GitHub 대안을 개발 중임. 비공개 저장소를 기본 제공하고, PR도 지원함. [공개 저장소 예시](https://monohub.dev/@tbayramov/efcore-audit-timestamps)

- 나는 OSS 프로젝트를 GitHub에 올리는 이유가 단순함 — **커뮤니티가 거기 있기 때문**임  
  코드만 올릴 거면 SSH나 SFTP로 직접 호스팅함
  - 커뮤니티가 GitHub에만 머무는 건 **닭이 먼저냐 달걀이 먼저냐** 문제임. 결국 누군가 먼저 다른 플랫폼으로 옮겨야 생태계가 이동함  
    나는 내 **개인 Gitea 인스턴스**에만 올리고, 별이나 홍보엔 신경 쓰지 않음
  - GitHub에 남아 있는 건 **폐쇄적 의존성을 받아들이는 FOSS 커뮤니티**일 뿐임. 오히려 GitHub의 정책이 사람들을 떠나게 만들고 있음
  - 일부 프로젝트는 GitHub 계정이 없으면 참여조차 불가능함. 예를 들어 [crates.io 이슈](https://github.com/rust-lang/crates.io/issues/326)는 10년째 해결되지 않았고, [Lean의 Reservoir](https://reservoir.lean-lang.org/inclusion-criteria)는 GitHub 별 2개 이상을 요구함. **Microsoft 종속성 강화**로 보임
  - GitHub는 무료로 **CI 리소스**를 많이 제공함. 특히 macOS 러너는 대체제가 거의 없음. 덕분에 다양한 환경에서 테스트 가능함
  - 나도 GitHub에서 벗어나려고 **홈서버에 Git 호스팅**을 시작했지만, 예전처럼 커밋 푸시할 때의 **도파민**은 사라졌음. 오픈소스가 상업화되며 매력이 줄어든 느낌임

- 나는 **Forgejo 셀프호스팅**으로 모든 개인 프로젝트를 관리 중임. GitHub가 전혀 그립지 않음  
  Tailscale로 접근을 제한해 **AI 크롤러 차단**도 가능함
  - 나도 몇 년째 Forgejo를 직접 운영 중임. [설치 튜토리얼](https://huijzer.xyz/posts/55/installing-forgejo-with-a-separ...)도 작성했고, 최근엔 Hetzner에서 **Raspberry Pi 2대**로 이전했음. GitHub보다 빠르고 안정적임
  - 예전엔 GitLab을 썼지만, Forgejo는 훨씬 **가벼운 Go 단일 바이너리**라 리소스 소모가 적음. Docker로 쉽게 돌릴 수 있고, 직접 기능을 해킹하는 재미도 큼
  - GitHub에서 **에이전트 계정 생성이 막혔을 때** Forgejo를 설치했는데, 15분 만에 PR 리뷰에서 “Viewed 파일 숨기기” 기능을 직접 추가했음
  - 최근 대형 OSS 프로젝트들이 Forgejo로 이동하면서 나도 따라갔는데, 지금까지 **아주 만족스러움**
  - 나도 Docker로 Forgejo 러너를 설치해 CI를 돌림. 자체 **레지스트리**가 있어서 앱을 Docker 이미지로 배포함

- 앞으로 GitHub 대안을 평가하는 게 점점 중요해질 것 같음  
  하지만 GitHub가 **CI와 멀티 아키텍처 빌드 표준**을 만들어버려서, 커뮤니티 주도의 대체재가 경쟁하기 어려움
  - CI가 꼭 GitHub에 종속될 필요는 없음. 사실 대부분의 CI는 **단순한 명령 실행기**일 뿐임. 작은 팀이라면 CI 없이도 충분히 운영 가능함
  - CI를 직접 운영하는 게 왜 비합리적인지 모르겠음. **레포와 CI를 분리**해도 문제없음
  - 나에게 중요한 건 CI보다 **PR과 코드리뷰 경험**임. GitHub는 여전히 불편한 부분이 많고, 이슈 시스템도 20년 전 수준임
  - 이런 중앙화된 레이어는 결국 **통제 욕구** 때문임. 로컬 중심의 분산형 워크플로우로도 충분히 즐겁게 개발할 수 있음

- GitHub는 많은 걸 “무료”로 제공하지만, 그 대가로 **데이터 수집과 학습**에 활용될 가능성이 큼  
  Codeberg는 비공개 저장소를 지원하지 않아, Copilot이 공개 저장소를 긁어가는 걸 막을 수도 없음  
  [Codeberg FAQ](https://docs.codeberg.org/getting-started/faq/)에 따르면, 비공개 프로젝트가 필요하면 **Forgejo 셀프호스팅**을 권장함
  - 하지만 내 Codeberg 저장소는 비공개로 설정되어 있음. 완전히 불가능한 건 아닌 듯함

- 우리 회사는 GitHub에서 **GitLab 셀프호스팅**으로 완전히 이전했음  
  Tailscale 뒤에 두어 SSO 부담이 없고, CI 러너는 EKS와 GPU 클러스터에서 돌림. 비슷한 이전을 고민하는 사람에게 도움 줄 수 있음
  - Forgejo도 고려했는지 궁금함. GitLab은 **엔터프라이즈급 CI/CD**에 강하지만, 작은 프로젝트엔 Forgejo가 더 가벼운 선택일 듯함
  - 셀프호스팅 GitLab에서 **자동 사용자 프로비저닝(SCIM)** 같은 기능을 지원하는지도 궁금함

- 단순히 “GitHub를 대체하자”는 건 의미 없음. **새로운 습관과 가치 제안**이 필요함  
  GitHub가 SourceForge를 대체했듯, 다음 세대 플랫폼은 **코드 작성과 협업을 실시간으로 연결**해야 함  
  예를 들어 Google Docs처럼 **프롬프트마다 커밋이 생성되는 구조**가 될 수도 있음
  - 하지만 **지정학적 이유**도 큼. 미국 기술 의존을 피하려는 움직임이 유럽 등에서 활발함
  - 최근 **Copilot 논란**으로 신뢰가 흔들리며, GitHub를 떠나려는 흐름이 생김
  - 나에게 중요한 건 단순히 기능이 아니라 **가용성(uptime)** 임. 요즘 GitHub는 99%도 못 미치는 수준임

- Codeberg는 이상적이지만, 현실적으로 **안정성 문제**가 큼  
  Cloudflare 없이 운영하다 보니 **DDoS 공격**에 취약하고, 다운타임이 잦음. 개발 중에 원격 저장소에 접근 못 하면 정말 답답함
  - 나는 GitHub나 Codeberg를 단순히 **비동기 코드 공유용**으로만 씀. 원격이 죽어도 로컬에서 작업 가능해야 함
  - Cloudflare가 싫지만, 현실적으로는 **봇 트래픽과 공격 방어**를 위해 필수적임. 대안 서비스들은 오히려 더 자주 막히거나 불안정했음. 원칙과 현실의 괴리를 절실히 느낌
  - GitHub의 [가동률 모니터링](https://mrshu.github.io/github-statuses/)을 보면 최근 90일간 90% 수준임. 오히려 Codeberg가 더 안정적임
  - 내 개인 git 서버도 **AI 크롤러들의 무차별 스크래핑**으로 성능이 떨어졌음. 결국 주요 기업 IP를 다 차단함
  - git의 핵심은 **분산성**임. 원격이 죽어도 로컬에 최신 버전이 있어야 함

- Microsoft 인수 이후 GitHub를 거의 쓰지 않음. **Sourcehut**의 단순한 이메일 기반 워크플로우가 오히려 마음에 듦  
  CI도 단순히 **로컬에서 실행 가능한 명령 기반**이면 충분하다고 생각함

- 코드 저장소는 본질적으로 **분산·연합형 구조**여야 함  
  git의 **암호학적 서명 체계(GPG/SSH)** 덕분에 저장소 신뢰와 커밋 신뢰를 분리할 수 있음  
  중앙에는 키 서버와 네임스페이스 관리만 두고, 나머지는 분산시키면 됨
  - [Radicle](https://radicle.xyz/)이 바로 이런 **분산형 git 호스팅**을 목표로 하는 프로젝트임
  - 하지만 대부분의 개발자는 **서명 키 관리**를 제대로 하지 못함
  - 이런 이유로 **Tangled**나 **ForgeFed** 같은 연합 프로토콜이 Forgejo에 통합되고 있음
  - [git-bug](https://github.com/git-bug/git-bug)도 흥미로운 접근임. 아직 써보진 않았지만 가능성이 있어 보임