당신의 브랜치 전략이 실패하는 3가지 이유
그리고 머지가 잘못되고 있다는 3가지 증거
이 글을 봐야 하는 사람은 누구인가? 당신이 혼자서 개발을 하고 있다면 이 글을 볼 필요는 없다. 만약 당신이 두 명이서 개발을 하고 있는데, 두 명 모두가 독립적인 repository에서 작업을 하고 있다고 해도 이 글을 볼 필요는 없다. (예를 들어 한 명은 서버를 개발하고, 한 명은 앱을 개발하는 식이다.) 내가 이야기하는 상황은 두 명 이상의 개발자가 같은 repository에서 동일한 코드를 건드리는 상황을 말한다. 바로 브랜치 전략이 필요해지는 순간이다.
당신의 협업이 실패하고 있다는 증거들
여러 명이 같은 브랜치에 작업할 때, 당신의 협업이 실패하고 있다는 증거는 다음과 같다. 이러한 현상이 반복적으로 발생하는 개발팀에서 일하고 있다면, 이건 분명 Red Flag다. 이러한 일들이 반복된다면 당신이 속한 개발팀의 협업이 매우 비효율적이라, 제품의 개발 속도가 느려 경쟁력을 확보하지 못할 것이다.
1. Merge Confilct가 너무 많이 발생한다.
한번 Pull Request를 날렸는데 머지 컨플릭트가 수십 개 이상 발생하는 경우가 있다. 그런데 머지 컨플릭트를 해결하려고 보니 어떤 코드가 맞는지 모르겠다. 그래서 대충 둘 중에 하나를 골라 찍기 식으로 선택한다. 돌려보니 별 문제없는 것 같아서 그냥 출시했다. 과연 당신의 찍기는 맞았을까?
2. 분명 내가 고쳐놓은 버그인데 어느 순간 다시 나타난다.
Merge Conflict가 자주 발생하면 내가 분명히 고친 버그인데, 누가 Merge 실수를 해 이전 상태도 되돌려 놓는 경우가 자주 발생한다. 내가 4시간에 걸쳐서 디버깅해 고쳐놓은 버그가 단 한 번의 Merge Conflict로 롤백된다면 나의 의욕에도 치명적이고 귀한 4시간을 다시 소모해야 한다. 지난번에는 4시간에 걸쳐서 고쳤지만 이번에는 몇 시간이 걸릴지 알 수 없는 노릇이다.
3. 내가 현재 작업 중인 코드를 배포하려면 다른 사람이 하고 있는 작업이 끝나야 가능하다.
브랜치 전략이 실패했을 경우 가장 많이 발생하는 문제점이다. 다른 사람의 작업이 먼저 머지가 되고 배포가 잘 되어야 내 작업도 배포가 될 수 있다. 이렇게 되어 버리면 협업이 큰 의미가 없다. 동시에 작업이 병렬적으로 진행되지 못하니 개발 속도는 더뎌진다. 특히 개발은 기능만 만들어 놓는다고 끝이 아니다. 코드가 정확히 통합이 되어 통합 테스트까지 완료가 되어야 개발이 끝나는데, 통합 테스트 시점이 계속 늦춰진다. 그래서 전반적으로 제품 개발 속도 자체가 굉장히 저해된다.
이러한 문제를 해결하기 위해 도입할 수 있는 것이 브랜치 전략이다. 그런데 많은 개발팀에서 이 브랜치 전략을 아예 사용하지 않거나, 잘못 사용하고 있다. 사실 브랜치 전략에 대한 아티클은 구글에 "브랜치 전략"이라고 검색만 하면 어렵지 않게 찾을 수 있다 그런데 그들은 왜 브랜치 전략을 제대로 사용하지 못하는 것일까?
1. 서로 현재의 작업 상황을 공유하지 않는다.
분명 브랜치 전략과 함께 만들어 나가야 할 것들이 있다. 브랜치 전략을 지금부터 도입하겠다고 선언하고 아티클을 읽고 규칙을 만든 후, 그다음 날부터 적용하면 모든 문제가 해결될까? 우리는 절대 그렇지 않다는 것을 안다. 내가 개발팀의 리드라 Git Flow 전략을 도입하자고 팀원들에게 의견을 냈다고 하자. 그럼 그때부터 나는 팀원들이 어떤 브랜치에서 작업을 하고 있는지 누가 머지를 했고 누가 아직 하지 않았는지를 어느 정도 트래킹하고 있어야 한다. 개발자들은 자신의 습관대로 브랜치를 따고 작업을 할 것이다. 그 습관이 브랜치 전략과 배치될 경우 리드가 제지해야 한다. 그렇지 않으면 브랜치 전략 도입 이전으로 바로 돌아가 버리고 만다. 이를 위해서는 서로가 주기적으로 어떤 브랜치에서 어떤 작업을 하고 있는지 공유해야 한다. 제일 좋은 시간은 아침 Daily Scrum 또는 팀 정기 논의 시간이 좋다. 물론 주 단위의 정기 논의에서 공유하는 것만으로는 부족하다. 새로운 작업을 들어가기 전에 어떤 부분의 코드를 수정할 것인지 슬랙으로 공유가 되어야 하고, 내가 다른 사람이 건드리고 있는 곳을 건드릴 것으로 예상되는 경우에는 명시적으로 해당 부분을 건드려도 되는지 물어봐야 한다.
2. 작업의 단위가 너무 크다.
여러 명이 작업하는 코드 베이스에서 이상적인 Pull Request의 크기는 얼마일까? 나는 적어도 1000줄이 넘으면 안 된다고 생각한다. 공통 영역을 건드리는 경우에는 이보다 더 작은 단위로 PR이 되어야 한다. 물론 이것은 절대적인 수치는 아니다. 1000줄이 넘어도 서로 격리된 공간에서 작업하고 있다는 사실이 보장된다면 괜찮다. 우리 팀은 Github Actions의 workflow를 통해 자동으로 코드 라인의 개수를 헤아려 Pull Reuqst에 라벨을 붙이는 방식으로 코드의 총 라인수가 1000줄이 넘지 않도록 유도하고 있다.
3. 코드 베이스가 잘 정리되어 있지 않다.
코드 베이스가 잘 정리되지 않으면 브랜치 전략을 도입하더라도 협업이 쉽지 않다. 예를 들어 클라이언트 개발인데, 화면을 정의하는 부분의 코드와 비즈니스 로직을 담당하는 코드가 분리되어 있지 않다거나, 작은 기능 하나를 수정하는데 광범위한 부분의 코드 수정이 필요한 경우 브랜치 전략이 있더라도 매우 빈번한 머지 컨플릭트가 발생하여 협업이 쉽지 않을 것이다. 이럴 경우 개발을 해나가면서 조금씩 코드 베이스를 정리하고 개선해 나가야 한다. 단 주의할 점이 있다. 앱 전체를 처음부터 새로 작성하는 것은 지양해야 한다. 이미 히스토리가 없는 상태에서 앱을 새롭게 만든다는 것은 모든 히스토리를 날려버리는 행위와도 같다.
위 세 가지의 사항이 해결되지 않은 채로 브랜치 전략만 달랑 도입하는 경우, 브랜치 전략이 아예 없는 것보다는 훨씬 낫지만 효과적인 성과를 얻기는 힘들다.
