--- title: "GitHub 떠나 Forgejo로 간 이유: 장애보다 더 큰 건 ‘내 코드의 주도권’" published: 2026-05-13T12:54:00.000Z canonical: https://jeff.news/article/2644 --- # GitHub 떠나 Forgejo로 간 이유: 장애보다 더 큰 건 ‘내 코드의 주도권’ 네덜란드 내무부가 정부 소스코드 공개용으로 자체 호스팅 Forgejo 인스턴스 code.overheid.nl을 열었고, 글쓴이도 개인 Git 저장소의 기준점을 GitHub에서 Forgejo로 옮기기 시작했다. 이유는 단순한 GitHub 장애가 아니라 Microsoft CoreAI 편입, Copilot 학습 데이터 기본 옵트인, 미국 관할권 리스크, CI 러너 보안까지 묶인 ‘플랫폼 소유권’ 문제다. ## 장애는 계기일 뿐, 진짜 이유는 ‘내가 이 플랫폼을 소유하지 않는다’는 감각임 - 글쓴이는 개인 Git 저장소의 기준점을 GitHub에서 자체 호스팅 Forgejo로 옮기고 있음 - 새 기준 저장소는 `code.jorijn.com`이고, Forgejo v15 LTS를 단일 Intel NUC에서 돌림 - 일부 저장소는 이미 이전했고, 나머지도 순차 이전 후 GitHub 공개 저장소는 아카이브로 돌릴 계획임 - GitHub 저장소는 삭제가 아니라 README에서 새 위치를 가리키는 발견 경로로 남기는 방식 - GitHub 장애가 많아진 건 맞지만, 글쓴이는 그 자체가 핵심 이유는 아니라고 봄 - 2025년 5월부터 2026년 4월까지 GitHub는 인시던트 257건, 대형 장애 48건, 총 다운타임 약 112시간을 기록함 - 2026년 4월 23일에는 merge queue의 squash-merge 경로 문제로 658개 저장소와 2,092개 풀 리퀘스트에서 이미 병합된 커밋이 되돌아가는 사고가 났음 - 4일 뒤에는 Elasticsearch 클러스터 과부하로 Pull Requests, Issues, Packages가 6시간 넘게 내려감 > [!IMPORTANT] > GitHub CTO는 2026년 4월 28일 공개 사과에서 AI 기반 워크플로 증가 때문에 용량을 30배까지 키워야 한다고 말했음. 장애는 단순 운영 실수가 아니라 GitHub가 AI 플랫폼으로 재편되는 과정의 증상이라는 게 글쓴이의 해석임. - 더 큰 변화는 GitHub가 더 이상 독립적인 GitHub가 아니라는 점임 - 2025년 8월 11일 Thomas Dohmke가 CEO에서 물러났고, Microsoft는 후임 GitHub CEO를 세우지 않음 - GitHub는 Microsoft의 CoreAI 조직 안으로 들어갔고, 이 조직은 Copilot과 AI 스택을 만드는 그룹임 - 예전에는 “Microsoft가 GitHub를 어느 정도 독립적으로 둔다”는 논리가 통했지만, 글쓴이는 2025년 이후 그 전제가 깨졌다고 봄 ## Copilot 학습 데이터 기본값이 바뀐 게 결정타 - 2026년 4월 24일부터 Copilot Free, Pro, Pro+ 사용자의 상호작용 데이터가 기본적으로 AI 학습에 쓰이게 바뀜 - 대상 데이터는 입력, 출력, 코드 조각, 관련 컨텍스트임 - 사용자가 직접 설정에서 꺼야 하는 opt-out 구조고, 처음부터 동의해야 켜지는 opt-in이 아님 - Copilot Business와 Copilot Enterprise는 별도 데이터 보호 계약 때문에 제외됨. 즉 충분히 돈을 내면 학습 데이터가 아니고, 아니면 기본적으로 학습 재료가 되는 구조임 - 저장소 관리자가 막을 수 없다는 점이 꽤 뼈아픔 - 저장소 단위로 “이 repo 안의 Copilot 상호작용은 학습에 쓰지 마”라고 설정할 방법이 없음 - 각 기여자가 자기 계정에서 꺼야 하므로, 누군가 Copilot Free, Pro, Pro+로 기여하면 그 상호작용은 학습 대상이 될 수 있음 - 비공개 저장소의 “저장된 코드 자체”는 학습에 쓰지 않는다고 하지만, 편집 중 생기는 코드 조각과 컨텍스트는 수집될 수 있어 경계가 흐릿함 - 글쓴이의 결론은 꽤 단순함: GitHub의 전략적 관심사는 이제 코드 호스팅이 아니라 개발자 상호작용 데이터까지 포함함 - 이게 옳고 그름의 논쟁이기 전에, 자기 코드베이스를 남의 AI 플랫폼 위에 계속 올려둘지의 문제라는 것 - 그래서 “이 전략에 반대한다”보다 “그 플랫폼 위에 있지 않겠다”를 선택함 ## 미국 관할권 문제는 데이터 위치만으로 안 끝남 - GitHub와 Microsoft는 미국 회사라서 FISA Section 702와 CLOUD Act의 영향권에 있음 - FISA Section 702는 미국 외 인물에 대한 정보 수집을 미국 전자통신 서비스 제공자를 통해 가능하게 함 - CLOUD Act는 미국 본사의 통제를 받는 회사에 대해, 데이터가 세계 어디 있든 제출을 요구할 수 있게 함 - GitHub Enterprise Cloud의 EU 데이터 레지던시는 데이터 위치 문제를 줄일 수는 있어도 관할권 문제를 없애진 못함 - 이 부분은 Microsoft 측 발언이 오히려 제일 솔직했음 - 2025년 6월 프랑스 상원 청문회에서 Microsoft 변호사는 유럽 Microsoft 데이터센터의 프랑스 데이터가 미국 정부의 비공개 접근에서 안전하다고 보장할 수 없다고 증언함 - 글쓴이는 “프랑크푸르트에 호스팅한다”가 곧 GDPR 관점의 완전한 안전을 뜻하진 않는다고 봄 ## 네덜란드 정부도 비슷한 결론을 내림 - 2026년 4월 27일 네덜란드 내무부는 `code.overheid.nl`을 소프트 런칭함 - 네덜란드 정부 소스코드를 공개하기 위한 자체 호스팅 Forgejo 인스턴스임 - 배경에는 2020년부터 적용된 “Open, tenzij” 정책이 있음. 공공 예산으로 개발한 소프트웨어는 보안이나 기밀 문제가 없으면 기본적으로 오픈소스로 공개한다는 원칙임 - 프로젝트 매니저 Boris Van Hoytema는 정부가 실제로 소유한 장소에 소스코드를 합법적으로 공개해야 했다고 설명함 - 흥미로운 건 GitLab이 아니라 Forgejo를 골랐다는 점임 - 유럽위원회의 `code.europa.eu`와 독일의 openCode는 자체 호스팅 GitLab 기반임 - 네덜란드 정부는 Forgejo가 완전 오픈소스이고, 오픈코어로 기능이 유료 티어 뒤에 숨겨지지 않는다는 점을 봄 - Forgejo의 로드맵이 디지털 자율성 목표와 더 잘 맞는다고 판단함 - 글쓴이는 이 선택이 개인의 괴짜 같은 탈GitHub가 아니라 제도권에서도 진지하게 검토되는 흐름이라고 봄 - 정부 기관이 법무 검토와 장기 운영을 고려한 뒤 비슷한 결론을 냈다는 점이 중요함 - 이게 무조건 정답이라는 뜻은 아니지만, 적어도 주변부 선택은 아니라는 얘기임 ## Forgejo를 고른 이유: 라이선스와 거버넌스 - GitLab도 진지하게 검토했지만, open-core 모델이 걸렸다고 함 - GitLab Community Edition은 MIT 라이선스지만, 운영에서 탐나는 기능 상당수는 Enterprise 티어에 있음 - Forgejo는 2024년 8월 v9.0부터 GPLv3+로 재라이선스하며 상업적 포획을 막겠다는 방향을 분명히 함 - Forgejo가 2022년 12월 Gitea에서 갈라진 것도 상표와 도메인 통제권을 둘러싼 커뮤니티 동의 문제 때문이었음 - 거버넌스도 개인 개발자가 보기엔 설득력 있는 구조임 - Forgejo는 2018년 9월 베를린에 등록된 비영리 단체 Codeberg e.V. 아래에 있음 - Codeberg 호스팅 인스턴스에는 30만 개 이상의 저장소가 있음 - 2025년 예산안은 찬성 88, 반대 0, 기권 1로 통과됨. 그냥 “커뮤니티 중심”이라고 말만 하는 수준은 아니라는 것 - 다만 Forgejo 생태계가 GitHub나 GitLab만큼 두껍진 않음 - Forgejo v15.0 LTS는 2026년 4월 16일에 나왔고, 2027년 7월 15일까지 장기 지원됨 - Actions는 ephemeral runner, OpenID Connect, reusable workflow expansion 등 글쓴이가 필요로 한 수준까지 올라왔다고 봄 - 하지만 상용 지원은 아직 얇고, Swiss 호스팅 관리형 Forgejo인 Codey도 월 19 CHF부터 시작하는 정도임 - 24시간 전화 지원과 엔터프라이즈 벤더 책임 소재가 필요하면 아직 기다려야 할 수 있음 ## 진짜 위험 구간은 forge가 아니라 CI 러너임 - 글쓴이가 만든 구성은 생각보다 작음 - Intel NUC 한 대, RAM 64GB - Docker 안에 Forgejo v15 LTS, Postgres 17, Traefik - 옆에는 Incus가 관리하는 KVM 가상 머신이 있고, 그 안에서 Forgejo Actions 러너를 실행함 - 보안상 까다로운 부분은 Git 저장소 웹앱이 아니라 CI 작업을 실행하는 러너임 - Renovate가 매일 `npm install`, `composer install`, `pip install`을 돌림 - 이 과정에서 lifecycle script가 실행되고, 의존성 공급망 공격과 같은 형태의 위험 코드가 들어올 수 있음 - 글쓴이는 러너의 역할을 “코드를 실행하는 것”이 아니라 “코드가 실행되는 동안 가두는 것”으로 봄 > [!WARNING] > 자체 호스팅 Git forge에서 제일 무서운 건 로그인 화면보다 CI 러너임. 러너가 의존성 설치 스크립트를 실행한다면, 그건 사실상 외부 코드를 주기적으로 받아 실행하는 시스템임. - 그래서 러너 방어를 다섯 겹으로 쌓음 - 러너는 호스트 컨테이너가 아니라 별도 KVM 가상 머신 안에서 실행됨. 작업 환경과 NUC 호스트가 커널을 공유하지 않음 - 그 VM 안의 Docker 기본 런타임은 gVisor의 `runsc`로 설정됨. 컨테이너 탈출이 바로 호스트 커널 접근으로 이어지지 않게 함 - 매주 월요일 02:00 UTC에 VM을 통째로 파괴하고 새 Ubuntu 베이스 이미지에서 재생성함 - 베이스 이미지는 일요일마다 다시 빌드되므로, 새 VM은 그 주의 apt와 커널 패치를 반영함 - nftables egress 필터로 러너가 443, 80, 22, 53 포트의 공용 목적지에는 나가되 `192.168.0.0/16`, `10.0.0.0/8`, `172.16.0.0/12` 같은 LAN 대역에는 접근하지 못하게 함 - 러너 토큰은 admin 권한이 아니라 사용자 또는 조직 범위에 묶인 제한된 토큰임 ```mermaid sequenceDiagram participant 기여자 participant Forgejo participant 러너관리자 participant KVM러너 participant 외부패키지저장소 기여자->>Forgejo: 코드 푸시 또는 풀 리퀘스트 생성 Forgejo->>KVM러너: Actions 작업 할당 KVM러너->>외부패키지저장소: npm, pip, composer 의존성 요청 외부패키지저장소-->>KVM러너: 패키지와 스크립트 반환 KVM러너->>KVM러너: gVisor 컨테이너 안에서 작업 실행 러너관리자->>KVM러너: 매주 VM 파괴 후 재생성 KVM러너-->>Forgejo: 빌드 결과 보고 ``` ## 그래도 잃는 게 있음 - GitHub의 발견성과 소셜 그래프는 쉽게 대체되지 않음 - 사람들이 작은 패치를 보낼 때 기대하는 장소는 여전히 `github.com`임 - 글쓴이는 공개 저장소를 아카이브하고 README로 새 위치를 안내해 발견 경로를 유지하려고 함 - 하지만 이전이 끝나기 전까지는 마찰이 있는 게 사실임 - GitHub Actions 호환성도 완벽하지 않음 - Forgejo Actions는 익숙함을 목표로 하지만 GitHub Actions와 완전 호환은 아님 - workflow 수준의 `permissions` 블록은 조용히 무시됨 - `actions/checkout@v6`은 2026년 초 non-GitHub 러너에서 인증 checkout이 깨져서 v5로 고정함 - `actions/upload-artifact@v4`는 Forgejo 호스팅 포크가 필요함 - OIDC도 GitHub의 `permissions: id-token: write`가 아니라 `enable-openid-connect: true` 키를 씀 - Dependabot도 없음 - 글쓴이는 같은 자체 호스팅 러너에서 Renovate를 3시간 주기로 돌림 - 같은 일을 할 수는 있지만 설정이 더 많고, 구성에 하루가 걸렸다고 함 - 팀 상황에 따라 안 옮기는 게 맞을 수도 있음 - 인프라 운영 의지가 전혀 없는 팀이면 자체 호스팅은 피곤한 선택임 - GitHub Apps, Codespaces, Copilot Workspace, Advanced Security에 깊게 묶여 있으면 Forgejo는 대체재라기보다 별도 마이그레이션 프로젝트임 - 기여자 유입이 GitHub 네트워크에 강하게 의존한다면 소유권보다 발견성이 더 중요할 수 있음 - 무엇보다 CI 러너 격리 설계를 감당할 생각이 없다면, 자체 러너를 굴리는 건 꽤 위험한 선택임 --- ## 기술 맥락 - 여기서 핵심 선택은 “Git 저장소를 어디에 둘 것인가”가 아니라 “코드 호스팅, AI 학습 데이터, CI 실행 권한을 누가 통제하느냐”예요. GitHub는 편하지만 Microsoft CoreAI 조직 안으로 들어간 뒤 Copilot 데이터 정책까지 바뀌면서, 단순 SaaS가 아니라 AI 플랫폼의 입력면이 됐거든요. - Forgejo를 고른 이유는 기능표만 보면 설명이 부족해요. GitLab은 더 큰 생태계와 더 polished한 UI가 있지만 open-core라서 운영에 필요한 기능이 상용 티어 뒤에 있을 수 있어요. 반대로 Forgejo는 GPLv3+와 Codeberg e.V. 거버넌스 덕분에 장기적으로 코드베이스를 누가 통제하는지가 더 명확해요. - CI 러너를 KVM, gVisor, nftables, 주간 재빌드로 감싼 것도 과한 취미 세팅이 아니에요. Renovate나 dependency bot이 `npm install` 같은 명령을 주기적으로 실행하면, 러너는 외부 패키지의 lifecycle script를 실행하는 시스템이 돼요. 그래서 러너를 신뢰하는 게 아니라 격리하고, 오래 살아남는 상태를 줄이는 쪽으로 설계한 거예요. - 이 접근은 개인 NUC 한 대에서도 가능하지만, 조직 규모가 커질수록 운영 책임이 커져요. GitHub Enterprise의 SLA와 지원 채널을 버리는 대신, 장애 대응과 러너 보안을 직접 가져오는 선택이기 때문이에요. 그래서 이 글은 “다 Forgejo로 가자”보다 “소유권을 원하면 어디까지 책임질 건지 계산하자”에 가까워요. ## 핵심 포인트 - GitHub는 2025년 5월부터 2026년 4월까지 257건의 인시던트와 48건의 대형 장애를 기록했다 - GitHub는 2025년 8월 이후 독립 CEO 없이 Microsoft CoreAI 조직에 흡수됐다 - 2026년 4월부터 Copilot Free, Pro, Pro+ 상호작용 데이터가 기본적으로 AI 학습에 쓰이도록 바뀌었다 - 네덜란드 정부는 완전한 오픈소스와 디지털 자율성을 이유로 GitLab 대신 Forgejo를 골랐다 - 글쓴이는 단일 NUC에 Forgejo v15 LTS, Postgres 17, Traefik, KVM 격리 Actions 러너를 구성했다 ## 인사이트 이 글의 포인트는 ‘GitHub가 싫다’가 아니라, 소스코드 호스팅이 이제 개발 도구를 넘어 AI 학습 데이터, 법적 관할권, CI 실행 보안까지 얽힌 인프라가 됐다는 거다. 개인 개발자한테도 꽤 빡센 운영 주제지만, 조직이라면 더 이상 감으로 넘기기 어려운 질문이 됐다.