# Guix가 Codeberg로 옮긴 뒤 1년

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30743](https://news.hada.io/topic?id=30743)
- GeekNews Markdown: [https://news.hada.io/topic/30743.md](https://news.hada.io/topic/30743.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-23T09:19:59+09:00
- Updated: 2026-06-23T09:19:59+09:00
- Original source: [guix.gnu.org](https://guix.gnu.org/en/blog/2026/one-year-with-codeberg/)
- Points: 1
- Comments: 1

## Topic Body

- Guix는 10년 넘게 Savannah와 이메일 기반 Debbugs로 운영하던 협업 방식을 2025년 Codeberg로 옮기며, 연간 400명 이상이 참여하는 프로젝트의 **기여 진입점**을 크게 바꿈
- 전환은 2024년 12월 도입한 **Guix Consensus Document** 절차의 첫 실전 사례였고, GCD 002는 두 달 논의 끝에 2025년 5월 초 발효됨
- 기존 이메일 워크플로는 Emacs, mumi, qa.guix.gnu.org 같은 도구 덕분에 숙련자에게 효율적이었지만, 900명이 응답한 설문에서는 기여자에게 **장애물**로 자주 지목됨
- Codeberg 이전 뒤 작성자 수와 신규 작성자 수는 늘었지만, 2025년 6월의 일시적 피크를 빼면 뚜렷한 **Codeberg 효과**는 확인하기 어려움
- 풀 리퀘스트가 매월 500개 이상 열리며 백로그가 커지고 있어, CI 공백·서명 요구·리뷰 부담을 줄이는 일이 Guix의 다음 실무 과제로 남음

---

### 이메일 기반 협업에서 Codeberg로 이동
- Guix는 2025년 Codeberg로 **소스 코드 호스팅, 이슈 추적, 풀 리퀘스트**를 이전함
  - 이전에는 10년 넘게 [Savannah](https://savannah.gnu.org/projects/guix)에 코드를 호스팅함
  - 버그 보고와 패치는 이메일로 처리하고 [Debbugs 인스턴스](https://issues.guix.gnu.org)로 추적함
  - 매년 400명 이상이 코드에 기여하는 프로젝트라 전환 자체가 큰 변화였음
- 기존 핵심 기여자들은 이메일 워크플로에 익숙했고, Emacs용 Debbugs 패키지나 고급 이메일 클라이언트로 효율적으로 일함
  - Debbugs는 수백 줄 Perl 코드와 이메일 표준·연합 구조에 기대는 반면, Forgejo 같은 웹 포지는 Go 의존성이 많은 더 큰 시스템임
- 이메일 흐름 주변에는 이미 **보조 도구**도 자리 잡고 있었음
  - [mumi](https://codeberg.org/guix/mumi)는 Debbugs용 웹 인터페이스를 제공함
  - [Quality Assurance service](https://qa.guix.gnu.org)는 이메일 패치 시리즈를 Git 브랜치에 자동 적용하고, 해당 브랜치에서 패키지를 빌드함
- 2025년 1월 공개된 첫 사용자·기여자 설문에는 900명 이상이 응답했고, 기여자들은 이메일 워크플로를 기여의 **장애물**로 자주 꼽음

### GCD 002로 진행한 합의 기반 결정
- Guix에는 결정을 내릴 “benevolent dictator”가 없었고, 2024년 12월 [Guix Consensus Document process](https://consensus.guix.gnu.org/gcd/001-gcd-process.html)를 도입함
- GCD 절차는 단순 투표보다 **합의 형성**을 목표로 함
  - 제안 작성자는 참여자들과 함께 제안을 조정해야 함
  - 참여자는 단순 반대 대신 자신의 필요와 이를 반영할 구체적 변경을 제안해야 함
  - 최종안에는 `support`, `accept`, `disapprove`로 입장을 표시함
- [GCD 002](https://consensus.guix.gnu.org/gcd/002-codeberg.html)는 2025년 2월 Codeberg 이전 제안으로 제출됨
  - [논의](https://issues.guix.gnu.org/76503)는 절차상 최대 기간인 두 달 동안 진행됨
  - Guix 팀 구성원 3분의 2가 숙의에 참여함
  - 참여자 중 72%는 `support`, 나머지 28%는 `accept`를 선택함
  - `disapprove`는 없었고, 제안은 2025년 5월 초 발효됨
- 오래 기여한 일부 구성원은 웹 우선으로 보이는 워크플로가 이메일보다 비효율적이라고 느꼈고, 이메일 기반 인프라 일부를 포기하는 점도 꺼림
- 더 넓은 커뮤니티와 접점이 생기고 **개발자 경험**이 개선될 가능성이 전환을 뒷받침함
- 자유 소프트웨어 기반 포지와 비영리 단체 [Codeberg e.V.](https://codeberg.org/about)가 호스팅하는 포지를 선호한 점은 큰 논쟁을 만들지 않았고, Guix의 지향과도 맞았음

### 단계적 전환과 예상보다 컸던 CI 공백
- Codeberg 전환은 GCD 합의대로 **점진적**으로 진행됨
  - 메인 저장소는 2025년 5월 25일 [이전](https://guix.gnu.org/blog/2025/migrating-to-codeberg/)됨
  - 이전 저장소는 현재도 미러로 남아 있음
  - 기존 이슈·패치 트래커는 2026년 1월 1일까지 유지됨
  - 이후 Codeberg 이슈와 풀 리퀘스트가 유일하게 지원되는 메커니즘이 됨
  - 과거 버그 보고와 패치는 [온라인에서 접근](https://issues.guix.gnu.org) 가능함
- 합의 논의 과정에서 만든 계획 덕분에 전환 시 큰 문제나 예상 밖 상황은 적었음
- Codeberg e.V. 직원과 자원봉사자의 서비스 품질은 좋았고, 간헐적 다운타임은 보통 짧고 명확히 공지됨
- 브라우저 밖 워크플로를 선호하는 기여자에게는 Emacs 인터페이스 개선이 도움이 됨
  - [`fj.el`](https://codeberg.org/martianh/fj.el/)과 [Emacs-Forgejo](https://codeberg.org/thanosapollo/emacs-forgejo)가 발전함
  - [AGit workflow](https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html)로 풀 리퀘스트를 만들 수 있는 점도 적응 부담을 줄임
- 충분히 예측하지 못한 문제는 **풀 리퀘스트용 지속적 통합**이었음
  - qa.guix.gnu.org에서 이메일 패치를 빌드하던 기능은 Codeberg로 포팅되지 않음
  - 몇 달 동안 리뷰어가 풀 리퀘스트가 문제를 만들지 않는지 직접 확인해야 했고, 지속 가능한 상태가 아니었음
- 2025년 9월 [Cuirass](https://guix.gnu.org/en/cuirass) 인스턴스가 [pulls.ci.guix.gnu.org](https://pulls.ci.guix.gnu.org/pull-requests)에 구축돼 풀 리퀘스트를 빌드하기 시작함
  - 처음에는 qa.guix.gnu.org보다 제약이 많아 [임시방편](https://codeberg.org/guix/maintenance/pulls/28)으로 여겨짐
  - 현재 패키지는 단일 아키텍처용으로 빌드됨
  - 신규 기여자는 `guix-cuirass-bot`이 풀 리퀘스트에 남기는 성공·실패 결과를 바로 볼 수 있음

### 기여 흐름은 늘었지만 백로그도 커짐
- 2024년 5월부터 2026년 5월까지 메인 브랜치 커밋 수를 기준으로 보면, Guix의 커밋 속도는 계속 “높음”과 “매우 높음” 사이에 머무름
- 커밋 속도만으로는 변화가 잘 드러나지 않아, 월별 커밋 작성자 수·커미터 수·신규 커밋 작성자 수가 더 유용한 지표가 됨
- 월별 작성자 수와 신규 작성자 수는 계속 증가함
  - Codeberg 이전 직후인 2025년 6월에는 작성자 수와 신규 작성자 수 모두 피크가 있었음
  - 그 외 기간의 성장은 2025–2026년 구간과 2024–2025년 구간이 비슷함
  - Guix는 계속 신규 기여자를 끌어들이지만, 뚜렷한 **Codeberg 효과**는 크지 않았음
- 월별 커미터 수 증가는 작성자 수 증가보다 완만했고, 이는 커미터가 더 많은 기여를 처리하고 있음을 시사할 수 있음
- 풀 리퀘스트 데이터는 Codeberg의 [Forgejo API](https://codeberg.org/api/swagger#/repository/repoListPullRequests)로 수집됨
- 매월 500개가 넘는 풀 리퀘스트가 열리고 병합 속도도 높지만, 유입보다 약간 낮아 **백로그**가 계속 증가함
  - 현재 열린 풀 리퀘스트는 전체 6,459개 중 약 639개로 약 10%임
  - 비교 대상으로 든 Nixpkgs는 전체 473k개 중 열린 풀 리퀘스트가 12k개로 약 2.5%임
  - Guix의 백로그는 과도한 마찰이나 불충분한 CI 피드백 때문일 수 있음
- Guix는 각 커밋이 [승인된 커미터의 서명](https://guix.gnu.org/manual/devel/en/html_node/Channel-Authentication.html)을 받아야 함
  - Nixpkgs를 포함한 많은 프로젝트처럼 `Merge` 버튼만 누르는 방식이 아님
  - 병합하는 사람이 변경을 적용하고 서명할 책임을 져야 함
  - Guix는 개발자 편의성과 [사용자 보안](https://guix.gnu.org/en/blog/2020/securing-updates/) 사이에서 소프트웨어 공급망 보안을 택함
  - 이 비용을 줄일 수 있을지는 아직 확인이 필요함

### Codeberg에서 더 잘 드러나는 협업
- Codeberg 이전 뒤 프로젝트 활동은 더 **가시적**이 됨
- CI 결과가 풀 리퀘스트 안에 직접 나타나 기여자가 즉시 확인할 수 있음
- Guix [팀](https://guix.gnu.org/manual/devel/en/html_node/Teams.html)은 Codeberg 팀으로 구현됨
  - 팀 범위는 [`CODEOWNERS` 파일](https://codeberg.org/guix/guix/src/branch/master/CODEOWNERS)에 명시됨
  - 해당 범위의 담당자가 자동으로 호출됨
  - 봇은 `team-python` 같은 라벨을 붙여 이슈와 풀 리퀘스트를 라벨로 필터링할 수 있게 함
- [해당 라벨이 붙은 이슈에서 팀이 알림을 받지 못하는 문제](https://codeberg.org/forgejo/forgejo/issues/11703)는 불편한 점으로 남아 있음
- 이슈와 풀 리퀘스트 사이의 상호 참조, [마일스톤](https://codeberg.org/guix/guix/milestones) 같은 기능도 협업에 도움이 되는 것으로 보임

### 남은 인프라 과제와 Codeberg와의 관계
- Guix 인프라는 더 많은 도움이 필요함
  - pulls.ci.guix.gnu.org의 빌드 성능을 높여야 함
  - x86이 아닌 아키텍처 빌드도 가능하면 좋음
  - Cuirass에는 여러 한계가 있고, 일부는 예정된 [1.4.x 시리즈](https://codeberg.org/guix/cuirass/milestone/27316)에서 해결 중임
  - pulls.ci.guix.gnu.org는 여전히 패키지 중심이며, 적절할 때 [시스템 테스트](https://guix.gnu.org/blog/2016/guixsd-system-tests/)도 실행할 수 있으면 좋음
- 패키저 워크플로도 개선 여지가 있음
  - [토픽 브랜치와 world rebuild scheduling](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html)은 은퇴한 버그 트래커에 상당 부분 묶여 있음
- Guix는 Codeberg 서버에 과도한 부하를 만들지 않고 저장소 사용량도 주시해야 함
  - Codeberg 서버에 [과도한 부하를 준 사례](https://codeberg.org/Codeberg-Infrastructure/scripted-configuration/issues/96)가 있었음
  - Guix의 단일 포크가 Codeberg의 새 사용자별 750MiB 할당량을 넘을 수 있음
- 해결책으로 신규 기여자가 [AGit workflow를 사용해 풀 리퀘스트를 만들도록 요구](https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00007.html)하는 방안이 있음
  - AGit은 Guix 기여자 사이에서 이미 인기가 있음
  - 다만 익숙한 일반 풀 리퀘스트 워크플로보다 덜 친숙해 “다운그레이드”로 보는 사람도 있음
  - Gentoo 사례처럼 “AGit fork” 아이콘을 추가하면 발견 가능성을 높일 수 있음
- Guix Foundation은 감사와 지원의 표시로 Codeberg e.V.의 지원 회원이 되기로 [투표](https://codeberg.org/guix-foundation/website/pulls/16)함
- [Forgejo와 이를 Guix에서 설정하는 서비스를 추가하는 풀 리퀘스트](https://codeberg.org/guix/guix/pulls/9006)가 제출됨
  - 선언적 구성과 재현 가능한 포지 배포가 Guix 안에서 가능해지는 방향임

## Comments



### Comment 60190

- Author: neo
- Created: 2026-06-23T09:20:01+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/pifl3k/one_year_with_codeberg) 
- **Codeberg 이전**과 관련된 실제 프로젝트 지표를 보니 아주 흥미로움. 개인적으로는 GitHub를 떠나야 할 이유가 너무 많아서 Codeberg가 새로운 GitHub가 되길 바라지만, 나는 자체 Forgejo 서버로 옮겼고 지금은 모든 저장소의 백업 대상으로 Codeberg를 쓰고 있음
  - 좋은 뜻으로 한 말인 건 알지만, 모든 것이 **Codeberg**로 몰리기보다는 여러 개의 독립 포지가 [ForgeFed](https://codeberg.org/ForgeFed)로 서로 통신하는 쪽이 더 낫다고 봄  
    새로운 오픈소스 중심 허브가 또 필요하진 않음
  - 현재 **Forgejo**가 이런 역할을 감당할 만큼 충분히 확장된다고 보진 않음. Codeberg 쪽이 할 수 있는 만큼 하고 있고 나아지길 바라지만, 시간이 걸릴 것 같음
  - 개인적으로 하는 작업은 결국 전부 **Fossil**로 옮겼고, 다른 사람에게 공개하고 싶은 것들은 자체 Fossil 서버를 세웠음  
    지금까지 아주 좋았고 `git`보다 확실히 선호함. 요즘 기준으로 그 허들이 아주 높은 건 아니지만

- Codeberg를 쓰기 시작하고 나서 정말 짜증났던 건, **git 연동**을 제대로 지원하는 도구가 거의 없고 사실상 GitHub / GitLab 전용인 경우가 대부분이라는 점임
  - `magit forge` 쓰는 입장에서는 눈물 남

- 예전 이슈·패치 추적기를 2026년 1월 1일까지 유지하다가 그 뒤에는 **Codeberg 이슈와 풀 리퀘스트**만 지원하게 했다는 부분이 이해되지 않음  
  기여자 상당수가 새 흐름을 싫어한다면 왜 강제로 바꾸는지 모르겠고, 여러 흐름을 허용하는 데 숨은 비용이 있는지도 궁금함. 왜 모두에게 같은 방식을 강제해야 하는지 의문임  
  사소한 트집이지만 Codeberg에 유급 직원이 여러 명 있는 것 같지는 않았고, 내가 알기로는 한 명뿐이었음. 수정: 작년 12월에 두 번째 직원을 추가했다고 함