# 트렁크 기반 개발이란: 최신 DevOps 팀의 분기 전략 URL: https://codebasechat.com/ko/journal/trunk-based-development-what-is Type: blog Locale: ko Published: 2026-09-22 Updated: 2026-09-22 --- > 트렁크 기반 개발은 모든 개발자가 매일 공유 브랜치에 병합하는 분기 전략입니다. 장수명 브랜치는 없고, 피처 플래그로 미완성 작업을 관리합니다. DORA 연구에서 확인된 DevOps 성과의 핵심 요소입니다. ## 트렁크 기반 개발이란 트렁크 기반 개발(Trunk-Based Development)은 모든 개발자가 하나의 공유 브랜치(보통 `main` 또는 `trunk`라고 불림)에 최소 하루에 한 번은 병합하는 분기 전략입니다. 장수명 피처 브랜치는 없습니다. 코드는 항상 프로덕션 배포 가능 상태로 유지됩니다. 피처가 준비되지 않았다면, 브랜치로 팀과 격리된 코드가 아니라 피처 플래그가 사용자로부터 숨깁니다. 이것이 간단한 설명입니다. 더 자세한 버전은 현재 워크플로우가 생각보다 많은 위험을 만들고 있을 수 있는 이유를 포함합니다. ## 장수명 브랜치가 부채가 되는 이유 대부분의 팀은 버전 관리를 피처 브랜치를 통해 배웁니다. 티켓당 한 브랜치, 리뷰 후 병합. 정리되어 보입니다. 브랜치가 24시간 이상 유지되면, 동료들이 main에 하는 모든 커밋은 아직 확인하지 못한 미래의 충돌입니다. 8명 엔지니어 팀에서 각각 2주짜리 브랜치를 들고 있다면, 하나의 통합을 실행하는 게 아닙니다. 매일 조금씩 더 멀어지는 8개의 평행한 세상을 관리하고 있는 것입니다. 병합 날은 작업이 아닙니다. 협상입니다. DORA 연구(수천 개 팀에 걸쳐 실시된 소프트웨어 전달 성능에 대한 가장 큰 규모의 종단 연구)는 여기서 명확한 경계를 그음니다. 24시간 이상 유지되는 브랜치는 배포 빈도 감소와 변경 실패율 증가의 예측 신호입니다. 최고 성과를 내는 팀은 하루에 여러 번 통합합니다. 나머지는 피처가 "완료"될 때 병합하는데, 이는 종종 깔끔하게 병합되지 않음을 의미합니다. 숨겨진 비용은 병합 충돌 자체가 아닙니다. 코드 작성 후 3주 후에 충돌을 해결하는 데 필요한 컨텍스트 전환입니다. 그 의도가 무엇이었는지 아무도 기억하지 못합니다. ## 트렁크 기반 개발의 실제 작동 방식 메커니즘은 간단합니다. main을 당겨옵니다. 작고 일관성 있는 변경을 합니다. 테스트 스위트를 실행합니다. main에 푸시합니다. 이 모든 과정은 점심시간 전에 일어나야 합니다. 개인 프로젝트에서 작은 저장소의 기여자라면, 이미 이렇게 작동합니다. 20명 팀이 300K LOC 모놀리식에서 작동한다면, 세 가지 방식이 함께 작동해야 합니다. **단기 브랜치(선택사항이지만 흔함)**: 일부 팀은 병합을 강제하기 전에 최대 2일까지 브랜치를 유지합니다. 이는 다중 주 발산을 만들지 않으면서 코드 리뷰 문화를 유지합니다. 브랜치는 격리 메커니즘이 아니라 리뷰 도구입니다. **모든 푸시에서의 지속적 통합**: main에 모든 커밋은 전체 빌드와 테스트 스위트를 트리거합니다. 깨지면, 2주 피처 브랜치가 금요일 4pm에 랜딩한 후가 아니라 몇 분 내에 깨집니다. **불완전한 작업을 위한 피처 플래그**: 미완성 피처는 플래그 뒤에서 프로덕션으로 배포됩니다. 사용자는 아무것도 봅니다. 팀은 모든 것을 통합합니다. 이것이 대부분의 팀이 건너뛰는 부분이며, 첫 TBD 실험이 실패하는 이유입니다. 이러한 방식은 어느 것도 트렁크 기반 개발에만 국한되지 않습니다. 차이점은 TBD가 이들을 선택사항이 아닌 필수사항으로 만든다는 것입니다. ## 피처 플래그: TBD를 작동시키는 메커니즘 ![랩탑 키보드에서 작업하는 개발자의 손과 화면에 표시된 피처 플래그 대시보드](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) 피처 플래그는 런타임에 평가되는 코드의 조건부입니다. 플래그가 꺼져 있으면, 새로운 코드 경로는 실행되지 않습니다. 켜져 있으면, 특정 사용자, 트래픽의 일정 비율, 또는 전체 사용자 기반에 대해 실행됩니다. 이것은 단순해 보입니다. 함의는 그렇지 않습니다. 배포를 릴리스에서 분리할 수 있습니다. 코드는 지속적으로 프로덕션으로 배포됩니다. 피처는 준비되면 시작되거나, 롤아웃이 잘못되고 3주의 커밋을 롤백하는 대신 10초 안에 킬해야 하는 경우 시작되지 않습니다. 최소 실행 가능 설정에는 세 가지가 필요합니다. 플래그를 정의하는 방법, 런타임에서 평가하는 방법, 재배포 없이 변경하는 방법입니다. 평면 JSON 설정 파일은 3명 팀에서 작동합니다. 전용 피처 관리 서비스는 약 10명 엔지니어 또는 "독일의 베타 코호트의 사용자에 대해 활성화"와 같은 타겟팅 규칙이 필요한 플래그가 시작될 때 복잡성을 정당화합니다. 추적해야 할 한 가지: 플래그 부채. 피처 배포 후 정리되지 않은 플래그는 조건부 스파게티가 됩니다. TBD를 올바르게 실행하는 팀은 피처가 완전히 롤아웃된 후 한 스프린트 내에 각 플래그를 폐기합니다. 플래그를 임시 스캐폴딩으로 취급하세요. 영구 설정이 아닙니다. ## TBD 대 Gitflow: 2026년 직접 비교 Gitflow는 분기별 순환으로 배포되는 박스형 소프트웨어를 위해 2010년에 설계되었습니다. 릴리스를 장수명 브랜치로 모델링합니다. 매일 또는 매시간 배포하는 팀의 경우, 해당 모델은 더 이상 적용되지 않습니다. CI/CD를 실행하는 팀에 대한 비교는 다음과 같습니다: **브랜치 수명**: Gitflow는 일에서 주 단위로 실행됩니다. TBD는 시간에서 최대 1-2일로 실행됩니다. **병합 충돌**: Gitflow는 빈번한 높은 심각도의 충돌을 생성합니다. TBD는 통합 간격이 주가 아닌 시간이기 때문에 드물고 낮은 심각도의 충돌을 생성합니다. **배포 빈도**: Gitflow는 릴리스 브랜치에 배포를 연결합니다. TBD는 배포와 릴리스를 완전히 분리합니다. **롤백 메커니즘**: Gitflow는 브랜치 병합을 되돌려 롤백합니다. TBD는 피처 플래그를 끄면 됩니다. **온보딩 복잡성**: Gitflow는 develop/main/hotfix 규칙을 이해해야 합니다. TBD는 한 브랜치만 있습니다: main. **필요한 CI 투자**: Gitflow는 낮습니다(브랜치가 위험을 흡수함). TBD는 높습니다(main은 항상 녹색이어야 함). Gitflow는 모든 문맥에서 틀렸습니다. App Store에 모바일 앱을 배포하고 몇 분 내에 핫픽스를 푸시할 수 없다면, 릴리스 브랜치 모델이 의미가 있습니다. SaaS를 배포에 완전히 제어한다면, 추가 분기 구조는 안전성을 추가하지 않으면서 조정 비용을 추가하는 오버헤드입니다. ## DORA 메트릭이 분기 전략에 대해 말하는 것 ![공유된 화면에서 페어 프로그래밍과 코드 리뷰를 수행하는 두 엔지니어](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) [DORA DevOps 상태 연구](https://dora.dev/research/)는 2014년부터 소프트웨어 전달 성능을 추적해왔습니다. 여기서 직접 관련된 데이터의 두 가지 발견이 있습니다. 첫째, 트렁크 기반 개발은 DORA 모델의 소프트웨어 전달 성능을 예측하는 24가지 역량 중 하나입니다. "지속적 전달" 클러스터 아래에 있으며, 이는 DORA가 이를 팀 선호도가 아니라 인프라 방식으로 취급함을 의미합니다. 둘째, 최고 성과 팀은 하루에 여러 번 배포합니다. 성과가 낮은 팀은 주당 한 번 또는 월당 한 번 배포합니다. 장수명 브랜치와 불빈번한 통합은 데이터 전체에서 느린 분포의 끝에 나타나고 여러 해에 걸쳐 나타납니다. 연구가 주장하지 않는 것: TBD가 최고 성과를 야기한다는 것. TBD를 성공적으로 채택한 팀은 자동 테스트, 작동하는 CI 파이프라인, 소형 커밋의 습관을 이미 가지고 있는 경향이 있습니다. 트렁크 기반 개발은 이들이 누락된 경우 즉시 노출합니다. 팀이 CI와 40% 테스트 플래키함이 없다면, TBD로 전환해도 이득이 없을 것입니다. 단지 main을 더 자주 깨질 것입니다. ## 트렁크 기반 개발이 더 이상 의미가 없는 곳 TBD가 해결하는 것보다 더 많은 문제를 만드는 세 가지 시나리오: **릴리스 전 승인 게이트가 필수인 높은 규제 환경**: 모든 릴리스가 배포되기 전에 컴플라이언스 서명이 필요한 경우, 프로덕션으로의 지속적 배포는 어쨌든 차단됩니다. 분기 모델은 보조적입니다. 분기 전략과 관계없이 변경사항을 일괄 처리합니다. **충분하지 않은 테스트 스위트**: TBD는 빠르고 신뢰할 수 있는 CI 파이프라인이 필요합니다. 빌드에 45분이 걸리고 20% 플래키함이 있으면, 개발자는 대기를 피하기 위해 커밋을 일괄 처리합니다. 이것은 모델을 무효화합니다. 제약은 분기 규칙이 아니라 테스트 인프라입니다. **코드 소유권이 일관되지 않은 매우 큰 팀**: 50명 이상의 팀에서 각 스쿼드가 별개 서비스를 소유하는 경우, TBD는 서비스 수준에서 잘 작동합니다. 모든 사람이 모든 것을 만지는 공유 모놀리식 전체에 적용하려면 엄격한 린팅 규칙과 CI 소유권 규칙이 필요합니다. 이 모든 경우에, 해결책은 다른 분기 전략이 아닙니다. 해결책은 근본적인 인프라 문제입니다. TBD는 단지 그 문제를 더 빨리 노출합니다. ## 배포를 중단하지 않고 마이그레이션하는 방법 대부분의 팀이 잘못 이해하는 마이그레이션: TBD를 발표하고, 피처 브랜치 규칙을 삭제하고, 첫 주에 main이 깨지는 것을 봅니다. 더 안전한 경로: - **기존 브랜치를 유지하고, 수명 규칙 추가**: 브랜치는 3일 이상 유지할 수 없습니다. 이것은 다중 주 발산을 꺼지 않으면서 빈번한 통합의 압박을 강제합니다. 브랜치는 격리 메커니즘이 아니라 리뷰 도구입니다. - **마이그레이션 전에 CI를 도구화**: 병합이 빨라지기 전에, 병합은 안전해야 합니다. 테스트 스위트가 녹색인지, 15분 이내에 실행되는지, main 브랜치의 실패를 차단하는지 확인하세요. - **한 피처를 플래그로 게이트**: 모든 미완성 피처를 위해 필요하기 전에 플래그 관리 근육을 구축하세요. - **주마다 브랜치 수명을 줄이기**: 3일에서 2일에서 6주 동안 1일로. 앞선 지표로 병합 충돌 빈도를 추적하세요. 떨어지면, 모델이 작동합니다. - **새 규칙이 작동할 때만 이전 규칙 폐기**: Gitflow 규칙은 파일럿 외부의 모든 것에 남아있습니다. 6-8주 동안 두 모델을 모두 실행하는 것은 괜찮습니다. ## TBD가 유지되는지 여부를 예측하는 한 가지 습관 ![CI/CD 파이프라인 대시보드를 모니터링하는 엔지니어와 녹색 배포 상태 지표](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) 트렁크 기반 개발은 팀이 main에 병합할 수 없어서 실패합니다. 개발자가 하루에 배포할 수 있는 크기의 작은 작업으로 작업의 범위를 지정하는 습관이 없어서 실패합니다. 근본 변화는 기술적이지 않습니다. 작업이 계획에서 어떻게 정의되는지에 관한 것입니다. "새로운 결제 흐름 구현"이라고 하는 스토리는 2주 브랜치 대기합니다. "라우트 핸들러를 추가하고 플래그 `payment-v2` 뒤에서 501을 반환"이라고 하는 스토리는 반나절 커밋입니다. 이는 대부분의 팀이 구축하지 못한 PM 관여와 백로그 위생이 필요합니다. 분기 전략 변경은 발표하는 데 하루가 걸립니다. 범위 지정 규칙은 구축하는 데 6개월이 걸립니다. TBD에 유지하는 팀은 전환 전에 세 가지에 투자한 팀입니다: sub-15분 CI 파이프라인, 작동하는 피처 플래그 서비스, 매일 종료할 수 있는 스토리를 생성하는 스프린트 의식. 이 세 가지가 없으면, 분기 규칙은 틀린 레버입니다. ## TBD 워크플로우를 실행하는 데 도움이 되는 도구 팀 수준에서 트렁크 기반 개발을 실행하는 것은 더 많은 동기식 정렬을 의미합니다. 통합 표류를 포착하는 빠른 스탠드업, 플래그와 CI 규칙에 대한 문서화된 규칙, 중요한 경로에 대한 쌍 리뷰 호출. ## FAQ ### 트렁크 기반 개발과 Gitflow의 차이점은 무엇인가요? Gitflow는 장수명 브랜치(일~주 단위)를 사용하고 릴리스 브랜치 모델에 의존합니다. TBD는 모든 개발자가 매일 main에 병합하며 브랜치 수명은 시간~1-2일입니다. TBD는 배포와 릴리스를 분리하고 피처 플래그로 관리합니다. ### 미완성 기능을 프로덕션에 배포해도 되나요? 네, 피처 플래그로 감싸면 됩니다. 코드는 프로덕션에 배포되지만 런타임에 플래그로 끄거나 특정 사용자에게만 활성화할 수 있습니다. 이를 통해 배포와 릴리스를 분리할 수 있습니다. ### 우리 팀이 TBD를 시작하려면 무엇이 필요한가요? 세 가지가 필수입니다: (1) 15분 이내에 완료되는 빠른 CI 파이프라인, (2) 작동하는 피처 플래그 서비스, (3) 하루 안에 완료할 수 있는 크기의 작업으로 정의하는 계획 규율입니다. ### 병합 충돌이 증가하지 않을까요? 오히려 줄어듭니다. 통합 간격이 짧을수록 충돌할 기회가 적습니다. Gitflow에서는 주 단위로 발산되지만 TBD에서는 시간 단위로 발산되므로 충돌이 훨씬 작고 해결하기 쉽습니다. ### 규제가 많은 업계에서도 TBD를 사용할 수 있나요? 어렵습니다. 릴리스 전 승인이 필수인 환경에서는 지속적 배포가 차단되므로 TBD의 이점이 크게 줄어듭니다. 이 경우 분기 전략보다는 승인 프로세스를 개선하는 것이 중요합니다.