트렁크 기반 개발

기능마다 줄기를 갈라 따로 작업하는 것이 오랫동안 기본이었습니다. 본류에서 갈라 따로 작업하는 줄기를 브랜치라 하고, 각자 자기 브랜치에서 마음껏 고치다가 다 되면 합치는 방식입니다. 작업 중에 서로 방해하지 않으니 안전해 보입니다.

문제는 합치는 날에 몰려서 터졌습니다. 3주 동안 따로 작업한 브랜치를 본류에 합치면, 그사이에 본류도 300줄이 바뀌어 있습니다. 같은 자리를 다르게 고쳐 자동으로 합칠 수 없는 상태를 충돌이라 하는데, 3주치 변경을 합칠 때는 이 충돌이 스무 군데에서 한꺼번에 나옵니다. 푸는 데 이틀이 걸리고, 푸는 과정에서 남의 코드를 지우는 실수가 섞여 들어갑니다.

기다리는 쪽도 손해였습니다. 세 사람이 각자 3주짜리 브랜치를 들고 있으면 세 덩어리가 순서대로 합쳐지고, 두 번째 사람은 첫 번째가 합친 뒤에 자기 브랜치를 다시 맞춰야 합니다. 마지막 사람은 두 번을 맞춥니다. 브랜치가 길면 이 비용이 사람 수의 제곱으로 늘어납니다.

트렁크 기반 개발은 이 비용을 브랜치 수명으로 잡았습니다. 오래 사는 브랜치를 없애면 합칠 때 어긋날 양 자체가 줄어듭니다. 3주치를 한 번 합치는 대신 하루치를 열다섯 번 합치면, 한 번의 충돌은 두 줄짜리가 됩니다.

모두가 같은 줄기를 바라보고 하루 안에 합칠 크기로 일을 자릅니다. 다섯 가지를 지킵니다.

1. 본류를 하나로 둡니다. 배포되는 코드가 늘 이 줄기에 있고, 아무도 여기서 오래 떨어져 있지 않습니다. 브랜치를 아예 안 쓰는 것은 아니고, 만들고 하루 안에 지우는 것으로 씁니다.
2. 하루에 한 번 이상 합칩니다. 기능이 끝나지 않았어도 합칩니다. 이 대목이 앞 방식과 가장 크게 갈리는 자리이고, 그래서 일을 자르는 방법을 함께 바꿔야 합니다. 3주짜리 기능을 하루치 열다섯 개로 자르는 연습이 이 방식의 실제 난관입니다.
3. 미완성 코드를 끈 상태로 내보냅니다. 코드는 배포하되 기능만 켜고 끄는 스위치를 피처 플래그라 하고, 절반만 만든 화면을 이 스위치로 꺼 둔 채 본류에 올립니다. 사용자에게는 없는 기능이고 코드는 이미 합쳐져 있는 상태입니다.
4. 합칠 때마다 기계가 검사합니다. 변경을 자주 합치고 자동으로 검증하는 방식을 지속적 통합이라 하는데, 이 방식은 그 검사 없이는 성립하지 않습니다. 하루 열다섯 번 합치면서 사람이 매번 전체를 확인할 수는 없습니다.
5. 리뷰를 짧게 돌립니다. 합쳐 달라고 올리는 요청을 풀 리퀘스트라 하고, 여기서는 그 크기를 200줄 안쪽으로 유지해 몇 시간 안에 처리합니다. 리뷰가 이틀 걸리면 하루에 한 번 합친다는 규칙이 자동으로 깨집니다.

맞는 조건이 셋 있습니다. 첫째는 하나의 제품을 하나의 버전으로 서비스하는 경우입니다. 웹 서비스가 대표적입니다. 둘째는 자동 검사가 이미 돌아가는 팀입니다. 셋째는 배포를 자주 하는 팀입니다. 하루에 여러 번 나갈 수 있으면 하루치씩 합치는 것이 자연스럽고, 한 달에 한 번 나가는 팀에서는 합쳐 둔 코드가 한 달을 기다리고, 그동안 쌓인 변경은 다시 한 덩어리가 됩니다.

한계도 분명합니다. 여러 버전을 동시에 지원해야 하면 이 방식만으로 안 됩니다. 고객사가 예전 버전을 쓰고 있고 그 버전에 보안 수정을 따로 내보내야 하면, 그 버전용 줄기를 오래 살려 두는 수밖에 없습니다. 이때는 본류는 트렁크 기반으로 굴리고 옛 버전만 별도 줄기로 두는 절충을 씁니다.

외부 기여자가 많은 공개 프로젝트에도 맞지 않습니다. 본류에 바로 합칠 권한을 모르는 사람에게 줄 수 없으니, 갈라 와서 검토받고 합치는 절차가 필요합니다. 역할별 브랜치를 나눠 운영하는 깃 플로우가 이런 자리에서 여전히 쓰입니다.

검사가 없는 팀에서 이 방식을 먼저 도입하면 반대 결과가 나옵니다. 하루 열다섯 번 합쳐지는 본류에 검사가 없으면 깨진 코드가 그대로 쌓이고, 누가 깼는지 찾는 데 시간이 더 듭니다. 순서는 검사를 먼저 세우고 그다음에 브랜치 수명을 줄이는 쪽입니다.

"이 브랜치 5일째예요. 오늘 합칠 수 있게 잘라 주세요."

수명이 길어지고 있으니 조각을 나누자는 말입니다.

"기능이 안 끝났는데 어떻게 합쳐요? 플래그로 꺼 두면 됩니다."

미완성 코드를 올리는 방법을 짚어 준 것입니다.

"본류가 깨져 있어요. 검사부터 세우고 이 방식으로 넘어가죠."

순서가 뒤집혔다는 지적입니다.

페이지덱은 태오가 들어온 뒤에 이 방식으로 바꿨습니다. 그전에는 기능별 브랜치가 평균 9일이었고, 합치는 날마다 충돌을 푸는 데 반나절이 들었습니다. 바꾼 뒤 브랜치 수명은 평균 1.2일이고 충돌은 대개 한두 줄에서 납니다.

옮기는 과정에서 걸린 것은 브랜치가 아니라 일 자르기였습니다. 지현이 요구사항을 쓸 때부터 하루치로 나눠 적기 시작했고, 그게 자리 잡기까지 두 달쯤 걸렸습니다. 도구는 첫날에 바뀌었지만 습관은 아니었습니다.

브랜치를 쓰지 않는 방식이라고 읽는 경우가 가장 많습니다. 이름에 본류가 들어가 있고 오래 사는 브랜치를 없애라고 하니 그렇게 들립니다. 실제로는 브랜치를 쓰고, 다만 수명을 하루 안으로 줍니다. 아예 쓰지 않고 본류에 직접 올리면 리뷰를 걸 자리가 사라지고, 깨진 코드가 검사 전에 본류에 들어갑니다. 브랜치를 금지로 이해한 팀은 리뷰를 함께 버리게 되고, 그러면 이 방식이 막으려던 문제와 다른 문제를 새로 얻습니다.

합치는 횟수만 늘리면 된다고 보는 시각도 자주 나옵니다. 규칙이 하루에 한 번이니 그것만 지키면 되는 것처럼 보입니다. 하지만 이 방식이 실제로 요구하는 것은 일을 하루치로 자르는 능력이고, 그건 요구사항을 쓰는 단계부터 달라져야 하는 일입니다. 자르는 연습 없이 횟수만 늘리면 절반만 만든 코드가 플래그도 없이 본류에 올라가고, 사용자가 만들다 만 화면을 보게 됩니다. 도구 설정은 하루면 바뀌지만 이 습관은 두어 달이 걸립니다.