GitLab Flow로 설계하는 안정적인 배포 브랜치 전략

배포 경로를 브랜치에 드러내는 방식

GitLab Flow는 GitHub Flow의 간결한 협업 방식에 배포 관리용 브랜치를 결합한 전략이다. 모바일 앱이나 게임처럼 배포 시기를 조절해야 하거나 버전 관리가 중요한 소프트웨어에서는, main만으로 배포 상태를 구분하기 어려울 수 있다.

기본 저장소는 main 또는 master 하나를 중심으로 유지한다. 여기에 배포 환경별 브랜치를 더해 개발 중인 코드와 실제 배포할 코드를 구분한다. 지속적 배포가 쉽지 않은 환경에서도 개발 흐름은 단순하게 가져가면서 배포 안정성을 확보하려는 구조다.

production 브랜치로 배포 대상을 분리하는 모델

가장 단순한 형태는 GitHub Flow에 production 브랜치를 추가하는 방식이다. main은 개발 기능이 모이는 통합 지점이고, production에는 실제 배포할 코드만 둔다.

⤢✕

개발자는 feature 브랜치에서 작업한 뒤 main으로 merge request를 만든다. main에서 테스트를 거쳐 안정적이라고 판단한 변경만 production에 병합한다. 이때 production 브랜치는 항상 배포 가능한 상태를 유지한다.

스테이징 검증 단계를 추가해야 할 때

추가 테스트 환경이 필요한 경우에는 main과 production 사이에 pre-production 브랜치를 둔다. 이 브랜치는 스테이징 환경에서 검증할 배포 후보를 관리하는 역할을 한다.

⤢✕

기능 변경은 feature 브랜치에서 main으로 먼저 합친다. 이후 pre-production으로 옮겨 스테이징 환경에서 테스트하고, 통과한 변경을 production으로 병합해 실제 배포한다. main은 개발 작업의 통합 지점, pre-production은 추가 검증 지점, production은 실서비스 코드의 위치가 된다.

환경마다 배포 브랜치를 두는 선택

개발·테스트·스테이징·프로덕션처럼 환경이 나뉜 조직에서는 각 환경에 대응하는 브랜치를 구성할 수 있다.

⤢✕

환경 브랜치는 각 배포 환경의 코드를 담당한다. 코드가 상위 환경으로 이동할수록 더 엄격한 검증 과정을 거치게 설계할 수 있다. 다만 모든 환경을 브랜치로 만들 필요는 없으며, 필요한 환경만 선택해야 브랜치 구조가 과도하게 복잡해지는 일을 막을 수 있다.

버전 단위로 유지하는 릴리스 흐름

모바일 앱이나 게임처럼 버전 관리가 중요한 소프트웨어는 릴리스 브랜치를 별도로 운영할 수 있다. 새 기능은 main에서 시작하고, 각 릴리스 버전에는 독립된 브랜치를 둔다.

⤢✕

버그 수정은 해당 릴리스 브랜치에서 직접 처리하고 main에도 병합한다. 이미 배포된 버전의 수정과 다음 기능 개발을 분리할 수 있다는 점이 이 방식의 핵심이다.

배포 주기에 맞춘 운영 예시

모바일 게임 회사의 경우 main에는 개발자의 feature 작업을 병합하고, staging은 QA 테스트용으로, production은 App Store와 Google Play에 배포할 코드를 관리하는 용도로 사용했다. 버전별로 1.0, 1.1 등의 릴리스 브랜치도 운영했다.

이 구조에서는 2주마다 staging에서 테스트한 뒤 production으로 배포한다. 긴급 버그는 해당 릴리스 브랜치에서 수정한 후 main으로 백포트하고, 새 기능은 feature 브랜치에서 개발해 main으로 병합한다.

웹 서비스 회사는 main, development, staging, production을 각각 개발 작업 통합, 개발 서버 배포, 스테이징 서버 배포, 실서비스 배포에 사용했다. 개발자는 최신 main에서 feature 브랜치를 만들고, 매일 오전 development 환경에 자동 배포해 진행 상황을 확인한다. 매주 금요일에는 staging에 배포해 QA 테스트를 진행하며, 매월 첫째 주 월요일 production에 배포한다. 긴급 이슈는 production에서 hotfix 브랜치를 분기해 처리한다.

GitHub Flow와 비교해 보는 선택 기준

특성	GitHub Flow	GitLab Flow
복잡성	단순함	중간 수준
브랜치 수	적음 (master + feature)	중간 (main + environment/release + feature)
배포 관리	즉시 배포 중심	환경별/릴리스별 관리 가능
적합한 프로젝트	웹 서비스, 지속적 배포가 가능한 환경	모바일 앱, 게임, 배포 주기가 긴 프로젝트
안정성	상대적으로 낮음	높음 (환경별 검증 단계 존재)
유연성	낮음	높음 (다양한 환경/릴리스 모델 지원)

소규모 팀의 단순한 프로젝트라면 GitHub Flow가 더 적합할 수 있다. 반대로 복잡한 배포 환경이나 릴리스 관리가 필요한 프로젝트라면 GitLab Flow의 환경·릴리스 브랜치 모델이 맞는다.

운영 전에 main과 환경 브랜치의 직접 푸시를 제한하고, merge request·코드 리뷰·자동화된 테스트 통과를 요구하는 보호 규칙을 정할 필요가 있다. 브랜치 명명 규칙, 커밋 메시지 형식, merge request 절차, 긴급 상황 대응 프로토콜도 팀이 공유하는 가이드라인으로 정리해야 한다.