TBD(Trunk Based Development) 전략이란?

 

 

이번에 팀에서 모노레포로 프로젝트를 관리하게 되면서 팀 내 워크플로우 방식을 Trunk Based Development 방식으로 변경하게 되었다.

이전에는 Git Flow, Github Flow 정도밖에 몰랐는데, 이번에 새롭게 알게 된 TBD(Trunk Based Development) 방식에 대해 정리해보려고 한다.

 

TBD의 목적

평소 소규모 팀에서는 코드가 많지 않고 인원이 적은 만큼 서로 각자 작업하고 반영하는 사항에 대해서 충돌이나 컨텍스트가 꼬이는 상황이 매우 적다. 그러나 어느 정도 규모가 커질수록 많은 개발자가 같은 코드를 유지하는 것이 어려워지며 이러한 문제는 내가 작업한 사항을 Trunk 브랜치에 반영하려고 할 때 충돌로 이어질 수 있다.

이러한 충돌을 줄이기 위해 팀 내에서 최대한 동일한 코드 상태로 유지하는 것을 목표로 브랜치를 관리하는 전략이라고 생각하면 된다.

 

Trunk Based Development

우선 TBD 방식은 매우 간단하다.
언제든 릴리즈가 가능한 상태인 Trunk 브랜치가 있고, 거기서 모든 개발자들이 바로 각자 자기 작업을 진행하며 Trunk에 바로 커밋하는 방식이다.

 

 

하위 브랜치 없이 바로 Trunk에 merge를 하는만큼 나도 모르게 큰 문제가 생길 수도 있다고 생각할 수 있다.

그러나 여기서 중요한건, Trunk에 바로 커밋을 날리기 전에 미리 해당 작업들이 개발자들과 컨텍스트 공유가 되고 코드 에러나 코드 스타일 등이 모두 검수가 된 다음에, 커밋 반영이 되어도 문제가 없다고 판단이 되면 실제로 반영을 하는 시스템이 되어야 하는 것이다.

그래서 TBD가 되기 위해 필요한 요소들은 아래와 같다.

 

자동화 빌드

내가 작업한 사항에 대해 실시간 빌드를 하면서 코드 에러가 발생하는 부분이 없는지 확인이 가능해야 한다. Trunk에 반영되기 전에 내 로컬에서 직접 돌아간 빌드 결과를 보고 문제가 없는 것이 확인이 된 후 반영이 될 수 있도록 해야 한다.

 

TDD

TDD 방식을 통해 테스트 코드 커버리지를 넓힘으로써, 내가 작업한 사항을 Trunk에 반영되기 전에 기능적 에러 발생을 최대한 파악하고 미리 조치가 되어야 한다.

 

실시간 코드 리뷰 및 페어 프로그래밍

페어 프로그래밍을 하게 되면 팀원들이 같은 코드를 함께 작업을 하기 때문에 자연스레 코드 사항에 컨텍스트 공유가 되고 이후 코드 리뷰 절차가 없어지게 된다. 

꼭 페어 프로그래밍이 아니더라도 내가 작업한 사항에 대해서 바로바로 팀원들에게 리뷰 요청을 하고, 다른 팀원들은 들어온 리뷰에 대한 검토를 가장 우선순위로 처리하도록 한다.

리뷰 검토가 늦어질수록 Trunk 상태와 나의 작업 내용이 계속 격차가 벌어지게 되면서 Trunk와 다른 팀원들과 코드 동기화가 어려워지게 되고, 내가 작업해야 할 사항에도 지연되는 영향을 주기 때문이다.

내가 작업한 사항에 대해 빠르게 검토되고 빨리 반영이 되는 게 핵심이다.

 

기타 등등..

---

 

우선 위 3가지는 TBD 관련 내용을 찾아보며 내가 생각한 TBD가 되기 위한 전제조건이고, 상황에 따라 이를 포함한 다른 요소들이 더 생길 수 있을 것이다.

아무튼 TBD 핵심은 Trunk라는 브랜치에 안정적이고 빠르게 바로 커밋을 할 수 있는 환경을 구축하여 많은 팀원들이 최대한 동일한 코드 상태로 유지가 되도록 하는 것이다.

그리고 이러한 환경을 구축하기 위해 어떻게 할 수 있는지를 고민해 봐야 한다.

 

💡 코드 리뷰나 페어 프로그래밍 없이 기능적 에러 문제없는지 검수가 되지 않은 채 바로 Trunk에 커밋을 반영해버리는 것은 절대 TBD 전략이 아니다.

 

Scaled Trunk Based Development

만약 팀 규모가 꽤 크고 팀 인원이 많은 상태에서는 이러한 페어 프로그래밍과 실시간 코드 리뷰가 마냥 벅차게 될 수도 있기 때문에, 이럴 땐 STBD(Scaled Trunk Based Development) 전략을 이용할 수 있다.

 

STBD는 Trunk 브랜치의 바로 하위 Feature 브랜치를 생성하여 작업을 진행한 후, Trunk에 반영하기 전에 테스트와 충분한 리뷰 검토가 거친 뒤에 반영이 되는 방식이다.

단, Trunk의 바로 하위 브랜치는 수명 주기가 매우 짧아야 한다.

수명주기가 짧아야 한다는 것은, 해당 브랜치가 최대한 빨리 Trunk에 반영이 되어야 한다는 것을 뜻한다.

 

따라서, 하위 브랜치를 따서 작업을 진행할 때, 적절하게 Trunk에 반영이 되어도 문제가 발생하지 않도록 작업 단위를 잘 나누는 것이 중요하다.

Trunk에 바로바로 반영이 되어야 하는 만큼, 내가 작업해야 할 내용 전체를 한 번에 반영하기보단 작업할 내용을 잘 쪼개서 Trunk에 일부 반영이 되도록 해야 하며, Trunk에 작업 사항의 일부가 반영이 되어도 Trunk 상태에 문제가 없도록 하기 위해 내가 어떻게 작업을 진행해야 하는지도 연습이 필요하다.

 

TBD에 대한 나의 생각

사실 TBD의 브랜치 전략 방식은 굉장히 단순하다.
하위 Feature 브랜치를 따지 않고 그냥 나의 작업 사항을 Trunk 브랜치로 바로 커밋을 하는 것이다. 

그러나 이러한 방식을 그냥 쓰는 게 아니라, 전체적으로 코드 상태나 배포 시도 문제없이 워크플로우를 원활하게 하기 위한 환경을 만드는 것이 핵심이고, 이러한 환경을 어떻게 체계화할지 굉장히 많은 고민이 필요한 부분이다.

이를 위해 내가 작업한 사항에 대해 최대한 문제가 없는지 테스트 코드를 통해 확인이 되어야 하며, 코드 리뷰를 통해 빠른 피드백을 받고 Trunk에 반영이 되어야 하며 팀원들과 최대한 실시간으로 커뮤니케이션이 되어야 한다.

 

특히 나는 코드 리뷰에 대해서 정말 많은 고민이 들었다.
TBD를 위해 내가 작업한 사항에 대해 안정적이면서 빠르게 반영이 되어야 하는 것인데, 사실 다른 팀원들도 바쁜 상태이고 마냥 코드 리뷰나 페어 프로그래밍만 할 수는 없기 때문에 빠르게 리뷰 검토를 받는다는 것이 쉽지가 않다.

TBD를 위해 자연스레 어떻게 하면 코드 리뷰를 더욱 원활하게 할 수 있을지 고민도 필요하게 된다.

만약 PR을 최대한 잘게 쪼갠다면 리뷰어가 검토해야 할 사항에 대해 복잡성을 적어 빠른 파악이 가능하고 리뷰의 부담감을 줄일 수 있을 것이다. 그렇다면 이를 위해 어떻게 내 작업 사항의 PR 단위를 나눌지에 대해서도 고민을 해봐야 한다.

이러한 부분들이 잘 체계화되고 원활한 TBD를 가져갈 수 있다면 빠른 피드백 반영을 할 수 있는 환경이 되기 때문에 자연스레 애자일 시스템도 갖출 수 있게 된다.

 

TBD 전략은 '간단하면서도 매우 어렵다'라는 말이 정말 잘 어울리는 것 같다.

 

 

Reference

Trunk Based Development