깃허브(GitHub)의 대안? 깃랩(GitLab) 미러링으로 두 마리 토끼를 잡다!

본문에서는 깃허브(GitHub)의 사회적 영향력(Social Inertia)을 활용하기 위해 깃랩(GitLab)을 주 저장소로 사용하면서 깃허브에 미러링하는 방법을 제시한다. 깃허브는 여전히 개발자 커뮤니티에서 널리 사용되므로, 깃허브를 통해 코드 가시성(Code Visibility)을 확보하고, 깃랩을 통해 데이터 격리 아키텍처(Data Isolation Architecture)를 구축하는 것이다. 이는 깃허브의 장점을 활용하면서, 깃허브의 단점(불안정성, 중앙 집중화)을 보완하는 전략이다.

저자는 깃허브(GitHub)에서 열린 PR(Pull Request)을 로컬에서 검토하고, 깃랩(GitLab)에 머지(Merge)하는 워크플로우(Workflow)를 설명한다. 구체적으로, 깃허브 CLI(Command Line Interface) 또는 Git 명령어를 사용하여 PR을 로컬 브랜치로 가져온 후, 코드 검토 및 테스트를 수행한다. 검토 후에는 로컬에서 머지하고, 깃랩에 푸시(Push)하여 깃허브의 PR을 닫는 방식이다. 이러한 방식은 깃허브의 불안정성(Unreliability) 문제를 우회하면서, 깃랩을 주 저장소로 활용할 수 있게 한다.

본문에서는 깃허브(GitHub)와 같은 중앙 집중형 코드 저장소의 문제점을 지적하며, 연합형 코드 저장소(Federated Forge)의 필요성을 강조한다. 중앙 집중형 저장소는 단일 실패 지점(Single Point of Failure)이 될 수 있으며, 특정 기업의 정책에 종속될 위험이 있다. 연합형 저장소는 여러 인스턴스에서 계정을 생성하고, 서로 통신할 수 있도록 하여 이러한 문제를 해결하고자 한다. 깃랩(GitLab)과 Forgejo가 연합형 저장소를 개발 중이며, 데이터 미저장 정책(Zero-Retention Policy)을 통해 보안을 강화할 수 있다.

댓글에서는 깃허브(GitHub)의 불안정성에 대한 불만이 제기되었다. 특히, 깃허브(GitHub)의 배포 실패 및 커밋 삭제와 같은 문제들이 언급되었다. 이는 깃허브(GitHub)를 신뢰할 수 없는 서비스(Unreliable Service)로 인식하게 만들고, 깃허브(GitHub) 의존성을 탈피하려는 움직임에 힘을 실어준다. 깃허브(GitHub)의 기술적 문제와 더불어, 마이크로소프트(Microsoft)의 코드 학습에 대한 우려도 깃허브(GitHub)를 떠나려는 이유로 제시되었다.