게으른 사람들을 위한 GitHub에서 Codeberg로 이동
Source: Hacker News
2025‑09‑06
저는 이제 막 GitHub에서 Codeberg로 몇몇 저장소를 옮기기 시작했습니다. 오래전부터 하고 싶었지만 Codeberg가 아직 준비가 안 된 것 같고 마이그레이션 과정이 (지루한) 작업이 많이 필요하다고 생각해서 미뤄왔습니다. 실제로는 부분적으로만 맞는 말이며 프로젝트에 따라 크게 달라집니다. 저와 비슷한 상황이라면 이 글이 동기 부여와 출발점이 되길 바랍니다. 아래 솔루션들은 장기적으로 유지할 계획은 아니지만, GitHub에서 마이그레이션할 때 시작하기 가장 쉬운 방법을 목표로 합니다.
이슈, 풀 리퀘스트, 릴리즈 가져오기
가장 쉬운 부분은 이슈, 풀 리퀘스트, 릴리즈와 그 아티팩트를 함께 옮기는 일입니다. Codeberg는 GitHub에서 바로 가져올 수 있는 저장소 임포트 기능을 제공하며, 모든 기능의 UI가 GitHub과 거의 동일합니다. 임포트 과정에서 이슈 번호, 라벨, 작성자 정보가 그대로 유지됩니다. 이는 다른 이슈 트래커에서 GitHub으로 가져올 때 사람들이 쓰는 매우 어색한 해킹 방법보다 한 단계 앞선 사용자 경험을 제공합니다.
GitHub Pages 대안
GitHub Pages를 사용하고 있다면 codeberg.page를 사용할 수 있습니다. 가동 시간에 대한 SLO를 제공하지 않는다는 경고가 있지만, 저는 아직 다운타임을 경험하지 않았고 현재로서는 충분히 괜찮습니다. HTML을 브랜치에 푸시하는 방식은 기존 GitHub Pages와 매우 유사합니다.
업데이트 2025‑09‑22: 대신에 grebedoc.dev 혹은 statichost.eu를 시도해 볼 수도 있습니다.
CI 고려 사항
가장 까다로운 부분은 CI입니다. GitHub은 무료 macOS 러너와 퍼블릭 레포에 대한 무제한 용량을 제공하며 사람들을 끌어들이는 데 뛰어난 성과를 보였습니다1. 이 두 가지를 포기해야 합니다. 저는 사용 중인 프로그래밍 언어에 대한 교차 컴파일을 검토하고, Forgejo Actions용 자체 호스팅 러너를 운영해 이 문제들을 각각 해결할 것을 권장합니다.
왜 Forgejo Actions (그리고 Woodpecker CI가 아니라?)
Codeberg의 Woodpecker는 안정적이지만, Forgejo Actions은 GitHub Actions에 익숙한 사용자에게 훨씬 친숙합니다. UI와 YAML 문법이 거의 동일하고, 기존 액션 생태계도 대부분 Codeberg에서 그대로 동작합니다. 예를 들어, GitHub Actions 워크플로우에서
uses: dtolnay/rust-toolchain라고 적었다면, Forgejo Actions 워크플로우에서는
uses: https://github.com/dtolnay/rust-toolchain와 같이 바꾸면 됩니다.
macOS 러너가 절대적으로 필요하다면, GitHub 저장소에서 GitHub Actions을 계속 사용하고, Codeberg에서 GitHub으로 모든 커밋을 미러링한 뒤 Forgejo Actions이 GitHub API를 폴링해 CI 상태를 Codeberg에 동기화하도록 할 수 있습니다. 아직 직접 해보지는 않았지만, macOS 빌드를 제공하는 다른 CI 제공업체들도 GitHub Actions만큼 쉽거나 깔끔하게 Codeberg와 통합되지는 않았습니다.
GitHub에 남아 있는 기존 저장소 처리
마지막으로, GitHub에 남아 있는 기존 저장소는 어떻게 할까요? 저는 README를 업데이트하고 저장소를 아카이브했습니다.
Codeberg가 새로운 커밋을 GitHub에 푸시하도록 설정하면, 사용자는 여전히 PR을 만들고 이슈와 커밋에 댓글을 달 수 있습니다2. 일부 사람들은 GitHub 저장소에서 이슈를 비활성화하는 방법을 사용했지만, 이는 모든 이슈가 404 오류를 반환하게 만들고 풀 리퀘스트는 비활성화할 수 없기 때문에 파괴적인 행동입니다. libvirt/libvirt와 같은 저장소는 모든 풀 리퀘스트를 자동으로 닫는 GitHub Action을 작성하기도 했습니다.
이 접근 방식은 자체 호스팅과 더 넓은 소프트웨어 생태계에 심각한 부작용을 초래합니다. 왜냐하면 사람들은 빌드를 최적화하거나 웹사이트에서 릴리즈 tarball을 다운로드하는 빈도에 대한 동기가 사라지기 때문입니다1.
전환 기간 동안 읽기 전용 미러를 유지하거나, GitHub Pages와 GitHub Actions를 계속 사용할 수도 있습니다2.