Git 브랜치 전략 완전 정복 - 신입이 꼭 알아야 할 협업 워크플로우

git commit, git push, git pull은 익숙한데, 막상 첫 회사에 입사하니 feature/login-page, release/1.2.0 같은 낯선 브랜치 이름이 잔뜩 보여서 당황하신 적 있나요? 혼자 프로젝트를 할 때는 브랜치 하나로도 충분했지만, 여러 명이 동시에 같은 코드베이스를 건드리는 팀에서는 이야기가 달라져요.

브랜치 전략 없이 협업하면 누가 무엇을 작업 중인지 알 수 없고, 충돌(conflict)이 여기저기서 터지고, 심하면 테스트 안 된 코드가 배포까지 흘러 들어가는 사고로 이어져요. 그래서 팀들은 저마다 "우리는 이렇게 브랜치를 나누고 합친다"는 규칙, 즉 브랜치 전략을 정해두고 있어요.

이 글에서는 실무에서 가장 많이 언급되는 네 가지 브랜치 전략 — Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development — 을 각각 무엇인지, 언제 쓰면 좋은지, 실제 브랜치 이름과 병합 흐름은 어떤 모습인지까지 살펴볼게요. Git의 기본 명령어는 안다는 전제로, "혼자 쓰는 Git"에서 "팀에서 쓰는 Git"으로 넘어가는 다리를 놓아드릴게요.

1. Git Flow — 가장 체계적이지만 무거운 전략

Git Flow는 2010년 Vincent Driessen이 nvie.com에 공개한 브랜칭 모델이에요^[1]. 지금도 "브랜치 전략" 하면 가장 먼저 떠올리는 이름일 만큼 널리 퍼져 있어요.

브랜치 구조

Git Flow는 두 개의 영구 브랜치와 세 종류의 임시 브랜치로 이루어져요.

main(master): 항상 배포 가능한, 실제 운영 중인 상태를 반영해요^[1].
develop: 다음 릴리즈를 위해 개발 중인 변경 사항들이 모이는 곳이에요^[1].
feature/\*: develop에서 분기해서, 기능이 완성되면 다시 develop으로 병합해요. feature 브랜치는 main과 직접 관계를 맺지 않아요^[2].
release/\*: develop에서 분기해서 배포 직전 마무리 작업(버그 수정, 문서 정리 등)을 하고, 완료되면 develop과 main 양쪽에 병합해요^[1]^[2].
hotfix/\*: main에서 직접 분기하는 유일한 브랜치예요. 운영 중 발생한 긴급 버그를 고치고, 역시 develop과 main 양쪽에 병합한 뒤 main에는 새 버전 태그를 남겨요^[1]^[2].

실제 워크플로우 예시

main -----o---------------------o--------o---> (v1.0.0)   (v1.0.1)  (v1.1.0)
           \                   / \       /
develop -----o---o---o---o----o---o-----o--->
                  \       \  /   /
feature/login      o---o---/   /
feature/payment          o----/

예를 들어 로그인 기능을 개발한다면 feature/login이라는 이름으로 develop에서 브랜치를 따고, 작업이 끝나면 PR을 열어 코드 리뷰 후 develop에 병합해요. 릴리즈 시점이 되면 develop에서 release/1.1.0 브랜치를 만들어 QA와 마무리 작업을 하고, 문제가 없으면 main과 develop에 동시에 병합하며 main에 v1.1.0 태그를 붙여요.

실제로 배달의민족을 운영하는 우아한형제들의 안드로이드 팀은 2016년부터 GitHub Flow를 쓰다가, 팀 규모가 2~3명에서 5명으로 늘고 병렬 개발이 필요해지면서 2017년 6월 Git Flow로 전환한 사례가 있어요^[7]. 약 3주 주기의 릴리즈 사이클을 운영하면서 즉시 배포할 기능과 장기 기능을 동시에 개발해야 했던 게 전환의 이유였다고 해요^[7].

장단점과 창시자의 2020년 업데이트

Git Flow는 역할이 명확하게 나뉜 만큼 릴리즈 관리가 체계적이고, 운영 중인 버전을 건드리지 않고도 다음 버전을 준비할 수 있다는 장점이 있어요. 반면 브랜치 종류가 많고 병합 지점도 많아서, 배포를 자주 하는 팀에게는 과정이 무겁게 느껴질 수 있어요.

여기서 꼭 짚고 넘어가야 할 부분이 있어요. Git Flow가 사실상 "표준"처럼 받아들여지고 있지만, 원래 지속적 배포(continuous delivery)를 염두에 두고 설계된 모델이 아니라는 점이에요. 실제로 창시자 Driessen은 원문에 업데이트 노트를 추가해서, 웹 애플리케이션을 만든다면 Git Flow를 억지로 맞추기보다 GitHub Flow처럼 더 단순한 워크플로우를 쓰라고 권장했어요^[1]. Git Flow가 여전히 잘 맞는 경우는 명시적으로 버전이 관리되거나, 여러 버전을 동시에 지원해야 하는 소프트웨어(라이브러리, 패키지, 모바일 앱 등)라고 밝히고 있어요^[1].

즉, "요즘도 Git Flow를 쓰나요?"라는 질문에는 "빠르게 배포하는 웹 서비스라면 다른 선택지를 먼저 고려해보세요"가 더 정확한 답이에요.

2. GitHub Flow — 단순하고 빠른 배포에 최적화

GitHub Flow는 GitHub가 공식 문서에서 소개하는, 가볍고 브랜치 기반인 워크플로우예요^[3]. develop 같은 별도 통합 브랜치 없이, 하나의 기본 브랜치(main)를 항상 배포 가능한 상태로 유지하는 게 핵심이에요.

핵심 원칙

브랜치 생성: main에 영향을 주지 않고 작업할 공간을 만들어요^[3].
작업 & 커밋: 하나의 커밋은 독립적이고 완결된 하나의 변경 사항을 담아요. 나중에 되돌리기도 쉬워져요^[3].
Pull Request 생성: 무엇을, 왜 바꿨는지 요약을 담아 PR을 열어요^[3].
리뷰 반영: 리뷰어 코멘트에 맞춰 커밋을 추가하면 PR이 자동으로 업데이트돼요^[3].
병합 & 브랜치 삭제: 승인되면 main에 병합하고, 재사용 실수를 막기 위해 브랜치는 삭제해요^[3].

실제 워크플로우 예시

main ---o---o-------o-----o---o--->
         \         /     /
          o---o---/     /
      increase-test-timeout
                    \   /
                     o-o
              add-code-of-conduct

브랜치 이름도 feature/xxx처럼 딱딱하게 붙이기보다 increase-test-timeout, add-code-of-conduct처럼 무엇을 하는지 바로 알 수 있게 짓는 걸 권장해요^[3]. 소프트웨어뿐 아니라 문서나 로드맵 관리에도 쓸 수 있을 만큼 범용적인 방식이에요^[3]. 배포를 자주, 지속적으로 하는 웹 서비스 팀이라면 Git Flow보다 GitHub Flow가 훨씬 가볍게 느껴질 거예요.

3. GitLab Flow — Git Flow와 GitHub Flow의 절충안

GitLab Flow는 GitLab이 공식적으로 제안하는 방식으로, feature 중심 개발에 이슈 트래킹과 지속적 배포 개념을 결합한 브랜칭 전략이에요^[4]. Git Flow처럼 develop 브랜치를 따로 두지 않고, main 브랜치에서 바로 시작한다는 점은 GitHub Flow와 비슷해요^[4].

environment branch(환경 브랜치)와 release branch

GitLab Flow의 특징은 배포 단계별로 environment branch를 둘 수 있다는 점이에요. 예를 들어 main → test → acceptance → production처럼 단계를 나누고, 각 단계로 올라갈 때는 머지 리퀘스트를 통해 승격시켜요^[4]. 커밋이 항상 main에서 production 방향으로만 흐르도록 만들어서, 모든 환경에서 코드가 검증된 상태로 배포되도록 하는 구조예요^[4].

여러 버전을 동시에 유지해야 하는 팀이라면 release branch도 활용할 수 있어요. 예를 들어 v1, v2 브랜치를 각각 관리하다가, 리뷰 중 발견된 버그를 이전 버전에도 반영(백포트)해야 할 때 유용해요^[4]. 다만 외부에 소프트웨어를 배포/납품하는 경우가 아니라면 release branch까지는 필요 없을 수 있어요^[4].

언제 유용한가

배포 환경이 dev-staging-production처럼 여러 단계로 나뉘어 있는 팀, 혹은 여러 버전을 동시에 지원해야 하지만 Git Flow만큼 무거운 구조는 부담스러운 팀에게 잘 맞아요. GitLab은 이를 팀 규모와 무관하게 유연하게 적용할 수 있는, Git Flow의 단순화 버전으로 소개하고 있어요^[4].

4. Trunk-Based Development — 최근 고성과 팀들의 선택

Trunk-Based Development(TBD)는 개발자들이 'trunk'라는 단일 브랜치에서 협업하고, 오래 유지되는 개발 브랜치는 최대한 만들지 않으려는 모델이에요^[5]. 브랜치를 쓰더라도 수명이 아주 짧아서, 하루에도 여러 번 trunk에 병합해요. 아주 작은 팀은 아예 trunk에 직접 커밋하기도 해요^[5].

정의와 핵심 원칙

미완성 기능은 브랜치를 오래 유지하는 대신 feature flag나 branch by abstraction 같은 기법으로 숨겨둔 채, 코드는 계속 trunk에 통합해요^[5]. 이렇게 하면 긴 생명주기의 브랜치 없이도 지속적 통합(CI)이 가능해져요. 구글이나 메타 같은 대규모 조직도 TBD를 실천하고 있는데, 이는 소규모 팀부터 수천 명 규모의 조직까지 이 모델이 통할 수 있다는 걸 보여주는 사례로 자주 인용돼요^[5].

DORA 리서치가 말하는 것

Google Cloud의 DevOps 연구 조직 DORA는 수년간 수만 명 규모의 설문을 바탕으로 한 State of DevOps 리서치에서, 고성과 팀의 공통된 특징으로 다음을 꼽았어요^[6].

저장소에 활성 브랜치 3개 이하 유지
하루 최소 1회 이상 trunk로 병합
코드 프리즈나 별도의 통합 단계를 두지 않음

이런 관행을 따르는 팀일수록 배포 속도, 안정성, 가용성 등 소프트웨어 딜리버리 성과가 더 높다는 상관관계가 나타났고, DORA는 TBD를 진짜 의미의 지속적 통합을 가능하게 하는 필수 관행으로 설명하고 있어요^[6].

물론 TBD는 매우 잦은 배포와 탄탄한 자동화 테스트, 성숙한 CI 환경을 전제로 해요. 이런 인프라가 아직 갖춰지지 않은 팀이라면 GitHub Flow 정도에서 시작해 점차 브랜치 생명주기를 줄여가는 게 현실적인 경로가 될 수 있어요.

5. 한눈에 비교하기

전략	복잡도	적합한 팀·상황	대표 브랜치
Git Flow	높음	릴리즈 주기가 길고 여러 버전을 동시 지원해야 하는 프로젝트(라이브러리, 패키지, 모바일 앱 등)^[1]	main, develop, feature/, release/, hotfix/*
GitHub Flow	낮음	지속적으로 배포하는 웹 서비스, 소규모~중간 규모 팀^[3]	main, 기능별 브랜치(예: add-login)
GitLab Flow	중간	배포 단계가 여러 환경(dev/staging/prod)으로 나뉘거나 여러 버전을 동시 지원해야 하는 팀^[4]	main, environment branch(test/acceptance/production), release/*
Trunk-Based Development	낮음(대신 CI/테스트 성숙도 요구)	배포를 매우 자주 하고 자동화 테스트가 탄탄한 고성과 지향 팀^[5]^[6]	trunk(main), 수명이 매우 짧은 개인 브랜치

6. 신입 개발자를 위한 실전 체크리스트

첫 회사에 입사했다면, 브랜치 전략을 스스로 고민하기보다 팀이 이미 정해둔 규칙을 빠르게 파악하는 게 우선이에요.

팀의 브랜치 전략부터 확인하기: git branch -a로 원격 브랜치 목록을 보고, README나 위키에 브랜치 규칙 문서가 있는지 찾아보세요. develop 브랜치가 있다면 Git Flow 계열, main 하나만 있다면 GitHub Flow나 GitLab Flow 계열일 가능성이 높아요.
브랜치 이름 컨벤션 지키기: 팀마다 다르지만 흔히 쓰는 접두사는 feature/, fix/, hotfix/, refactor/, chore/예요. 예) feature/user-signup, fix/login-error.
작은 단위로 자주 커밋하고 병합하기: 브랜치를 오래 붙잡고 있을수록 나중에 충돌이 커져요. 작업을 작게 쪼개고 PR도 작게 유지하는 게 리뷰받기도, 병합하기도 편해요.
PR/MR 만들기 전 체크하기: 최신 main(또는 develop)을 반영했는지, 불필요한 커밋이나 디버깅 코드가 남아있지 않은지, 변경 이유를 요약해뒀는지 확인하세요.
모르면 물어보기: 브랜치 전략은 팀마다 세부 규칙이 조금씩 달라요. 헷갈리면 추측해서 진행하기보다 리드나 동료에게 먼저 확인하는 게 훨씬 빨라요.

마무리

네 가지 전략 중 정답은 하나가 아니에요. 팀의 배포 주기, 지원해야 하는 버전 수, 자동화 테스트 성숙도에 따라 맞는 선택이 달라져요. 다만 최근 흐름은 확실히 더 단순한 방향(GitHub Flow, Trunk-Based Development)으로 수렴하고 있고, Git Flow의 창시자조차 웹 서비스라면 단순한 워크플로우를 권장한다는 점은 기억해둘 만해요^[1].

처음에는 낯선 브랜치 이름과 병합 규칙이 헷갈릴 수 있지만, 몇 번의 PR을 직접 만들어보면 금방 익숙해져요. 작은 실수들을 겪으면서 팀의 협업 방식을 몸으로 익히는 것도 소중한 경험이에요. 이렇게 쌓인 협업 경험은 다음 이직이나 커리어를 준비할 때도 중요한 자산이 되니, 경험 관리로 틈틈이 기록해두는 것도 좋은 습관이에요.