GHES 이전 중에도 개발은 계속된다…중단은 cutover에 집중된다

GitHub가 2026년 9월 1일 Enterprise Live Migrations(ELM)를 정식 출시했다. releases.sh의 9월 1일 릴리스 기록 은 GHES 저장소를 데이터 레지던시를 지원하는 GitHub Enterprise Cloud로 옮기는 기능이 정식 제공 상태가 됐음을 확인한다.

ELM은 초기 데이터를 복사하는 동안에도 소스 저장소의 변경분을 계속 수집한다. 개발자는 이전 과정 대부분에서 작업을 이어갈 수 있고, 실제 접근 제한은 소스 저장소를 읽기 전용으로 전환해 마지막 변경분을 보내는 cutover 구간에 집중된다. 다만 이는 접근 제한이 전혀 없는 ‘완전한 무중단’을 뜻하지 않는다.

백필과 개발 중단 시간을 분리한다

ELM의 핵심은 저장소 전체를 복사하는 시간과 개발자가 쓰기를 멈추는 시간을 분리하는 데 있다. GitHub의 ELM 작동 방식 문서 는 과정을 생성, 사전 점검, 백필, cutover, 완료, 후속 작업의 여섯 단계로 구분한다. 백필 단계에서는 기존 저장소 데이터를 수집해 대상으로 보내면서 웹훅으로 새 커밋과 설정 변경을 확인한다.

cutover가 시작되면 소스 저장소는 보관 상태로 바뀌어 읽기 전용이 되고, 아직 전송되지 않은 변경분이 대상에 반영된다. 이 구간이 개발자에게 발생하는 중단 시간이다. 따라서 운영팀은 전체 백필 시간을 유지보수 창으로 잡을 필요는 없지만, cutover와 완료 검증을 위한 통제된 쓰기 중단 구간은 마련해야 한다.

백필 도중에도 진행 상태와 저장소 리소스별 실패를 확인할 수 있어 cutover 여부를 결정할 근거가 생긴다. 깊은 Git 이력, 많은 이슈와 풀 리퀘스트, 지속적인 커밋 때문에 장시간 동결하기 어려운 대형 모노리포지토리가 ELM의 주된 대상이다. 반대로 이전 중 force push처럼 이력 구조를 바꾸는 작업은 동기화를 방해할 수 있으므로 일반적인 개발 활동과 동일하게 취급해서는 안 된다.

지원 패치는 발표 기준과 최신 운영 문서를 함께 봐야 한다

GitHub의 정식 출시 공지 가 제시한 최소 버전은 GHES 3.17.18, 3.18.12, 3.19.9, 3.20.3, 3.21.3, 3.22.0이며 각 버전 계열에서 해당 패치 이상이어야 한다. 같은 3.20 계열이라도 3.20.2는 이 발표 기준을 충족하지 않는다.

다만 현재 준비 문서가 예시로 드는 3.20 계열의 최소 패치는 공지보다 높은 3.20.5다. 이는 공지와 운영 문서가 서로 다른 시점의 패치 기준을 보여주는 경우이므로, 실제 실행에는 더 최신인 준비 문서와 사용 중인 GHES 계열의 최신 패치 릴리스 기준을 적용하는 편이 안전하다. 3.22 계열도 정식 출시 공지에는 포함되지만 준비 문서의 버전 표에는 아직 나타나지 않으므로 실행 전 해당 계열 문서를 다시 확인해야 한다.

목적지도 모든 GitHub Enterprise Cloud 환경으로 넓어진 것은 아니다. 확인된 경로는 GHES에서 데이터 레지던시를 지원하는 GHE.com 엔터프라이즈로의 저장소 이전이다. 소스 인스턴스는 HTTPS를 사용하고 대상 방향의 아웃바운드 통신을 허용해야 하며, 관리 콘솔에서 마이그레이션 기능도 활성화해야 한다.

ELM과 GitHub Enterprise Importer는 저장소별로 고른다

ELM은 GitHub Enterprise Importer(GEI)의 새 이름이나 일괄 대체품이 아니라 별도의 이전 도구다. 두 도구 모두 GHES 저장소를 GHE.com으로 옮길 수 있지만, GEI는 이전이 진행되는 동안 개발자가 저장소에 접근할 수 없는 반면 ELM은 백필 중 소스 작업을 허용한다. 중단 허용 시간이 선택 기준이 되는 이유다.

짧고 계획된 중단을 받아들일 수 있는 일반적인 저장소에는 GEI가 더 단순할 수 있다. 장시간 동결이 어려운 대형 또는 고활동 저장소에는 변경분을 계속 동기화하는 ELM이 더 적합하다. GitHub는 같은 플랫폼 이전 프로그램에서 두 도구를 병행할 수 있다고 설명하므로, 모든 저장소를 한 경로에 넣을 필요는 없다.

운영팀은 저장소의 명목상 중요도만으로 도구를 정하기보다 데이터 규모, Git 이력의 깊이, 평상시 쓰기 활동, 허용 가능한 중단 시간과 기존 도구의 처리 가능 여부를 함께 봐야 한다. ELM을 선택해도 cutover 승인과 대상 저장소 검증은 사라지지 않는다. 달라지는 것은 긴 복사 과정 전체가 아니라 마지막 전환 단계에 쓰기 중단을 모을 수 있다는 점이다.

저장소는 한 건씩, 동시 실행은 소스 10개·대상 20개까지다

ELM 이전 한 건에는 저장소 하나만 포함된다. 조직 설정, 팀, 프로젝트 같은 조직 수준 데이터는 자동으로 넘어가지 않으며 대상 엔터프라이즈에서 수동으로 다시 구성해야 한다. 저장소 복사가 완료됐다는 상태만으로 권한 구조와 프로젝트 운영 환경까지 복원됐다고 판단해서는 안 된다.

동시 실행 한도는 단일 GHES 인스턴스에서 저장소 10개, 하나의 대상 엔터프라이즈에서 20개다. 여러 GHES 인스턴스가 같은 GHE.com 엔터프라이즈로 이동한다면 각 소스의 한도뿐 아니라 대상 전체의 20개 한도를 함께 계산해야 한다. 대규모 이전은 결국 저장소 단위의 여러 차수로 나눠야 한다.

이 한도는 GEI와의 병행 전략에도 영향을 준다. 긴 중단을 허용하기 어려운 저장소를 ELM 동시 실행 슬롯에 우선 배치하고, 별도의 유지보수 창을 확보할 수 있는 저장소는 GEI로 분리할 수 있다. 이는 도구의 처리 방식에 따른 운영 선택이며 ELM이 모든 저장소에 항상 우월하다는 의미는 아니다.

실제 순서는 사전 점검에서 수동 재구성까지 이어진다

첫 단계는 저장소별 이전 도구를 정하고 소스 GHES의 정확한 패치, GHE.com 대상, 네트워크 조건을 확인하는 것이다. 실행자는 GHES 사이트 관리자 권한과 대상 엔터프라이즈 권한을 갖추고 양쪽에 접근할 수 있는 개인용 액세스 토큰을 준비해야 한다. ELM 수명주기는 GitHub CLI의 gh elm 확장 기능으로 관리한다.

이전을 생성하면 사전 점검에서 매개변수, 토큰, 네트워크 연결과 저장소 구성을 검사한다. 점검을 통과한 뒤 백필을 시작하며, 이 기간에는 개발을 계속하면서 진행 상태와 리소스별 실패를 확인한다. 운영팀은 남은 오류와 동기화 상태를 근거로 cutover에 들어갈 시점을 결정해야 한다.

cutover를 시작하기 전에는 소스가 읽기 전용으로 바뀌는 시점과 새 작업을 대상 저장소에서 재개할 시점을 개발팀에 알려야 한다. 마지막 변경분 전송과 완료 상태를 확인한 뒤 대상 데이터를 검증하고, 조직 소유자가 설정·팀·프로젝트를 다시 구성한다. 사용자 활동을 올바른 계정에 귀속하는 작업도 완료 후 단계에 남는다.

현재 확정된 범위는 지원되는 GHES 패치에서 GHE.com으로 옮기는 저장소 단위 이전이다. ELM은 개발을 백필 전체에서 멈추게 하는 대신 중단을 cutover에 집중하지만, 조직 데이터 재구성과 검증 작업까지 없애지는 않는다. GitHub는 추가 이전 경로 확대 계획을 밝혔으나 구체적인 대상과 일정은 제시하지 않았다.