GitLab에서 GitHub로 옮기는 공식 경로 확대: Enterprise Importer가 바꾸는 마이그레이션

GitHub는 2026년 8월 3일 GitHub Enterprise Importer(GEI)가 GitLab.com과 GitLab 자체 호스팅 인스턴스의 저장소를 GitHub Enterprise Cloud로 옮기는 경로를 지원한다고 발표했다. 조직 전체를 한 번에 복제하는 기능이 아니라, 저장소 데이터와 사용자 연결을 공식 도구로 이전하는 기능의 확대다.

무엇이 바뀌었나

지원 대상은 GitLab.com과 네트워크로 접근할 수 있는 GitLab 자체 호스팅 인스턴스다. GitHub CLI의 GEI 확장과 마이그레이션 API를 통해 저장소를 가져오고, 이전 뒤 사용자 활동을 GitHub 계정에 연결하는 mannequin reclamation¹ 절차를 사용할 수 있다.

이번 발표는 GitLab 서버를 그대로 변환하는 범용 백업·복원 기능이 아니다. 이슈·병합 요청·브랜치·커밋 등 실제 이전 범위와 제외 항목은 GitHub가 게시한 현재 지원 표를 기준으로 확인해야 한다.

개발자에게 왜 중요한가

대규모 이전에서 가장 어려운 부분은 Git 객체 복사보다 사용자 신원, 이슈와 병합 요청의 작성자, 첨부 자료와 권한을 일관되게 옮기는 일이다. 공식 importer를 사용하면 반복 실행과 로그 수집, 사용자 매핑을 표준 절차로 묶을 수 있다.

기존 프로젝트 영향

현재 GitLab을 계속 쓰는 프로젝트에는 즉시 바뀌는 런타임이나 API가 없다. 이전을 준비하는 조직은 CI/CD, 패키지 레지스트리, 배포 키, 웹훅, 보호 브랜치 규칙을 별도 작업으로 취급해야 한다. 저장소가 옮겨졌다고 파이프라인과 외부 연동이 자동으로 같은 상태가 되는 것은 아니다.

적용 전 확인 사항

• 지원되는 GitLab 버전과 GitHub Enterprise Cloud 대상 조직의 권한 요건을 공식 문서에서 확인한다.
• 대표 저장소로 시험 이전을 수행하고 이슈·병합 요청·브랜치·릴리스·LFS 객체의 수를 원본과 대조한다.
• 사용자 매핑과 mannequin 회수 계획을 세우고 퇴사자·봇 계정의 처리 방식을 정한다.
• GitLab CI 변수, 러너, 컨테이너·패키지 레지스트리, 웹훅과 배포 키는 별도 이전 목록으로 관리한다.
• 최종 전환 창에는 쓰기 동결, 증분 확인, DNS·리모트 URL 변경과 롤백 기준을 포함한다.

출처

• GitHub Changelog — GitLab에서 GitHub로 이전
• GitHub Docs — GitHub Enterprise Importer
• GitHub Docs — GitLab 마이그레이션

¹ Mannequin reclamation: 이전 과정에서 임시 사용자로 표시된 과거 활동을 실제 GitHub 계정에 연결하는 절차.