암튼 정리해보는 깃 브런치 전략

오늘 우연히 유튜브에서 “딩딩하라” 님이 퇴사 후 다시 이직 준비하면서 공부하는 영상을 봤다.

그러다 문득 — 누가 나한테 “깃 브런치 전략이 뭐예요?” 라고 물어보면, 명쾌하게 답을 못 하겠다는 자각이 들었다.

내 환경이 좀 그랬다. 중소기업에서 1명이 여러 프로젝트 유지보수하면서, 그 중 한 프로젝트의 특정 부분(주로 모바일이나 React 쪽)을 맡았는데 — 협업이 아니라 본인 혼자 했다.

그러니까 새 업무가 들어오면 그냥 main 에서 바로 작업하거나, main 에서 브런치 하나 따서 작업하고 바로 머지하는 식이었다.

PR? 1인이니까 본인이 본인한테 리뷰 요청할 일도 없고, 그냥 머지.

이 상태로 몇 년을 일했다. 그리고 1인 개발자로 독립한 지금도 별로 다르지 않다.

근데 누가 “브랜치 전략 뭐 쓰세요?” 라고 물어보면 — 솔직히 “그냥 main 에서 따요” 라고밖에 답을 못 한다. 그게 뭔지를 모르니까 비교도 못 한다.

암튼, 정리해보자.

브랜치 전략이라는 게 뭐냐

정의부터 보면:

브랜치를 언제, 어디서 따고, 어떻게 합칠지에 대한 팀의 약속.

Git 이라는 도구 자체는 뭐 다 허용한다. 브랜치 100개 만들든 main 에 직접 push 하든 막지 않는다. 근데 약속이 없으면 사람마다 제멋대로 굴어서 히스토리가 엉킨다.

전략을 결정하는 핵심 질문은 세 개다.

1. 배포 가능한 코드는 어느 브랜치에 있나 (단일 진실의 출처)
2. 새 작업은 어디서 시작하나
3. 운영 긴급 수정(hotfix)은 어떻게 처리하나

이 세 질문에 어떻게 답하느냐가 전략을 가른다.

대표적인 게 네 가지다.

1. Git Flow

2010년 Vincent Driessen 이 정리한, 가장 무겁고 구조 많은 모델.

브랜치 구성:

• 영구 브랜치 2개: main (운영 코드), develop (다음 릴리즈 통합)
• 임시 브랜치 3종: feature/*, release/*, hotfix/*

흐름은 대략:

feature/* → develop → release/* → main (태그/배포)
                          ↓
hotfix/* → main + develop

장점: 역할 분리 명확. 큰 팀도 혼선 적음. “개발 중” 이랑 “운영 중” 이 물리적으로 갈림.

단점: 무거움. release/hotfix 를 main 과 develop 양쪽에 머지하는 과정에서 누락/충돌 실수가 잦음. 하루에도 여러 번 배포하는 환경에는 안 맞음.

적합한 상황: 정해진 릴리즈 주기가 있는 제품. 설치형/펌웨어. 버전별 납품 제품.

2. GitHub Flow

Git Flow 의 복잡함에 대한 반작용으로 등장한 극단적으로 단순한 모델. 사실상 규칙이 하나다.

main 은 언제나 배포 가능한 상태다.

브랜치 구성:

• 영구 브랜치 1개: main 뿐. develop 도 release 도 없다.
• 작업할 때마다 main 에서 설명적인 이름의 작업 브랜치 (add-apple-login, fix-promo-code 등)

흐름:

1. main 에서 작업 브랜치 딴다
2. 작업하고 커밋
3. PR 올린다
4. 리뷰 + CI 통과하면 main 에 머지
5. 머지되면 곧바로 (또는 자동으로) 배포

장점: 단순. 빠른 배포. “최신 하나” 만 신경 쓰면 됨.

단점: 머지 = 배포 이므로 CI/CD 약하면 위험. staging 같은 중간 단계가 기본 구조에 없음.

적합한 상황: 지속 배포 웹 서비스, SaaS, 대부분의 스타트업. 오늘날 가장 널리 쓰이는 기본값.

3. GitLab Flow

GitHub Flow 의 단순함을 유지하면서 단계적 배포 / 버전 관리를 보완한 중간 모델. 크게 두 변형이 있다.

(a) 환경 브랜치 방식

코드가 환경을 따라 단방향으로 흐른다.

main → staging → production

핵심 원칙: “항상 위(main)에 먼저 머지하고 아래로 내려보낸다” (upstream first). 절대 production 에서 먼저 고치지 않는다.

(b) 릴리즈 브랜치 방식

버전 릴리즈가 필요하면 release/2.3 같은 브랜치 만들고, 버그는 main 에서 먼저 고친 뒤 release 브랜치로 cherry-pick.

적합한 상황: staging 검증이 꼭 필요한 서비스. GitHub Flow 로는 통제 부족이고 Git Flow 는 과한 중간 규모 팀.

4. Trunk-Based Development (TBD)

구글, 페이스북 같은 초대형 조직 방식. 모두가 하나의 트렁크(main) 중심으로 작업.

핵심 규칙:

• 브랜치를 따더라도 수명이 아주 짧음 (이상적으로 하루 이내)
• 큰 기능도 작은 단위로 쪼개서 자주 main 에 머지 (하루 여러 번 머지가 정상)
• 미완 기능은 feature flag 로 숨겨놓고 배포 — 코드는 main 에 있지만 사용자한테는 꺼져있는 상태

전제 조건: 강력한 자동화 필수. 빠르고 신뢰도 높은 CI, 광범위한 자동 테스트, feature flag 운영 체계. 이게 없으면 main 이 수시로 깨진다.

적합한 상황: CI/CD 가 충분히 성숙한 대규모 조직.

한 눈에 비교

항목	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based
영구 브랜치	main, develop	main	main (+환경/릴리즈)	main
복잡도	높음	낮음	중간	낮음 (단, CI 의존)
배포 빈도	낮음	높음	중간~높음	매우 높음
여러 버전 동시 운영	강함	약함	가능	약함
CI/CD 의존도	낮음	중간	중간	높음(필수)
잘 맞는 곳	버전별 유지보수 제품	지속 배포 웹/앱	단계 배포 중간 팀	성숙한 대규모 조직

그래서 나는 뭘 써야 하나

전략 선택은 “유명하니까”, “멋있어 보여서” 가 아니라 본인 상황에 맞춰서다.

질문 네 개로 좁힌다.

1. 동시에 여러 버전 운영해야 하나? 그렇다 → Git Flow / GitLab Flow 릴리즈 방식. 아니다 → GitHub Flow 계열.
2. CI/CD 가 갖춰져 있나? 약하다 → staging 검증 두는 GitLab Flow 가 안전. 성숙하다 → GitHub Flow / TBD 로 빠른 배포 가능.
3. 배포 전 staging 검증 필요한가? 필요하다 → GitLab Flow 환경 브랜치. 아니다 → GitHub Flow.
4. 팀 규모 + 통합 빈도는? 대규모 + 잦은 통합 + 강한 자동화 → Trunk-Based. 중소 → GitHub Flow.

1인 / 소규모 인디면

GitHub Flow. 더 단순하게 가도 무방하다. develop / release 같은 의식은 관리 부담만 늘고 얻는 게 없다.

내가 지금까지 해온 게 사실상 이거였다. main 에서 작업 브랜치 따서, 작업 끝나면 머지. 다만 본인이 1인이니까 PR 단계만 생략한 거.

이게 잘못된 게 아니라 — 본인 환경에 맞는 GitHub Flow 의 축약 버전 인 거였다는 거. 정리하고 나서야 알았다.

모바일은 좀 다르다 — 스토어 심사 비대칭

모바일 앱은 변수 하나가 추가된다. 백엔드는 즉시 배포되는데, 앱은 스토어 심사 때문에 며칠씩 지연된다. 즉 “현재 스토어에 올라간 앱 버전” 과 “지금 배포된 백엔드” 가 일시적으로 어긋날 수 있음.

이 때문에 순수 GitHub Flow 만으로는 부족할 때가 있다.

• 운영 중인 앱 버전 대응하는 hotfix/release 브랜치를 잠깐 유지해야 할 수 있음 (심사 중인 버전과 별개로 긴급 패치 필요한 경우)
• 백엔드는 GitHub Flow, 앱은 release 브랜치 두는 혼합 전략 이 현실적
• “서버가 지원하는 최소 클라이언트 버전” 관리 + 구버전 강제 업데이트 장치는 브랜치 전략과 별개로 필요

마치며

브랜치 전략의 모든 차이는 결국 두 축으로 수렴한다.

1. 동시 운영 버전 수
2. 자동화 성숙도

• 단일 버전 + 성숙한 CI → 단순한 전략 (GitHub Flow / TBD)
• 다중 버전 또는 약한 CI → 안전망 있는 무거운 전략 (Git Flow / GitLab Flow)

항상 Git Flow 가 뭔가 체계적으로 보이고 그럴듯해 보여서, 간혹 feature/ 를 달고 release 도 달고 작업을 해봤는데 — 그럼 뭐하나, PR 을 봐줄 사람도 배포 버전을 관리해줄 사람도 난데…

그래서 난 항상 그냥 히스토리 관리만을 위해서 GitHub Flow 를 썼던 거 같다.

더 좋은 전략이 있는지는 차근차근 알아봐야겠다.

암튼 정리 한 번 해보고 싶었다.

마침.