GitHub를 떠나 Forgejo로 이동하기

• 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에 흡수됨
  • CoreAI는 Satya Nadella가 2025년 1월 소개한 조직으로, 1st-party와 3rd-party 고객을 위한 end-to-end Copilot 및 AI stack 구축을 목표로 함
• 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는 나중에 다시 판단할 수 있음