디지털 자율성: 개발자와 정부가 GitHub에서 Forgejo로 이동하는 이유

소스 코드를 중앙 집중식 제공업체에서 셀프 호스팅 인스턴스로 이동하려는 결정은 단순히 한 번의 서비스 중단 때문인 경우는 드뭅니다. 서비스 중단은 좌절감을 주지만, 대개 더 깊은 구조적 변화의 증상일 뿐입니다. 많은 개발자와 심지어 국가 정부에게 있어, 논의의 초점은 "is the service reliable?"에서 "내 지적 재산이 머무는 플랫폼을 실제로 누가 소유하는가?"로 옮겨갔습니다.

이러한 긴장은 최근 네덜란드 정부가 code.overheid.nl을 출시하며 정점에 달했습니다. 이는 공공 소스 코드가 국가가 실제로 통제하는 인프라에 호스팅되도록 설계된 셀프 호스팅 Forgejo 인스턴스입니다. 이러한 움직임은 "platform-as-a-service" 모델에서 주권적 인프라로 이동하며 디지털 자율성을 향해가는 성장하는 추세를 반영합니다.

독립성의 침식

수년 동안 GitHub를 계속 사용하는 것에 대한 지배적인 논거는 Microsoft가 적절한 거리를 유지하며 관리한다는 것이었습니다. 그러나 이러한 역학 관계는 2025년 8월 Thomas Dohmke가 CEO에서 물러나고 후임이 임명되지 않았을 때 근본적으로 변화했습니다. 대신, GitHub는 Microsoft의 CoreAI 부서로 흡수되었습니다.

이 재편성은 우선순위의 변화를 의미합니다: GitHub는 더 이상 단순한 코드 호스팅 장소가 아닙니다. 이제는 Copilot 및 AI 스택의 엔드 투 엔드 핵심 엔진입니다. 이러한 구조적 변화는 사용자에게 실질적인 결과를 초래합니다:

AI 학습의 기본 설정

In 2026년 4월, GitHub는 Copilot Free, Pro, Pro+ 사용자를 대상으로 사용자 상호작용 데이터를 AI 학습용으로 사용하는 설정을 'opt-out' 방식(사용자가 직접 거부해야 함)으로 변경했습니다. 결정적으로, 저장소 수준의 opt-out 기능은 없습니다. 이는 Copilot을 사용하는 기여자가 저장소와 상호작용할 경우, 메인테이너가 자신의 코드베이스가 학습 자료로 사용되는 것을 막을 수 없음을 의미합니다.

AI의 부작용으로서의 신뢰성

2026년 4월에 발생한 수백 개의 저장소에서 커밋이 조용히 되돌아가는 현상을 포함한 최근의 주요 중단 사태는, GitHub의 CTO가 "agentic AI workflow growth"로 인해 발생한 엄청난 부하 때문이라고 설명했습니다. AI를 따라잡기 위해 용량이 30배 확장되어야 할 때, 전통적인 git 운영의 안정성은 AI 생태계의 성장보다 부차적인 문제가 됩니다.

관할권의 함정

기업 정책을 넘어 법적 현실이 존재합니다. GitHub와 Microsoft는 미국에 본사를 둔 기업이므로, FISA Section 702 및 CLOUD Act의 적용을 받습니다. 이 법들은 미국 정보 기관과 법 집행 기관이 데이터의 물리적 저장 위치와 관계없이 데이터 제출을 강제할 수 있도록 허용합니다.

GitHub가 Enterprise Cloud를 위해 EU 데이터 거주성을 도입했지만, 이는 관할권 문제를 지리적 해결책으로 접근한 것입니다. 2025년 Microsoft의 자체 변호사가 프랑스 상원에서 선서 후 인정한 것처럼, 유럽 데이터 센터에 저장된 데이터도 미국의 정부 접근으로부터 안전하다는 보장을 받을 수 없습니다. 진정한 디지털 주권을 요구하는 엔체티(entities)에게 "Frankfurt에 호스팅됨"은 "현지에서 소유하고 운영함"을 대체할 수 없습니다.

왜 Forgejo인가?

대안을 찾을 때 선택지는 종종 GitLab 또는 Forgejo로 좁혀집니다. GitLab은 강력한 업계 표준이지만, 많은 중요한 프로덕션 기능이 독점적인 엔터프라이즈 티어에 묶여 있는 "open core" 모델을을 따릅니다.

Gitea의 포크인 Forgejo는 다른 길을 제시합니다:

  • True Open Source: 상업적 점유를 방지하기 위해 GPLv3+로 라이선스를 재지정했습니다.
  • Non-Profit Governance: 회원 선출 이사회와 공개 예산을 가진 독일의 Verein인 Codeberg e.V.에 의해 관리됩니다.
  • Lightweight Footprint: 필수적인 forge 경험을 제공하면서도 Intel NUC와 같은 적당한 하드웨어에서도 실행 가능합니다.

어려운 부분: CI/CD Runner의 보안

Git forge를 셀프 호스팅하는 것은 비교적 간단합니다. 하지만 CI/CD 러너에서 신뢰할 수 없는 코드를 실행하는 보안 문제는 실제적인 도전 과제입니다. 방어 가능한 러너 아키텍처는 공급망 공격이 호스트 시스템을 침해하지 못하도록 "perimeter with depth"를를 위한 설계가 필요합니다.

다층 방어 전략

lifecycle 스크립트(예: npm install) 실행의 위험을 완화하기 위해, 강화된 러너 설정은 다음과 같은 중첩된 계층을 사용해야 합니다:

  1. KVM Isolation: 호스트 커널을 공유하지 않도록 컨테이너 대신 전용 가상 머신(Virtual Machine)에서 러너를 실행합니다.
  2. gVisor Runtime: VM 내부에서 runsc를 사용하여 유저 스페이스에서 시스템 호출을 가선히하여, 작업과 커널 사이의 두 번째 격리 계층을 추가합니다.
  3. Destructive Rebuilds: 지속적인 상태나 멀웨어가 남지 않도록 매주 자동화된 방식으로 신규 이미지로부터 VM을 파괴하고 재생성합니다.
  4. Egress Filtering: nftables를 사용하여 러너가 로컬 네트워크(LAN)에 접근하는 것을 차단하여, 침해된 작업이 내부 인프라를 스캔하는 것을 방지합니다.
  5. Scope-Bound Tokens: 제한된 PAT 스코프를 사용하여 유출된 토큰이 관리자 권한으로 사용되는 것을 방지합니다.

트레이드오프와 현실

GitHub에서 벗어나는 것은 비용이 따릅니다. 가장 큰 손실은 발견 가능성과 소셜 그래프입니다. GitHub는 오픈 소스의 "town square"입니다. 개인 인스턴스로 이동하는 것은 프로젝트의 가시성을 낮출 수 있습니다.

이를 완화하기 위한 전략 중 하나는 GitHub를 미러(mirror) 또는 아카이브로 유지하는 데 있습니다. GitHub에 공개 저장소를 아카이브하고 README를 새로운 공식 홈(예: code.jorijn.com)으로 연결함으로써, 개발자들은 발견 경로를를 유지하면서 주된 개발 환경에 대한 소유권을 되찾을 수 있습니다.

결론

Forgejo와 셀프 호스팅으로의 전환은 단순한 서비스 중단에 대한 반응이 아니라, 자율성을 향한 전략적 움직임입니다. 국가 정부와 개별 개발자 모두 기업이 통제하는 플랫폼이 사용자의 주권보다 자신의 AI 로드맵을 우선시한다는 것을 깨닫게 됨에 따라, 분산형이며 소유자 운영 인프라로의 회귀는 틈새 선호도가 아닌 필연적인 필요가 됩니다.

Sources