# GitHub에서 Codeberg로: 나의 경험 > Clean Markdown view of GeekNews topic #24756. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24756](https://news.hada.io/topic?id=24756) - GeekNews Markdown: [https://news.hada.io/topic/24756.md](https://news.hada.io/topic/24756.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-02T00:33:40+09:00 - Updated: 2025-12-02T00:33:40+09:00 - Original source: [eldred.fr](https://eldred.fr/blog/forge-migration/) - Points: 3 - Comments: 1 ## Topic Body - 개인 프로젝트와 웹사이트를 **GitHub에서 Codeberg로 이전한 과정과 결과**를 구체적으로 설명 - **Forgejo의 “migrate from GitHub” 기능**을 이용해 저장소, 이슈, PR, 위키, 릴리스를 완전하게 이전 - **링크 재지정과 GitHub 저장소 스텁 처리**를 자동화 스크립트로 수행해 이전 사실을 명확히 표시 - **CI/CD 이전**에서는 Codeberg의 **Forgejo Actions**를 활용하고, 환경 제약에 맞춰 경량화된 워크플로를 구성 - **웹사이트는 git-pages와 Grebedoc**을 이용해 무중단으로 이전, 전체 마이그레이션을 주말 내 완료 --- ### 마이그레이션 개요 - GitHub Pages에서 호스팅하던 사이트와 45개의 저장소를 **Codeberg로 이전** - 단순 클릭으로 끝나지 않고 여러 단계의 수작업이 필요했음 - 전체 과정은 주말 동안 완료되었으며, 불편함 없이 진행됨 - 이 과정을 통해 **다른 개발자들도 쉽게 이전할 수 있음**을 보여주려는 목적 ### 1단계: 저장소 이전 - Codeberg는 **Forgejo 기반**으로, “migrate from GitHub” 기능을 제공 - GitHub에서 **Personal Access Token(PAT)** 을 생성해 이슈 등 메타데이터를 함께 가져올 수 있음 - GitHub API의 **rate limit** 때문에 동시에 여러 저장소를 가져오면 실패할 수 있었음 - 이슈, PR, 위키, 릴리스가 완벽히 이전되어 **GitHub 참조가 불필요**해짐 ### 2단계: 링크 재지정 - 로컬 저장소 내의 GitHub 링크를 **Codeberg 주소로 일괄 변환** - `sed`와 `find` 명령어를 이용해 텍스트 기반으로 자동 치환 - 각 저장소의 `git remote` URL도 Codeberg로 변경 후 **모든 저장소에 푸시** ### 3단계: GitHub 저장소 스텁 처리 - GitHub 저장소에 **이전 공지용 README**를 추가하고, 설명과 홈페이지 링크를 Codeberg로 수정 - 자동화 스크립트를 작성해 여러 저장소에 일괄 적용 - `gh repo archive` 명령으로 저장소를 아카이브 처리 ### 4단계: CI/CD 이전 - Codeberg의 CI 문서에서 **에너지 소비 최소화 원칙**을 강조 - 이에 따라 CI가 꼭 필요한 프로젝트(웹사이트, 문서 빌드 등)만 유지 - Codeberg는 **Woodpecker**와 **Forgejo Actions** 두 가지 CI를 제공 - GitHub Actions와 유사한 Forgejo Actions를 선택 - 주요 차이점 - 대부분의 Actions가 그대로 작동 - **Linux 전용 러너**만 제공, macOS·Windows는 비제공 - 설치된 소프트웨어가 적고 자원이 제한적 - **lazy runners**를 사용하면 부하 분산과 친환경적 실행 가능 - CI 성능 향상을 위해 **LaTeX 사전 설치 Docker 이미지**를 사용했으나 버전 문제로 기본 Ubuntu 이미지로 복귀 ### 5단계: 웹사이트 재호스팅 - GitHub Pages에서 운영하던 사이트를 **Codeberg Pages**로 옮기려 했으나, 해당 기능이 **유지보수 모드** 상태 - 복잡성과 성능 문제로 업데이트가 지연 중 - 대안으로 **git-pages와 Grebedoc**을 발견해 사용 - **DNS 변경 전 업로드 지원**으로 무중단 전환 가능 - **서버 측 리디렉션**과 **커스텀 헤더** 지원 - 기존 링크(`eldred.fr/fortISSimO`)를 유지하면서 이전 완료 - Codeberg는 향후 **git-pages로 점진적 이전**을 계획 중 - GitHub Pages보다 만족도가 높아 **git-pages 개발자 Patreon 후원** 참여 ### 시간 소요 - 저장소 이전(1~3단계): 반나절 - CI 이전(4단계): 반나절 - 웹사이트 이전(5단계): 기술 부채 정리 포함 며칠 소요 - 전체적으로 **주말 내 완료**, 예상보다 간단한 작업 ### 마이그레이션 이후 - 웹사이트 기능 이상 없음, GitHub의 **master 브랜치만 축소** - 영구 링크(permalink)는 여전히 작동 - GitHub 저장소 삭제는 리디렉션 부재로 **보류 중** - GitHub 계정은 타 프로젝트 기여를 위해 유지 - Codeberg로 옮기며 **기여자 수 감소 가능성**은 있으나, 일부 사용자가 이미 Codeberg 계정을 생성해 지속 기여 중 ### 감사 인사 - **Catherine ‘whitequark’** : git-pages 및 Grebedoc 운영 - **SERVFAIL network 팀**: DNS 제공 - **Codeberg 및 Forgejo 기여자들**: 마이그레이션 기반 제공 ## Comments ### Comment 47051 - Author: neo - Created: 2025-12-02T00:33:42+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46097829) - 이번 **마이그레이션 이야기**에서 눈에 띄는 건 기술적인 부분이 아니라, ‘기능 동등성(feature parity)’이 진짜 장애물이 아니라는 점임 Codeberg는 일상적인 워크플로우에는 충분하지만, GitHub이 쌓아온 **네트워크 효과와 관성**이 부족함 - [Tangled.org](https://tangled.org) 같은 프로젝트가 이 문제를 일부 해결하려고 함 Bluesky와 같은 프로토콜을 기반으로 해서, Git이 어디에 호스팅되든 **정체성과 연결성**이 유지되도록 설계됨 - 내가 Codeberg에서 겪은 가장 큰 불편은 **이슈 검색 기능**이 약하다는 점임 예전에 분명히 본 이슈를 다시 찾기 어려움. 성능은 최근엔 괜찮아졌지만, 수백 개의 이슈가 있는 프로젝트라면 **테스트 마이그레이션**을 먼저 해보는 게 좋음 - GitHub에는 방대한 **문서와 예시**가 있어서, 새로 합류한 사람도 쉽게 적응할 수 있음 CI/CD 같은 건 팀 전체가 알 필요는 없고, 한 명만 잘 알아도 충분함 - Codeberg는 Gitea의 포크이고, Gitea는 Gogs의 포크임 두 포크 모두 기술적 이유보다는 **철학적 이유**로 시작되었고, Gogs를 만든 Joe Chen이 큰 공을 세웠음 - 실제로는 Codeberg는 **Forgejo** 기반의 웹사이트임 Gitea는 한 개발자가 저장소 권한을 독점해서 포크된 것이고, Forgejo는 Gitea의 상표권을 되찾기 위해 만들어진 포크임 - 농담이지만, 언젠가 Codeberg 커뮤니티도 사소한 이념 차이로 **분열**될지도 모른다는 얘기도 나옴 - Codeberg와 **F-Droid**를 함께 써본 사람이 있는지 궁금함 GitHub처럼 자동으로 릴리스를 감지할 수 있는지 알고 싶음 - F-Droid는 아니지만, Codeberg 지원을 추가하는 프로젝트들이 늘고 있음 이제 **临계점(threshold effect)** 에 도달한 듯함 - 최근 며칠간 여러 프로젝트가 GitHub에서 **이탈**하는 걸 봤음 무슨 사건이나 트렌드가 있는지 궁금함 - GitHub의 **가용성 문제**, Microsoft의 **AI 강제 통합**, Azure 이전에 집중하느라 기능 개선이 뒤처진 점 등이 원인일 수 있음 - [Zig의 마이그레이션 발표](https://ziglang.org/news/migrating-from-github-to-codeberg/)가 좋은 참고가 됨 - GitHub이 **신뢰 붕괴(trust thermocline)** 현상을 겪고 있는 것 같음 오픈소스 커뮤니티의 불만이 누적되다가 한계점에 도달한 듯함 Microsoft 전반의 **AI·광고화 논란**과 Windows 10 지원 종료도 영향을 주는 듯함 관련 개념은 [이 트위터 스레드](https://threadreaderapp.com/thread/1588115310124539904.html)에서 처음 제시됨 - 개인적으로는 GitHub의 **AI 남용**이 지침 예전의 Rails 기반일 때가 더 나았던 것 같음 - 이건 일종의 **Summer of the Shark** 현상처럼 보임 실제보다 과도하게 주목받는 일시적 현상일 수도 있음 - GitHub 대안 중 **소규모 팀이나 개인 개발자**에게 적합한 게 있는지 궁금함 Codeberg는 FOSS 중심이라서 상업적 용도엔 맞지 않아 보임 - Codeberg의 기반인 **Forgejo**를 직접 호스팅할 수 있음 GitLab은 기능이 많지만 유지보수가 무거움 그 외에도 Gitea, Gogs, Phorge 등 다양한 FOSS 포지가 있음 - GitHub의 핵심은 기술이 아니라 **소셜 네트워크**임 - 나는 **sourcehut**을 선호함 GitHub UI를 복제하지 않고, 로컬처럼 빠른 **즉각적인 인터페이스**가 마음에 듦 - 특별한 이유가 없다면 GitHub을 계속 쓰는 게 합리적임 “Microsoft가 싫다”는 이유만으로 옮길 필요는 없음 - 개인용으로는 Migadu 같은 **저비용 프라이빗 호스팅**을 찾고 있었지만 마땅한 게 없었음 결국 Codeberg에 새 프로젝트를 올리고, 일부는 GCP에 **프라이빗 미러**로 유지 중임 관련해서 [Ask HN 스레드](https://news.ycombinator.com/item?id=46011054)를 올렸지만 반응은 없었음 - [eldred.fr의 블로그 글](https://eldred.fr/blog/codeberg/)을 보면 저자의 이유는 합리적이지만, 사용자 입장에서는 **체감 개선이 거의 없음** Codeberg를 써보니 - “봇이 아닌지 확인 중”이라는 **애니메이션 검증 화면**이 자주 뜸 - GitHub 로그인 버튼이 작게 숨겨져 있음 - UI는 GitHub과 거의 동일하고, README가 아래쪽에 있어서 불편함 예: [https://codeberg.org/dnkl/foot](https://codeberg.org/dnkl/foot) README를 메인 페이지로 두는 게 더 나을 듯함 - 결국 **차별화 없는 복제 전략**은 매력적이지 않음 - “봇 검증”은 [Anubis](https://anubis.techaro.lol/)라는 오픈 솔루션을 사용함 유료 버전에서는 이미지 커스터마이징도 가능함 - GitHub을 그대로 따라가는 건 **사용자 익숙함**을 위한 선택임 너무 다르게 만들면 오히려 반발이 큼 GitHub 로그인 버튼을 숨긴 건 커뮤니티 중심의 결정이며, 원하면 **PR로 제안**할 수도 있음 - 이런 문제들은 오히려 **서비스의 깊은 문제를 드러내는 신호**일 수도 있음 - 나는 GitHub의 **AI 학습 논란**과 중앙집중화에 지쳐서 Codeberg로 옮겼음 GitHub과 동일한 기능을 갖추되, **윤리적 대안**을 찾는 게 목적이었음 - GitHub에서 AI 스캔이 문제되지 않는다면, **비정치적 이유**로 옮길 필요가 있는지 궁금함 - 최근 GitHub의 **가용성 저하**가 있었지만, 불편함의 정도는 개인 판단에 달림 - Codeberg가 **무료 CI 러너**를 제공하는지 궁금함 GitHub은 연간 1억 달러 이상을 CI에 쓰는 것으로 추정됨 - Codeberg 문서([docs.codeberg.org/ci](https://docs.codeberg.org/ci/))에 따르면, 용량이 제한되어 있고 **요청 후 승인**을 받아야 함 - 개인적으로는 **Woodpecker 인스턴스**를 Codeberg와 함께 써서 잘 작동 중임 - Codeberg는 CI/CD의 **에너지 비용**을 강조함 하지만 환경 비용을 언급하는 건 오히려 사용자 참여를 꺼리게 만들 수 있음 기술자에게는 **성능 최적화 문제**로 접근하는 게 더 효과적임 - 이런 CI 인프라가 바로 GitHub의 **진입장벽(moat)** 이라고 생각함 - Codeberg가 예전에 **스팸 사건**을 “극우 혐오 캠페인”으로 과장하며 자화자찬한 걸 보고 실망했음 단순히 예방 실패를 인정했으면 됐는데, 정치적 프레임으로 포장함 관련 링크: [이슈](https://codeberg.org/Codeberg/Community/issues/1786), [HN 토론](https://news.ycombinator.com/item?id=31627061), [블로그 글](https://blog.codeberg.org/we-stay-strong-against-hate-and-hatred.html) - 이런 태도는 **과도한 자기미화**로 보임 - 하지만 인종차별적 단어를 사용한 스팸이라면, Codeberg의 대응은 정당했다고 봄 그런 이유로 존중을 잃었다면, 문제는 프로젝트가 아니라 그 시각에 있음 - 나도 한때 Codeberg로 **저장소를 옮겼다가 다시 GitHub으로 복귀**했음 GitHub의 여러 기능이 마음에 들진 않지만, Codeberg에는 **협업을 끌어당기는 힘**이 부족함 단독 유지보수자로서는 **가시성과 네트워크 효과**가 절실함