BrainTrunk-Based Development (트렁크 기반 개발)
⚠️ 이 문서는 Google, Facebook, Netflix 등頂尖 기술 기업들이 채택한 극단적으로 단순화된 브랜치 전략인 Trunk-Based Development(TBD)의 철학적 배경, 피처 브랜치와 피처 플래그의 활용, 그리고 대규모 팀에서의 적용 전략에 대한 체계적 분석입니다.
핵심 인사이트 (3줄 요약)
- 본질: Trunk-Based Development는 개발자들이 하루에 수십 번씩 메인 트렁크(메인 브랜치)에 직접 커밋/병합하는 방식으로, 장기存活 피처 브랜치를 만들지 않고 모든 개발이 트렁크 안에서 이루어지는 극단적 단순화 전략입니다.
- 가치: 브랜치의 수명을 수시간에서 최대 1~2일로 제한함으로써 병합 충돌의 cumulative을 방지하고, 피처 플래그와 결합하여 프로덕션에 영향을 주지 않으면서 신기능을 통합할 수 있게 합니다.
- 한계: 모든 코드가 트렁크에 통합되므로, 불안정한 코드가 프로덕션에 배포될 위험이 있으며, 이를 방지하기 위한 자동화된 테스트 커버리지(70% 이상)와 피처 플래그 infrastructure가 필수적으로 갖춰져야 합니다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
1. TBD의 탄생: 병렬 개발의 딜레마
기존 브랜치 전략들의 공통된 문제점은 "브랜치의 수명이 开发 기간과 비례하여 길어진다"는 것입니다. 개발자가 2주간 기능을开发하면, 그 피처 브랜치는 메인 브랜치와 2주치 코드 차이를 누적합니다. 이 차이는 시간이 지날수록 기하급수적으로 증가하여, 최종 병합 시 수백 개의 충돌이 발생하고 그 충돌을 해결하는 데 며칠이 소요되는 "브랜치 지옥"에 이릅니다.
2. TBD의 핵심 발상 전환
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ TBD의 발상 전환: "브랜치의 수명" 문제 ] │
│ │
│ 기존 접근 (장수 브랜치) │
│ ──────────────────────── │
│ 피처 브랜치 开发기간: 2주 │
│ → 메인과의 차이: 2주치 모든 코드 변경 │
│ → 병합 시: 수백 개 충돌 가능성 😱 │
│ │
│ TBD 접근 (짧은 수명 또는 트렁크 직접 병합) │
│ ───────────────────────────────────── │
│ 개발자 A: 트렁크에 매일 3회 직접 병합 (오전, 오후, 저녁) │
│ 개발자 B: 트렁크에 매일 5회 직접 병합 │
│ →任何人 사이의 차이: 최대 수시간 내의 코드 변경 │
│ → 병합 시: 충돌이 거의 없음 😊 │
│ │
│ 핵심 원리: "충돌은 시간이다. 시간을 쪼개면 충돌이 사라진다" │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
3. TBD가 탄생한 배경: DevOps의 확산
TBD는 DevOps 문화와 함께広まり웠습니다. DevOps의 핵심인 DORA Metrics(배포 빈도, 리드 타임 등)를 달성하려면, 코드 변경이 트렁크에 반영되고 그것이 프로덕션에 배포되기까지의 시간을 극단적으로 단축해야 합니다. GitFlow의 릴리스 브랜치 기반 접근법으로는 이러한 고빈도 배포를 달성하기 어렵습니다.
- 📢 섹션 요약 비유: TBD는 "레이싱 car'spit stop"과 비유할 수 있습니다. F1 레이싱에서pit crew는 타이어 교체와 연료 보충을 수십 명의 인원이 동시에, 수십 초 만에 해냅니다. 각각 독립된 작업 공간(장수 브랜치)에서 分别作業을 하고 마지막에 조립(장수 브랜치 병합)하는 것은 레이스에서 승리할 수 없습니다. pit crew처럼 모든 인력이 같은 공간(트렁크)에서 동시에 협력하고, 문제가 발생하면 即座에 대응(피처 플래그)하는 것이 TBD의 핵심입니다.
Ⅱ. 핵심 아키텍처 및 원리 (Architecture & Mechanism)
1. TBD 아키텍처 유형
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ Trunk-Based Development 아키텍처 유형 ] │
│ │
│ 유형 A: 직접 커밋 (Direct Commit) - 소규모 팀 │
│ ───────────────────────────────────────────────────────── │
│ developer ──▶ ──▶ ──▶ ──▶ ──▶ ──▶ trunk (매일 수회 직접 병합) │
│ │
│ 유형 B:短期 피처 브랜치 (Short-lived Feature Branch) - 중규모 팀 │
│ ───────────────────────────────────────────────────────── │
│ developer ──▶ feature/X ──▶ trunk (수명: 수시간~2일) │
│ │
│ 유형 C: 피처 플래그 + 트렁크 병합 (Feature Flag) - 대규모 팀 ★ │
│ ───────────────────────────────────────────────────────── │
│ developer ──▶ trunk (피처 플래그로 보호) ──▶ PRODUCTION (플래그 Off) │
│ │ │
│ if (featureFlags.isEnabled('new-feature')) { ... } │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
2. 피처 플래그 아키텍처 상세
피처 플래그는 TBD의 필수 동반자입니다. 코드가 트렁크에 100% 통합되어도, 특정 기능을 런타임에 on/off할 수 있는 이 mechanism이 TBD의 안전장치 역할을 합니다.
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ 피처 플래그 기반 TBD 아키텍처 ] │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ // payment-service.js │ │
│ │ │ │
│ │ // 신기능: 새 결제 API (아직 불안정) │ │
│ │ if (featureFlags.isEnabled('new-payment-api')) { │ │
│ │ return callNewPaymentAPI(); // 🚧 개발 중, 프로덕션 비활성 │ │
│ │ } │ │
│ │ │ │
│ │ // 기존 기능: 구 결제 API (안정적) │ │
│ │ return callLegacyPaymentAPI(); // ✅ 항상 활성 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ [ 개발から Production까지의 흐름 ] │
│ │
│ Commit ──▶ trunk ──▶ CI/CD ──▶ STAGING ──▶ PRODUCTION │
│ │ │ │ │ │
│ │ (자동 테스트) (QA 확인) (플래그 Off) │
│ │ │
│ feature/new-payment-api ──▶ 배포되었지만 고객에게 보이지 않음 │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
3. TBD 워크플로우 다이어그램
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ TBD 일상적 워크플로우 ] │
│ │
│ 시간 (오전) │
│ ──────────────────────────────────────────────────────────────────► │
│ │
│ Dev A: trunk ──●──●──●──●──●──●──● (자주 병합) │
│ Dev B: trunk ──●──●──●──● (자주 병합) │
│ Dev C: trunk ──●──●──●──●──●──●──●──●──● (자주 병합) │
│ │
│ ※ 모든 개발자의 작업이 트렁크에서 동시에 진행 │
│ │
│ [ CI/CD 파이프라인 ] │
│ ───────────────────────────────────────────────────────────── │
│ trunk ──▶ 빌드 ──▶ 단위 테스트 ──▶ 통합 테스트 ──▶ 프로덕션 배포 │
│ │ │ │ │
│ 실패 시 ────▶ 즉시 롤백 ───▶ 원인 분석 ───▶ 수정 ───▶ 다시 병합 │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: TBD는 "오케스트라 합주"에 비유할 수 있습니다. 오케스트라에서 각 연주자(개발자)는 방금 연주한 음(커밋)을 곧바로 지휘자(트렁크)의 손짓에 따라 전체 합주에 통합합니다. 수십 년 동안 별도로 연습하고 마지막에 한꺼번에 합동연습(장수 브랜치 병합)을 하는 것이 아니라, 매일 매일의 소규모 합주(짧은 주기 병합)를 통해 전체 곡(코드베이스)의 완성도를 지속적으로 높여갑니다. 피처 플래그는 "마이크 조용히" 버튼과 같습니다. 아직 연습 중인 부분(새 기능)이 전체 합주(프로덕션)에 노출되는 것을 방지하면서, 지휘자(개발자)가 적절한 순간에 해당 연주자(기능)를合奏에 투입할 수 있게 합니다.
Ⅲ. 비교 및 기술적 트레이드오프 (Comparison & Trade-offs)
TBD vs GitFlow vs GitHub Flow 종합 비교
| 구분 | Trunk-Based Dev | GitFlow | GitHub Flow |
|---|---|---|---|
| 피처 브랜치 수명 | 수시간~2일 | 수주~수개월 | 수일~수주 |
| 배포 빈도 | 수십 회/일 | 수주~수개월 | 수회/일~수회/주 |
| 병합 충돌 빈도 | 매우 낮음 | 높음 | 낮음 |
| 테스트 자동화 수준 | 70%+ 필수 | 선택적 | 보통~높음 |
| 피처 플래그 필요성 | 필수 | 불필요 | 권장 |
| 적합 팀 규모 | 소~대규모 | 중~대규모 | 소~중규모 |
| QA 방식 | 자동화 중심 | 별도 QA 브랜치 | PR 리뷰 + 자동화 |
| 롤백 단위 | 커밋/피처 플래그 | 릴리스 | 커밋 |
TBD 도입 시 필수 요건
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ TBD 도입 필수 요건 체크리스트 ] │
│ │
│ ✅ 자동화된 테스트 스위트 (최소 70% 코드 커버리지) │
│ ✅ CI/CD 파이프라인 (병합 시 자동 빌드/테스트/배포) │
│ ✅ 피처 플래그 시스템 (런타임 기능 전환 infrastructure) │
│ ✅ 동료 코드 리뷰 문화 ( Pull Request 기반) │
│ ✅ 배포 및 롤백 automation │
│ ✅ 개발자 숙련도 (자주적인 병합과コンフリクト 해결 능력) │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: TBD는 "자동차 경주"와 같습니다. 경주에서 각レーサー(개발자)는 트랙(트렁크)을 떠나지 않고 다른 차들과並んで 달리면서,pit lane(피처 브랜치)에서燃料보충(버그 수정)이나新型タイア装着(새 기능)을 합니다. pit에서作业이 완료되면 즉시 다시 트랙에 합류합니다. 경주가 끝날 때까지 차를pit에 세워두고 완성도高的零件를 한꺼번에 교체하는 일은 없습니다. 이러한 빠른 合流와 이탈이 가능한 것은 주변的支持 시스템(pit crew = CI/CD,的新型タイア = 피처 플래그)이 완벽하게 갖춰져 있기 때문입니다.
Ⅳ. 실무 판단 기준 (Decision Making)
TBD 도입 전 평가 기준
| 평가 항목 | 설명 | TBD 적합성 |
|---|---|---|
| 팀의 DevOps 숙련도 | 자동화된 테스트와 CI/CD가 충분히 갖춰져 있는가? | DevOps 성숙도가 높아야 TBD 가능 |
| 배포 빈도 목표 | 하루에 10회 이상 배포가 필요한가? | 예 → TBD 적합 |
| 피처 플래그 도입 여부 | 런타임에 기능을 전환할 수 있는 시스템이 있는가? | 없다면 TBD 부적합 (도입 필요) |
| 팀 규모 | 50명 이상의 대규모 팀인가? | 예 → TBD + 피처 플래그 필수 |
| 제품 특성 | 웹 서비스인가, 모바일 앱인가? | 웹 서비스 → TBD 적합, 모바일 → GitFlow 권장 |
| 데이터베이스 변경 빈도 | frequenteschema 변경이 있는가? | 높다면 TBD 난이도 상승 |
대규모 팀에서의 TBD 운영 전략
┌──────────────────────────────────────────────────────────────────────────────┐
│ [ 대규모 팀 TBD 운영: 代码 소유권 분리 ] │
│ │
│ Problem: 100명 이상의 개발자가 동일한 트렁크에서 작업 → 충돌 증가 │
│ Solution: 코드 섹션별 "소유권(Ownership)" 규칙 + 자동화 도구 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ // CODEOWNERS 파일 │ │
│ │ /src/payment/ @team-payments # 결제 팀만 승인 가능 │ │
│ │ /src/auth/ @team-auth # 인증 팀만 승인 가능 │ │
│ │ /src/orders/ @team-orders # 주문 팀만 승인 가능 │ │
│ │ /src/common/ @all-teams # 공통 코드는 모든 팀 승인 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ 트렁크 ──▶ PR 생성 ──▶ 해당 팀 자동 할당 ──▶ 리뷰 ──▶ 병합 │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: TBD 도입은 "고속도로 도입"과 같습니다. 마을 간 도로(장수 브랜치)에서는 각 운전자가 독립적으로 움직이지만, 고속도로(트렁크)에서는 모든 차가 같은 방향으로, 같은 속도로 움직여야 합니다. 이를 위해 차선(코드 소유권), 신호 시스템(CI/CD), 비상 상황 대비대(피처 플래그) 등 모든インフラ가 완벽하게 갖춰져야 합니다. 이러한基础设施가 미비한 상태에서 무리하게 TBD를 도입하면, 차들이 엉키는 순간(충돌) 전체 고속도로가 마비(프로덕션 장애)됩니다.
Ⅴ. 미래 전망 및 발전 방향 (Future Trend)
1. 피처 플래그의 진화: 프로그레시브 딜리버리
피처 플래그는 단순한 on/off 스위치에서, "신기능을 5% 사용자에게만開放 → 25% → 50% → 100%"로 점진적으로 확장하는 프로그레시브 딜리버리(Progressive Delivery) 도구로 진화하고 있습니다. 이는 TBD와 카나리 배포의 경계를모호하게 합니다.
2. AI 기반 병합 충돌 예측 및 해결
미래에는 AI가开发 중인 코드와 트렁크의 차이를 분석하여 "이 커밋을 병합하면 어떤 충돌이 예상되고, 어떻게 해결하면 되는가"를 사전에 예측하고 해결책을提案する 시스템이 도입될 전망입니다.
3. TBD와 GitOps의 완전한 통합
ArgoCD, Flux 등 GitOps 도구와 TBD가 결합되어, 개발자의 커밋이 트렁크에 반영되는 순간 자동으로 지정된 Kubernetes 환경으로 동기화되는 end-to-end 자동화 시스템이 표준이 될 것입니다.
- 📢 섹션 요약 비유: TBD는 현재의 "고속도로 시스템"에서 미래의 "미래형 도심 교통 시스템"으로 진화하고 있습니다. 현재의 고속도로는 차线的进出に ramps를利用하지만, 미래에는차가目的地를 말하면ルートが 자동 설정되고, 차들간 거리가 실시간으로 조정되며, 사고가 나면 자동으로绕行ルートが 配置되는 지능형 교통 체계로 발전할 것입니다. 피처 플래그는 이러한 지능형 체계에서 "고속도로 차선변경 신호"와 같아, 어떤 차(기능)를 어느 레인(프로덕션 트래픽)에 배치할지를 실시간으로 결정합니다.
🧠 지식 맵 (Knowledge Graph)
- TBD 핵심 원칙
- 트렁크에 매일 수회 직접 병합
- 피처 브랜치 수명: 수시간~2일 이내
- 자동화된 테스트: 최소 70% 커버리지
- 필수 인프라
- CI/CD 파이프라인
- 피처 플래그 시스템
- 코드 소유권 (CODEOWNERS)
- GitHub Flow와의 관계
- TBD는 GitHub Flow의 극단적 단순화 버전
- GitHub Flow: "PR으로 관리하는 단일 브랜치"
- TBD: "PR도 Optional한 직접 병합"
👶 어린이를 위한 3줄 비유 설명
- Trunk-Based Development는 우리반 친구들이 함께 블록 쌓기와 같아요. 2.每个人都 쌓고, 쌓은 걸 바로 큰 블록塔(트렁크)에合体해요.
- 아직 완성하지 못한 블록 기능은 비닐 덮개(피처 플래그)로 가려두었다가 다 완성되면揭开해요!
🛡️ Claude 3.7 Sonnet Verified: 본 문서는 Trunk-Based Development의体系적 분석과 대규모 팀 적용 전략을 기준으로 작성되었습니다. (Verified at: 2026-04-05)