2026년 6월 22일, Guix 프로젝트 메인테이너 Ludovic Courtès가 블로그 글 하나를 올렸다. 제목은 평범했다: “One year with Codeberg”. 하지만 내용의 무게는 절제된 제목을 훨씬 넘어섰다 — 이것은 현재 자유 소프트웨어 커뮤니티에서 가장 규모가 크고, 과정이 가장 투명한 ‘GitHub 탈출’ 실험의 완전한 복기다.
1년 전, Guix는 전체 코드 저장소, 이슈 추적, Pull Request 프로세스를 GNU Savannah와 메일 기반 Debbugs 시스템에서 Codeberg로 옮겼다 — Forgejo를 구동하는 독일의 비영리 호스팅 플랫폼. 매년 400명 이상이 코드를 제출하는 프로젝트가, 10년 이상 메일 패치 워크플로에 의존해온 끝에, 많은 사람들이 ‘과격하다’고 생각한 선택을 했다. 이제 데이터가 나왔다.
메일 vs 웹: 외부에 잘 알려지지 않은 분열
Guix의 옛 워크플로는 오늘날 기준으로 보면 거의 고고학 발굴 현장이다: 버그 보고와 패치를 메일로 보내고, Perl로 작성된 Debbugs 시스템이 추적한다. 핵심 기여자들은 Emacs와顶级 메일 클라이언트로 이 체계 안에서 물 만난 물고기처럼 일한다 — 그들에게 Debbugs는 메일이라는 오랜 시간 검증된 연합 표준 위에 세워진 몇백 줄의 Perl 코드인 반면, Forgejo 같은 웹 단조장은 수백 개의 Go 의존성을 달고 있고, 비대하기 짝이 없다.
커뮤니티는 메일 워크플로 주변에 정교한 보조 시설까지 구축해두었다: mumi는 Debbugs에 아름다운 웹 인터페이스를 씌웠고, QA 서비스는 패치 시리즈를 자동으로 Git 브랜치에 적용해 컴파일 테스트했다. 마이그레이션은 이 도구들이 전부 폐기됨을 의미한다.
하지만 반대쪽의 목소리도 똑같이 진실이다. 2025년 1월, Steve George(Futurile)는 Guix 최초 사용자 및 기여자 설문조사 결과를 발표했고, 900명이 참여했다. 결론은 단호했다: 상당수의 잠재적 기여자에게 메일 워크플로는 ‘하나의 장벽’이다. 솔직히 말해서, 젊은 세대 해커들은 아마 평생 메일로 패치를 제출해본 적이 없을 것이다 — 그들에게 익숙한 것은 GitHub식 PR 버튼이다.
이 분열은 자유 소프트웨어 운동의 고전적 딜레마다: 베테랑들이 소중히 여기는 ‘극소주의, 연합화, 표준 준수’가 신인들의 눈에는 ‘진입 장벽이 높고, 응답이 느리며, 내 패치를 누군가 보고는 있는지 알 수 없는’ 것으로 보인다.
GCD 합의: 독재자 없는 프로젝트의 의사 결정 방식
Guix는 두 가지 차원의 문제를 마주했다: 도구 선택, 그리고 의사 결정 메커니즘 — 이 프로젝트에는 ‘자비로운 독재자’(BDFL)가 없다. 2024년 12월, 커뮤니티는 Guix 합의 문서(GCD) 프로세스를 통과시켰다: 제안자는 반드시 모두와 협력하여 합의에 도달해야 하며, 참여자는 단순히 ‘반대’할 수 없고, 구체적인 요구사항과 수정 제안을 제시해야 한다. 최종적으로 ‘지지’, ‘수용’, ‘불찬’을 표현할 수 있다.
GCD 002호 제안이 바로 Codeberg로의 마이그레이션이었다. 2025년 2월 제출되어, 꼬박 두 달 동안 논의되었다 — 이는 프로세스가 허용하는 최장 기한이다. Guix 팀 구성원의 3분의 2가 심의에 참여했다: 72%가 ‘지지’, 28%가 ‘수용’, 0명이 ‘불찬’. 2025년 5월 초, 제안이 정식 발효되었다.
이 결과는 꽤 흥미롭다. 28%의 사람들이 ‘지지’가 아닌 ‘수용’에 머물렀다는 것은, 상당한 비율의 기존 기여자들이 이 방향을 좋아하지 않았지만, 거부권을 행사할 정도로 강하게 느끼지는 않았다는 뜻이다. Courtès의 블로그는 이렇게 전한다: “논의는 많은 장기 기여자들이 주로 ‘웹 우선’으로 인식되고 메일 워크플로 대비 효율성이 낮은 방향으로 전환하는 것에 불안을 느꼈음을 보여주었다. 수년간 메일 워크플로 주변에 정성껏 구축해온 인프라를 포기하는 것도 아쉬운 일이었다.”
하지만 저울이 결국 기운 이유도 명확히 쓰여 있다: “더 넓은 커뮤니티와의 접촉, 대다수의 개발 경험을 개선할 것이라는 기대가 이 긍정적인 결과를 이끈 핵심 동력이었을 것이다.”
거의 논란을 일으키지 않은 요소도 하나 있다: Codeberg를 선택한 이유는 단순히 자유 소프트웨어(Forgejo)이기 때문만이 아니라, 비영리 조직 Codeberg e.V.가 운영하기 때문이기도 하다. 이것은 Guix의 가치관과 자연스럽게 일치한다 — 상업 회사의 이해관계가 없고, 어느 날 아침 서비스 약관이 수정되는 일을 걱정할 필요도 없다.
전환 현장: CI 단절이 가장 큰 구덩이
합의 문서의 계획에 따르면, 마이그레이션은 점진적이었다. 메인 저장소가 2025년 5월 25일 마이그레이션을 완료했고, 원래의 Savannah 저장소는 미러로 유지되었다. 이전 이슈와 패치 트래커는 2026년 1월 1일까지 계속 운영된 후 공식 폐쇄되었다.
전환 과정 자체에 큰 혼란은 없었다. Courtès는 Codeberg e.V. 직원과 자원봉사자의 서비스 품질을 “매우 좋다”고 평가했으며, 가끔 다운타임이 있었지만 “보통 시간이 짧고 명확히 소통되었다”.
가장 큰 구덩이는 충분히 예측되지 못한 문제에서 왔다: 지속적 통합(CI).
원래 메일 시대의 QA 서비스(qa.guix.gnu.org)는 패치를 자동으로 임시 브랜치에 적용해 컴파일 테스트했다. Codeberg로 마이그레이션한 후, PR의 CI가 제때 따라붙지 못했다. 몇 달 동안, 리뷰어는 오로지 수동으로 PR이 무언가를 망가뜨릴지 판단해야 했다 — 연간 500+ PR의 프로젝트에서, 이것은 전혀 지속 불가능했다.
2025년 9월이 되어서야 프로젝트는 pulls.ci.guix.gnu.org에 Cuirass(Guix 자체 개발 CI 도구)를 배포하여 PR 빌드를 접수하기 시작했다. Courtès는 솔직히 인정했다: 이것이 “처음에는 임시방편으로 간주되었다”. 현재 단일 아키텍처(x86)만 빌드하고 있어, 원래 QA의 다중 아키텍처 커버리지에 미치지 못한다. 하지만 예상치 못한 호재는 피드백의 “즉시 가시성”이었다 — Cuirass가 guix-cuirass-bot 신분으로 PR 바로 아래에 빌드 성공/실패를 회신하며, 신입들이 더 이상 패치 테스트 결과를 찾느라 메일링 리스트를 뒤질 필요가 없어졌다.
Emacs를 떠날 수 없는 개발자들에게 좋은 소식은, fj.el과 Emacs-Forgejo 두 개의 Emacs 인터페이스가 이 1년간 빠르게 성숙했다는 점이다. AGit 워크플로(git push로 직접 PR 생성, 웹에서 먼저 저장소를 포크할 필요 없음)도 적지 않은 사용자를 얻었다.
데이터가 말한다: 기여자는 줄지 않았지만, 백로그는 늘고 있다
이것이 전체 블로그에서 가장 가치 있는 부분이다. Guix 팀은 탄탄한 데이터 통계를 했다.
먼저 결론: 마이그레이션은 일부가 기대했던 ‘Codeberg 효과’를 가져오지 않았다 — 기여자 수의 폭발적 증가는 일어나지 않았다. 2025년 6월(마이그레이션 직후)에 신규 기여자 수와 총 기여자 수의 작은 피크가 있었지만, 이후 1년간의 성장 추세는 마이그레이션 전 1년과 대체로 비슷했다. Guix는 꾸준히 신규 기여자를 끌어들이고 있으며, Codeberg는 이 과정을 가속하지도, 둔화시키지도 않았다.
하지만 절대 숫자는 여전히 볼 만하다: 매월 500개 이상의 PR이 제출된다. 병합 속도는 제출 속도보다 약간 낮아, 백로그가 지속적으로 증가 중이다. 현재 639개의 열린 PR이 있으며, 이는 누적 총 PR 수(6,459건)의 10%에 해당한다. 비교하자면, Nixpkgs의 열린 PR 비율은 2.5%(1.2만 열림 / 47.3만 누적)에 불과하다.
Courtès는 백로그를 두 가지 가능한 요인으로 돌린다: 과도한 제출 마찰, 혹은 CI 피드백 부족.
가장 큰 마찰 지점은 서명된 커밋 요구사항이다. Guix는 모든 커밋에 권한 있는 커미터의 서명을 요구한다 — Nixpkgs 등 많은 프로젝트처럼 ‘Merge’ 버튼만 누르면 되는 게 아니다. 이는 코드를 병합하는 사람이 반드시 변경에 대해 진짜로 책임을 지도록 하며, 숨을 수 없다는 뜻이다. ‘소프트웨어 공급망 보안’과 ‘개발자 편의성’ 사이의 트레이드오프며, Guix는 전자를 선택했다: “이것은 우리가 기꺼이 하는 트레이드오프다. 소프트웨어 공급망 보안을 보호하는 데 관심이 있기 때문이다. 하지만 이 비용이 어떤 방식으로든 완화될 수 있는지도 계속 살펴볼 필요가 있다.”
Lobsters에서 터진 진짜 문제들
Lobsters에서 이 블로그는 90점, 38개 댓글을 받았다. 기술적 디테일을 제쳐두면, 커뮤니티 토론은 몇 가지 더 깊은 문제들을 터뜨렸다.
“GitHub를 Codeberg 독점으로 바꾸지 마라”. 사용자 FedericoSchonborn은 “Codeberg가 새 GitHub가 되길 바란다”는 댓글에 이렇게 답했다: “나는 모든 것을 Codeberg로 옮기는 것보다, ForgeFed를 통해 서로 통신하는 수많은 독립된 코드 단조장을 보는 쪽을 훨씬 선호한다. 우리에게 필요한 것은 새 오픈소스 중심 노드가 아니다.” 이것은 하나의 역설을 가리킨다: 집중형 플랫폼에서 탈출하는 것이 단지 다른 중심 노드로 점프하는 것에 불과하다면, 아무것도 변하지 않았다는 뜻이다. 단조장 간의 연합 상호운용성을 추진하는 쪽이 더 근본적인 출구다.
도구 체인 통합은 여전히 약점. 사용자 colonelpanic은 지적한다: “Codeberg를 쓰기 시작한 이후로, 사실상 어떤 것도 진정한 범용 Git 통합을 지원하지 않는다는 것을 발견했다 — 거의 전부 GitHub / GitLab 전용이다.” 이 문제는 서드파티 CI, 정적 호스팅, 프로젝트 관리 시스템 등 시나리오에서 반복적으로 나타난다. 뿌리는 생태계 관성 — 모든 SaaS의 ‘Connect your repo’ 버튼 뒤에 GitHub와 GitLab의 OAuth 플로우만 작성되어 있을 때, 다른 플랫폼을 선택한다는 것은 전체 도구 체인으로부터 버려진다는 의미다.
안정성은 여전히 격차. 사용자 ysun은 썼다: “내 경험으로 보면, Codeberg는 GitHub보다 더 많은 기이한 장애를 가진다. 예를 들어 push가 랜덤하게 실패하는 경우.” 또 다른 사용자 srtcd424는 덧붙였다: “Forgejo가 GitHub의 확장 능력에 근접할 수 있다고 생각하지 않는다. Codeberg 사람들이 최선을 다하고 있지만, 시간이 필요하다.”
이것들은 치명적이지 않다. ‘대안’의 진짜 비용은, 이후 매일매일 생태계 지원이 한 단계 약하고, 안정성이 한 단계 낮고, 통합이 한 단계 적은 세계에서 살아야 한다는 점이다 — 마이그레이션 당일의 공수는 오히려 무시할 수 있다. Guix는 충분한 기술 역량과 자체 인프라를 구축할 의지가 있기에 이 비용을 감당할 수 있다 — 하지만 대부분의 프로젝트는 감당할 수 없다.
자유 소프트웨어의 대가, 그리고 그 대가로 산 것
Guix의 이 글이 가장 오래 기억되어야 할 것은 결론이 아니다 — 단순한 ‘성공’ 또는 ‘실패’ 판단을 내리지 않았다. 그 과정의 투명성이다. BDFL 없는 자유 소프트웨어 프로젝트가, 스스로 설계한 합의 의사 결정 메커니즘으로, 400명 이상이 관련된 인프라 마이그레이션을 완수한 후, 데이터, 결함, 논쟁을 전부 공개했다.
Courtès는 말미에 ‘속보’ 하나를 언급한다: Guix 위에 Forgejo를 배포하는 PR이 방금 제출되었다 — “순수 선언형 설정, 완전히 재현 가능한 단조장 배포, 상상할 수 있겠는가?” 이것이 Guix식 자유의 최종 형태를 가리킨다: 자유 소프트웨어의 단조장 위에서 실행될 뿐 아니라, 누구든 Guix로 자신의 단조장을 선언적으로 배포할 수 있게 하는 것. GitHub 탈출에서, 자신이 대안의 인프라가 되기까지 — Guix는 ‘이사’보다 더 먼 길을 걷고 있다.
Guix 재단은 최근 투표를 통해 Codeberg e.V.의 지원(비투표) 멤버가 되었다. 감사와 지지를 표현하는 방식이다. 이것은 아마도 또 다른 신호일 것이다: GitHub 탈출은 대안 플랫폼과 지속적으로 자원을 투입하는 장기적 관계를 맺어야 하는 일이며, 한 번 이사하는 것으로는 턱없이 부족하다.
이 글의 소재는 공개 정보와 커뮤니티 논의에서 가져왔습니다. 이 주제에 대해 더 깊이 있는 일차 경험이 있다면 글의 부족한 점을 지적해 주시기 바랍니다.