잦은 배포를 언제나 안정적이고 쉽게- SimGit flow 기반 Git 브랜치 전략 개선기1

세금 신고·환급 도움 서비스 ‘삼쩜삼’을 운영하는 스타트업 자비스앤빌런즈의 프론트엔드(FE) 챕터장 정원덕 엔지니어입니다.

최근 삼쩜삼에서 제공하는 서비스가 늘고 FE 챕터의 인력 규모 또한 늘었습니다. 이는 결과적으로 동시에 개발하는 기능의 개수 증가로 이어져 개발 생산성 저하에 영향을 미쳤습니다. 이에 따라 기존의 Git Flow 모델 대신 새로운 브랜치 전략을 세울 필요성이 제기되었습니다. SimGit Flow 모델에 기반해 브랜치 전략을 개선해보니 실질적으로 생산성 향상을 얻을 수 있었습니다.

이번 글에서는 자비스앤빌런즈가 SimGit Flow 모델을 활용하여 브랜치 전략을 바꾼 배경과 그 과정, 결과를 설명하고자 합니다.

Git Flow의 한계

Git Flow는 브랜치 전략의 초기 모델 중 하나로, 개발에서 배포까지의 프로세스를 4단계 브랜치(feature , develop, release, main*)로 제어합니다. 지난 2010년 Vincent Driessen가 처음 제안했습니다.

*

2020년 11월 이전만 하더라도 main 대신 master라는 이름의 브랜치를 사용해 왔습니다. 지금까지 기술 업계에서는 관행적으로 메인인 개체에 master, 부가적인 개체에 slave라는 이름을 붙여왔기 때문이죠. 그런데 이는 과거 불평등의 극단적인 형태로 나타났던 ‘노예제도'를 떠올린다는 지적이 있었던바, 이에 Github에서는 해당 용어를 main으로 변경했습니다.

이 Git Flow는 오늘날 많은 테크 기업이 활용하는 대중적인 브랜치 전략으로 자리하고 있습니다. 프로젝트를 일정한 주기로 배포할 때 매우 유용하기 때문입니다. 이 덕분에 프로젝트를 지표화하여 버전 및 일정 관리가 편리합니다. 어느 시점에 어떤 기능이 추가되었는지 쉽게 알 수 있는 React Release Note를 대표적인 예로 들 수 있겠습니다.

자비스앤빌런즈 역시 삼쩜삼 프로젝트 초반에는 FE 구성원 모두가 이미 잘 아는 대중적인 방법론인 Git Flow를 채택했습니다.

[ 이미지 1 ] Git Flow 워크플로우 (출처 : Hostinger)

Git Flow에서 개발자 작업한 feature 브랜치는 특정 지점에서 한 번에 병합(merge)됩니다. 그래서 서로 영향을 주고받을 수 있는 feature 브랜치의 병합 시점이 서로 겹치지 않도록 개발자 간에 일정을 긴밀히 공유하고 조율하는 일은 대단히 중요합니다.

그런데 자비스앤빌런즈에서 FE 담당 인원이 4명에서 10명으로 늘어나자, 특정 시점에 함께 병합되는 feature 브랜치의 수도 자연스럽게 늘기 시작했습니다. 특정 시기에는 배포 횟수마저 늘어났습니다. 2023년 기준 삼쩜삼에서 운영하는 8개 서비스의 평균 배포 주기는 각 1회/1일인데요, 서비스 이용이 집중되는 종합소득세 정기 신고 기간인 5월에는 평균 배포 주기가 1.5회/1일까지 올랐습니다. 특히 사용자가 몰리는 5월 중순부터 말까지는 다양한 이벤트 노출과 A/B 테스트, 서비스 개선으로 최대 3회/1일의 배포가 이뤄지기도 했습니다.

그 결과, feature 브랜치를 병합하는 시점에 서로 영향을 주고받는 다른 feature 브랜치를 파악하고 이를 처리하는 커뮤니케이션 비용은 기하급수적으로 증가했습니다. 각 담당자가 배포 때마다 각자가 개발한 feature 브랜치 간 의존성이 없는지 확인하고, 배포 일정을 조율하는 커뮤니케이션에 시간 비용을 들여야만 하는 거죠. 문제를 일으킨 다른 feature 브랜치가 수정될 때까지 작업을 멈춰야 하는 일도 비일비재했습니다. 이에 따라 작업한 기능을 배포하는 데 예정보다 며칠씩 걸리는 일까지 발생했습니다.

[ 이미지 2 ] Git Flow를 적용한 상황에서 개발자 간 배포 시점을 일일이 조율해야 한다.

[ 이미지 3 ] Git Flow에서는 feature 브랜치가 한곳으로 모이는 브랜치(develop, release) 자체를 수정하려면 팀원 모두에게 반드시 공유해야 한다.

한마디로 정리하면, 배포 주기가 잦은 서비스를 개발할수록, 해당 서비스를 만드는 개발 인원이 많을수록 Git Flow는 개발 생산성 증대에 큰 도움이 되지 못했습니다. 이에 자비스앤빌런즈 FE 챕터는 더 나은 대안을 찾을 필요가 있다고 판단했습니다.

TBD vs SimGit Flow

자비스앤빌런즈 FE 챕터는 여러 차례 내부 미팅을 통해 조직에 더 적합한 브랜치 전략의 기준을 세웠습니다.

우선, 다른 누군가가 개발 중이거나 배포 예정인 기능의 독립성을 보장할 수 있어야 한다고 판단했습니다. 또한, 여러 개의 서비스를 하나의 리포지토리(repository)에서 관리하는 모노레포(monorepo) 환경에서는 더더욱 Git Flow보다는 좀 더 단순하게 브랜치를 관리하는 전략을 채택할 필요가 있었습니다.

그 결과, SimGit Flow와 Trunk-Based Development(TBD)가 저희가 지향하는 방향과 가장 가까웠습니다. 같은 문제(잦은 배포)를 해결하는 방법론이라는 점에서 두 전략은 비슷합니다. 다만 SimGit Flow는 아직 국내에서 널리 쓰이지 않는다면, TBD는 좀 더 대중적으로 활용되고 있는 전략입니다.

TBD는 main 브랜치에서 feature 브랜치를 바로 따서 작업 후, 이를 다시 기존의 main 브랜치에 바로 병합하는 전략입니다. 구글의 엔지니어 Jez Humble가 지난 공동 저술한 도서 ‘The DevOps Handbook’에 언급한 1990년대에 들어서 그 개념을 확실히 정립한 거라 보시면 되겠습니다.

Jez Humble가 공유한 내용에 따르면, 지난 2014년을 기준으로 1만 명이 넘는 구글 엔지니어가 이 방식으로 서비스를 개발했습니다. 개발 조직 규모도 크고 제공하는 서비스 가짓수도 많은 구글에서 전방위적으로 활용했던 방법론이라면 배포가 잦은 서비스인 삼쩜삼에도 적용해 볼 만한 좋은 대안이라고 판단했습니다.

[ 이미지 4 ] TBD 기본 흐름 (출처 : dora.dev)

SimGit Flow는 앞서 설명한 대로 비교적 최근에 제안된 브랜치 전략으로, 환경 스타트업 Omnevue의 CTO인 Andrew Winnicki가 지난 2022년에 처음 제안했습니다. SimGit Flow는 TBD와 마찬가지로 main 브랜치에서 바로 feature 브랜치를 따서 작업을 진행합니다만, 그 이후부터는 다소 차이가 있습니다. 테스트 단계에서 feature 브랜치를 release 브랜치로, 배포 단계에서 release 브랜치를 main 브랜치로 합칩니다.

[ 이미지 5 ] SimGit Flow 기본 흐름 (출처 : SimGit Flow)

깃 브랜치 전략을 개선해 보니…

TBD에는 release 브랜치의 역할인 ‘관리’의 장점을 극대화할 수 없다는 단점이 있습니다. 따라서 TBD를 도입하려는 개발 조직에서는 배포에 관한 규칙을 다시 세워야 합니다. 자비스앤빌런즈 FE 챕터에는 이를 위한 충분한 시간이 없는 상황이었습니다. 이에 TBD의 도입을 더 심층적으로 고려하지는 않았습니다.

하지만 SimGit Flow은 각 개발자가 작업한 feature 브랜치의 독립성을 보장하고 개발자 간 커뮤니케이션 횟수를 줄이는 데 효과적이라고 판단했습니다. 그래서 배포 주기가 짧고 빠른 프로젝트에 적합하다고 판단, SimGit Flow를 자비스앤런즈 FE 챕터에도 바로 적용했습니다.

SimGit Flow를 기반으로 삼쩜삼의 브랜치 전략을 개선해 보니, 3단계( feature > release > main)만 거치면 되므로 코드 리뷰 단계를 2회에서 1회로 줄일 수 있었습니다. 또한, 제각각 작업한 feature 브랜치를 release 브랜치로 합칠 때조차 서로 커뮤니케이션할 필요는 없습니다. 그 덕분에 FE 챕터원들 모두 개발에만 온전히 집중할 수 있는 시간 확보에도 큰 도움이 되었습니다.

다만 SimGit Flow를 삼쩜삼 개발 환경에 그대로 적용할 수는 없었습니다. 다른 챕터(기획∙PM∙디자인∙QA )를 위해 실제 운영 서비스의 테스트 공간을 따로 마련해야 했기 때문입니다. 그래서 SimGit Flow에 develop, stage 브랜치를 추가하여 dev, stage 환경에서 운영 중인 서비스를 바로 테스트할 수 있도록 하였습니다.

한편, 삼쩜삼 서비스에서는 새롭게 도입되거나 사라지는 서비스(예 : 연금 3억 받기)의 속도가 빠른 편이라 각 기능을 배포할 때마다 버전을 부여하는 데에는 현실적인 어려움이 따랐습니다. 그래서 자비스앤빌런즈 FE 챕터에서는 버저닝을 사용하지 않기로 했습니다. 하지만 제품에 버전을 부여하는 작업은 여전히 제품 개발에 많은 편의를 제공합니다. 그래서 내부적으로는 특정 시점에 함께 배포하는 feature 브랜치를 한 단위로 묶어서 관리할 수 있도록 ID 발급 과정을 따로 도입했습니다.

[ 이미지 6 ] 삼쩜삼의 새로운 브랜치 흐름도(SZS Git Flow)

향후 계획

자, 이처럼 자비스앤빌런즈 FE 챕터는 새로운 브랜치 전략을 결정하였습니다. 그렇다면 실제로 개발 및 QA 부서에서 이를 어떻게 적용해서 실제로 작동이 되도록 만들었을까요? 그리고 어떻게 자동화를 통해 개발자의 생산성을 올릴 수 있었을까요? 다음 글에서 이에 대해 좀 더 자세히 다뤄보겠습니다.

글 | 정원덕
편집 | 이수경
디자인 | 박서영/커버 이미지