TBD(Trunk Based Development)로 모노레포에서 git을 효율적 커밋하기
6/13/2025
모노레포를 서비스에 도입하기 위해서 가장 고민했던 문제는 Git 브랜치 전략이였는데 그때 Trunk Based Development(TBD)에 대해 학습한 내용을 정리해봅니다.
트렁크 기반 개발(TBD)이란?
TBD는 여러 명이 함께 일할 때 복잡한 브랜치 없이 모두가 한 줄(main 브랜치)에서 작업하는 방식입니다.
핵심은 “작고 자주 커밋하고, 빠르게 머지한다”는 점이에요.
구글, 페이스북, 넷플릭스, 우버 등 글로벌 IT 기업들도 이 방식을 실무에 적극적으로 적용하고 있습니다.
- 모든 소스 코드가 하나의 trunk(main)에 모인다
- 작은 단위로 자주 커밋, 빠른 머지
- 자동화된 빌드와 테스트(CI) 필수
- 장기 브랜치 최소화, feature 브랜치는 아주 짧게만 사용
모노레포 환경에서 GitFlow가 힘들었던 이유
처음에는 익숙한 GitFlow를 그대로 적용해보려고 했어요.
하지만 모노레포 환경에서는 다음과 같은 문제가 있었습니다.
- 브랜치가 너무 많아져 관리가 복잡해짐
서비스/모듈마다 feature, release 브랜치가 생기고, develop 브랜치에 여러 커밋이 한꺼번에 쌓여 어떤 코드가 어디에 쓰이는지 파악하기 어려워졌어요. - 릴리즈 타이밍이 제각각
서비스마다 배포 주기가 달라 develop 브랜치에 여러 서비스의 변경사항이 섞이면 "지금 배포해도 되나?" 고민이 생기고, 특정 서비스만 빨리 배포하고 싶어도 분리해서 처리해야 하는 번거로움이 컸어요. - 병합 충돌과 머지 헬
여러 팀이 동시에 develop이나 feature 브랜치에서 작업하면, 나중에 master로 합칠 때 충돌이 빈번하게 발생했어요. - CI/CD 파이프라인 관리가 어려움
develop 브랜치에 머지될 때마다 어떤 서비스의 CI/CD가 돌아야 하는지 기준을 잡기 힘들었고, 여러 서비스가 섞여 있다 보니 배포 자동화도 복잡해졌어요. - 팀원 간 컨텍스트 공유 어려움
각자 다른 브랜치에서 작업하다 보니, 전체 코드베이스의 상태를 파악하기 어렵고, 다른 팀원이 무슨 작업을 하고 있는지 알기 힘들었어요.
그래서 TBD를 선택 후 장점
더 단순한 브랜치 전략을 찾다가 트렁크 기반 개발(TBD)을 알게 됐어요.
TBD는 모든 개발자가 main(혹은 trunk) 브랜치 하나에 집중해서 작업하는 방식입니다.
- 브랜치 관리가 단순해짐
main 브랜치 하나만 신경 쓰면 되니까, 브랜치가 복잡하게 늘어나지 않고 관리가 훨씬 쉬워졌어요. - 빠른 통합과 배포
코드가 자주 main에 합쳐지니, 충돌이 생겨도 바로바로 해결할 수 있고, 배포도 빠르게 진행할 수 있었어요. - CI/CD 파이프라인도 단순화
main 브랜치만 감시하면 되니까, 자동화된 빌드와 배포 파이프라인도 훨씬 간단해졌어요. - 팀원 간 협업과 컨텍스트 공유 용이
모두가 같은 브랜치에서 작업하니, 전체 코드 상태를 쉽게 파악할 수 있고, 팀원 간 소통도 더 원활해졌어요.
모노레포에서 TBD만의 특징과 실무 팁
1. 소스 레벨에서의 코드 공유
모노레포에서는 모든 서비스/라이브러리/앱이 하나의 트렁크에 소스 레벨로 들어갑니다.
이렇게 하면 여러 모듈이 동시에 변경될 때 원자적(atomic) 커밋이 가능하고, 공통 모듈의 버전 관리도 HEAD(최신 커밋)만 신경 쓰면 되죠.
2. 락스텝(lock-step) 업그레이드
공통 라이브러리나 서드파티 의존성도 한 번에 업그레이드합니다.
모든 팀이 동시에 최신 버전을 사용하게 되니, 버전 충돌이나 호환성 문제를 최소화할 수 있습니다[1].
3. 디렉토리 구조와 빌드 시스템
모노레포는 디렉토리 구조가 명확해야 하고, Bazel, Buck 같은 빌드 시스템을 쓰면 필요한 부분만 빠르게 빌드·테스트할 수 있습니다.
4. 원자적 커밋
여러 모듈이나 서비스에 영향을 주는 변경도 한 번에 커밋할 수 있어, 전체적인 일관성을 유지하기 쉽습니다.
릴리즈 브랜치와 배포 전략
- 릴리즈 브랜치는 ‘정말 필요할 때만’ 만든다
TBD에서는 릴리즈 직전에만 브랜치를 잠깐 만들고, 개발은 계속 trunk에서 진행합니다.
버그 수정도 trunk에서 먼저 고치고, cherry-pick으로 릴리즈 브랜치에만 반영합니다. - 고빈도 배포(Continuous Delivery)라면 trunk에서 바로 배포
하루에도 여러 번 배포하는 팀은 아예 릴리즈 브랜치 없이 trunk에서 바로 배포합니다.
버그가 생기면 trunk에서 고치고, 바로 다시 배포하는 “롤포워드(roll-forward)” 전략을 씁니다. - 릴리즈 태그 활용
브랜치 대신 태그만 찍고, 필요할 때만 브랜치를 만드는 것도 좋은 방법입니다.
실무에서 어떻게 사용하면 될까?
- 작업 시작
main에서 바로 작업하거나, 꼭 필요하면 1~2일 내로 머지할 feature 브랜치를 짧게 만듭니다[4][5]. - 작은 단위로 자주 커밋
커밋이 작고 자주 이루어지면, 충돌도 줄고, 전체 코드베이스가 항상 최신 상태로 유지됩니다[4]. - 자동화된 빌드와 테스트(CI)
main에 머지될 때마다 자동으로 빌드와 테스트가 돌아가야 합니다. trunk는 항상 배포 가능한 상태여야 해요. - 코드 리뷰와 머지
Pull Request(PR)로 코드 리뷰를 받고, 자동화 테스트를 통과한 코드만 main에 머지합니다. - feature 브랜치는 최대한 짧게!
feature 브랜치는 몇 시간12일 내로 머지하고 바로 삭제합니다[4]. - Feature Flag(기능 토글) 적극 활용
미완성 기능은 Feature Flag로 감싸 main에 미리 머지하고, 실제로는 숨겨둘 수 있습니다.
TBD의 단점과 극복 방법
- 바로 배포 위험
main에 머지하면 곧바로 운영에 반영될 수 있으니, Feature Flag로 미완성 기능은 숨기고, 배포는 수동 승인으로 분리하는 게 좋습니다. - 테스트 자동화 필수
자동화된 테스트가 부족하면 main이 쉽게 깨질 수 있으니, 반드시 CI를 강화해야 합니다. - 장기 브랜치 금지, 짧은 브랜치만 허용
장기 브랜치는 충돌과 머지 헬의 원인입니다. feature 브랜치는 꼭 짧게, 빠르게 머지하세요. - 디렉토리 구조와 빌드 시스템 중요
모노레포는 디렉토리 구조가 명확해야 하고, 빌드 시스템도 대규모에 맞게 설계해야 합니다.
결론
트렁크 기반 개발(TBD)은 복잡한 브랜치 관리에서 벗어나, 빠르고 효율적으로 협업하고 배포할 수 있는 방법입니다.
특히 모노레포 환경에서는 GitFlow보다 훨씬 단순하고 실용적이에요.
단, 자동화와 테스트, 팀 내 소통이 반드시 뒷받침되어야 하며, 브랜치 전략과 빌드 시스템 설계에도 신경을 써야 합니다.
참고
- 공식 사이트: trunkbaseddevelopment.com