머지

코드를 파일로 주고받던 시절에는 같은 파일을 둘이 고치면 나중에 저장한 쪽이 이겼습니다. 오전에 고친 내용을 공용 폴더에 올려 두면, 같은 파일을 받아 저녁까지 다른 부분을 고치던 동료가 자기 것을 올리는 순간 오전 수정이 사라졌습니다. 사라진 게 두 줄이면 다행이고 하루치가 통째로 날아가기도 했습니다.

그래서 팀은 파일을 잠그는 쪽으로 움직였습니다. 누가 파일을 열면 다 쓸 때까지 다른 사람이 못 건드리게 막는 방식입니다. 덮어쓰기는 사라졌지만 이번에는 기다리는 시간이 생겼습니다. "결제 화면 파일 언제 놓으세요" 가 하루에도 몇 번씩 오갔고, 그 파일을 잡은 사람이 휴가를 가면 일주일 내내 아무도 손대지 못했습니다.

머지는 둘 중 어느 쪽도 고르지 않은 답입니다. 같은 파일을 동시에 고치게 두되, 합칠 때 두 변경을 줄 단위로 비교해서 겹치지 않은 부분은 기계가 알아서 붙이고 겹친 부분만 사람에게 물어봅니다. 본류에서 갈라져 나온 작업 줄기인 브랜치를 각자 마음껏 따서 일하다 나중에 합치는 지금의 방식은, 이 계산이 자동으로 돌아간다는 전제 위에 서 있습니다.

합칠 대상을 정하고, 받는 쪽을 최신으로 맞추고, 합친 뒤 확인하는 순서로 진행합니다.

1. 받는 쪽으로 옮깁니다. 합쳐 넣을 줄기가 아니라 합쳐 받을 줄기에서 시작합니다. 기능 브랜치를 본류에 넣는 일이면 본류로 옮겨 섭니다.
2. 받는 쪽을 최신 상태로 내려받습니다. 내 컴퓨터의 본류가 사흘 전 상태면 그 사흘치를 모르는 채로 합치게 됩니다.
3. 합칩니다. 겹치지 않는 변경은 기계가 줄 단위로 붙여 넣고, 두 쪽이 같은 줄을 다르게 고친 자리에서는 멈추고 충돌을 알립니다. 충돌은 자동으로 합칠 수 없는 상태를 말하며, 어느 쪽을 남길지는 사람이 파일을 열어 정합니다.
4. 합친 결과를 확인합니다. 각자 돌 때는 멀쩡했는데 합쳐 놓으니 깨지는 경우가 있습니다. 테스트를 돌리고 화면을 한 번 열어 봅니다.
5. 기록이 남습니다. 합치기가 끝나면 합쳤다는 사실 자체가 하나의 커밋으로 남습니다. 커밋은 변경을 한 덩어리로 묶어 기록한 지점인데, 이 기록에는 합쳐진 두 줄기가 부모로 나란히 적혀 어디서 갈라져 다시 만났는지가 이력에 보입니다.

실무에서는 3번을 각자 컴퓨터에서 처리하지 않고 풀 리퀘스트를 거칩니다. 변경을 합쳐 달라고 올려 두는 요청인데, 화면의 버튼 하나로 합쳐지되 코드 리뷰 승인과 자동 검사 통과가 조건으로 걸립니다.

여럿이 각자 다른 부분을 며칠씩 붙들고 있다가 하나로 모을 때 제 값을 합니다. 특히 세 경우가 그렇습니다.

1. 한 저장소에서 여러 사람이 서로 다른 기능을 동시에 만들 때입니다. 각자 브랜치를 따 두면 남의 작업이 반쯤 된 상태여도 내 배포가 막히지 않습니다.
2. 이미 다른 사람이 받아 간 줄기일 때입니다. 기록을 옮겨 붙이는 방식은 기록 번호를 새로 만들기 때문에, 남이 그 줄기를 내려받은 뒤라면 두 사람의 이력이 어긋납니다. 머지는 기존 기록을 건드리지 않고 위에 한 줄을 더하는 방식이라 이 문제가 없습니다.
3. 언제 합쳤는지가 나중에 필요할 때입니다. 출시 직전에 급히 넣은 수정이 어느 시점에 들어갔는지 따질 일이 생기면 합친 기록이 그 답을 들고 있습니다.

한계는 둘입니다. 하나는 이력이 읽기 어려워진다는 점입니다. 열 명이 브랜치를 따서 하루에 서른 번씩 합치면 이력 그래프가 노선도처럼 얽혀, 지난주 금요일에 무엇이 들어갔는지 훑는 데만 한참이 걸립니다.

다른 하나는 미룰수록 비싸진다는 점입니다. 비용은 갈라져 있던 시간에 비례해 늘어납니다. 하루 만에 합치면 겹치는 줄이 두세 개라 10분이면 끝나지만, 3주를 묵히면 파일 열 개가 어긋나 있고 그중에는 상대가 이름을 바꿔 버린 함수까지 섞여 있습니다. 본류에 하루에도 여러 번 합치고 브랜치를 이틀 이상 두지 않는 트렁크 기반 개발은 이 비용 곡선을 아예 피하려고 정한 규칙입니다.

"이거 머지해도 될까요? 승인 하나 더 받아야 하나요?"

합쳐도 되느냐를 묻는 게 아니라 합칠 조건이 다 찼는지 확인하는 말입니다.

"본류 먼저 한 번 받아서 머지하고 다시 올려 주세요."

올라온 브랜치가 옛날 본류 위에 서 있으니 최신 본류를 그쪽으로 먼저 합쳐 오라는 요청입니다.

"금요일 저녁에는 머지 안 합니다."

합친 뒤 문제가 터지면 주말에 대응해야 하니 월요일로 미루자는 팀 규칙입니다.

페이지덱에서 태오가 댓글 알림 기능을 닷새 동안 자기 브랜치에서 만들었습니다. 그사이 본류에는 다른 사람들의 변경 열일곱 개가 쌓였고, 양쪽 다 알림 설정 화면을 건드렸습니다. 태오는 최신 본류를 자기 브랜치로 먼저 가져와 충돌 세 군데를 정리하고, 테스트가 전부 통과한 뒤에 풀 리퀘스트를 올렸습니다. 승인이 붙자 합치기는 버튼 한 번으로 끝났습니다.

순서를 뒤집어 본류에서 곧장 합치려 들면 문제가 본류에서 터집니다. 충돌을 정리하는 동안 본류가 반쯤 깨진 상태로 남고, 그때 다른 사람이 그 본류를 받아 가면 남의 작업까지 같이 멈춥니다.

충돌이 나면 누가 뭘 잘못했다는 뜻으로 읽는 경우가 가장 많습니다. 빨간 글씨가 여러 줄 뜨고 진행이 멈추니 오류처럼 보입니다. 실제로는 기계가 판단을 미룬 자리를 표시해 둔 것이고, 두 사람이 같은 줄을 동시에 고쳤다는 사실을 알려 주는 신호일 뿐입니다. 오류로 읽으면 사람은 충돌을 피하는 쪽으로 움직입니다. 남이 건드릴 만한 파일을 뒤로 미루거나, 브랜치를 더 오래 묵히거나, 한 파일을 혼자 잡고 다른 사람을 기다리게 합니다. 셋 다 파일을 잠그던 시절로 돌아가는 길이고, 미룬 만큼 나중에 더 큰 충돌로 돌아옵니다.

합쳐졌으니 코드가 맞다는 뜻으로 읽는 것도 흔합니다. 화면에 성공이라고 뜨니 검증이 끝난 것처럼 느껴집니다. 기계가 본 것은 줄이 겹쳤는지뿐입니다. 태오가 함수 이름을 바꾸고 동료가 같은 함수를 다른 파일에서 새로 불렀다면 두 변경은 줄이 겹치지 않아 조용히 합쳐지고, 합쳐진 결과는 돌지 않습니다. 이 상태로 본류에 들어가면 다음 사람부터 화면이 뜨지 않고, 원인을 찾는 데 반나절이 갑니다. 합친 뒤에 테스트를 돌리는 절차가 붙어 있는 이유입니다.