blog

Git 브랜치 전략

NEXTREE.

15 7월 2026 • 24 min read

1. 들어가며

Git 브랜치를 "기능별로 나누는 도구" 정도로 생각하기 쉽지만, 실제 업무에서 브랜치 전략은 협업 방식, 개발 환경 배포 및 테스트, QA 검증, 운영 배포, hotfix 대응까지 직접 연결됩니다. 여러 명이 동시에 개발하고 정해진 일정에 맞춰 배포해야 하는 환경에서는 특히 브랜치 전략이 단순한 Git 사용법을 넘어 팀의 일하는 방식이 됩니다.

처음에는 Git Flow, GitHub Flow 같은 이름 있는 전략을 기준으로 실무 브랜치 구조를 이해하려 했습니다. 하지만 실제 프로젝트에서 마주한 브랜치 전략은 교과서와 완전히 일치하지 않았습니다. feature, develop, stage, prod, release 같은 브랜치가 있어도 실제 운용 방식은 배포 주기, QA 방식, 인원 규모, CI/CD 환경, 승인 절차에 따라 변형되어 있었습니다.

이 글에서는 대표적인 브랜치 전략을 간단히 정리한 뒤, 실제로 경험한 환경 브랜치와 배포 후보 브랜치 구조를 중심으로 정리합니다. 이 전략을 직접 설계한 것은 아니지만, feature 브랜치를 만들고, 개발 브랜치에 병합해 테스트하고, 배포 후보 브랜치에 기능을 모아 운영 배포하는 흐름을 경험하면서 장점과 주의점을 이해할 수 있었습니다.

이 경험에서 가장 크게 느낀 것은 "우리 팀이 Git Flow를 쓰는가, GitHub Flow를 쓰는가"라는 이름표보다, 각 브랜치의 역할이 명확한지, 머지 방향이 일관적인지, 배포 기준과 동기화 절차를 팀원들이 동일하게 이해하고 있는지가 훨씬 중요하다는 점이었습니다.

2. 대표적인 Git 브랜치 전략

2.1 Git Flow

Git Flow는 브랜치 역할을 명확하게 나누는 릴리즈 중심 전략입니다. main 또는 과거 명칭인 master는 운영 배포 가능한 릴리즈 이력을 관리하고, develop은 다음 배포를 위한 통합 브랜치 역할을 합니다. feature/*는 기능 개발, release/*는 배포 전 안정화와 버전 준비, hotfix/*는 운영 긴급 수정에 사용합니다.

feature/* -> develop -> release/* -> main
hotfix/*  -> main, develop 또는 현재 release/*

명시적인 버전 릴리즈가 있거나, 릴리즈 전 별도 안정화 및 검증 단계가 필요하거나, 여러 버전을 유지해야 하는 프로젝트에 잘 맞습니다. 다만 브랜치가 많고 머지 방향이 정해져 있어 팀 내 규칙 공유, 브랜치 보호, 자동화가 중요합니다. 모든 프로젝트에 기본값처럼 적용하기보다는 릴리즈 방식과 팀 규모에 맞는지 먼저 판단해야 합니다.

2.2 GitHub Flow

GitHub Flow는 main 브랜치를 중심으로 하는 단순한 전략입니다. 기능 개발은 짧은 feature 브랜치에서 진행하고, Pull Request로 리뷰와 테스트를 거친 뒤 main에 병합합니다. 핵심은 main에 들어간 코드는 항상 배포 가능한 상태여야 한다는 점입니다.

feature/* -> Pull Request / CI / review -> main -> deploy

실무에서는 main에 병합되면 즉시 자동 배포되는 팀도 있고, 수동 승인이나 단계적 배포를 거치는 팀도 있습니다. 따라서 "main에 병합하면 무조건 즉시 배포"라기보다 "main에 병합된 코드는 언제든 배포 가능해야 한다"고 이해하는 편이 더 정확합니다.

단순하고 PR 중심 협업에 잘 맞지만, 아직 사용자에게 노출되면 안 되는 기능은 feature flag, 권한 제어, 설정값, 단계적 rollout 같은 방식으로 제어해야 합니다. main이 깨지면 배포 흐름 전체가 막히기 때문에 자동 테스트와 브랜치 보호 규칙도 중요합니다.

2.3 GitLab Flow

GitLab Flow는 GitHub Flow의 단순한 feature branch에서 Merge Request를 거쳐 main에 병합하는 흐름을 바탕으로, 프로젝트의 배포 방식에 따라 production 브랜치, staging 브랜치, release 브랜치, 태그, CI/CD 환경을 조합해 운영 흐름을 표현하는 방식입니다.

예시 1: feature/* -> main -> staging -> production
예시 2: feature/* -> main -> release/x.y -> production deploy

Git Flow보다 단순하면서도 GitHub Flow보다 배포 및 검증 단계를 명확히 표현할 수 있습니다. QA, staging, UAT, production처럼 환경별 검증 단계가 중요한 프로젝트에서 유용합니다.

다만 GitLab Flow가 항상 staging 또는 production 브랜치를 반드시 둔다는 뜻은 아닙니다. GitLab CI/CD의 environment 기능만으로도 QA, staging, production 환경을 관리할 수 있고, 릴리즈 브랜치나 태그 기반 배포를 선택할 수도 있습니다. 즉, 환경 브랜치는 GitLab Flow의 대표적인 형태 중 하나이지 필수 조건은 아닙니다.

2.4 Trunk-Based Development

Trunk-Based Development는 하나의 중심 브랜치, 보통 main 또는 trunk에 변경사항을 자주 통합하는 전략입니다. 브랜치를 전혀 쓰지 않는다는 뜻이 아니라, 오래 살아있는 브랜치를 피하고 작은 단위의 변경을 짧은 브랜치 또는 직접 커밋 방식으로 빠르게 통합하는 것이 핵심입니다.

main 또는 trunk
└─ short-lived branch -> main 또는 trunk

trunk는 항상 빌드 가능하고 배포 가능한 상태를 유지해야 하므로 빠른 CI, 자동 테스트, 작은 작업 단위, 빠른 코드 리뷰가 중요합니다. 큰 기능을 한 번에 오래 숨겨두기보다는 feature flag, branch by abstraction, 설정값 제어 등을 활용해 미완성 기능이 사용자에게 노출되지 않게 관리합니다.

CI/CD가 잘 갖춰져 있고 자동 테스트를 신뢰할 수 있는 조직에 잘 맞습니다. 반대로 테스트가 느리거나 수동 검증 의존도가 높고 기능 브랜치가 오래 유지되는 조직에서는 trunk를 안정적으로 유지하기 어렵습니다.

3. 실무에서 정석 전략이 그대로 적용되지 않는 이유

실제 프로젝트에서는 하나의 전략이 깔끔하게 적용되기보다 여러 전략의 요소가 섞이는 경우가 많습니다. 브랜치 전략은 단순히 Git 사용 방식의 문제가 아니라 배포 주기, QA 방식, 운영 장애 대응, 팀 인원, CI/CD 수준, 업무 승인 절차와 모두 연결되어 있기 때문입니다.

예를 들어 develop, stage, prod 브랜치가 있다고 해서 무조건 Git Flow는 아닙니다. staging이나 production 브랜치가 있다고 해서 항상 GitLab Flow라고 단정할 수도 없습니다. main에서 feature 브랜치를 따고 다시 main에 병합한다고 해서 무조건 Trunk-Based Development도 아닙니다. Pull Request를 쓴다고 해서 GitHub Flow가 되는 것도 아닙니다. PR은 브랜치 전략 그 자체가 아니라 코드 리뷰와 병합을 위한 협업 방식입니다.

실무에서 브랜치 전략을 파악할 때는 이름보다 다음 질문에 답할 수 있는지가 더 중요했습니다.

운영 배포의 기준 브랜치는 무엇인지 확인해야 합니다.
개발계와 검증계에 배포되는 브랜치가 각각 무엇인지 확인해야 합니다.
feature 브랜치는 어디서 생성되고 어디에 먼저 병합되는지 확인해야 합니다.
이번 배포에 포함할 feature는 어떤 방식으로 선택되는지 확인해야 합니다.
운영 배포 후 개발/검증 브랜치는 어떻게 동기화되는지 확인해야 합니다.
hotfix는 어느 브랜치에서 시작하고 어느 브랜치로 되돌려 보내는지 확인해야 합니다.

이 질문들에 대한 답이 명확할 때 팀원들이 같은 기준으로 움직일 수 있었습니다. 반대로 브랜치 이름은 익숙하지만 실제 역할이 모호하면, 개발 브랜치에 들어간 기능이 모두 배포되는지, 검증 브랜치가 운영 후보인지 단순 테스트용인지 같은 부분에서 오해가 생길 수 있었습니다.

4. 실무 경험: 환경 브랜치와 배포 후보 브랜치 구조

제가 경험한 프로젝트에는 운영 브랜치, 개발 브랜치, 검증 브랜치가 존재했습니다. 실제 브랜치명은 프로젝트마다 다를 수 있으므로, 이 글에서는 이름보다 역할을 기준으로 설명하겠습니다.

운영 브랜치는 실제 운영 배포의 기준이 되는 브랜치입니다. 보통 보호 브랜치로 두고 직접 push를 제한합니다.
개발 브랜치는 개발계 배포 및 통합 테스트용 브랜치입니다. 운영 배포 대상 전체를 의미하지는 않습니다.
검증 브랜치는 QA, staging, pre-production 등 운영 전 검증 환경에 배포되는 브랜치입니다.
feature 브랜치는 개별 작업을 위한 브랜치입니다. 선택 배포를 고려하면 작업 원본을 안전하게 보존하는 역할도 합니다.
배포 후보 브랜치는 운영에 나갈 feature만 모아 최종 검증하기 위한 임시 브랜치입니다.

핵심은 운영 배포 전에 별도의 배포 후보 브랜치를 만들고, 이번 배포 대상 feature만 모았다는 점입니다. 개발 브랜치에 들어간 모든 기능이 이번 운영 배포에 포함되는 구조가 아니었기 때문에, 운영 브랜치를 기준으로 배포 후보 브랜치를 만들고 배포 범위를 명시적으로 제어했습니다.

이 구조는 정석 Git Flow라고 단정하기 어렵습니다. GitLab Flow처럼 환경 브랜치를 활용하는 면도 있고, Git Flow의 release 브랜치처럼 운영 전 안정화 브랜치를 두는 면도 있습니다. 다만 develop에서 release 브랜치를 따는 전형적인 Git Flow와 달리, 운영 브랜치를 기준으로 배포 후보를 만들고 선택한 feature만 모았다는 점에서 실무형 하이브리드 구조에 가깝습니다.

4.1 일반 개발 흐름

각 개발자는 운영 브랜치 또는 팀에서 정한 최신 기준 브랜치에서 feature 브랜치를 생성하고, 개발이 끝나면 개발 브랜치에 병합해 개발계에서 테스트했습니다. 여기서 기준 브랜치는 팀 정책에 따라 달라질 수 있습니다. 중요한 것은 어느 브랜치에서 시작하고 어느 브랜치에 먼저 병합하는지 팀 전체가 동일하게 알고 있어야 한다는 점입니다.

feature/A -> 개발 브랜치 -> 개발계 배포 및 테스트
feature/B -> 개발 브랜치 -> 개발계 배포 및 테스트
feature/C -> 개발 브랜치 -> 개발계 배포 및 테스트

여기서 중요한 것은 개발 브랜치가 운영 배포의 기준이 아니라는 점입니다. 개발 브랜치에 들어간 모든 기능이 이번 운영 배포에 포함되는 것은 아니었습니다.

개발 브랜치 = 운영 코드 + feature/A + feature/B + feature/C
이번 배포 대상 = feature/A + feature/B

위와 같은 상황에서 개발 브랜치를 그대로 운영에 병합하면 feature/C까지 함께 나가게 됩니다. 따라서 feature 브랜치는 단순한 작업 공간이 아니라, 배포 범위를 선택할 수 있는 단위로도 관리되어야 했습니다. 개발 브랜치에 병합했다고 해서 feature 브랜치 원본을 바로 삭제하거나 작업 이력을 잃어버리면, 선택 배포 시점에 다시 모으기 어려워집니다.

4.2 배포 후보 브랜치 생성

배포일이 다가오면 운영 브랜치를 기준으로 배포 후보 브랜치를 생성하고, 이번 배포에 포함할 feature만 하나씩 병합했습니다. 팀에 따라 merge를 사용할 수도 있고, 필요한 커밋만 선별할 수도 있습니다. 어떤 방식을 쓰든 핵심은 운영에 나갈 변경만 배포 후보 브랜치에 들어가야 한다는 점입니다.

개발 중: feature/A, feature/B, feature/C -> 개발 브랜치 -> 개발계 테스트
배포 준비: 운영 브랜치 -> 배포 후보 브랜치 <- feature/A, feature/B
최종 흐름: 충돌 해결 -> 의존성 확인 -> 검증 환경 테스트 -> 운영 PR -> 운영 배포

이 구조의 핵심 장점은 배포 범위를 명확히 제어할 수 있다는 것입니다. 개발 브랜치에 어떤 기능들이 섞여 있어도 운영에 나갈 기능만 배포 후보 브랜치에 모을 수 있습니다.

다만 feature 간 의존성이 있다면 주의해야 합니다. 예를 들어 feature/B가 내부적으로 feature/C의 코드에 의존한다면, B만 배포 후보에 포함하고 C를 제외하는 것은 불가능하거나 위험할 수 있습니다. 선택 배포가 필요한 구조에서는 feature를 독립적으로 나누는 설계, 의존성 확인, feature flag 전략이 함께 필요합니다.

4.3 통합, 검증, 운영 반영

배포 후보 브랜치에서 가장 많이 신경 써야 했던 부분은 conflict와 최종 검증이었습니다. feature 브랜치는 작업 공간을 분리해줄 뿐, 통합 비용을 없애주지는 않습니다. 공통 컴포넌트, 라우팅 파일, 타입 정의, 설정 파일 등을 여러 feature가 동시에 수정하면 배포 후보 브랜치에 모으는 시점에 conflict가 발생할 수 있습니다.

또한 개발 브랜치에서 테스트한 조합과 배포 후보 브랜치의 조합이 다를 수 있습니다. 예를 들어 개발 브랜치에서는 A+B+C 조합으로 테스트했지만, 운영 후보에는 A+B만 포함될 수 있습니다. 따라서 최종 검증은 개발 브랜치가 아니라 실제 운영에 나갈 배포 후보 브랜치 기준으로 이루어져야 합니다.

검증이 끝나면 배포 후보 브랜치를 운랜치로 병합하는 Pull Request를 생성했습니다. 이 PR은 단순한 병합 절차가 아니라 이번 배포에 무엇이 포함되는지 확인하는 기준점 역할을 했습니다. 포함된 feature, 제외된 feature, conflict 해결 내용, 검증 결과, 배포 설정 변경 여부, rollback 기준이 한곳에 정리되어 있으면 배포 안정성이 높아집니다.

정리하면, 배포 후보 브랜치는 “배포할 기능을 모아두는 임시 브랜치”이면서 동시에 “운영 배포 전 최종 검증 기준”입니다. 따라서 배포 직전에 급하게 만들기보다 충분한 검증 시간을 두고 만드는 편이 안전합니다.

4.4 배포 후 동기화와 hotfix

운영 배포가 끝난 뒤에는 운영 브랜치를 기준으로 개발 브랜치와 검증 브랜치를 다시 맞추는 과정이 있었습니다. 그래야 배포 직후 기준점이 명확해지고, 브랜치 간 차이가 계속 누적되는 문제를 줄일 수 있습니다. 이때 운영 브랜치의 변경사항을 개발 브랜치와 검증 브랜치에 되돌려 병합할 수도 있고, 팀 정책에 따라 특정 환경 브랜치를 운영 기준으로 다시 맞출 수도 있습니다.

다만 공유 브랜치를 force push 또는 reset으로 초기화하는 방식은 위험하므로 예외적으로만 사용해야 합니다. 원격 브랜치를 맞추는 것만으로 끝나지 않고, 팀원들의 로컬 브랜치도 함께 재동기화해야 하기 때문입니다. 명령어 자체보다 중요한 것은 팀 정책과 공지입니다. 기준이 불명확하면 배포 후 동기화 과정에서 제거된 코드가 다시 살아나거나, 반대로 필요한 작업이 사라질 수 있습니다.

hotfix 흐름도 별도로 정해야 합니다. 운영 장애나 긴급 수정은 일반 feature 흐름과 분리해 생각해야 하며, 대개 운영 브랜치에서 hotfix 브랜치를 만들고 수정과 검증이 끝나면 운영 브랜치에 먼저 반영합니다. 이후 같은 수정이 다음 개발 흐름에서 사라지지 않도록 개발 브랜치, 검증 브랜치, 진행 중인 배포 후보 브랜치에도 되돌려 보내야 합니다. hotfix에는 리팩터링이나 별도 기능 변경을 섞지 않고 범위를 최소화하는 편이 안전합니다.

4.5 이 구조를 어떤 전략으로 볼 수 있는가

제가 경험한 구조는 순수한 Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development 중 하나로 딱 잘라 말하기 어렵습니다. 개발 브랜치와 운영 브랜치가 분리되어 있다는 점은 Git Flow와 닮았고, 검증 브랜치와 운영 브랜치처럼 환경을 브랜치로 표현한다는 점은 GitLab Flow와 닮았습니다. 배포 후보 브랜치를 만들어 운영 전 안정화와 검증을 한다는 점은 release 브랜치 전략과도 유사합니다.

하지만 개발 브랜치 전체를 release로 보내는 것이 아니라 운영 브랜치 기준으로 선택한 feature만 모았다는 점에서 전형적인 Git Flow와는 다릅니다. 또한 feature 브랜치가 배포 전까지 유지되고 배포 후보 브랜치에서 최종 통합된다는 점에서 Trunk-Based Development와도 다릅니다. 따라서 이 구조는 환경 브랜치와 배포 후보 브랜치를 조합한 선택 배포형 하이브리드 전략으로 이해하는 편이 가장 정확했습니다.

5. 장점과 주의점

5.1 장점

배포 범위를 명확히 제어할 수 있습니다. 개발 브랜치에 여러 feature가 섞여 있어도, 배포 후보 브랜치에는 이번 배포 대상만 모을 수 있습니다.
개발계 테스트와 운영 배포를 분리할 수 있습니다. feature 브랜치를 개발 브랜치에 병합해 개발계에서 먼저 테스트하고, 운영 전에는 배포 후보 브랜치에서 실제 배포 조합을 따로 검증합니다.
운영 배포 단위가 명확해집니다. 배포 후보 브랜치 하나가 이번 배포의 범위를 나타내기 때문에 어떤 기능이 포함되는지 추적하기 쉽습니다.
운영 브랜치를 안정적인 기준점으로 유지할 수 있습니다. 운영 브랜치에서 배포 후보 브랜치를 만들면, 개발 브랜치에 섞인 미배포 기능이 의도치 않게 운영에 포함되는 위험을 줄일 수 있습니다.
배포 후 기준점이 정리됩니다. 운영 브랜치 기준으로 개발/검증 브랜치를 맞추면 다음 작업을 현재 운영 코드에서 다시 시작하기 쉽습니다.

5.2 주의점

통합 비용이 배포 직전에 몰릴 수 있습니다. 공통 파일을 여러 feature에서 수정하면 배포 후보 브랜치를 만드는 시점에 conflict가 집중됩니다.
개발 브랜치 테스트 조합과 운영 후보 조합이 다를 수 있습니다. 최종 검증은 반드시 배포 후보 브랜치 기준으로 해야 합니다.
feature 간 숨은 의존성이 있으면 선택 배포가 깨질 수 있습니다. A만 배포한다고 생각했지만 실제로는 B나 C의 코드에 의존할 수 있습니다.
merge와 cherry-pick 같은 반영 방식이 섞이면 이력 추적이 어려워질 수 있습니다. 팀에서 어떤 방식을 쓸지 명확히 정해야 합니다.
공유 브랜치 초기화 후 로컬 동기화를 빠뜨리면 제거된 코드가 다시 살아날 수 있습니다. 공유 브랜치 조작은 사전 공지와 팀 단위 절차가 필요합니다.
미완료 작업은 feature 브랜치에 안전하게 남아 있어야 합니다. 개발 브랜치가 초기화될 수 있는 구조에서 작업 원본을 개발 브랜치에만 남겨두면 위험합니다.
숨겨야 하는 기능은 브랜치만으로 관리하지 않는 편이 좋습니다. 장기간 미노출 기능은 feature flag나 권한 제어를 함께 고려해야 합니다.

5.3 팀 규칙으로 남겨야 할 항목

브랜치 전략은 그림이나 이름보다 운영 규칙으로 남아 있어야 실수 가능성이 줄어듭니다. 제가 경험한 구조라면 모든 항목을 길게 문서화하기보다, 실제로 헷갈리기 쉬운 기준을 짧고 명확하게 정해두는 편이 좋습니다.

각 브랜치의 역할과 보호 여부
feature 브랜치를 생성하는 기준 브랜치와 먼저 병합하는 대상 브랜치
개발계, 검증계, 운영계 배포 기준
배포 후보 브랜치 생성 시점과 포함 feature 선정 방식
운영 브랜치 PR 승인 조건과 배포 체크리스트
운영 배포 후 개발/검증 브랜치 동기화 방식
hotfix 시작 브랜치, 병합 대상, 후속 동기화 절차
feature flag 사용 기준과 미배포 기능 관리 방식

6. 마무리

Git 브랜치 전략에는 하나의 정답이 없습니다. Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development는 각각의 장점이 있는 좋은 기준점이지만, 실제 프로젝트에서는 배포 주기, QA 방식, 운영 리스크, CI/CD 수준, 팀 규모에 따라 변형됩니다.

제가 경험한 구조도 정석 Git Flow라고 단정할 수 없었습니다. feature, 개발, 검증, 운영, 배포 후보 브랜치가 함께 사용되었고, 운영 배포 후에는 환경 브랜치를 운영 기준으로 다시 맞추는 정책도 있었습니다. 이론적 전략이라기보다 실제 배포 안정성과 협업 효율을 위해 만들어진 실무형 구조에 가까웠습니다.

이 경험에서 가장 기억에 남는 것은 두 가지입니다. 하나는 feature 브랜치는 통합 비용을 없애주지 않는다는 점입니다. 각자 브랜치에서 작업하더라도, 배포 전에는 하나의 브랜치에 모아야 하고 그때 conflict가 발생할 수 있습니다. "어디서 작업할 것인가"만큼 "언제 통합할 것인가"와 "어디서 최종 검증할 것인가"가 중요합니다.

다른 하나는 브랜치 전략의 본질은 이름이 아니라 규칙의 명확성이라는 점입니다. 각 브랜치의 역할, 머지 방향, 배포 기준, 배포 후 동기화 절차가 팀원 모두에게 동일하게 공유되어 있어야 합니다. 좋은 브랜치 전략은 유명한 전략을 그대로 따라 하는 것이 아니라, 우리 팀 상황에 맞게 일관성 있게 운영되는 전략입니다.

참고

- Git Flow: Vincent Driessen, nvie.com

- GitHub Flow: GitHub Docs

- GitLab Flow: GitLab 공식 사이트, GitLab Docs

- Trunk-Based Development: TrunkBasedDevelopment.com

- Trunk-Based Development: Atlassian

green