Trunk-based Development(TBD)
이슈마다 feature 브랜치를 생성 후 마스터 브랜치에 merge 하는 방식이다. 경우에 따라서 여기에 develop 브런치나 release 브런치를 추가로 만들어 관리하는 경우가 있다. 이 방식은 git branching stategy보다 적용하기 쉬워 평소에도 협업할 일이 있다면 이 방식으로 많이 사용하는 편이다.
다른 것들을 검토하기 전에 먼저 내가 자주 사용하던 GitHub Flow를 먼저 살펴보자.
위 과정이 발생되면서 개발이 완료되고 PR이 승인되기 위해 대부분 긴 시간이 걸린다(길게는 일주일도..!). 이렇게 되면 어떤 문제가 발생할 수 있을까? 뭐가 문제길래 다른 개발론이 필요하다고 말하고 싶은 걸까? 예를 들어 위 작업이 동시에 4명의 개발자에 의해 일어나고 있다고 하자. master 브랜치를 기준으로 feature a, feature b, feature c, feature d 브랜치 총 4개가 생성되었을 것이다. 물론 장점은 a개발자가 빌드에 실패하더라도 b, c, d의 개발자가 개발하는 데에는 아무런 영향을 미치지 않는다는 것이다. 반면에 단점은 4개의 브랜치는 각각 다른 시점에 병합되며, 4개가 모두 프로덕션 환경에 릴리즈 되었을 때 실제로 잘 작동하는지 예측할 수가 없다.
물론 4명의 개발자가 처리하고 반영될 이슈와 기능에 대해서 어느 정도 예측을 할 수 있다고 해보자. 근데 사업이 너무 잘되고 우리의 애플리케이션이 커짐에 따라 개발팀이 더 커져 개발자가 50명이 되었다고 하자. 50명의 개발자가 각기 다른 브랜치에서 작업 후, 머지한다면 그때도 예측할 수 있을까? 이슈 하나를 해결하기 위해 50번째로 작업이 완료되는 개발자는 pull과 수많은 merge conflicts를 해결해야 될 것이며 이 이슈가 프로덕션 환경에서 잘 작동하는지는 테스트하기 더 어려울 것이다.
또 한 가지 문제점은 피드백을 늦게 받는다는 것이다. 어떤 이슈에 대해 담당 개발자가 개발을 끝까지 하기 전에는 코드 오너이건 PL이건 신경 쓰지 않는다. 개발을 끝내고 PR을 요청했을 때 비로소 다른 사람들은 그 코드와 비즈니스 로직에 대해 검증해 보며 피드백을 준다. 피드백이 크리티컬 할수록 PR이 승인되는 시간은 길어질 가능성이 커지며, 핫픽스나 시간상 여유가 없을 경우에는 이조차 생략하여 이질적인 코드 스타일이 프로젝트에 종종 녹아들기도 한다.
우리는 개발 서버를 새로 만들고 최대한 동일한 환경에서 미리 릴리즈를 해보며 테스트해보는 방식으로 이를 극복해 나가곤 한다. 그래도 규모가 큰 팀에서는 역시나 한계가 존재하는 법이다. 아니면 QA팀의 인원을 늘려서 더 세밀한 테스트를 할 수도 있다. 하지만 비용의 증가와 더불어 하나의 기능을 추가하기 위해 장기간이 소요될 가능성이 더 커진다. 우리 개발팀은 더 느려지고 둔한 조직이 될 수도 있는 것이다. 그래서 나온지는 20년도 더 된(절대 새로운 개발론이 아니다!), Google과 FaceBook에서 사용해서 유명해진 브랜칭 모델 중에 하나인 트렁크 기반 개발에 대해 알아보려 한다.
**Trunk-Based Development(트렁크 기반 개발, TBD)**란 모든 개발자가 트렁크(trunk or master)라는 단일 브랜치에서 직접 모든 작업을 하는 것이다. 물론 이 말만 본다면, "그냥 마스터 브랜치에서 모든 작업을 하는 거 아냐? 트렁크라는 이름만 붙이고?"라고 반문할 수 있다. 물론 틀린 말 아니다. 하지만 그냥 작업하는 것이 아닌 몇 가지 절대적이고 안전한 규칙들을 지켜져야 된다.
