Nested Feature Branch Workflow 전략으로 브랜치 관리
규모가 큰 프로젝트를 시작할 때면, 언제나 브랜치 전략을 어떻게 가져갈지가 고민입니다. 저 역시 피쳐(Feature) 단위의 프로젝트를 진행하며 여러 시행착오를 겪었고, 현재 정착하게 된 제 경험을 바탕으로 브랜치 관리 방법을 정리해 보았습니다. 팀원들과 공유하기 위해 그렸던 간단한 플로우 차트와 함께 소개합니다.
저는 이 고민에 대한 솔루션으로 Nested Feature Branch Workflow (중첩된 기능 브랜치 워크플로우) 전략을 사용하고 있습니다.
Nested Feature Branch Workflow란?
이 방식의 핵심은 하나의 큰 기능을 개발할 때, 그 아래에 여러 개의 하위 기능 브랜치를 두어 작업을 잘게 쪼개서 진행하는 것입니다.
- 하나의 거대한 기능을 담당하는 Root 브랜치를 생성합니다.
- 각각의 세부 작업(하위 피처)들은 이 Root 브랜치에서 분기하여 독립적으로 진행합니다.
- 각 하위 작업이 완료되면, 다시 Root 브랜치로 병합(Merge)합니다.
- 최종적으로 모든 하위 작업이 완료된 Root 브랜치 딱 하나만
develop브랜치에 병합됩니다.
어떻게 활용하는가?
보통 하나의 큰 기능을 개발할 때, 하위 브랜치는 크게 4가지 역할로 나뉩니다. (물론 프로젝트 성격에 따라 달라질 수 있습니다.)
- Root (모든 하위 브랜치의 부모)
- 레이아웃 / UI
- API 연동
- 비즈니스 로직
이 네 가지 브랜치는 상황에 따라 더 세부적으로 나뉘기도 합니다. 특히 아래와 같은 상황에서 이 전략은 빛을 발합니다.
- 공통 컴포넌트를 건드릴 때: 같은 레포지토리를 사용하는 동료들에게 영향 범위를 명확히 알려야 할 경우
- 복잡한 비즈니스 로직을 다룰 때: 로직의 규모가 크고 복잡하여 아주 상세한 리뷰가 필요한 경우
- 확신이 부족할 때: 작성한 코드에 대해 동료들의 조언이나 토론이 필요한 경우
이 방식을 도입한 이후, 각 기능이나 수정 사항이 독립된 브랜치에서 격리되어 작업 되므로 변경 사항을 파악하기가 훨씬 수월해졌습니다. 무엇보다 코드 리뷰의 효율성을 높이는 데 큰 도움이 되었습니다. 리뷰어는 거대한 PR 하나를 보는 대신, 잘게 쪼개진 맥락 있는 PR 여러 개를 보면 되니까요.
단점과 극복
물론, 이 방식이 장점만 있는 것은 아닙니다.
- 복잡성 증가: 구조 자체가 복잡합니다. 여러 하위 브랜치를 동시에 관리해야 하므로 브랜치 간 의존성이 늘어나고 충돌 가능성도 높아집니다.
- 관리 오버헤드: 브랜치를 만들고 관리하는 데 상당한 노력이 들어갑니다. 매번 PR 디스크립션을 작성해야 하는 번거로움도 무시할 수 없습니다.
- 병합 충돌의 위험: 하위 브랜치가 많아질수록 최종적으로 Root 브랜치에 병합될 때 충돌이 발생할 확률이 높습니다. 이를 해결하는 데 시간과 노력이 필요합니다.
결론
모든 전략에는 트레이드오프가 있듯이, Nested Feature Branch Workflow도 마찬가지입니다.
하지만 저는 이 전략이 가져다주는 코드 리뷰 생산성 향상이라는 장점이 앞서 언급한 세 가지 단점을 상쇄하고도 남는다고 생각합니다.
물론 모든 규모의 팀이나 프로젝트에 적합한 만능 열쇠는 아닙니다. 하지만 협업이 활발하고 코드 리뷰의 품질을 중요하게 생각하는 팀이라면, 특히 큰 규모의 프로젝트를 앞두고 있다면 이 방식을 한번 활용해 볼 만한 가치가 충분히 있다고 생각합니다.