Git 브랜치를 TBD로 바꾸기 전에 확인해야 할 3가지

도입

Git 브랜치 전략을 TBD(Trunk-Based Development)로 바꿀까 GitFlow를 유지할까 고민하는 팀이라면, 결론부터 말씀드리면 "하루 여러 번 배포하고 싶고 CI를 믿을 수 있다면 TBD, 여러 버전을 동시에 유지보수해야 한다면 GitFlow"입니다. 이번 글에서는 TBD가 GitFlow와 구체적으로 무엇이 다른지, 그리고 도입하려면 무엇을 먼저 갖춰야 하는지를 정리해보겠습니다.

TBD란 무엇인가

Trunk-Based Development는 모든 개발자가 짧은 수명의 브랜치만 파고, 하루~이틀 안에 main(trunk)에 병합한 뒤 바로 삭제하는 방식입니다. GitFlow처럼 develop/release/hotfix 등 여러 종류의 장기 브랜치를 두지 않고, main은 언제든 배포 가능한 상태로 유지하는 것이 핵심 규칙입니다. 변경사항이 작고 자주 통합되니까 충돌이 누적되기 전에 일찍 발견되고, 릴리스할 때도 변경량이 작아 충돌 범위가 좁혀집니다.

GitFlow와 실무에서 체감되는 차이

GitFlow는 develop 브랜치에서 기능을 모으고, release 브랜치를 따서 QA한 뒤 main에 반영하는 구조라 다중 버전을 동시에 지원하거나 정해진 일정에 맞춰 배포해야 하는 팀에 잘 맞습니다. 반면 TBD는 브랜치 자체가 오래 살아남지 않으므로 병합 시점의 충돌 복잡도가 낮고, 배포 빈도를 끌어올리기가 훨씬 수월합니다. 실제로 GitFlow를 처음 제안한 저자 본인도 지속적 배포를 하는 팀에는 더 이상 GitFlow를 권하지 않는다고 밝힌 바 있습니다.

도입 전 반드시 갖춰야 할 것들

TBD는 브랜치 전략만 바꾼다고 되는 게 아니라 아래 세 가지가 뒷받침돼야 합니다.

1. 빠르고 신뢰할 수 있는 CI: 병합 전에 짧은 시간 안에 결과가 나와야 개발자들이 실제로 자주 병합합니다. CI가 느리거나 자주 실패하면 다들 병합을 미루게 되고 TBD는 무너집니다.
2. Feature flag: 아직 완성되지 않은 기능도 main에 병합해야 하므로, 배포(deploy)와 실제 노출(release)을 분리하는 feature flag가 필수입니다. flag 없이 미완성 코드를 그냥 병합하면 main이 항상 배포 가능하다는 전제 자체가 깨집니다.
3. 브랜치 보호 및 머지 정책: main에 들어가기 전 리뷰·체크 통과를 강제하는 보호 규칙, 그리고 팀 규모가 커지면 병합 충돌을 줄이는 머지 큐가 필요합니다.

도입을 검토하며 걸리는 지점들

아직 TBD를 실제로 도입해본 적은 없고, 지금은 저희 팀에 맞을지 검토하는 단계입니다. 그래도 원칙을 읽고 실무에 대입해보면 미리 걸리는 지점들이 있습니다.

브랜치 수명을 짧게 가져가야 한다는 원칙은 이해가 되는데, 실제로 저희 팀 작업 단위가 하루~이틀 안에 끝날 만큼 잘게 쪼개져 있는지는 도입 전에 먼저 점검해봐야 할 부분입니다. 지금처럼 기능 단위로 크게 브랜치를 파는 습관이 남아있다면, 방침만 TBD로 바꾼다고 바로 따라가지지는 않을 것 같습니다.

feature flag도 마찬가지입니다. 개념만 보면 스위치 하나 추가하는 정도로 가볍게 느껴지는데, 막상 도입 사례들을 찾아보니 flag를 언제 켜고 끌지 정하는 규칙, 그리고 기능이 안정화된 뒤 flag를 제때 정리하는 절차까지 함께 갖추지 않으면 오히려 관리 부담이 하나 더 늘어나는 구조라는 점이 검토하면서 새롭게 보였습니다.

CI 속도와 신뢰도도 저희 팀이 먼저 짚어봐야 할 전제조건입니다. 지금 CI가 TBD를 뒷받침할 만큼 빠르고 안정적인지부터 확인한 뒤에 전환 순서를 정할 계획입니다.

주의사항 / 흔한 실수

• 브랜치 수명을 "짧게"라고만 정해두고 구체적 기준(예: 이틀 이내)을 팀 규칙으로 명시하지 않으면 흐지부지됩니다.
• feature flag를 켜고 끄는 것까지만 관리하고, 기능이 안정화된 뒤 flag 자체를 제거하는 절차를 빼먹으면 코드가 지저분해집니다.
• CI가 느린 상태에서 TBD만 먼저 도입하면 오히려 병합이 미뤄지며 역효과가 납니다. 도입 순서는 CI 개선이 먼저입니다.
• 다중 버전을 동시에 유지보수해야 하는 라이브러리·SDK 성격의 프로젝트라면 TBD만으로는 부족하고 release 브랜치를 부분적으로 병행하는 것이 현실적입니다.

마무리

TBD는 브랜치 전략을 바꾸는 문제가 아니라 CI·feature flag·머지 정책이라는 세 가지 전제를 먼저 갖추는 문제에 가깝습니다. 이 셋 중 하나라도 준비가 안 된 상태에서 브랜치 정책만 TBD로 바꾸면 오히려 혼란이 커질 수 있으니, 팀의 배포 빈도와 버전 유지보수 요구사항을 먼저 점검한 뒤 전환 여부를 결정하시길 권합니다.

Q&A

Q. 팀 규모가 작으면 TBD가 항상 유리한가요?

A. 규모보다는 배포 빈도와 CI 신뢰도가 기준입니다. 소규모 팀이라도 CI가 느리거나 불안정하면 TBD 도입이 오히려 부담이 될 수 있습니다.

Q. Feature flag 없이 TBD를 시도해도 되나요?

A. 미완성 기능을 그대로 main에 병합하게 되므로 권장되지 않습니다. flag로 배포와 노출을 분리하는 것이 TBD의 전제조건 중 하나입니다.

 

TBD 원칙과 실무 적용방법 정리는 다음 블로그글을 읽어주세요!

트렁크 기반 개발(TBD), 원칙과 실무 적용 방법 정리

 

 

---

[핵심요약]

Git TBD 전략과 GitFlow 차이, 도입 전제조건 정리