우리는 오랫동안 깃허브(GitHub)라는 거대한 생태계 속에서 안주해 왔습니다. 전 세계 수억 명의 개발자가 사용하는 이 플랫폼은 단순한 코드 저장소를 넘어 개발자의 포트폴리오이자, 협업의 표준이며, 오픈소스의 성지였습니다. 하지만 최근 많은 개발자가 문득 불안함을 느끼기 시작했습니다. 내 코드가 기업의 AI 학습 데이터로 무단 활용되고 있다는 의구심, 플랫폼의 정책 변경 한 번에 내 프로젝트의 가시성이 결정되는 종속성, 그리고 점점 더 상업적으로 변해가는 커뮤니티의 분위기가 그 원인입니다.

코드의 소유권은 개발자에게 있지만, 그 코드가 담긴 ‘그릇’을 특정 기업이 독점하고 있을 때 발생하는 리스크는 생각보다 큽니다. 만약 내일 당장 계정이 정지되거나, 서비스 이용 약관이 나에게 불리하게 변경된다면 우리는 어떻게 대응해야 할까요? 이러한 문제의식은 자연스럽게 ‘탈중앙화’와 ‘자기 호스팅(Self-hosting)’이라는 대안으로 이어졌고, 그 중심에 코드버그(Codeberg)와 포지조(Forgejo)가 있습니다.

중앙집중형 플랫폼의 한계와 대안의 등장

깃허브는 매우 편리합니다. 하지만 그 편리함의 대가는 ‘데이터의 중앙 집중화’입니다. 마이크로소프트라는 거대 기업의 통제 아래 있는 플랫폼은 효율적이지만, 오픈소스 정신의 핵심인 ‘자율성’과 ‘독립성’과는 거리가 멉니다. 특히 최근 AI 코파일럿(Copilot)의 등장 이후, 오픈소스 라이선스를 무시한 채 코드를 학습 데이터로 사용하는 행태는 많은 개발자에게 배신감을 안겨주었습니다.

이런 상황에서 코드버그와 포지조는 단순한 ‘깃허브 복제판’이 아닌, 철학적인 대안으로 제시됩니다. 코드버그는 비영리 단체가 운영하는 플랫폼으로, 사용자 데이터의 상업적 이용을 철저히 배제합니다. 포지조는 Gitea에서 파생된 커뮤니티 주도 프로젝트로, 누구나 자신의 서버에 설치해 운영할 수 있는 완전한 제어권을 제공합니다. 이는 ‘내 코드는 내가 관리한다’는 개발자의 기본 권리를 되찾으려는 움직임입니다.

기술적 관점에서 본 전환의 득과 실

깃허브에서 코드버그나 포지조로 옮길 때 가장 먼저 고려해야 할 점은 기술적 생태계의 차이입니다. 깃허브는 GitHub Actions라는 강력한 CI/CD 도구와 방대한 마켓플레이스를 제공합니다. 반면 포지조나 코드버그는 더 가볍고 빠르며, 리소스 소모가 적다는 장점이 있습니다.

포지조의 경우, 가벼운 Go 언어로 작성되어 저사양 VPS에서도 원활하게 작동합니다. 이는 기업이 자체 인프라를 구축할 때 비용 효율성을 극대화할 수 있음을 의미합니다. 또한, 깃허브의 복잡한 UI 대신 핵심 기능에 집중한 인터페이스를 제공하여 코드 관리 본연의 목적에 충실합니다. 하지만 깃허브가 제공하는 정교한 프로젝트 관리 도구(Projects)나 이슈 트래킹의 세밀한 기능들은 다소 부족하게 느껴질 수 있습니다.

• 코드버그(Codeberg): 설치의 번거로움 없이 비영리 환경의 가치를 누리고 싶은 개발자에게 적합합니다.
• 포지조(Forgejo): 완전한 데이터 주권을 갖고 직접 인프라를 제어하고 싶은 팀이나 기업에 최적입니다.
• 깃허브(GitHub): 압도적인 네트워크 효과와 AI 통합 도구가 필수적인 상업적 프로젝트에 유리합니다.

실제 마이그레이션: 어떻게 옮겨야 하는가?

단순히 코드를 복사해서 붙여넣는 것은 마이그레이션이 아닙니다. 커밋 히스토리, 브랜치, 태그, 그리고 무엇보다 중요한 ‘이슈(Issues)’와 ‘풀 리퀘스트(PR)’ 데이터를 보존하는 것이 핵심입니다. 대부분의 대안 플랫폼은 깃허브 API를 이용한 가져오기(Import) 기능을 제공합니다.

가장 권장되는 절차는 다음과 같습니다. 먼저, 깃허브에서 프로젝트의 미러링 저장소를 생성하여 최신 상태를 유지합니다. 그 후, 포지조나 코드버그의 ‘Migrate’ 기능을 통해 깃허브 저장소 URL과 개인 액세스 토큰(PAT)을 입력합니다. 이때 단순히 Git 데이터만 가져올 것인지, 아니면 위키(Wiki)와 이슈 내역까지 모두 가져올 것인지 선택해야 합니다. 데이터 이전 후에는 로컬 저장소의 원격지(remote) 주소를 새 플랫폼으로 변경하는 작업이 필요합니다.

실제로 한 오픈소스 라이브러리 팀은 깃허브의 과도한 알림과 상업적 광고에 피로감을 느껴 포지조로 이전했습니다. 초기에는 커뮤니티 기여자들이 새로운 플랫폼에 적응하는 데 시간이 걸렸지만, 결과적으로 불필요한 기능이 제거된 환경에서 코드 리뷰 속도가 빨라졌고, 운영 주체에 대한 신뢰도가 높아지는 결과를 얻었습니다.

법적 관점과 데이터 주권의 해석

많은 기업이 깃허브를 사용하는 이유는 ‘법적 안정성’ 때문이라고 생각합니다. 하지만 역설적으로, 모든 데이터를 하나의 미국 기업 서버에 저장하는 것은 컴플라이언스 측면에서 리스크가 될 수 있습니다. 특히 유럽의 GDPR이나 한국의 개인정보보호법처럼 데이터의 물리적 위치와 처리 주체가 중요한 경우, 자체 호스팅하는 포지조는 강력한 법적 방어 수단이 됩니다.

또한, 오픈소스 라이선스 준수 여부도 중요합니다. 깃허브의 약관은 플랫폼 이용 과정에서 일정 부분의 권한을 깃허브에 부여하도록 설계되어 있습니다. 반면 코드버그와 같은 비영리 플랫폼은 이러한 권한 요구를 최소화하며, 개발자가 선택한 라이선스를 그대로 존중하는 구조를 가집니다.

실무자를 위한 플랫폼 비교 분석

결정을 돕기 위해 주요 특징을 비교해 보겠습니다.

비교 항목	GitHub	Codeberg	Forgejo (Self-hosted)
운영 주체	Microsoft (영리)	Codeberg e.V. (비영리)	사용자 본인/조직
데이터 주권	낮음 (플랫폼 종속)	중간 (비영리 신뢰)	매우 높음 (완전 제어)
CI/CD 도구	GitHub Actions (강력)	Forgejo Actions / Woodpecker	Forgejo Actions / Drone CI
리소스 요구량	없음 (SaaS)	없음 (SaaS)	낮음 (가벼운 Go 기반)

지금 당장 실행할 수 있는 액션 아이템

무작정 모든 프로젝트를 옮기는 것은 위험합니다. 단계적인 접근이 필요합니다. 지금 당장 다음의 단계를 밟아보시길 권장합니다.

첫째, ‘백업 저장소’ 구축하기입니다. 메인 프로젝트는 깃허브에 두더라도, 코드버그나 개인 포지조 서버에 미러링 저장소를 설정하십시오. 이는 플랫폼 장애나 계정 문제 발생 시 즉각적인 복구 지점을 만들어줍니다.

둘째, 사이드 프로젝트로 테스트하기입니다. 중요도가 낮은 개인 프로젝트 하나를 선정해 포지조로 완전히 이전해 보십시오. 이슈 관리, PR 프로세스, CI/CD 파이프라인을 직접 구축하며 깃허브 없이도 개발 프로세스가 원활하게 돌아가는지 검증하는 과정이 필요합니다.

셋째, 커뮤니티와 소통하기입니다. 만약 팀 프로젝트라면, 왜 대안 플랫폼이 필요한지에 대해 ‘데이터 주권’과 ‘독립성’의 관점에서 논의하십시오. 단순히 ‘새로운 툴을 써보고 싶다’가 아니라, ‘우리의 자산을 어떻게 안전하게 보호할 것인가’에 초점을 맞춰야 합니다.

결론: 도구가 아닌 철학의 선택

깃허브에서 코드버그나 포지조로 옮기는 것은 단순히 UI가 다른 툴로 바꾸는 작업이 아닙니다. 그것은 내 코드의 주인은 누구이며, 오픈소스 생태계가 어떤 방향으로 나아가야 하는지에 대한 철학적인 선택입니다. 편리함이라는 이름의 종속성에서 벗어나, 진정한 의미의 자유로운 개발 환경을 구축하는 것은 장기적으로 개발자 개인과 조직의 경쟁력을 높이는 길이 될 것입니다.

물론 깃허브의 네트워크 효과는 여전히 강력합니다. 하지만 대안이 존재한다는 사실, 그리고 그 대안이 충분히 성숙했다는 사실만으로도 우리는 더 이상 하나의 플랫폼에 모든 것을 걸 필요가 없습니다. 이제 당신의 코드를 어디에 담을지, 그 결정권을 다시 가져올 때입니다.