GitLab Flow에서 Git Flow로 브랜치 전략 전환기

약 1년 8개월간 운영해온 브랜치 전략을 Git Flow로 전환한 경험을 정리한다.

배경

2023년 2월 입사 이후 PHP에서 Java로의 시스템 고도화를 진행했다. 당시에는 신속한 개발이 최우선이었기 때문에 공식적인 브랜치 전략 없이 운영 환경 기준으로만 브랜치를 분리하여 사용했다.

기존 브랜치 구조

dev (개발)
    ↓
staging (검증)
    ↓
production (운영)

GitLab Flow와 유사한 형태였지만, 기능 브랜치(feature branch) 없이 개발자들이 각자 로컬에서 작업한 뒤 dev에 직접 병합하는 방식이었다.

기존 전략의 문제점

1. 기능 브랜치 부재

개발자 A: local 작업 → dev 병합
개발자 B: local 작업 → dev 병합 (충돌 발생)
개발자 C: local 작업 → dev 병합 (이전 충돌 해결 코드 덮어씀)

기능 브랜치 없이 로컬에서 바로 dev로 병합하다 보니 충돌이 빈번하게 발생했고, 해결 과정에서 다른 개발자의 코드가 누락되는 일이 반복되었다.

2. PR(Pull Request) 부재

코드 리뷰 없이 바로 병합되었기 때문에:

• 다른 개발자가 어떤 작업을 했는지 파악하기 어려움
• 미완성 기능이 그대로 상위 브랜치로 전파됨
• 버그가 발견되어도 원인 추적이 어려움

3. 크리티컬한 문제 발생

가장 심각했던 것은 미완료 기능이 운영 환경에 반영되는 사고였다. staging에서 테스트 중이던 기능이 다른 배포와 함께 production으로 넘어가면서 장애가 발생했다.

기존 전략 장단점 정리

Git Flow 전환 결정

전환 시점

2024년 11월, 다음 조건이 갖춰졌을 때 전환을 결정했다.

• 주요 고도화 작업 완료
• 팀원들의 Git 숙련도 향상
• 반복되는 배포 사고에 대한 공감대 형성

목표

1. 코드 충돌 최소화: 기능 브랜치로 작업 단위 분리
2. 작업 가시성 확보: PR을 통한 코드 리뷰 도입
3. 배포 안정성 향상: 명확한 브랜치 흐름 정립

전환 과정

1단계: 브랜치 통일

Production 브랜치를 기준으로 모든 브랜치를 재정렬했다.

# production을 기준으로 main 생성
git checkout production
git checkout -b main

# develop 브랜치 생성
git checkout -b develop

2단계: 전환 실행

각 서버(dev, staging, production) 작업이 없는 날을 선정하여 동시에 전환을 진행했다. 부분 전환은 오히려 혼란을 가중시킬 수 있어 한 번에 진행하는 것이 효과적이었다.

3단계: 새로운 브랜치 구조

main (운영)
    │
    ├─ hotfix/*   ← 긴급 수정
    │
develop (개발 통합)
    │
    ├─ feature/*  ← 기능 개발
    ├─ bugfix/*   ← 버그 수정
    │
release/* (배포 준비)

4단계: 컨벤션 수립

브랜치 명명 규칙과 PR 규칙을 정했다.

브랜치 명명

feature/기능명
bugfix/버그설명
hotfix/긴급수정내용
release/버전

PR 규칙

• feature → develop: 최소 1명 이상 리뷰 필수
• develop → release: QA 담당자 승인 필요
• release → main: 팀 리드 승인 필요
• hotfix → main: 긴급 상황 시 사후 리뷰 허용

전환 후 변화

긍정적 변화

1. 작업 가시성 확보

PR 도입으로 다른 개발자가 어떤 작업을 진행 중인지 쉽게 파악할 수 있게 되었다.

[PR #42] feature/user-export - 사용자 데이터 내보내기 기능
├─ 변경 파일: 12개
├─ 리뷰어: @teammate
└─ 상태: 리뷰 대기 중

2. 충돌 및 누락 감소

기능 브랜치 단위로 작업이 분리되면서 코드 충돌이 현저히 줄었다. 충돌이 발생해도 PR 단계에서 발견되어 사전에 해결할 수 있었다.

3. 배포 안정성 향상

전환 이후 크리티컬한 배포 사고가 발생하지 않았다. release 브랜치를 통한 검증 단계가 추가되면서 운영 반영 전 충분한 테스트가 가능해졌다.

예상했던 우려와 실제

회고

잘한 점

• 한 번에 전환: 부분 전환의 혼란을 피하고 깔끔하게 진행
• 컨벤션 선 수립: 전환과 동시에 규칙을 정해 혼선 방지
• 팀 공감대 형성: 문제 인식을 공유한 상태에서 전환하여 저항 최소화

아쉬운 점

• 더 빨리 전환했으면: 고도화 완료 직후가 아닌, 중간 시점에 전환했다면 사고를 줄일 수 있었음
• CI/CD 연동 미비: 브랜치 전략과 함께 자동화 파이프라인도 정비했으면 더 좋았을 것

배운 점

정리

참고

• Git Flow 원문
• GitHub Flow vs Git Flow