매일 배포하는 팀이 되는 여정(1) — 브랜치 전략 개선하기 (2023-04)

주 1회 배포의 부담

당근페이 팀이 주 1회 정기 배포를 1년 넘게 이어가자 릴리즈에 변경이 너무 많이 쌓였고, 마이크로서비스도 늘어 배포 뒤 이슈를 일으킨 서비스를 찾기 어려워졌습니다. 배포일에는 CI/CD가 몰려 30분 넘게 기다리기도 했습니다.

팀은 코드 한 줄 없는 상태에서 제품과 개발 문화·프로세스를 함께 세웠습니다. 출시된 서비스에는 익숙한 Git Flow를 썼습니다. 금융 서비스라 배포마다 별도 승인자가 필요해, 승인 부담을 줄이려고 리뷰·승인·배포·모니터링을 정해진 요일 오후에 모았습니다. 저자가 배포 열차라고 부른 방식입니다.

매주 release 브랜치 생성, main 병합 PR, CI 대기, 태그 생성도 반복했습니다. 이미 검증한 코드를 한 줄씩 다시 확인하고 Deploy 버튼 앞에서 긴장하는 일도 부담이었습니다. 팀에는 Git Flow의 장점인 release 브랜치 단독 테스트 환경도 없었습니다.

GitHub Flow 선택과 적용

팀은 스터디에서 Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development를 비교했습니다. Trunk-Based에는 하루 한 번 이상 병합, 작은 변경, 자동화 테스트, 피처 플래그 같은 기술적 기반과 팀 문화가 필요했습니다. 팀에 Trunk-Based를 해 본 사람이 없어, 상대적으로 익숙한 GitHub Flow를 기본 전략으로 골랐습니다.

GitHub Flow에서는 develop, release, hotfix 브랜치를 없애고 main에서 작업을 시작합니다. GitHub Flow를 쓰려면 main이 항상 배포 가능한 안정 상태여야 한다는 팀 합의가 필요합니다. main에 있지만 배포하면 안 되는 기능은 피처 플래그로, 병합 충돌은 기능·PR·커밋 단위를 작게 나누고 브랜치 수명을 줄여 풀 수 있다고 봤습니다.

배포 시간과 습관의 변화

적용 반년쯤 뒤에는 1시간을 넉넉히 잡던 배포가 20분 미만으로 끝났습니다. 배포 시간은 절반 이상 줄었고 심리적 부담도 낮아져 팀은 매일 배포하게 됐습니다. 이 과정에서 빌드 속도 개선과 피처 플래그 사용이 팀 습관으로 자리 잡았습니다.

적용할 때 확인할 조건

저자는 운영에 단일 버전만 두는 제품에는 GitHub Flow가 맞고, 여러 버전을 함께 유지해야 한다면 Git Flow가 더 어울린다고 봤습니다. 금융 서비스라 자동화 테스트와 꼼꼼한 리뷰가 중요하다는 점은 저자가 거듭 짚습니다. 배포하면 안 되는 기능을 막는 방법은 다음 글에서 이어집니다.