Zig, 메인 저장소를 GitHub에서 Codeberg로 이전
(ziglang.org)- Zig 프로그래밍 언어 저장소가 10년간 사용하던 GitHub를 떠나 Codeberg로 이전
- GitHub의 성능 저하와 버그, 특히 Actions의 불안정성과 방치가 주요 원인
- GitHub의 AI 중심 정책과 Copilot 기능 강제 노출이 Zig의 ‘no LLM / no AI’ 정책과 충돌
- GitHub Sponsors는 여전히 큰 수입원이지만, 의존 위험으로 판단되어 Every.org로 후원 이전 권장
- Codeberg로의 전환은 비영리·공공성 중심 생태계 강화라는 의미
GitHub에서 Codeberg로의 이전 배경
- Zig 프로젝트는 10년 전
git init이후 GitHub에서 호스팅되어 왔음- GitHub가 Microsoft에 인수된 후, 플랫폼 품질이 악화되었다고 평가
- GitHub의 엔지니어링 문화와 우선순위 붕괴로 인해 느리고 버그가 많은 JavaScript 프레임워크로 변질되었다고 서술
-
GitHub Actions는 “용납할 수 없는 버그”가 있으며, 유지보수가 거의 이루어지지 않는다고 명시
- CEO의 “AI를 수용하거나 떠나라” 발언 이후, Actions가 무작위로 작업을 실행하는 ‘vibe-scheduling’ 현상을 보였다고 설명
- 수동 개입이 불가능해 CI 시스템이 마비되는 문제 발생
- Zig는 이러한 문제를 해결하기 위해 새로운 Git 호스팅 제공자로 전환 결정
GitHub와 AI 관련 문제
- GitHub의 Copilot 기능 강제 노출이 Zig의 ‘no LLM / no AI 정책’ 위반 사례를 유발했다고 언급
- 관련 위반 사례로 GitHub의 세 개 PR 링크(A, B, C) 제시
- Codeberg로 이전함으로써 AI 관련 정책 위반 감소를 기대
GitHub Sponsors와 후원 구조
- GitHub Sponsors는 Zig의 초기 자금 조달에 핵심적 역할을 했으며, 현재도 수익의 큰 비중을 차지
- Devon Zuegel의 기여로 많은 개발자들이 GitHub를 통해 수익을 얻을 수 있었으나, 그녀의 퇴사 이후 제품이 방치되고 쇠퇴 중
- Zig Software Foundation은 GitHub Sponsors를 ‘부채(liability)’로 간주
- 후원자들에게 Every.org로 정기 후원 이전을 요청
- GitHub Sponsors의 후원자 혜택(홈페이지 이름 표기, 릴리스 노트 언급 등) 은 종료 예정
- Every.org를 통해 동등한 혜택 제공 방안을 준비 중
이전 계획 및 기술적 세부 사항
- GitHub의
ziglang/zig저장소는 즉시 읽기 전용(read-only) 으로 전환 - 공식 저장소는
https://codeberg.org/ziglang/zig.git으로 변경 -
Forgejo 및 Codeberg 커뮤니티의 지원에 감사 표시
- 특히 Earl Warren, Otto, Gusted, Mathieu Fenniak의 협력 언급
- GitHub의 벤더 종속(vendor lock-in) 을 피하기 위해 단순한 전략 채택
- 기존 GitHub 이슈는 그대로 유지하고, Codeberg에서는 이슈 번호를 30000부터 시작
- 기존 GitHub 이슈와 PR은 그대로 두며, 수정이나 코멘트가 필요한 경우에만 Codeberg로 이동
- 기존 PR과 이슈는 계속 검토 예정
비영리 생태계의 의미
- 현대의 인수합병, 약한 반독점 규제, 플랫폼 자본주의 속에서
비영리 조직이 공공 영역을 지키는 최후의 보루로 언급 - 글의 마지막은 “Happy hacking”으로 마무리됨
Hacker News 의견
-
Zig 프로젝트가 GitHub의 LLM/AI 금지 정책 위반 사례(exhibit A, B, C)를 언급하며 Codeberg로 이전한 것을 보고 웃음이 나왔음
특히 exhibit A의 문제 제기 인물이 며칠 전 HN 프론트페이지에 올랐던 같은 사람이라는 점이 흥미로움- 예전에 내가 세운 규칙은 “코딩은 ‘내 컴퓨터에서 잘 되면 됨’, 하지만 소프트웨어 엔지니어링은 그렇지 않음”이었음
이제는 “코딩은 AI로 작성해도 되지만, 엔지니어링은 안 됨”으로 바뀌었음 -
GhostKellz의 GitHub를 보면 Zig와 Rust로 만든 비작동 프로젝트가 수십 개 있음
심지어 zquic 이슈에서 다른 사람들을 혼란스럽게 만들고 있음 - 그는 Julia용 StaticCompiler PR에서도 AI 생성 코드를 대량으로 올렸음
- 가장 웃겼던 건 이 트윗에서 “Claude가 Zig 컴파일러 버그를 고쳤다”고 자랑한 뒤,
몇 분 후 PR 링크가 올라온 장면이었음
나중에 면접에서 “가장 큰 업적이 뭐냐” 묻는다면 “Zig를 GitHub에서 몰아낸 장본인”이라 답할 듯함 - 이쯤 되면 단순한 트롤링인지 진심인지 모르겠음
- 예전에 내가 세운 규칙은 “코딩은 ‘내 컴퓨터에서 잘 되면 됨’, 하지만 소프트웨어 엔지니어링은 그렇지 않음”이었음
-
GitHub의 “Copilot으로 이슈 제기” 기능이 AI 정책 위반을 부추긴다는 지적에 공감함
또 많은 개발자가 프로필을 멋지게 보여 취업 확률을 높이려는 동기로 GitHub를 사용한다고 봄- 하지만 정말로 무작위 PR을 많이 올리면 채용에 도움이 될까 의문임
내 경험상 리크루터나 면접관은 GitHub 프로필을 거의 보지 않음 - 사실 GitHub는 단순히 git 호스팅만으로도 충분히 쓸 수 있음
예를 들어 torvalds/linux처럼 이슈나 PR 기능 없이 미러로만 활용 가능함 - 예전엔 CODE_OF_CONDUCT.md를 강조했지만, 이제는 “레포에 쓰레기 코드를 보내지 말라”는 조항을 넣고 싶어짐
- 하지만 정말로 무작위 PR을 많이 올리면 채용에 도움이 될까 의문임
-
Zig가 GitHub 대신 Codeberg로 이전한 이유가 ICE(미 이민세관단속국) 고객 문제 때문이라는데,
Codeberg도 PayPal을 사용하고 PayPal은 ICE 관련 조직의 일원임
이런 식의 ‘순수성 나선(purity spiral)’ 은 결국 스스로를 고립시키는 결과를 낳음- 하지만 나는 그걸 ‘순수성 나선’이라 부르지 않음
단지 윤리적 고려를 포함한 실용적 선택일 뿐임. GitHub에서 Codeberg로 옮기는 건 큰 부담이 아니었음 - 세상은 흑백논리가 아님. 완벽히 일관된 선택만을 강요하는 건 냉소주의자들의 함정임
가능한 범위에서 해악을 줄이는 노력은 여전히 의미 있음 - Zig 커뮤니티는 기존 툴을 거부하고 직접 더 나은 도구를 만드는 전통이 있음
이번 계기로 “GitHub보다 나은 플랫폼”을 만들 수도 있을 것 같아 기대됨 - 물론 GitHub과 ICE의 관계와는 별개로, 글의 대부분은 기술적 이유를 다루고 있었음
- GitHub과 직접 거래하는 것과, 결제 프로세서가 협력 관계인 것은 다름
완벽한 대안은 없지만, 덜 나쁜 선택을 하는 건 충분히 이해할 만함
- 하지만 나는 그걸 ‘순수성 나선’이라 부르지 않음
-
Codeberg의 인프라 상태를 보면 불안정한 하드웨어를 커뮤니티 기부로 운영 중이라 함
공식 블로그 글을 보면
안정적인 프로덕션 환경이라기보단 취미 프로젝트에 가까워 보임- 글의 인프라 부분을 읽고 웃음이 나왔음.
마치 Chaos Monkey가 실시간으로 돌고 있는 환경 같음
하지만 그 한 대의 서버를 유지하는 기술력은 인상적임
다만 Zig 레포는 내 서버에도 미러를 둘 예정임 - 왜 Zig가 자체 호스팅(gitea나 forgejo) 대신 Codeberg를 택했는지 궁금함
GitHub에서 옮기는 것만으로도 큰 변화인데, 안정성 측면에서 더 안전한 선택이었을 수도 있음 - Codeberg의 상태 페이지가 항상 초록색인데, 실제로는 몇 분마다 장애가 발생하는 것처럼 보임
- 글의 인프라 부분을 읽고 웃음이 나왔음.
-
GitHub Actions를 “원숭이가 만든 최고의 무료 CI”라며 비난하는 건 과도함
Zig Foundation처럼 수백만 달러 예산이 없는 프로젝트에게는 큰 도움이 됨
하지만 GitHub Sponsors를 “부담”이라 부르는 건 과장임- Zig 팀은 GitHub Actions의 기술적 문제를 무시하지 말라고 반박함
우리는 자체 CI 머신을 운영하고 있어서 무료 러너는 의미가 없음
또 “수백만 달러”는 사실이 아님. 대부분 팀원 집의 소비자용 하드웨어로 운영 중임
GitHub Sponsors는 Microsoft가 언제든 수수료를 올리거나 종료할 수 있는 위험이 있어 Every.org로 옮긴 것임 - GitLab이나 Jenkins를 써본 사람이라면 GitHub Actions보다 더 나은 경험을 했을 것임
문서화도 부족하고 정규식 처리조차 불명확했음 - macOS 15 러너가 CPU 100% 버그로 반년째 방치된 상태임
관련 이슈 참고 - GitHub CI의 유일한 장점은 무료 Mac 러너 제공뿐임
- “Actions는 원숭이가 만든 게 낫겠다”는 말이 나올 정도로 품질이 낮음
- Zig 팀은 GitHub Actions의 기술적 문제를 무시하지 말라고 반박함
-
Forgejo와 Codeberg의 기여자들이 직접 도와준 점이 가장 인상 깊었음
이름이 언급된 Earl Warren, Otto, Gusted, Mathieu Fenniak 같은 사람들의 헌신이 느껴짐- 이런 진정성 있는 커뮤니티 정신은 많은 자유 소프트웨어 프로젝트에서 공통적으로 느껴짐
-
Microsoft를 옹호하고 대안 커뮤니티를 비난하는 분위기가 Hacker News에서 보이는 건 씁쓸함
예전의 해커 정신과는 거리가 있음- 다만 사람들은 Microsoft 옹호가 아니라, 이전 방식과 대안 선택, 공격적 어조를 문제 삼는 것 같음
- “Actions는 원숭이가 만들었다” 같은 표현은 유치한 공격으로 보임
- 한때 Microsoft가 Balmer 이후 개선되는 듯했지만,
지금은 광고와 AI 과열로 다시 퇴보한 모습을 보임
-
Codeberg로의 이전을 환영함. SourceHut도 좋지만, Codeberg가 더 안정적이고 장기적 대안이라 생각함
나도 GitHub를 떠났음- 하지만 이제 너무 많은 플랫폼이 생겨 피로감이 있음
GitHub, GitLab, SourceHut, Codeberg 등 대부분 기능은 비슷함
중앙화의 장점도 있었지만, 경쟁이 생긴 건 긍정적임 - Drew가 SourceHut에서 물러났고, 메일링 리스트 중심 워크플로우를 고집한 점이 아쉬움
- SourceHut 창립자가 “조금 불안정한 성향”이라는 말이 있는데, 그게 무슨 뜻인지 궁금함
- SourceHut의 가장 큰 문제는 조직(organization) 기능 부재임
여러 저장소를 가진 대형 프로젝트에는 불편함
- 하지만 이제 너무 많은 플랫폼이 생겨 피로감이 있음
-
GitHub의 ICE 관련 언급보다, “남은 사람들은 버그 많은 JS 프레임워크를 강요한다”는 문장이
오히려 글쓴이의 성향을 더 드러내는 듯함 -
Codeberg는 현재 시각장애인 접근성이 부족함
이미지 기반 CAPTCHA 때문에 스크린리더 사용자는 가입 불가함
수동 절차가 있지만, 처리 기간이 불명확함- 하지만 이슈 페이지에
CAPTCHA 접근성 문제를 인지하고 제거 계획을 밝힌 내용이 있음
Wikimedia의 대응 속도를 근거로 Codeberg를 비판하는 건 부적절함 - 개발 도구에서 접근성을 사치로 여기는 문화가 슬픔
AI가 접근성을 개선할 수도 있지만, 오히려 사용자에게 더 많은 부담을 줄까 걱정임 - 접근성이 왜 정치적 문제로 취급되는지 이해할 수 없음
- 그들이 사용하는 CAPTCHA 패키지에는 오디오 캡차 기능이 있는데,
왜 활성화하지 않았는지 의문임
- 하지만 이슈 페이지에