긴급 보안 패치가 필요합니다. 그런데 main에는 아직 출시 안 한 기능이 잔뜩 머지돼 있습니다. "패치만 프로덕션에 넣어야 하는데, main을 배포하면 미완성 기능까지 나가요." 팀이 우왕좌왕합니다.
또 다른 팀은 두 달째 사는 feature/redesign 브랜치를 main에 합치려다 충돌 수백 개에 막혔습니다.
브랜치 전략은 '브랜치를 어떻게 따고 합치고 배포하는가'의 팀 규칙입니다. 이게 없거나 안 맞으면, 긴급 상황과 큰 작업에서 반드시 사고가 납니다.
- 1Git Flow·GitHub Flow·Trunk-based의 구조와 차이를 설명할 수 있다
- 2장수 브랜치의 "머지 지옥" 위험과 작은 통합의 가치를 설명할 수 있다
- 3핫픽스·릴리스 브랜치가 긴급 배포에서 하는 역할을 설명할 수 있다
- 4브랜치 전략이 배포 파이프라인(어느 브랜치→어느 환경)과 어떻게 연결되는지 설명할 수 있다
세 가지 대표 전략
복잡도와 배포 빈도의 트레이드오프
브랜치 전략은 "얼마나 자주 배포하고, 몇 개 버전을 유지하나"에 따라 갈립니다.
Trunk-based (잦은 배포·단순)
main ●─●─●─●─● ← 작은 브랜치를 몇 시간 내 머지, 미완성은 기능 플래그로 숨김
GitHub Flow (중간)
main ●───────●──────●
\feature/ \feature/ ← 기능 브랜치 → PR → main 머지 → 바로 배포
Git Flow (복잡·정해진 릴리스)
main(prod) ──●────────● (태그 = 릴리스)
develop ●─●─●─●─● (통합 브랜치)
feature/ ●─● (기능)
release/ ●──● (출시 준비·QA)
hotfix/ ● (prod 긴급 수정)
- Trunk-based: 작게 자주 통합. CI/CD·자동테스트·기능 플래그가 전제. 빠른 배포에 최적.
- GitHub Flow: 기능 브랜치 → PR → main → 배포. 단순하고 웹 서비스에 무난.
- Git Flow: 역할별 브랜치로 릴리스 주기·다중 버전·QA 게이트를 체계화. 무겁지만 구조적.
핫픽스 — 긴급 패치의 길
미완성과 섞이지 않고 prod만 고치는 경로
오프닝의 "패치만 넣어야 하는데 main엔 미완성 기능이…" 문제는 핫픽스 브랜치로 풉니다.
main(prod, v1.2.0) ●───────────●(v1.2.1) ← 핫픽스만 반영
\hotfix/ /
●───────── (prod 태그에서 따서 패치 → prod로)
핵심: 핫픽스는 '현재 prod에 떠 있는 코드(태그)'에서 분기한다.
개발 중인 develop/main HEAD가 아니라.
→ 미완성 기능을 끌고 가지 않고 긴급 수정만 배포 가능.
Trunk-based에서도 같은 원리로 'prod 태그에서 hotfix 브랜치 → 패치 → 즉시 배포 → main에 백포트'합니다. 핵심은 **"긴급 수정이 미완성 작업과 섞이지 않게 분리"**하는 것 — 이것이 브랜치 전략이 운영 안전에 직결되는 지점입니다.
어느 브랜치가 어디에 떠 있나 — 직접 확인
배포 사고를 막으려면 "어느 브랜치가 어느 환경에 배포되는가"가 명확해야 합니다. 미머지 브랜치와 환경 매핑을 점검합니다.
# main에 아직 머지 안 된 브랜치들(장수 브랜치 = 머지 지옥 위험)
git branch -a --no-merged main
# 각 브랜치가 main보다 얼마나 뒤처졌나(통합 지연 정도)
git for-each-ref --format='%(refname:short) %(committerdate:relative)' refs/heads/
# 현재 prod에 떠 있는 태그(롤백·핫픽스 기준점)
git tag --sort=-creatordate | head -3
$ git branch --no-merged main
feature/redesign ← 마지막 커밋 2개월 전! 머지 지옥 임박
feature/payment-v2 ← 3일 전, 정상 범위
환경 매핑(팀 규칙 예):
main 머지 → staging 자동 배포
태그 vX.Y.Z → production 배포
hotfix/* → production 직행(승인 후)
git branch -a --no-merged main- --no-merged 목록에 수주~수개월 된 브랜치가 있으면 "머지 지옥" 경고 → 작게 쪼개 자주 통합하도록 개입. 오래될수록 충돌·재테스트 비용 폭증
- 브랜치↔환경 매핑이 문서화돼 있는지 확인 — 없으면 "어느 코드가 prod에 떠 있나"를 아무도 확신 못 함(배포 사고 원인 1순위)
- prod 태그가 명확하면 롤백·핫픽스 기준점이 분명 → 긴급 상황에서 "이 태그로 되돌린다"가 즉시 가능. 태그 없으면 위험
- 기능 플래그 사용 팀이면 "배포됨 ≠ 노출됨" — main에 머지·배포돼도 플래그 OFF면 사용자에겐 안 보임. 릴리스 논의 시 이 구분을 확인
상황: 대규모 리디자인을 feature/redesign 브랜치에서 두 달간 진행한 뒤 main에 머지하려는데, 그사이 main이 수백 커밋 바뀌어 충돌이 폭발하고, 억지로 합친 뒤엔 회귀 버그가 쏟아집니다.
원인: 장수 브랜치(long-lived branch) 가 main과 멀어진 '머지 지옥'입니다. 통합을 미룬 두 달치 차이를 한 번에 합치려니 충돌과 재테스트가 감당 불가가 됐습니다. 통합을 미루는 것은 이자가 붙는 부채입니다.
진단:
git log --oneline main..feature/redesign | wc -l # 브랜치 고유 커밋 수
git log --oneline feature/redesign..main | wc -l # 놓친 main 변경 수(클수록 위험)
해결: 큰 작업도 작게 쪼개 자주 통합합니다 — 미완성은 기능 플래그로 숨겨 main에 계속 머지(Trunk-based 원리)하거나, 최소한 main을 주기적으로 브랜치에 합쳐(rebase/merge) 차이를 작게 유지합니다. 이미 벌어졌다면 단계적으로(파일 그룹별) 나눠 머지합니다. 브랜치 전략의 제1원칙은 "통합을 미루지 마라"입니다.
인프라/SRE로서 브랜치 전략은 곧 당신이 설계할 배포 파이프라인의 명세입니다 — "main 머지 → staging 자동 배포, 태그 → prod, hotfix/* → prod 직행" 같은 규칙을 CI/CD에 박습니다([[cicd-pipeline]]). 전략이 모호하면 "어느 코드가 prod에 떠 있나"를 아무도 확신 못 해 배포 사고가 납니다. 또한 핫픽스 경로를 미리 설계해 두면, 긴급 보안 패치를 미완성 기능과 섞지 않고 prod 태그에서 분기해 안전하게 배포할 수 있습니다. PM은 브랜치 전략으로 "배포됨 vs 노출됨(기능 플래그)"을 구분해 릴리스 일정을 더 유연하게 가져갑니다.
다음 모듈에서는 브랜치를 main에 합치기 전 거치는 품질 관문 — PR과 코드 리뷰 문화를 다룹니다.