Trunk-Based Development

왜 쓰는가

대부분의 병합 문제는 코드 품질보다 "통합 지연"에서 시작됩니다. 브랜치 수명이 길어질수록 충돌 비용과 리뷰 비용이 급증합니다.

TBD는 이를 줄이기 위한 방식입니다.

• 짧은 브랜치
• 작은 PR
• 빠른 main 통합

운영 규칙

1. main은 항상 배포 가능 상태 유지
2. 브랜치 수명은 짧게(보통 1일 이내)
3. 미완성 기능은 feature flag로 숨김
4. CI 실패 시 merge 금지

추천 지표

• PR lead time
• 배포 빈도
• 변경 실패율
• MTTR

자주 하는 실수

• PR이 너무 커서 리뷰 병목
• flaky test 방치로 CI 신뢰 하락
• feature flag 제거 누락으로 기술부채 누적

요약

TBD의 핵심은 철학이 아니라 운영 규율입니다. 작은 변경을 빠르게 통합하는 습관이 잡히면 릴리즈 리드타임과 장애 복구 속도가 같이 개선됩니다.