깃 플로우

본류에서 갈라져 나온 작업 줄기인 브랜치는 만들기가 너무 쉽습니다. 명령 한 줄이면 생기고 이름도 마음대로 붙입니다. 규칙이 없는 팀에서는 new-login, fix2, taeo-test 같은 것이 스무 개쯤 떠다닙니다.

문제는 이름이 아니라 경로입니다. 어디서 갈라 어디로 돌아가야 하는지가 사람마다 다르면, 출시 전날 "지금 본류에 뭐가 들어가 있죠" 라는 질문에 아무도 답하지 못합니다. 검수를 마친 기능 옆에 어제 올라온 실험 코드가 섞여 있고, 그것을 빼내려면 위에 쌓인 것들까지 들어내야 합니다.

출시일이 정해진 제품에서는 이 상황이 특히 비쌉니다. 설치해서 쓰는 프로그램이나 심사를 거치는 앱은 한 번 내보내면 되돌리기 어려워서, 내보낼 것만 모아 며칠 검증할 자리가 필요합니다. 그 자리를 브랜치로 만든 것이 깃 플로우입니다.

2010년에 한 개발자가 자기 팀이 쓰던 방식을 그림 한 장과 함께 공개한 것이 시작이었습니다. 브랜치마다 역할을 정해 두고 어느 브랜치에서 갈라 어디로 합칠지를 못 박은 것이 전부인데, 그림이 명확했던 덕에 빠르게 퍼졌습니다.

브랜치 다섯 종류에 각각 역할을 주고, 그 사이의 이동 경로를 고정합니다.

1. main — 실제로 내보낸 것만 들어갑니다. 여기 쌓인 기록은 곧 출시 이력이라, 합칠 때마다 2.4.1 같은 버전 표를 붙입니다. 자리마다 뜻을 정해 둔 시맨틱 버저닝을 함께 쓰는 팀이 많습니다.
2. develop — 다음 출시에 들어갈 것이 모이는 곳입니다. 평소 개발의 기준선이 됩니다.
3. feature/* — 기능 하나를 만드는 줄기입니다. develop 에서 갈라 나와 다 만들면 develop 으로 돌아갑니다. main 과는 직접 만나지 않습니다.
4. release/* — 출시 준비용입니다. develop 에서 한 벌 떠내 새 기능은 넣지 않고 버그만 고칩니다. 품질 보증 담당이 검증하는 며칠이 이 브랜치 위에서 지나가고, 끝나면 main 과 develop 양쪽으로 합칩니다.
5. hotfix/* — 이미 내보낸 것에서 급한 문제가 터졌을 때 씁니다. 지금 사용자가 쓰는 버전에만 손을 대야 하므로 develop 이 아니라 main 에서 갈라 나오고, 고친 뒤에는 역시 양쪽으로 합칩니다.

경로가 두 갈래로 끝나는 4번과 5번이 이 규칙의 핵심입니다. main 에만 합치고 develop 을 잊으면 방금 고친 버그가 다음 출시에서 되살아납니다. 가장 자주 나는 사고가 이것입니다.

feature/* 를 합칠 때 갈라진 변경을 다시 하나로 만드는 머지를 쓰되 합쳤다는 기록을 남기는 것, 승인 없이는 들어가지 못하게 막아 두는 것도 함께 정해 둡니다.

이 규칙이 잘 맞는 곳은 버전이 겉으로 드러나고 여러 버전을 동시에 돌봐야 하는 제품입니다. 설치해서 쓰는 프로그램, 남이 가져다 쓰는 라이브러리, 심사를 거쳐야 배포되는 앱이 여기 속합니다. 지금 사용자 손에 있는 2.4 버전을 고치면서 3.0 을 따로 만들어 가야 하는 상황에서는 main 과 develop 이 나뉜 구조가 그대로 쓸모가 되고, 검증 기간이 따로 잡힌 팀에는 release/* 가 그 며칠을 담을 그릇이 됩니다.

반대로 하루에도 여러 번 내보내는 웹 서비스에서는 값이 비싸집니다. 브랜치가 다섯 종류라는 것은 합치는 자리도 다섯 군데라는 뜻이라, 하루 두 번 배포하는 팀이 매번 이 경로를 밟으면 배포보다 브랜치 관리에 시간이 더 듭니다.

더 큰 문제는 브랜치가 오래 산다는 점입니다. feature/* 하나가 3주를 묵으면 그동안 develop 은 계속 움직입니다. 같은 곳을 다르게 고쳐 기계가 합칠 수 없는 충돌은 묵힌 기간에 따라 커져서, 하루 만에 합치면 겹치는 줄이 두세 개인데 3주를 두면 파일 열 개가 통째로 어긋나 있습니다.

그래서 빠르게 내보내는 팀은 본류에 하루에도 여러 번 합치는 트렁크 기반 개발 쪽으로 옮겨 갔습니다. 다만 그쪽은 반쯤 만든 코드가 늘 본류에 있다는 뜻이라, 합칠 때마다 자동으로 검증하는 지속적 통합 없이 넘어가면 본류가 깨진 채로 하루를 보내게 됩니다.

"이건 핫픽스니까 develop 말고 main 에서 따 주세요."

지금 사용자가 쓰는 버전을 고치는 일이라 개발용 줄기가 아니라 출시된 줄기에서 갈라야 한다는 지시입니다.

"릴리스 브랜치 떴으니까 이제 기능 추가는 다음 차수로 넘깁니다."

검증이 시작됐으므로 새 기능은 받지 않고 버그 수정만 넣겠다는 선언입니다.

"핫픽스 develop 에 백머지 하셨어요?"

main 에만 합치고 개발용 줄기에 반영하지 않으면 다음 출시에서 같은 버그가 되살아난다는 확인입니다.

페이지덱에서는 웹 제품과 모바일 앱이 서로 다른 규칙을 씁니다. 웹은 하루에도 몇 번씩 내보내니 본류에 바로 합치고, 앱은 심사를 거쳐야 해서 깃 플로우에 가까운 경로를 씁니다.

태오가 신입에게 이 차이를 설명할 때 드는 근거는 되돌리기 비용입니다. 웹은 문제가 생기면 10분 만에 이전 버전으로 돌아갈 수 있지만, 앱은 고친 판이 사용자 기기에 닿기까지 며칠이 걸립니다. 되돌리기가 비싼 쪽에 검증 기간을 담을 브랜치를 둡니다.

깃 플로우를 브랜치 전략의 기본값으로 배우는 경우가 많습니다. 검색하면 가장 먼저 나오고 그림도 잘 정리돼 있으니 표준처럼 보이며, 학습 자료가 브랜치를 설명할 때 이 그림을 그대로 쓰는 일도 잦습니다.

실제로는 특정 상황을 위해 만들어진 여러 선택지 가운데 하나입니다. 정해진 날짜에 버전을 묶어 내보내는 제품을 전제로 설계됐고, 그 전제가 없는 팀에서는 얻는 것 없이 단계만 늘어납니다. 그대로 두면 배포가 느려지는 것으로 끝나지 않습니다. 절차가 번거로우니 사람들이 우회하기 시작해서, 급하다는 이유로 develop 을 건너뛰고 main 에 직접 합치는 일이 한 달에 몇 번씩 생깁니다. 규칙이 있는데 지켜지지 않는 상태가 규칙이 없는 상태보다 나쁩니다.