무슨 일이 있었냐면
스트리밍 기기와 TV 플랫폼으로 유명한 Roku가 개발자 블로그에 개발자용 저장소를 GitHub에서 GitLab으로 옮겼다고 공지했어요. Roku 채널(앱)을 만들 때 참고하는 샘플 코드와 개발 도구들을 이제 GitLab에서 관리한다는 뜻이에요.
'저장소 위치 하나 바뀐 게 뭐 대수야?' 싶을 수 있는데, 생각보다 의미가 있어요. 오픈소스와 개발자 생태계에서 GitHub은 거의 '기본값'이잖아요. 큰 기업이 공개 개발자 저장소를 GitHub 밖으로 옮기는 일은 흔하지 않거든요. 게다가 최근 몇 년 사이 GitHub 대신 다른 곳을 찾는 프로젝트가 하나둘 늘고 있어서, 이번 이전도 그 흐름 속에서 볼 만해요.
Roku 개발 생태계를 잠깐 짚고 가면
Roku 앱은 BrightScript라는 Roku 전용 스크립트 언어와 SceneGraph라는 XML 기반 UI 프레임워크로 만들어요. 한국에서는 좀 생소하지만, 북미에서는 스마트 TV와 스트리밍 플랫폼 점유율이 높아서 OTT 서비스를 해외에 내보내려면 거의 꼭 거쳐야 하는 플랫폼이에요. 그래서 공식 샘플 저장소는 Roku 개발자들한테 사실상 교과서 같은 존재고요. 이걸 북마크하거나 클론해서 쓰던 개발자라면 이제 새 주소로 갈아타야 해요.
기업은 왜 GitHub을 떠날까
Roku가 구체적으로 어떤 이유를 들었는지는 원문 공지에서 확인하는 게 가장 정확해요. 일반적으로 기업이 이런 결정을 내리는 이유는 몇 가지로 나눌 수 있어요.
첫째는 사내 도구와 맞추기 위해서예요. 회사 안에서 이미 GitLab으로 코드와 CI/CD를 관리하고 있다면, 공개 저장소만 GitHub에 따로 두는 건 관리할 곳이 두 군데로 늘어나는 셈이거든요.
둘째는 플랫폼 방향에 대한 고민이에요. GitHub은 2025년에 마이크로소프트의 AI 조직 쪽으로 편입되면서 Copilot과 AI 기능 쪽으로 방향을 크게 틀었어요. 이걸 반기지 않는 프로젝트도 있는데, 실제로 Zig 프로그래밍 언어 프로젝트는 2025년 말 비영리 호스팅 서비스인 Codeberg로 옮기면서 GitHub Actions 품질 문제와 AI 위주 행보에 대한 불만을 공개적으로 밝혔죠.
셋째는 벤더 종속(lock-in) 줄이기예요. 이게 뭐냐면, 한 플랫폼에 이슈, CI, 패키지, 문서까지 몽땅 기대고 있으면 그 플랫폼의 정책이나 가격이 바뀔 때 빠져나오기 어려워지는 상황을 말해요.
GitHub vs GitLab, 뭐가 다르냐면
둘 다 Git 저장소를 호스팅하지만 성격은 꽤 달라요. GitHub의 가장 큰 무기는 네트워크 효과예요. 거의 모든 개발자가 이미 계정을 갖고 있고, 스타, 포크, PR 문화가 자리 잡혀 있어서 외부 기여를 받기가 쉬워요.
GitLab은 올인원 DevOps 플랫폼을 지향해요. CI/CD, 컨테이너 레지스트리, 이슈 보드, 보안 스캔까지 한곳에 묶었고, 무엇보다 회사 서버에 직접 설치해서 쓰는 셀프 호스팅이 강점이에요. 그래서 GNOME, KDE, freedesktop.org, 데비안(Salsa) 같은 대형 오픈소스 커뮤니티도 GitLab을 쓰고 있어요.
물론 옮기는 데는 비용이 들어요. 그동안 쌓은 스타와 팔로워는 따라오지 않고, GitHub은 외부 사이트로 자동 리다이렉트를 해주지 않아서 옛 링크가 끊길 수 있어요. GitHub Actions로 짜둔 워크플로도 .gitlab-ci.yml 형식으로 다시 써야 하고요. 그래서 보통은 기존 GitHub 저장소를 보관(archive) 처리하고 README에 새 주소를 적어두는 방식을 많이 써요.
한국 개발자에게 주는 시사점
Roku 샘플을 쓰고 있다면 당장 할 일은 간단해요. 로컬 저장소에서 git remote set-url origin <새 GitLab 주소>로 원격 주소를 바꾸세요. 그다음 서브모듈, 패키지 의존성, CI 스크립트에 GitHub 주소가 하드코딩돼 있지 않은지도 점검하고요.
좀 더 넓게 보면, 한국 회사들은 사내에 GitLab을 직접 설치해서 쓰는 경우가 정말 많아요. GitHub만 익숙한 주니어라면 GitLab CI의 파이프라인 문법이나 머지 리퀘스트(MR) 흐름을 한 번쯤 익혀두세요. 이직하거나 다른 팀과 협업할 때 바로 써먹을 수 있어요. 그리고 어떤 플랫폼을 쓰든, 빌드와 배포 로직을 플랫폼 전용 YAML에 몽땅 넣기보다 Makefile이나 셸 스크립트로 빼두면 나중에 옮길 때 훨씬 편해요. 중요한 저장소는 다른 호스팅에 미러링해 두는 것도 좋은 보험이고요.
마무리
한 줄로 정리하면, Roku의 이전은 'GitHub이 곧 기본값'이라는 공식이 조금씩 흔들린다는 신호이면서, 플랫폼 종속을 줄이는 습관이 왜 중요한지 보여주는 사례예요.
여러분 팀은 어떤 코드 호스팅을 쓰고 있나요? GitHub에서 다른 곳으로 옮겨야 할 일이 생긴다면, 가장 아쉬울 것과 가장 걱정되는 건 뭔가요?
🔗 출처: Hacker News