Git 브랜치 전략: Git Flow vs GitHub Flow vs Trunk-based

브랜치 전략 글은 보통 모델 이름을 소개하는 데서 끝납니다. 하지만 실무에서 팀이 힘들어지는 이유는 Git Flow를 몰라서가 아니라, 브랜치 정책과 릴리스 방식, CI, 핫픽스 경로가 서로 맞지 않기 때문입니다.

그래서 중요한 질문은 “어떤 모델이 가장 좋아 보이는가”가 아니라 “우리 팀의 배포 방식에 가장 적은 운영 마찰을 만드는가”입니다.

브랜치 전략이 실제로 바꾸는 것

브랜치 전략은 단순한 merge 모양이 아닙니다.

코드가 얼마나 오래 미출시 상태로 남는가
충돌이 얼마나 늦게 한꺼번에 터지는가
핫픽스를 얼마나 빠르게 적용할 수 있는가
feature flag와 release branch 중 무엇에 더 의존하는가
CI가 실제 운영 경로를 검증하는가, 아니면 옆길만 검증하는가

팀의 릴리스 습관과 맞지 않는 전략을 선택하면 Git은 버전 관리 도구가 아니라 프로세스 부채 저장소가 됩니다.

Git 취향보다 릴리스 방식부터 정해야 한다

많은 팀이 브랜치 모델부터 고르려 하지만, 실전에서는 순서가 반대입니다. 먼저 아래 질문에 답해야 합니다.

우리는 계속 배포하는가, 정해진 주기로 배포하는가
동시에 여러 운영 버전을 관리해야 하는가
미완성 기능을 feature flag 뒤에 숨길 수 있는가
main을 보호할 만큼 CI가 빠르고 신뢰할 수 있는가
긴급 핫픽스가 얼마나 자주 발생하는가

이 답들이야말로 어떤 전략이 맞는지 훨씬 강하게 결정합니다.

GitHub Flow는 main과 릴리스가 가까울 때 강하다

GitHub Flow는 자주 배포하는 팀에서 가장 실용적인 기본값이 됩니다.

feature branch -> PR -> main -> deploy

이 흐름이 잘 맞으려면 다음 조건이 필요합니다.

feature branch가 짧게 유지될 것
main이 항상 배포 가능한 상태일 것
CI가 신뢰 가능할 것
release branch가 거의 필요 없을 것
미완성 기능을 flag로 숨길 수 있을 것

장점은 단순함입니다. 하지만 배포 통제가 약한 팀이 이 모양만 따라 하면, 겉보기만 단순하고 실제 운영은 불안정해질 수 있습니다.

Git Flow는 일정 기반 릴리스에 맞지만 비용이 크다

Git Flow는 구조가 더 명확합니다.

릴리스용 main
개발 통합용 develop
feature branch
release branch
hotfix branch

이 구조는 정해진 배포 주기를 가진 팀, 여러 버전을 관리하는 제품, QA 단계가 긴 조직에는 여전히 유용할 수 있습니다. 대신 비용도 큽니다.

통합이 늦어짐
충돌이 오래 쌓임
핫픽스 반영 경로가 복잡함
무엇이 진짜 운영 준비 상태인지 흐려지기 쉬움

Git Flow는 틀린 전략이 아니라, 필요가 있을 때만 정당화되는 비싼 전략에 가깝습니다.

Trunk-based는 빠른 통합을 위해 설계된 방식이다

Trunk-based Development는 모두가 짧은 branch로 빠르게 mainline에 합류하는 것을 전제로 합니다. 핵심은 이념이 아니라 통합 지연을 줄이는 데 있습니다.

이 전략은 다음 조건에서 특히 강합니다.

CI가 빠르고 안정적일 것
변경을 작게 쪼갤 수 있을 것
feature flag가 있을 것
팀이 자주 통합하는 문화에 익숙할 것

장점은 충돌과 통합 리스크를 초기에 드러낸다는 점입니다. 대신 테스트 품질이 약하거나 미완성 기능을 숨길 장치가 없으면 오히려 팀이 더 불안해질 수 있습니다.

실무에서는 이렇게 고르는 편이 낫다

자주 배포하고 싶다면 GitHub Flow가 가장 실용적이다.
정기 릴리스와 다중 버전 관리가 필요하면 Git Flow가 맞을 수 있다.
빠른 통합과 작은 변경 단위에 강한 팀이면 Trunk-based가 효율적이다.

요즘 제품팀에서는 GitHub Flow에 feature flag를 결합한 형태가 가장 현실적인 중간지점이 되는 경우가 많습니다.

feature flag가 브랜치 전략보다 더 중요할 때가 많다

브랜치 논쟁처럼 보이지만 실제로는 릴리스 통제 논쟁인 경우가 많습니다. 미완성 기능을 안전하게 숨길 수 있다면:

긴 생명주기의 feature branch 필요성이 줄고
release branch 빈도도 낮아지고
통합을 더 빨리 당길 수 있습니다

반대로 flag가 없으면 팀은 불안해서 branch 안에 오래 숨겨 두고, 그 대가를 나중에 더 큰 충돌로 치르게 됩니다.

핫픽스 경로가 전략의 실체를 드러낸다

모든 브랜치 전략은 결국 한 질문에 답해야 합니다.

“운영 장애를 한 시간 안에 고치면서도 두 번째 사고를 만들지 않을 수 있는가?”

핫픽스 경로가 문서에만 있고 실제 연습이 없다면 그 전략은 보기보다 약합니다. 진짜 핫픽스 절차는 아래를 분명히 해야 합니다.

어디서 수정이 시작되는가
어떤 브랜치에 먼저 들어가는가
개발 라인으로 어떻게 되돌아가는가
패치 릴리스는 어떻게 태깅되고 추적되는가

이게 브랜치 이름 규칙보다 훨씬 중요합니다.

자주 터지는 실패 패턴

긴 feature branch를 feature flag 대용으로 쓰는 경우
develop이 항상 불안정한 채로 방치되는 경우
실질적인 작업은 다른 브랜치에서 하면서 main만 상징적으로 지키는 경우
핫픽스 절차를 실제로는 아무도 연습하지 않은 경우
release branch가 의도치 않게 장기 유지 브랜치가 되는 경우

브랜치 모델은 문서가 아니라 실제 팀 행동과 맞지 않는 순간부터 실패합니다.

체크리스트

새 팀원이 기본 흐름을 한 번에 이해할 수 있는가
핫픽스 경로가 명확하고 실제로 검증되었는가
가장 중요한 브랜치를 CI가 제대로 검증하는가
미완성 기능을 안전하게 숨길 수 있는가
충돌을 줄이고 있는가, 아니면 나중으로 미루고만 있는가

마무리

브랜치 전략은 운영 모호성을 줄여야지 늘리면 안 됩니다. 좋은 전략은 보통 가장 화려한 전략이 아니라, 릴리스 리듬과 핫픽스 요구, CI 성숙도에 맞는 최소 전략입니다. 많은 팀에서 Git이 복잡해지는 이유는 Git이 아니라 릴리스 엔지니어링 문제가 먼저 정리되지 않았기 때문입니다.

다음으로 읽기 좋은 글

🔧 Tools

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다