브랜치

코드가 한 벌뿐이던 시절에는 누군가 고치는 동안 나머지가 기다렸습니다. 같은 파일을 둘이 동시에 열면 나중에 저장한 쪽이 앞사람의 수정을 덮어썼기 때문에, 손대기 전에 "지금 결제 쪽 만지는 사람 있나요" 부터 물어야 했습니다.

그러다 보니 일정이 사람 수가 아니라 순서에 묶였습니다. 페이지덱에서 태오가 결제 화면을 사흘째 고치고 있으면 버튼 문구의 오타 하나를 고치는 데도 그 작업이 끝나기를 기다렸습니다. 기다리기 싫은 사람은 폴더를 복사해 자기 컴퓨터에서 고쳤는데, 나중에 두 벌을 눈으로 대조해 합쳐야 했고 그러다 빠뜨린 줄은 사라졌습니다.

브랜치는 이 기다림을 없애려고 만든 장치입니다. 복사본을 손으로 관리하던 일을 버전 관리 도구 안으로 들여왔다는 점이 다릅니다. 누가 어디서 갈라졌고 그동안 본류가 어떻게 바뀌었는지를 도구가 기억하므로, 합칠 때 파일을 나란히 놓고 대조할 필요가 없습니다.

브랜치를 만든다는 것은 코드를 복사하는 일이 아니라, 지금까지 쌓인 기록 가운데 한 지점에 이름표를 하나 더 붙이는 일입니다. 그래서 브랜치 하나를 만드는 데 1초도 걸리지 않고 저장 공간도 거의 안 씁니다.

이름표가 가리키는 그 지점이 커밋입니다. 커밋은 변경을 한 덩어리로 묶어 남긴 기록이고, 무엇을 왜 바꿨는지 적은 메시지가 붙습니다. 이런 커밋이 쌓이는 공간이 저장소이고, 브랜치는 그 안에서 커밋이 이어지는 줄기 하나에 붙은 이름입니다. 변경 이력을 다루는 도구 가운데 사실상 표준인 Git이 이 방식을 씁니다.

브랜치 하나가 사는 과정은 네 단계입니다.

1. 갈라내기 — 본류의 맨 끝 커밋을 가리키는 새 이름을 만듭니다. 보통 main 이라고 부르는 본류에서 payment-retry 같은 이름으로 갈라냅니다.
2. 쌓기 — 그 위에 커밋을 얹습니다. 얹은 커밋은 내 이름표만 앞으로 밀고 본류의 이름표는 건드리지 않아서, 열두 개를 쌓아도 본류를 보는 사람 화면에는 아무 변화가 없습니다.
3. 따라잡기 — 그사이 본류에도 다른 사람의 커밋이 쌓입니다. 갈라진 지점이 뒤로 밀릴수록 어긋나는 줄이 늘어나므로, 며칠에 한 번씩 본류의 변경을 내 브랜치로 먼저 가져옵니다.
4. 합치기 — 머지로 두 줄기의 변경을 하나로 모읍니다. 같은 파일의 같은 줄을 양쪽이 다르게 고쳤으면 도구가 판단을 미루고 충돌로 표시해 사람에게 고르게 합니다.

브랜치를 옮기면 내 컴퓨터의 파일도 그 브랜치 모습으로 바뀌었다가, 돌아오면 내 수정이 그대로 되살아납니다.

어긋나는 양은 갈라져 있던 시간을 따라갑니다. 하루 만에 합치면 겹치는 줄이 두세 개라 몇 분이면 끝나지만, 3주를 묵히면 파일 열 개가 통째로 어긋납니다.

브랜치는 작업 하나에 하나씩 붙습니다. 기능 하나, 버그 하나, 실험 하나가 각각 자기 브랜치를 갖고, 그 일이 본류에 들어가면 브랜치는 지웁니다. 태오가 이번 주에 만든 브랜치도 feature/payment-retry 와 fix/login-typo 둘이었고, 합쳐진 다음 날 지웠습니다.

이름을 아무렇게나 붙이지 않는 것도 그래서입니다. 브랜치가 서른 개 떠 있으면 무슨 작업인지 알아볼 단서가 이름뿐이라, 팀은 대개 머리말과 작업 번호를 붙이는 규칙을 정해 둡니다.

합치기 전에 사람을 한 번 거치게 만드는 자리도 브랜치입니다. 풀 리퀘스트는 내 브랜치를 본류에 합쳐 달라고 올리는 요청이고, 그 화면에서 동료가 바뀐 줄을 읽고 의견을 남기는 절차가 코드 리뷰입니다. 승인 없이는 본류에 못 들어가게 막는 것이 기본 설정이라, 브랜치는 검사를 기다리는 대기줄 노릇도 합니다.

브랜치를 몇 개나 얼마나 오래 두는지는 팀마다 다릅니다. 트렁크 기반 개발은 브랜치를 이틀 이상 두지 않고 하루에도 여러 번 본류에 합칩니다. 충돌이 커지기 전에 부딪히게 만드는 방식이라 자동 검사가 촘촘해야 버팁니다. 깃 플로우는 반대로 개발용·출시용·긴급수정용 브랜치를 나눠 두고 정해진 경로로만 옮깁니다. 날짜를 정해 버전을 묶어 내보내는 제품에 맞지만, 브랜치가 오래 사는 만큼 합칠 때 값이 큽니다.

"이거 main 에서 바로 고치신 거예요? 브랜치 따서 다시 올려 주세요."

본류를 직접 고치면 리뷰도 되돌리기도 어려우니 줄기를 따로 만들라는 말입니다.

"그 브랜치 2주째 떠 있는데 main 한 번 받아 오세요."

갈라진 지 오래돼 어긋난 곳이 쌓였을 테니 본류의 최신 변경을 먼저 받으라는 뜻입니다.

"브랜치 하나에 기능이 세 개 들어가 있어서 리뷰를 못 하겠어요."

관련 없는 작업이 한 줄기에 섞여 있어 어느 변경이 무엇 때문인지 가릴 수 없다는 뜻입니다.

페이지덱에서 이 구조가 값을 한 장면은 결제 재시도 기능을 만들던 주였습니다. 태오가 그 기능을 절반쯤 만들어 둔 때 규원이 가입 화면의 잘못된 요금을 발견하고 당장 고쳐 달라고 했습니다. 문구 수정은 열 줄이었지만 결제 기능은 아직 동작하지 않았습니다.

두 작업이 다른 브랜치에 있었으므로 태오는 문구 수정만 그날 오후에 본류로 합쳐 내보냈고, 결제 기능은 원래 속도로 계속 만들었습니다. 한 벌만 있었다면 반쯤 만든 결제 코드까지 함께 나가거나, 결제가 끝날 때까지 잘못된 요금을 그대로 두는 수밖에 없었습니다.

브랜치를 따 두면 그 작업이 안전하게 보관된다고 여기는 경우가 많습니다. 본류가 어떻게 바뀌든 내 브랜치의 코드는 그대로 남으니 그렇게 보입니다. 하지만 남아 있는 것과 쓸 수 있는 것은 다릅니다. 본류가 나아가는 동안 내 코드가 딛고 선 바닥은 낡아 가고, 두 달 묵힌 브랜치는 합치는 데 며칠이 걸리거나 버리고 다시 만드는 편이 빠릅니다.

브랜치를 많이 만들면 저장소가 무거워진다는 오해도 흔합니다. 이름이 복사본처럼 들려 개수만큼 용량이 늘 것 같지만, 커밋 하나를 가리키는 이름표라 개수는 값을 거의 치르지 않습니다. 값을 치르게 하는 쪽은 개수가 아니라 수명입니다. 이를 거꾸로 알면 정작 필요한 순간에 브랜치를 아끼게 되고, 여러 작업을 한 줄기에 몰아넣어 되돌리기 어려운 덩어리를 만듭니다.