▲

GitHub를 떠나 Forgejo로 이동하기

 (jorijn.com)
1P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • GitHub를 떠나는 직접 계기는 2026년 4월 장애가 아니라, GitHub 위에서 실행되는 코드와 워크플로의 소유권 문제임
  • GitHub는 2025년 8월 이후 자체 CEO 없이 Microsoft CoreAI division에 편입됐고, 코드는 Microsoft AI 조직 산하에 놓이게 됨
  • Copilot Free, Pro, Pro+는 2026년 4월부터 상호작용 데이터가 기본적으로 학습 데이터에 쓰이는 opt-out 구조로 바뀜
  • GitHub와 Microsoft는 미국 기업이어서 FISA 702와 CLOUD Act 관할권에 놓이며, EU data residency만으로는 해결되지 않음
  • Forgejo v15 LTS는 code.jorijn.com의 단일 NUC에서 운영되며, runner는 KVM, gVisor, 주간 재빌드, egress filter로 격리됨

GitHub를 떠나는 이유는 장애가 아니라 소유권 문제

  • 2026년 4월 장애는 개발자에게 충분히 심각했지만, GitHub를 떠나는 핵심 이유는 장애 자체가 아니라 GitHub 위에서 실행되는 코드와 워크플로의 소유권임
  • 2026년 4월 27일 네덜란드 내무부는 정부 소스코드를 위한 자체 호스팅 Forgejo 인스턴스인 code.overheid.nl을 소프트 런칭함
    • 프로젝트 매니저 Boris Van Hoytema는 부처가 법적으로 소스코드를 “소유한 장소”에 공개해야 한다는 요구에서 플랫폼이 출발했다고 밝힘
    • Forgejo는 완전한 오픈소스이고 디지털 자율성에 필요한 자유를 제공한다는 이유로 GitLab보다 우선 선택됨
  • 개인 코드의 기본 Git 호스트도 code.jorijn.com으로 이동했으며, Forgejo v15 LTS가 단일 NUC의 강화된 구성에서 실행됨
    • 일부 저장소는 이미 이동했고 나머지는 대기 중임
    • 마이그레이션이 끝나면 공개 GitHub 저장소를 아카이브하고 각 아카이브에서 새 위치를 가리킬 계획임

장애와 AI 부하

  • 2026년 4월 23일 merge queue의 squash-merge 코드 경로가 기능 플래그의 불완전한 롤아웃 뒤에 658개 저장소와 2,092개 pull request에서 이미 병합된 커밋을 조용히 되돌림
    • Modal과 Zipline을 포함한 회사들이 수동으로 데이터를 복구함
    • 나흘 뒤에는 과부하된 Elasticsearch 클러스터로 Pull Requests, Issues, Packages가 6시간 넘게 중단됨
  • 2026년 2월 한 달에만 37건의 인시던트가 기록됐고, Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot, Pages가 동시에 내려간 3시간 40분 장애도 들어 있음
  • 2025년 10월 1일에는 10시간 macOS runner 장애가 발생함
  • IncidentHub 집계 기준 2025년 5월부터 2026년 4월까지 GitHub는 257건의 인시던트와 48건의 주요 장애를 기록했고, 총 다운타임은 약 112시간임
  • GitHub CTO Vlad Fedorov는 4월 28일 사과하면서, 2025년 12월 이후의 “agentic AI workflow growth”로 인한 부하를 따라가려면 용량을 30배 늘려야 한다고 밝힘
    • 신뢰성 문제는 AI 기능 확대의 하위 결과로 해석됨
    • GitHub는 AI 기능을 늦추기보다 더 강하게 밀고 있음
  • The Pragmatic Engineer는 GitLab, Bitbucket, Vercel, Linear, Sentry는 같은 해를 겪지 않았다고 짚음
    • 이들도 개발자 수요 압력을 받고 있으므로, GitHub의 장애 양상은 GitHub 특유의 문제로 보임

GitHub의 조직 변화

  • 2025년 8월 11일 Thomas Dohmke가 GitHub CEO에서 물러났고, Microsoft는 후임 CEO를 두지 않음
  • GitHub는 Microsoft의 CoreAI division에 흡수됨
  • GitHub의 매출, 엔지니어링, 지원은 Julia Liuson 아래 Microsoft developer division으로 보고됨
    • GitHub CPO는 Microsoft AI platform VP에게 보고함
    • 브랜드는 남아 있지만 독립 리더십은 사라짐
  • 2018년부터 2024년까지는 Microsoft가 GitHub를 어느 정도 거리 두고 운영했다는 평가가 실질적으로 맞았지만, 2025년 8월 이후에는 그 전제가 유지되기 어려워짐
  • 현재 github.com에 코드를 푸시한다는 것은 Microsoft의 AI 조직 산하 유닛에 코드를 푸시한다는 뜻이 됨

Copilot 학습 데이터 기본값 변경

  • GitHub는 2026년 3월 25일, 4월 24일부터 적용되는 개인정보 처리방침 변경을 발표함
    • Copilot Free, Pro, Pro+ 사용자의 상호작용 데이터, 특히 입력, 출력, 코드 조각, 관련 문맥이 사용자가 거부하지 않는 한 AI 모델 학습과 개선에 사용됨
  • 핵심 변화는 opt-in이 아니라 opt-out이라는 점임
    • Copilot Free, Pro, Pro+ 사용자는 Copilot 설정 페이지에서 끄지 않으면 모델 학습에 기여하게 됨
  • 저장소 단위 차단이 없음
    • 관리자는 특정 저장소 안의 상호작용을 학습하지 말라고 GitHub에 지정할 수 없음
    • opt-out은 사용자 계정별 설정이므로 각 기여자가 직접 선택해야 함
    • 결과적으로 Copilot Free/Pro/Pro+ 사용자가 저장소를 다루면 라이선스와 무관하게 코드베이스가 학습 재료가 될 수 있음
  • 비공개 저장소 예외도 좁게 적용됨
    • GitHub는 비공개 저장소의 “at rest” 콘텐츠를 학습에 사용하지 않는다고 말함
    • 하지만 비공개 저장소 안에서 Copilot을 쓰는 동안 생성된 “code snippets and interaction context”는 수집함
    • “정지 상태의 코드”와 “편집 중 생성된 조각” 사이의 경계는 흐릿함
  • Copilot Business와 Copilot Enterprise 고객은 별도 Data Protection Agreements가 적용되므로 제외됨
    • 충분히 비용을 내면 상호작용이 학습 데이터가 아니고, 그렇지 않으면 학습 데이터가 되는 구조임
  • GitHub의 사용자 상호작용 데이터에 대한 전략적 관심은 이제 선택적 요소가 아니라 구조적 요소가 됨

관할권 리스크는 데이터 위치로 해결되지 않음

  • GitHub Inc.와 Microsoft Corp.는 미국 기업이며, 이들이 보유한 데이터는 FISA Section 702와 2018년 CLOUD Act를 포함한 미국 법의 범위에 들어감
    • 두 법은 데이터가 물리적으로 어디에 있든 적용될 수 있음
  • Section 702는 2024년 4월 2년간 재승인됐고, 2026년 4월 말 서명된 45일 연장으로 유지 중임
    • 미국에 소재한 전자통신 서비스 제공자를 통해 비미국인을 대상으로 한 미국 정보기관 수집을 허용함
  • CLOUD Act는 미국에 본사를 둔 회사에 전 세계 어디에 저장된 데이터든 제출하도록 강제할 수 있음
  • GitHub는 2024년 10월 Enterprise Cloud의 EU data residency 일반 제공을 발표함
    • 이는 데이터 위치 문제를 다루지만 관할권 문제를 해결하지는 못함
    • CLOUD Act 노출은 지리적 위치가 아니라 기업 지배 구조를 따라감
  • Microsoft 측 변호사는 2025년 6월 프랑스 상원 청문회에서 선서 아래, 유럽 Microsoft 데이터센터에 저장된 프랑스 데이터가 조용한 미국 정부 접근으로부터 안전하다고 보장할 수 없다고 답함
  • 코드가 github.com에 있는 한, 그 코드는 미국 법적 영역에 있음
    • EU data residency는 안심 요소일 수 있지만 해결책은 아님

네덜란드 정부의 code.overheid.nl 선택

  • 네덜란드 정부 선택의 법적 배경은 2020년부터 시행 중인 “Open, tenzij” 정책임
    • 공공 자금으로 개발된 소프트웨어는 보안이나 기밀성이 요구되지 않는 한 기본적으로 오픈소스가 됨
    • 이를 준수하려면 부처가 실제로 통제하는 곳에 코드를 공개할 장소가 필요했음
  • 유럽위원회는 2022년 9월부터 자체 호스팅 GitLab 기반 code.europa.eu를 운영 중임
  • 독일의 openCode도 GitLab 기반임
  • 프랑스의 code.gouv.fr는 자체 forge가 아니라 다른 곳에 호스팅된 저장소를 색인하는 애그리게이터임
  • 네덜란드 정부는 GitLab이 아니라 Forgejo를 의도적으로 선택함
    • OSOR에 따르면 Forgejo가 완전한 오픈소스이며 open-core 분리가 없고, 디지털 자율성에 필요한 모든 자유를 제공한다는 점이 이유였음
    • Van Hoytema는 Forgejo 로드맵이 대안보다 “way more aligned”돼 있었다고 덧붙임
  • 네덜란드 정부는 단순한 주권적 forge가 아니라, 상용 벤더의 프리미엄 티어 뒤에 잠기지 않는 주권적 forge를 원함
  • 정부도 같은 문제 구도를 보고 같은 결정을 내렸고, Forgejo 선택은 더 이상 주변부 선택으로 보기 어려워짐

Forgejo를 선택한 이유

  • GitLab도 진지하게 검토됐음
    • 자체 호스팅 GitLab CE는 잘 알려진 선택지이고, 더 큰 상업 생태계와 더 다듬어진 UI를 갖고 있음

  • 라이선스

    • GitLab은 open core 모델임
      • Community Edition은 MIT 라이선스지만, 운영 환경에서 원하는 많은 기능은 비자유 라이선스의 Enterprise tier에 있음
    • Forgejo는 반대로 움직임
      • 2024년 8월 v9.0부터 MIT에서 GPLv3+로 재라이선스됨
      • 명시적 목표는 copyleft를 유지하고 코드베이스의 향후 상업적 포획을 막는 것임
    • Forgejo가 2022년 12월 Gitea에서 포크된 이유도 Gitea Ltd가 커뮤니티 동의 없이 상표와 도메인을 통제했기 때문임
      • 그 교훈이 라이선스 선택에 반영됨

  • 거버넌스

    • Forgejo는 Codeberg e.V. 아래에 있음
      • Codeberg e.V.는 2018년 9월부터 베를린에 등록된 비영리 단체임
      • 회원이 선출한 이사회, 공개 예산, 호스팅 인스턴스의 300,000개 이상 저장소를 갖고 있음
    • 회원들은 매년 예산에 투표함
      • 2025년 계획은 찬성 88표, 반대 0표, 기권 1표로 승인됨

  • 릴리스와 성숙도

    • Forgejo v15.0 LTS는 2026년 4월 16일 출시됨
      • 프로젝트의 100번째 릴리스임
      • 장기 지원은 2027년 7월 15일까지 이어짐
    • Forgejo Actions는 v15에서 필요한 수준에 도달함
      • ephemeral runner, OpenID Connect, reusable workflow expansion이 포함됨
    • 포크 이후 릴리스는 꾸준했고, 월간 보고도 활발함

  • 상업 생태계의 한계

    • Forgejo의 상업 생태계는 존재하지만 얇음
    • 현재 가장 깔끔한 상업 제품은 Codey by VSHN임
      • 2025년 3월 Servala에서 출시된 스위스 호스팅 관리형 Forgejo임
      • 월 19 CHF부터 시작함
    • Red Hat식 엔터프라이즈 지원 구독은 없음
    • 24/7 전화 지원과 책임질 벤더가 필요하다면 직접 구축하거나 기다려야 함

code.jorijn.com 구성

  • code.jorijn.com은 홈오피스의 단일 Intel NUC에서 실행됨
    • RAM은 64GB임
    • Forgejo v15 LTS, Postgres 17, Traefik은 Docker 안에서 실행됨
    • Incus 관리 KVM 가상 머신이 옆에서 Forgejo Actions runner를 실행함
  • Forgejo, Postgres, reverse proxy 배치 자체보다 더 중요한 결정은 runner 구성임

runner가 가장 위험한 부분

  • 자체 호스팅 forge에서 forge 자체는 쉬운 부분이고, 어려운 부분은 CI 작업을 실행하는 환경임
  • runner는 매일 Renovate 일정에 따라 npm install, composer install, pip install을 실행해야 함
    • 대상은 자체 저장소에서 생성된 lockfile임
    • 이는 lifecycle script 실행을 뜻함
    • 모든 작업이 잠재적으로 신뢰할 수 없는 코드를 실행할 수 있음
  • 최근 npm worm과 axios 공급망 공격이 한 시간 안에 자동 병합되는 dependency bot을 타고 이동한 것과 같은 위험이 있음
  • runner의 역할은 코드를 실행하는 것이 아니라, 실행 중인 코드를 격리하는 것임
    • 단일 방어 계층이 실패할 수 있다고 가정하고 다음 계층이 실패를 흡수하도록 설계됨

runner 방어 계층

  • 지속형 KVM 가상 머신

    • runner는 호스트의 컨테이너가 아니라 별도 KVM VM 안에 있음
    • 작업 환경은 호스트 커널을 공유하지 않음
    • runner 내부의 Linux 커널 CVE가 NUC에 닿으려면 KVM 경계를 먼저 깨야 함

  • VM 내부 기본 Docker runtime으로 gVisor 사용

    • 작업 컨테이너는 runsc 아래에서 실행됨
    • runsc는 시스템 호출을 호스트 커널에 바로 넘기지 않고 사용자 공간에서 가로챔
    • 컨테이너 탈출은 gVisor와 주변 KVM을 모두 깨야 함

  • 주간 파괴적 재빌드

    • 매주 월요일 02:00 UTC에 전체 VM을 삭제하고 새 Ubuntu base image에서 다시 생성함
    • Forgejo를 향한 새 persistent runner registration도 다시 발급됨
    • base image는 일요일에 재빌드되므로 새 VM은 해당 주의 apt와 커널 패치를 반영함
    • 영속 상태는 7일보다 오래 남을 수 없음

  • runner bridge의 nftables egress filter

    • runner는 공개 목적지의 :443, :80, :22, :53에 접근할 수 있음
      • npm, pypi, ghcr, hairpin NAT를 통해 공개 호스트명으로 접근하는 자체 Forgejo가 대상임
    • 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12에는 접근할 수 없음
    • 손상된 작업은 LAN을 스캔하거나 라우터 관리자 인터페이스나 호스트의 다른 서비스에 접근할 수 없음

  • 범위 제한 runner token

    • 두 persistent runner registration은 각각 단일 사용자 범위와 단일 조직 범위에 묶임
    • 관리는 write:user,write:organization PAT scope를 사용함
    • 유출된 토큰은 범위 밖에 runner를 등록할 수 없고, admin scope 작업도 할 수 없음
    • 계층들은 의도적으로 겹치도록 구성됨
    • 각 계층은 울타리이고, 합쳐서 깊이 있는 경계를 만듦
    • KVM isolation, gVisor, 주간 재빌드, scope-bound runner registration은 모두 Forgejo와 Incus가 기본 지원하는 요소임

포기한 것들

  • 발견성과 소셜 그래프

    • GitHub는 기여자들이 저장소를 찾는 곳임
    • 공개 저장소에 작은 수정을 보내려는 사람은 낯선 도메인이 아니라 github.com에서 작업하기를 기대함
    • 이동이 완료되면 각 공개 GitHub 저장소를 아카이브하고 README가 code.jorijn.com을 가리키도록 할 계획임
    • 발견 경로는 유지됨
      • 사람들은 여전히 GitHub에서 저장소를 찾고, 아카이브 안내를 본 뒤 canonical home으로 이동함
    • 아직 완료되지는 않았고, 일부 저장소만 code.jorijn.com에 있으며 나머지는 대기 중임

  • GitHub Actions 생태계의 취약한 호환성

    • Forgejo Actions는 호환성이 아니라 익숙함을 목표로 함
    • 대부분은 작동하지만 일부는 작동하지 않음
    • workflow 수준의 permissions: 블록은 조용히 무시됨
    • actions/checkout@v6는 2026년 초 non-GitHub runner에서 authenticated checkout을 깨뜨려 v5로 고정함
    • actions/upload-artifact@v4는 Forgejo-hosted fork가 필요함
    • OIDC는 작동하지만 GitHub의 permissions: id-token: write가 아니라 enable-openid-connect: true라는 다른 workflow key를 사용함
    • GitHub 고유 기능에 workflow가 많이 의존한다면 마이그레이션은 저녁 한 번에 끝나는 일이 아니라 프로젝트가 됨

  • Dependabot 부재

    • Forgejo에는 Dependabot이 없음
    • Renovate를 같은 자체 호스팅 runner에서 3시간 주기로 실행함
    • 같은 역할을 하지만 설정이 더 많고, 구성에는 하루가 걸림

  • 24/7 벤더 지원

    • GitHub Enterprise는 전화번호와 SLA를 제공함
    • Forgejo는 issue tracker와 chat room을 제공함
    • 1인 운영에는 충분하지만, 200명 엔지니어 조직에는 충분하지 않을 수 있음

옮길 가치가 없는 경우

  • 인프라를 운영할 의지나 역량이 팀에 전혀 없다면 자체 호스팅 Forgejo로 옮기지 않는 편이 나음
    • 관리형 Forgejo인 Codey나 FOSS용 Codeberg는 격차를 대부분 줄여주지만, 마이그레이션 비용은 여전히 남음
  • GitHub Apps marketplace, Codespaces, Copilot Workspace, Advanced Security 같은 GitHub 고유 기능에 깊이 투자했다면 적합하지 않음
    • Forgejo는 forge이지 developer-platform-as-a-service가 아님
  • 기여자 기반이 GitHub 소셜 그래프라면 발견성이 소유권보다 중요할 수 있음
    • 기여자가 있는 곳에 남거나, 마찰을 감수하고 이동 완료 뒤 공개 GitHub 저장소를 아카이브해 새 위치를 가리킨 다음 나중에 다시 판단하는 선택이 가능함
  • runner에 대한 신뢰 가능한 운영 답이 없다면 옮기기 어려움
    • 이 부분이 가장 진지하게 다뤄야 할 영역임
    • KVM isolation, gVisor, nftables, 주간 재빌드를 고민할 준비가 없다면 CI 작업은 관리형 runner host에서 실행하거나 GitHub에 남는 편이 나음
  • 네덜란드 정부도 모든 것을 한 번에 옮기지 않았음
    • code.overheid.nl은 부처들이 오픈소스 코드를 공유하기 위한 소프트 런칭 플랫폼이지, 사용하는 모든 것을 전면 교체한 것은 아님
    • code.jorijn.com 구성도 같은 형태임
      • Forgejo는 canonical host이고 GitHub는 mirror이며, mirror는 나중에 다시 판단할 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 21시간전  [-]
Hacker News 의견들

  • 모두가 GitHub를 떠나면서 git의 본래 정신을 잊는 것처럼 보임
    git은 원래 탈중앙화를 의도했고, 문제는 GitHub가 더 깔끔하고 잘 확장되며 관리도 잘돼서 git 주변 도구가 모두 GitHub로 중앙화됐다는 데 있음
    그래도 GitHub에 자동 동기화되는 미러는 남아 있으면 좋겠음. 몇 년 동안 프로젝트가 자체 호스팅이나 틈새 호스팅으로 갔다가 GitHub 미러가 죽거나 삭제되고, 결국 프로젝트가 시간 속으로 사라지는 걸 봐왔기 때문임
    git은 탈중앙화되어 있고 GitHub는 코드를 올릴 수 있는 장소 중 하나일 뿐이며, 여러 원격 서버에 push할 수 있음

    • git의 정신을 잊은 건 아니지만, GitHub가 아무에게도 말하지 않고 모든 공개 저장소로 첫 Copilot을 학습시킨 것도 기억함
      그래서 더는 개인 코드를 거기에 커밋하지 않겠음
      발견 가능성, 별표, AI 봇이 쏟아내는 이슈 같은 사회적 기능에도 관심 없음. 지금 상태로 충분함
      그리고 “Open Source is not about You”도 기억해야 함
    • 맞지만 GitHub는 git 이상임
      모두가 잊는 플랫폼의 가장 중요한 측면은 사회적 구성요소이고, 지속적인 외부 저장소를 만들고 저장소 간 협업을 아주 쉽게 해줬다는 점임
    • Forgejo는 도구까지 탈중앙화하려고 많은 작업을 하고 있음
      자체 호스팅 forge들을 서로 연결하기 위해 공개 프로토콜과 표준을 사용함
    • 모두가 “git의 정신”에 매료돼서 git을 쓰는 건 아님
      원래 의도됐던 이메일 패치 모델로 써본 사람은 아주 소수이고, 나머지 대부분은 배울 생각도 없을 가능성이 큼
      사람들은 기본적으로 GitHub가 쓰니까 git을 쓰거나, 조금 더 후하게 말하면 GitHub 같은 중앙 호스트와 결합했을 때 잘 동작하기 때문에 씀
      로컬에서 코드를 개발하고 웹 포털에서 이슈와 패치를 논의하는 모델에 끌리는 것이고, 그중 git 자체가 제공하는 부분은 작음
    • 동의함. git 저장소를 옮기는 건 쉽지만, 프로젝트 전체 표면적을 옮기는 게 어려움
      이슈, 릴리스, CI, 문서, 보안 권고, 검색과 발견 가능성은 시간이 지나며 모두 GitHub에 묶이는 경향이 있음
      오픈소스 프로젝트라면 자체 호스팅을 진실의 원천으로 두되, 사람들이 실제로 찾을 수 있게 읽기 전용 GitHub 미러를 유지하는 방식이 좋다고 봄

  • 진짜 판도를 바꿀 건 완성된 연합 지원임
    그래서 Forgejo와 Codeberg에 기부하고 있고, Forgejo 팀이 제대로 구현할 수 있도록 모두가 시간과 자원을 더 보태길 권함
    또 다른 좋은 후보는 Git 위에 완전히 탈중앙화된 Radicle임
    https://codeberg.org/forgejo-contrib/federation/src/branch/m...
    https://liberapay.com/forgejo
    https://donate.codeberg.org/
    https://radicle.dev/
    https://radicle.network/nodes/seed.radicle.dev

    • 연합은 최악의 탈중앙화 모델임. 협력이 너무 느슨함

  • 내 git 저장소도 자체 호스팅 NUC로 옮겼음
    아직 세상에 공유할 HTTP 프론트엔드는 안 붙였는데, AI 스크래퍼에게 콘텐츠를 제공하고 싶지 않고 그것들을 막는 작업도 하고 싶지 않기 때문임
    오픈소스 덕을 본 회사들이 업계를 이렇게 오염시킨 건 부끄러운 일임

    • NUC에서 Gitea를 쓰고 있고, 중고 하드웨어라 50파운드 정도 들었음
      3년째 돌아가는 중임. LAN에서만 접근 가능하게 잠그고 인터넷에 공개하지 않으면 견고하고 오래가는 사용감임
    • Pi에서 자체 호스팅 Forgejo를 GitHub 미러로 돌리고 있지만 아마 오래가진 않을 듯함
      저장소는 몇 주 동안은 잘 미러링되다가 멈춤. 만료되지 않는 PAT 토큰을 넣었는데도 만료됐다고 주장하고, 다른 곳에서 테스트하면 토큰은 정상 동작함
      로그에 아무것도 없을 때도 있고, 어떤 때는 데이터베이스가 잠겨 있음. 데이터베이스를 쓰는 건 Forgejo뿐임
      지금까지는 이게 Forgejo 문제인지, Pi의 형편없는 SD 카드 입출력 때문에 데이터베이스 잠금이 생기는 건지, Forgejo가 미러 역할을 못하는 건지 구분하지 못했음
    • 오픈소스와 OSI는 업계가 심어둔 장치임. 누가 후원하는지 보면 됨
      독점 초대형 클라우드 기업들은 공짜 노동을 얻고, 그걸로 추적 감시망, 마음대로 설치할 수 없는 휴대폰, 기기 증명, 광고 차단 없는 브라우저 단일 문화 같은 우리가 싫어하는 세상을 만듦
      Google은 사람들이 BSD/MIT를 사랑하게 만들었고, 그 결과를 보면 됨
      전형적인 수법 중 하나는 “이제 그건 우리 것”임. Elasticsearch나 Redis 같은 걸 벤더가 만들면, 초대형 클라우드가 자기 독점 상품으로 가져가 이익을 다 가져가고, 원 저자와 회사는 굶게 됨
      또 하나는 “수용, 확장, 말살”임. KHTML이나 Linux 같은 오픈소스 프로젝트를 가져와 자기 버전을 만들고, 시장에 뿌려 경쟁자를 밀어낸 뒤, 반경쟁적 수단으로 모두의 눈앞에 자기 제품을 놓고, 점유율을 얻으면 추적을 넣고 자유를 제거함
      오픈소스는 “사람에게는 자유, 회사는 돈을 내야 함”으로 대체돼야 함. 초대형 클라우드에 맞설 이빨이 있는 소스 공개 셰어웨어가 필요함
      Richard Stallman의 라이선스조차 충분히 강하지 않고, CC BY-NC-SA가 더 낫다고 봄
      “순수” 오픈소스는 기업 복지였고 실수였음. 거인들이 우리 밧줄로 우리를 매달 수 있게 해줬음
    • 누군가 자기 작업을 기꺼이 오픈소스로 제공하면서, AI가 읽고 지식으로 삼아 나중에 더 많은 프로그래머를 돕는 건 선을 긋는 이유를 모르겠음
      내 코드는 AI가 적극적으로 읽어주길 바람

  • 글의 “What I gave up” 절에서 저자가 자기 사회적 그래프를 언급했는데, GitSocial을 쓰면 사회적 그래프와 협업 이력을 가져갈 수 있음
    어떤 git 호스트 사이에서도 forge 간 pull request를 가능하게 해주며, 전부 제3자 의존성 없이 동작함

    • GitHub는 소셜 네트워크이고 git 호스팅은 작은 기능일 뿐임
      그래서 이런 대안들이 좀처럼 뜨지 못함

  • “CTO가 공개 사과했고 AI 기반 부하를 감당하려면 용량을 30배 키워야 한다고 말했다”는 대목을 보면, GitHub의 일반 사용에 과금을 시작하지 않길 바람
    하지만 일부 바이브 코더들이 하루에 수천 커밋을 만드는 걸 보면 점점 더 회의적이 됨
    코드를 무료로 공유하고 협력할 수 없게 되면 정말 아쉬울 것임

    • 일정 개수 이후에는 하루 커밋 수에 과금하면 됨. 문제 해결임
    • 솔직히 LLM이 자신들이 만든 이 문제를 해결하는 데도 도움을 줄 것 같음
      숙련된 사람은 저장소가 이런 문제를 갖고 있으면 몇 초 만에 알아보니, 조정된 시스템도 가능할 것임
      까다로운 부분은 바이브 할당량을 적용할 수 있게 하는 법적 약관을 쓰는 일임
      Anthropic이 이미 CC에서 하는 방식이고, GitHub와 GitLab도 아마 비슷하게 하고 있을 것 같음. 대가는 Twitter 개발자들과 작은 subreddit 일부의 미움이겠지만, 충분히 감수할 만할 듯함
      한편 /r/vibecoding 같은 곳에서 사람들이 월 200달러 구독료를 내고 취미 프로젝트나 장난감 사이트에 가까운 것을 만드는 걸 자주 보면 꽤 놀라움
      감당 가능할 때 어리석은 지출을 해본 적은 있지만 이건 좀 다르게 느껴짐
      어쩌면 의미와 목적을 제공하는 서비스에 연 2400달러를 내는 것일 수도 있음. 40대쯤 되어 부자나 유명인이 될 수 없다는 걸 깨닫는다면, 다른 대안들에 비해 감당 가능한 가격일지도 모름

  • Bluesky처럼 AT Protocol 위에 만들어진 탈중앙화 서비스 Tangled도 들었음
    GitHub가 구현을 질질 끌어서, 그 기능을 GitHub에 추가하는 회사들이 생길 정도였던 pull request 쌓기 같은 실제로 유용한 기능도 있음
    써본 사람이 있는지 궁금함
    https://tangled.org/

    • 최근에 자체 호스팅 Knot을 설정했지만, 다른 기능은 아직 많이 써보지 못했음
      https://tangled.org/h14h.com/knot
      전반적으로 플랫폼은 꽤 유망해 보임. AtProto가 개인 데이터 서버, 릴레이, AppView를 분리하는 방식은 적절한 절충으로 보임
      git 저장소를 헤드리스 데이터 전용 서버로 호스팅할 수 있어서, 자체 호스팅치고는 거의 고통이 없음
      Forgejo 같은 ActivityPub 해법과 비교하면, 내가 신경 쓰는 건 데이터 통제뿐인데 웹앱 전체를 호스팅하고 확장하는 지루함을 피할 수 있어 좋음
      초기 설정 이후 운영 유지보수는 knot-server 버전을 올리고 다시 배포한 것뿐임. tangled.org가 오래된 버전이면 경고 배너를 보여줌
      다른 프로젝트에서 Tangled를 더 써보고 기능도 테스트해보고 싶음. 특히 jj와 stacked PR의 네이티브 지원에 관심 있음
    • 확실히 알파 소프트웨어지만 오픈소스 용도로는 쓸 수 있음
      맞춤 CI를 연결하는 tack 같은 흥미로운 실험도 있음
      ATProto가 비공개 데이터를 지원하게 되면 언젠가 비공개 저장소도 지원할 수 있겠지만, 시간이 좀 걸릴 수 있음
      https://tangled.org/mitchellh.com/tack
    • 큰 벤처 투자를 막 받았음
      아직 사업 모델에 대한 언급은 없어서, 무엇이 될지 정말 궁금함
    • jj 호환성과 깔끔한 CI 구현 때문에 쓰고 싶지만, 비공개 저장소가 필요해서 아직은 나한테 맞지 않음
    • 내 취향에는 너무 탈중앙화되어 있음
      대신 radicle.xyz를 쓰는 게 좋음

  • Fossil도 고려해볼 만함
    코드 이력, 위키, 티켓, 포럼을 포함한 전체 저장소 상태를 단일 파일로 묶고, 그 상태가 복제됨
    호스팅 제공자를 바꿔야 할 때도 Fossil에서는 그 때문에 잃는 데이터가 없음
    https://fossil-scm.org/

    • Fossil을 좋아함. 고집 있는 작업 흐름이 내 생각과 맞는 무언가가 있음
      하지만 네트워크 효과가 문제임. 팀을 Fossil로 데려올 수가 없음
      팀은 다른 사람들, 다른 부서와 코드를 공유해야 하고 모두, 사실상 99% 이상이 git을 씀
      Fossil을 쓰라고 강제하는 건 오히려 해를 끼치는 느낌이고, 진퇴양난임
      기술 분야의 다른 많은 일과 비슷함. 동료 개발자에게 함수형 스타일 관용구를 쓰게 하거나 불변성을 강제하려 할 때도 그렇음
      Facebook이나 Google 프로젝트 같은 큰 무언가가 커뮤니티를 강제로 움직여야 하는 것처럼 느껴짐
    • 몇 년 전에 Fossil을 검토했고 정말 멋지다고 생각했음. 모든 것이 통합돼 있는 점은 훌륭함
      하지만 철학적으로는 Fossil이 마음에 들지 않음. 이력을 정리할 방법이 없고 모든 것을 그대로 보존함
      그게 원하는 바면 좋지만, 내 git 작업 흐름에서는 이것저것 실험한 뒤 push하기 전에 커밋을 정리하고 조직하는 걸 좋아함

  • 사람들은 끊임없이 탈중앙화를 외침
    하지만 현실에서는 대부분의 시스템이 결국 중앙화됨
    어쩌면 사람들이 탈중앙화를 요구할 때 실제로 찾는 건, 자신들이 새 개척자가 될 수 있는 새로운 중심일지도 모름
    기존 규칙으로는 이길 가능성이 없다고 느끼면, 탈중앙화를 명분 삼아 판을 뒤집으려는 것처럼 보임

    • 글 제목 바로 아래 첫 줄만 읽었어도 됐을 텐데: “I moved my code from GitHub to a self-hosted Forgejo”
    • 탈중앙화는 단일 중심이 없다는 뜻임
      사람들이 원하는 이유는 그 단일 중앙 관리가 이런저런 이유로 충분하지 않기 때문임
      사람들이 외친다는 것과 실제로 원한다는 것 사이에는 차이가 없음
    • 사람들은 탈중앙화의 장점을 원하지만, 그 대가를 치르기는 원하지 않음
      더 나쁜 건 중앙화 시스템이 대부분의 시간에는 훌륭하고, 고통은 합병이나 갑작스러운 가격 인상처럼 짧은 기간에 매우 강하게 온다는 점임
      탈중앙화는 항상 조금씩 아픈 대신, 중앙화 대안이 무너지는 드문 순간에 큰 행복을 줌
    • 개발자라서 탈중앙화라고 말하는 것뿐임
      보통 말로는 불매운동임. “과자가 Nestlé에 너무 중앙화됐으니 과자를 탈중앙화해야 한다”고 말하진 않음
    • 사람들이 정말 필요로 하는 것에 대한 답으로는 탈중앙화가 아니라 이식성이 맞다고 봄

  • Tangled로 옮기는 중이고, AT Protocol 위에 만들어져서 Bluesky 등과 같은 계정을 씀
    써보니 꽤 마음에 듦
    https://vale.rocks/micros/20260511-0440

  • 1년 전부터 홈랩에서 자체 호스팅 Gitea로 옮겼고, 공개 접근은 막아뒀음
    HTTPS도 없고, 가입은 비활성화했으며 저장소도 공개가 아님
    공개 인스턴스를 만들고 HTTPS를 쓰되 공격 표면을 최소화할까 고민 중인데, 특히 Gitea/Forgejo 관련 추천이 궁금함

    • 그렇게 해봤음. fly.io 프록시에서 nginx와 fail2ban을 돌리고, 내 tailnet으로 전달하면 Caddy가 실제 인스턴스로 해석함
      로컬 가입을 비활성화하는 게 중요함. 내 경우 authentik을 IdP로 쓰는데 tailnet에서만 접근 가능함. 아니면 자기 계정을 만든 뒤 가입을 끄면 됨
      robots.txt로 개별 렌더링된 git 커밋 보기 같은 일부를 막아뒀음. 안 그러면 스크래퍼가 끝없는 루프에 빠짐
      Forgejo 패키지 저장소 접근도 엄격히 금지했는데, 비공개 패키지가 있고 그쪽 권한 세분성이 내가 원하는 수준이 아니라서 아직 조정 중임
      계속 지켜보고 있으며 지금까지 큰 문제는 없었음. 자세한 내용은 docs.eblu.me에 있고, 원하면 인프라 코드로 바로 연결해줄 수도 있음
    • 과거에 해봤고, 지금도 내부/LAN Forgejo 인스턴스는 돌리지만 공개 인스턴스는 현재 없음
      예전에는 내부 인스턴스를 미러링하는 공개 읽기 전용 인스턴스를 세웠고, 내부에서 공개 인스턴스로 가는 reverse proxy 연결 하나를 두어 공개 쪽이 git 데이터를 가져가게 했음
      이후에는 대체로 알아서 잘 돌아갔고, 내부 Forgejo에서 무언가 바꾸면 공개 쪽도 갱신됐음
      이슈, CI 등은 완전히 비공개로 LAN 안에 유지할 수 있었음
    • Forgejo를 도입한 건, Forgejo가 Gitea에 제기했지만 Gitea가 무시했다는 보안 이슈를 둘러싼 정치적 논쟁들이 마음에 들지 않았기 때문임
      계속 Gitea를 쓰는 이유가 궁금함. 이제 Forgejo 대신 Gitea를 다시 시도해봐야 할지 고민됨
답변달기