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

도입

트렁크 기반 개발(TBD, Trunk-Based Development)은 모든 개발자가 단일 트렁크(메인 브랜치)에 짧은 주기로 계속 병합해 나가는 방식입니다. 기능별로 브랜치를 오래 띄워두는 대신, 작은 단위로 자주 통합하면서 미완성된 기능은 feature flag로 가려두는 게 핵심입니다. 이 글에서는 TBD를 GitFlow와 비교하기보다(그 비교는 별도 글에서 다뤘습니다), TBD 자체의 원칙과 실무 적용 방법을 자세히 다룹니다.

 

TBD로 바꾸기 위해 확인해야할 3가지는 이전 블로그글을 확인해주세요.

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

 

 

핵심 원칙

트렁크 기반 개발을 한 줄로 요약하면 "트렁크를 항상 배포 가능한 상태로 유지하면서, 가능한 한 자주 병합한다"입니다. 이 원칙이 지켜지는지를 가르는 세 가지 요소가 있습니다.

원칙	설명	실무 팁
초단명 브랜치	브랜치는 만들더라도 생명이 짧다(수 시간~최대 1~2일 수준)	작업을 작게 쪼개서 병합 단위를 생명주기에 맞추는 게 먼저
feature flag 활용	미완성 기능은 토글로 가려두고 코드는 병합	플래그 정리 시점을 필수로 관리하지 않으면 토글 더미가 쌓여서 코드가 깊어짐
강력한 CI	병합 직전에 자동 테스트가 트렁크를 보호	테스트가 느리거나 불안정하면 TBD 자체가 작동하지 않음

실전 단계별 적용 방법

1. 버그/작은 기능 단위로 이슈를 쪼개기: "로그인 화면 개편"같은 큰 작업을 하나의 PR로 묶는 대신, 하루~이틀 안에 병합할 수 있는 단위로 미리 나눠놓습니다.
2. 브랜치를 파고 바로 커밋: 브랜치를 파더라도 그 자리에서 오래 머무르지 않고, 작업이 끝나는 즉시 트렁크로 병합합니다. 병합 전 최신 트렁크를 rebase해 충돌 여지를 미리 줄입니다.
3. 미완성 기능은 flag 뒤에 감추기: UI에 노출되면 안 되는 코드는 if (flag.isEnabled("new_checkout"))처럼 토글로 감싸서 병합합니다. 미완성 상태라도 트렁크에 있을 수 있지만, 빌드는 깨지지 않아야 합니다.

// 간단한 feature flag 예시
if (featureFlags.isEnabled("new_checkout")) {
  renderNewCheckout();
} else {
  renderLegacyCheckout();
}

1. CI가 항상 트렁크를 감시: 병합될 때마다 자동 빌드·테스트가 돌고, 실패하면 트렁크가 깨진 상태로 간주되어 다음 사람이 버그를 이어 받는 일이 없도록 합니다. 간단한 파이프라인 예시는 아래와 같습니다.

on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

저는 Android 프로젝트에서 Firebase Remote Config를 앱 기능 on/off 토글, A/B 테스트, 그리고 버전 코드 기반 강제 업데이트 체크까지 세 가지 용도로 써봤는데, 이 경험에 비춰보면 feature flag가 편해지는 만큼 관리 부담도 같이 늘어난다는 걸 체감했습니다. 특히 A/B 테스트용으로 잠깐 켜뒀던 플래그를 실험이 끝난 뒤에도 정리하지 않고 방치하면, 나중에 이 분기가 왜 있었는지조차 기억이 안 나는 경우가 생깁니다.

주의사항 / 흔한 실수

• 브랜치가 사실상 장기화되는 경우: TBD를 도입했다고 말하면서도 브랜치를 며칠씩 파놓고 있으면 이름만 TBD입니다. 병합 주기를 팀이 함께 감시해야 합니다.
• 테스트 없이 flag만 달기: feature flag는 테스트가 뒷받침되는 안전망이지, 테스트 자체를 대체하지 않습니다. flag의 두 경로(on/off)를 모두 CI에서 검증하지 않으면 토글 전환 순간 장애가 터집니다.
• 코드 리뷰가 병목: 브랜치가 짧은 만큼 리뷰도 빨라야 합니다. 리뷰가 느리면 결국 브랜치가 묵히면서 TBD의 장점이 사라집니다.
• 오래 남은 flag 정리: 전환이 끝난 flag를 정리하지 않으면 코드베이스가 분기문으로 뒤덮여 갑니다. flag는 만든 사람이 다시 그 자리에서 정리하는 것까지 프로세스에 포함해야 합니다.

제 경우엔 강제 업데이트 체크처럼 앱이 살아있는 한 계속 유지돼야 하는 플래그와, A/B 테스트처럼 결론이 나면 반드시 걷어내야 하는 플래그를 같은 방식으로 관리하다가 후자가 계속 쌓이는 걸 겪은 뒤로, 플래그를 만들 때부터 '영구'와 '한시적'을 구분해두는 습관을 들이고 있습니다.

마무리

TBD의 핵심은 "브랜치 전략"이 아니라 "통합 빈도와 트렁크 안정성을 지키는 규율"입니다. 짧은 브랜치, feature flag, 강력한 CI 이 세 가지가 함께 갖춰져야 제대로 작동합니다. 도구를 바꾸는 것보다, 팀이 작은 단위로 작업하고 미완성 코드를 안전하게 감추는 습관을 먼저 만드는 게 전환의 실질입니다.

Q&A

Q. 팀 규모가 작아도 TBD를 도입할 가치가 있나요?

A. 있습니다. 오히려 인원이 적을수록 리뷰·병합 과정을 가볍게 가져가는 게 유리할 수 있지만, CI 테스트가 미비하면 병합 자체가 위험해지므로 테스트 자동화를 먼저 정비하는 게 순서입니다.

Q. feature flag 도구는 무엇을 써야 하나요?

A. 앱 프로젝트라면 Firebase Remote Config처럼 무료로 쉽게 시작할 수 있는 도구로도 기능 토글·A/B 테스트·강제 업데이트 체크까지 충분히 됩니다. 팀 규모와 flag 수가 늘어나면 Unleash, Harness 같은 전용 툴로 옮겨가는 것도 고려할 만합니다.

---

[핵심요약] 트렁크 기반 개발(TBD)의 원칙과 실무 적용 방법