1P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • Zig 프로그래밍 언어 재단이 GitHub의 품질 저하와 Microsoft의 AI 중심 경영을 이유로 Codeberg로 이전 결정
  • GitHub Actions의 ‘safe_sleep.sh’ 버그가 수년간 방치되며 CI 시스템이 마비되는 사례가 발생
  • Zig 측은 GitHub이 AI 중심 전략으로 엔지니어링 품질을 희생하고 있다고 비판
  • Fast.AI 공동창립자 Jeremy Howard도 GitHub의 버그 관리 부실과 코드 품질 저하를 지적
  • 오픈소스 프로젝트들이 GitHub을 떠나는 움직임이 확산되며, AI 상업화 중심의 플랫폼 운영에 대한 반발이 커지는 추세

Zig 재단의 GitHub 탈퇴 배경

  • Zig 프로그래밍 언어를 관리하는 Zig Software Foundation이 GitHub을 떠나 비영리 git 호스팅 서비스 Codeberg로 이전 결정
    • 이유는 GitHub이 더 이상 엔지니어링 우수성에 헌신하지 않는다는 판단
  • Andrew Kelly는 GitHub Actions의 ‘safe_sleep.sh’ 무한 루프 버그를 대표적 사례로 지적
    • 해당 스크립트는 CPU를 100% 점유하며 무한 실행되는 문제가 있었음
    • 이로 인해 Zig의 CI 러너가 수 주간 중단되는 사태 발생

GitHub Actions의 기술적 문제

  • 문제의 원인은 2022년 2월 코드 변경으로, POSIX의 sleep 명령을 ‘safe_sleep’ 스크립트로 대체한 것
    • 스크립트가 특정 초 단위 타이밍을 놓치면 무한 루프에 빠지는 구조
  • 이 버그는 2025년 8월 20일에야 수정되었으며, 관련 이슈는 12월 1일까지 미해결 상태로 남음
  • 또 다른 CPU 과다 사용 버그는 여전히 해결되지 않은 상태

커뮤니티와 전문가 반응

  • Jeremy Howard(Fast.AI 공동창립자) 는 GitHub Actions의 상태가 “명백히 부실하다”고 평가
    • CPU를 100% 점유하는 코드가 1년간 검토되지 않고 방치되었다고 지적
    • “정상적으로 운영되는 조직이라면 이런 일련의 실수를 반복할 수 없다”고 언급
  • Kelly는 이후 자신의 발언이 과격했다며 사과했지만, GitHub의 품질 저하 문제는 여전히 강조

다른 프로젝트들의 이탈 움직임

  • Dillo 브라우저 프로젝트 창립자 Rodrigo Arias Mallo도 GitHub을 떠날 계획 발표
    • JavaScript 의존도, 서비스 거부 가능성, LLM·생성형 AI 중심 운영 등을 문제로 지적
    • “생성형 AI가 오픈 웹을 파괴하고 있다”고 언급
  • Codeberg는 2025년 1월 이후 후원 회원 수가 600명에서 1,200명 이상으로 두 배 증가

GitHub의 AI 중심 수익 구조

  • Microsoft CEO Satya Nadella는 2024년 2분기 실적 발표에서
    • GitHub Copilot 유료 구독자 130만 명 이상, 분기 대비 30% 증가라고 발표
  • 2024년 GitHub의 연간 매출 20억 달러 중 약 40%가 Copilot 구독에서 발생
  • 2025년 3분기에는 Copilot 사용자 1,500만 명 이상, 전년 대비 4배 증가 보고
  • GitHub은 현재 유료 사용자 수를 공개하지 않음, Copilot 중심의 수익 구조만 강조됨

요약적 의미

  • Zig와 Dillo 사례는 AI 상업화 중심의 플랫폼 운영이 개발자 신뢰를 약화시키는 현상을 보여줌
  • GitHub의 AI 집중 전략과 품질 관리 부재가 오픈소스 커뮤니티의 이탈을 촉발
  • Codeberg 같은 비영리 대안 플랫폼의 성장세가 가속되는 추세
Hacker News 의견
  • Zig 팀의 공지문 수정 이력이 꽤 흥미로움
    처음엔 GitHub 팀을 “무능한 잔류자들이 만든 버그투성이 JS 프레임워크” 로 비난했지만, 이후 표현이 완화되었음
    최종 버전에서는 GitHub의 “엔지니어링 우수성” 이 사라졌다는 식으로 정리됨
    초기 버전(11/27 02:10)중간 수정(11/27 14:04)최종 수정(11/28 09:21)

    • 이전 HN 스레드에서 “정치적 감정 표현을 빼라”는 피드백이 많았는데, Zig 팀이 그걸 받아들인 듯함
      커뮤니티를 위해 자존심을 내려놓은 수정을 한 점이 인상적임
    • Kelly가 보여준 “엔지니어링 우수성” 에 대한 집착과 분노는 오히려 Zig의 밝은 미래를 보여주는 듯함
      기술 리더가 평범함에 분노하는 건 좋은 신호라고 생각함
    • 처음 문구처럼 “형편없는 소프트웨어는 의도적”이라는 식의 비난은 과함
      실제로는 환경과 역량의 제약 속에서 만들어지는 결과물일 뿐임
    • 분노는 판단력을 흐리게 함
      사랑으로 만드는 소프트웨어, 즉 기술과 사람에 대한 애정이 더 나은 결과를 만든다고 믿음
    • “bloated, buggy JS framework”라는 표현에 공감함
      거대 기업들이 돈을 쏟아부어 이런 프레임워크를 유지하고, 수백만 명이 비활성화도 못 한 채 사용 중임
      나는 GitHub를 쓸 때 JS를 전혀 실행하지 않고, 프록시 규칙으로 raw 파일만 다운로드
      http-request set-path %[path,regsub(/blob/,/raw/,g)] if { hdr(host) github.com }
      http-request set-path %[path,regsub(/releases/tag/,/releases/expanded_assets/,g)] if { hdr(host) github.com }
      
      이렇게 쓰면 잘 작동함
  • GitHub의 강점은 에코시스템
    PR 시스템, 이슈 관리, CI 액션, 스폰서십 등 모든 게 한곳에 모여 있음
    AI 집착은 불안하지만, 여전히 개발자에게 가장 편한 도구라고 생각함

    • 동의하지 않음. GitHub의 진짜 힘은 소셜 네트워크 효과
      스타, 포크, 팔로워 수 같은 지표가 품질의 신호로 작용함
      결국 개발자들은 “커뮤니티의 눈”을 신뢰함
    • 예전 Gerrit을 써봤는데, GitHub PR이 특별히 낫다고 느끼진 않음
      Actions는 YAML-지옥이라 불릴 만큼 복잡하고 자주 장애가 남
      그래도 “모두가 쓰는 곳”이라는 점이 가장 큰 이유임
    • CI 시스템이 잘 만들어졌다는 말엔 동의 못함
      Actions는 편리하지만 끔찍한 제품
    • 차라리 brainfuck으로 Advent of Code를 푸는 게 낫겠음
      GitHub Actions 디버깅은 고통 그 자체임
    • GitHub이 비공개 저장소를 AI 학습에 사용했는지 부인하지 않은 점이 불만임
      GitLab은 명확히 부정했는데, 이 차이가 신뢰를 깎음
  • Codeberg의 인프라가 궁금해서 찾아봤음
    공식 블로그 글에 따르면
    3대의 서버(1대 Gigabyte, 2대 Dell R730/R740) 로 운영 중이며, 중고 하드웨어 재활용을 강조함
    심지어 고장난 MacBook을 CI 러너로 재활용하려는 시도도 있음
    성능 저하가 가끔 있지만 재시작으로 해결 가능하다고 함
    해커스페이스 같은 DIY 감성이 느껴짐

    • 상태 페이지를 보면 가용성이 낮음
      최근 24시간 89% 업타임, 14일 평균은 98%지만 메인 사이트는 자주 느림
    • Codeberg는 기업용이 아닌 FLOSS 전용 플랫폼
      상업적 서비스 제공이 목적이 아님
    • 나도 20살 때 더 큰 클러스터를 돌렸었음
      전기요금만 월 600달러 넘게 나가는데, 이 정도면 나도 무료 서비스를 열 수 있을 듯함
      아이디어 있으면 메일 달라고 함
  • Zig의 GitHub 이슈 대응을 보면 약간 감정적인 결정처럼 보임
    버그는 어디에나 있고, GitHub 규모를 생각하면 당연한 일임
    Codeberg로의 이전은 논의가 부족해 보임
    Zig는 기술적으로 훌륭하지만 성숙한 리더십 구조가 아직 자리 잡지 못한 듯함

    • 문제는 버그보다 거대 기업의 무관심
      Microsoft 같은 회사는 고객이 아무리 불만을 제기해도 신경 쓰지 않음
      그래서 작은 플랫폼으로 옮기면 고객 성공에 더 동기부여된 지원을 받을 수 있을 거라 기대함
      CI 스크립트는 가능한 한 순수 스크립트 형태로 만들어야 이식성이 높음
    • “Codeberg를 몰랐다”는 건 개인 문제임
      내부 논의가 없었다는 근거도 없음
  • GitHub의 문제엔 공감하지만, Codeberg는 자주 다운됨
    상태 페이지 기준 최근 2주 업타임이 95% 수준임

    • GitHub Actions도 자주 장애가 나서, 사실 큰 차이는 없다고 느낌
    • 서비스 수준이 중요하다면 Forgejo를 직접 호스팅하는 게 나음
      GitHub처럼 단일 장애점에 의존하지 않게 됨
    • Reddit에서도 Codeberg의 봇 검증 절차가 불편하다는 불만이 있었음
      그래도 자체 호스팅 가능한 Forgejo는 매력적임
    • Codeberg는 DDoS 공격을 자주 받음
      Mastodon 계정을 보면 투명하게 상황을 공유함
      공격받는다는 건 그만큼 의미 있는 존재라는 반증일 수도 있음
    • Codeberg는 오픈소스 전용 플랫폼
      상업 프로젝트나 개인 백업용으로 쓰기엔 부적절함
  • 요즘 AI라는 단어가 마케팅 용어로 전락했다고 느낌
    2년쯤 지나면 대부분의 앱에 AI 기능은 남겠지만, “AI-first”라는 홍보 문구는 사라질 것 같음

    • 지난 15년간 늘 그랬음
      그래도 예측엔 동의함 — 이제 AI 광고는 촌스러운 일이 됨
    • “빅데이터”, “머신러닝”처럼 유행어가 바뀌었을 뿐
      여전히 개인화 광고는 건재함, 비록 개념 자체는 불쾌하지만
  • GitHub의 대시보드 피드 개편은 재앙이었음
    관련 토론에서도 불만이 많음

    • 최근 업데이트로 최근 PR·이슈 목록 중심으로 바뀌었는데, 이건 오히려 개선처럼 느껴짐
      실제로 자주 활용 중임
    • 솔직히 대시보드 자체를 안 씀
      대부분 프로젝트 페이지에서 바로 작업함
    • 나도 알림 페이지를 기본 홈으로 씀
      브라우저 자동완성으로 “not”만 쳐도 바로 이동함
  • Zig의 이전 이유는 단순히 Microsoft 불신 때문만은 아님
    Zig는 원래 의견이 강한 커뮤니티
    GitLab도 만족스럽지 않고, 대안이 많지 않음
    문제의 본질은 거대 기업의 독점 구조이며, AI는 그 문제를 더 악화시킴

    • Bitbucket은 요즘 어떤지 궁금함
      이제는 거의 존재감이 사라진 듯함
  • Codeberg의 장점은 페이지 로딩 속도
    GitHub는 종종 느리고 무겁게 느껴짐

    • 특히 불안정한 4G 환경에서는 GitHub가 끔찍함
      Linear 같은 서비스와 비교하면 차이가 큼
    • 반대로 내 테스트에선 Codeberg가 더 느렸음
      $ time curl -L 'https://codeberg.org/'  → 3.06s  
      $ time curl -L 'https://github.com/'    → 1.35s
      
      환경에 따라 다를 듯함
  • Fossil SCM을 추천하고 싶음
    SQLite 제작자가 만든 도구로, 6MB 단일 실행 파일에 GitHub급 기능이 내장되어 있음
    fossil-scm.org에서 확인 가능함

    • 다만 코드 리뷰 시스템이 없음
      창시자가 외부 기여를 거의 받지 않기 때문임
      1인 프로젝트에는 훌륭하지만, 협업에는 부적합함
    • 그래도 개인 프로젝트엔 훌륭함
      다음 사이드 프로젝트에서 꼭 써보길 권함