Trunk Based Development란 무엇인가
Trunk Based Development(TBD)는 모든 개발자가 ‘main’ 혹은 ‘trunk’라고 부르는 단일 브랜치에 코드를 짧은 주기로 병합하는 브랜치 전략입니다. Git Flow처럼 feature, develop, release 등 여러 브랜치를 오래 유지하는 대신, 하나의 트렁크 브랜치를 중심에 두고 작업 단위를 최대한 잘게 쪼개어 자주 통합하는 것이 핵심입니다.
비유하자면 Git Flow가 여러 지류가 합쳐지는 강 하구와 같다면, TBD는 처음부터 하나의 큰 본류만 흐르게 하고 모든 물줄기가 그 본류로 바로 합류하도록 만드는 방식입니다.
동작 원리와 예시
TBD를 실천하는 개발자는 기능 하나를 통째로 완성한 뒤 병합하지 않고, 하루 이틀 안에 끝낼 수 있는 작은 단위로 쪼개서 커밋하고 곧바로 ‘main’에 병합합니다. 아직 완성되지 않은 기능이 사용자에게 노출되지 않도록 하기 위해 feature flag(기능 플래그)를 활용하는 경우가 많습니다.
- 개발자는 로컬에서 짧은 수명의 브랜치를 만든다 (하루 이내 존재)
- 코드 리뷰와 자동화 테스트를 통과하면 즉시 ‘main’에 병합한다
- 미완성 기능은 feature flag로 off 상태를 유지한다
- 병합 즉시 CI 파이프라인이 빌드와 테스트를 검증한다
예를 들어 결제 기능에 새로운 할인 로직을 추가한다면, 전체 로직이 끝날 때까지 기다리지 않고 ‘할인율 계산 함수 추가’, ‘할인 UI 노출’ 같은 작은 단위로 나눠 각각 병합하면서 feature flag로 사용자에게는 아직 보이지 않게 관리합니다.
실무에서 왜 쓰는지
TBD가 주목받는 이유는 CI/CD 문화와 궁합이 좋기 때문입니다. 브랜치가 오래 살아있으면 병합 시점에 충돌이 커지고, 통합 테스트도 늦게 이뤄져 문제 발견이 지연됩니다. 반면 TBD는 병합 주기가 짧아 충돌 범위가 작고, 문제가 생겨도 원인 커밋을 빠르게 특정할 수 있습니다.
또한 배포 자동화 파이프라인을 구축한 팀이라면 ‘main’ 브랜치가 항상 배포 가능한 상태를 유지해야 하는데, TBD는 이 원칙과 자연스럽게 맞아떨어집니다. 구글, 페이스북 등 대규모 트렁크를 운영하는 회사들도 이 전략을 채택하며, 브랜치 관리 비용을 줄이고 배포 속도를 높이는 데 활용하고 있습니다.