브랜치 전략 도입에도 전략이 필요합니다 #2
구글 검색으로도 못 찾는 브랜치 전략 성공 방법 7가지
6. 머지의 속도가 빨라야 합니다.
머지의 속도가 늦어지면 지속적인 통합이나 빠른 주기의 배포를 달성하기가 힘듭니다. 브랜치를 처음 생성하고 머지하기까지의 시간이 오래 걸릴수록 히스토리는 옅어지고, 머지 컨플릭트의 가능성은 높아지며, 피드백을 받았을 때의 수정 가능성 또한 줄어듭니다. 시간이 갈수록 PR사이즈(변경된 코드 라인 수) 또한 증가하는 것은 덤입니다. 이렇게 되면 브랜치 전략을 유지하는 의미가 줄어듭니다. 브랜치 전략을 유지하는 이유는 안정적이고 빠른 배포와 협업 생산성을 위한 것이기 때문이죠.
7. 코드 리뷰가 빠른 머지의 속도를 방해하지 않아야 합니다.
코드 리뷰를 하는 회사도 있고 상황에 따라 하지 않는 회사도 있을 텐데요. 지금 하는 이야기는 코드 리뷰를 하는 회사입니다. 조금 간단한 규칙으로 머지되는 모든 코드는 리뷰를 해야 한다고 정해놓은 회사도 있을 텐데요. 물론 좋은 정책이지만 상황에 따라 역효과가 발생할 수 있습니다.
a. approve는 하지만 실제로는 코드를 읽어보지도 않는 경우.
코드 리뷰를 강제하는 정책을 가지고 있는 회사에서 흔히 일어나는 일인데요. 배포가 급하고 버그 수정이 급하니 코드를 읽어보지도 않고 LGTM과 approve를 누르는 경우가 있습니다. 이런 경우 문제가 됩니다. 나중에 어떤 PR이 리뷰가 된 코드이고 어떤 PR이 되지 않았는지 구분을 할 수가 없는데요. 코드 리뷰를 하지 않아도 approve를 눌렀기 때문이죠. 이런 경우 차라리 리뷰하지 않아도 머지가 가능한 정책을 만들고, 나중에 머지 후 리뷰(post-review)를 하는 것이 좋습니다.
b. 개발에 더 집중하고 싶어 리뷰를 하지 않는 경우
내가 맡은 기능을 담당하다 보면 다른 사람의 코드를 읽고 리뷰하는 것은 생각보다 꽤 귀찮은 일입니다. 내가 가지고 있는 집중의 전환이 일어나기 때문입니다. 내가 개발하고 있는 부분의 코드를 작성하고 있다가, 조금만 다른 생각을 하면 집중이 흐트러지고 기억이 휘발되기 쉽습니다. 그 경우 다시 처음부터 코드를 따라간 후 작업을 하게 되는데요. 이러한 일이 반복되다 보면 개발자는 일할 의욕이 떨어지고 개발 속도는 떨어지기 쉽습니다. 그래서 개발자들은 내가 개발에 집중하고 있는 동안에는 리뷰 요청이 와도 바로 응답하기가 쉽지 않죠. 그래서 필요한 것이 루틴화입니다. 아침에 출근하거나, 데일리 스크럼 이후 또는 점심을 먹고 난 후 다른 사람의 리뷰를 처리하는 루틴을 만드는 것이죠. 이것은 한 사람만 한다고 되는 것은 아니고 모든 팀원이 함께 노력해야 합니다. 비슷한 예로 의사들은 회진이라는 것을 하더라고요. 환자 보느라 얼마나 바쁘겠어요. 그럼에도 불구하고 주기적으로 같이 환자의 상태를 보며 동기화하고 서로가 가지고 있는 지식을 전파하는 것이 무엇보다 우선순위이기에 그렇게 하는 것이죠. 지식의 전파와 공유, 그리고 서로의 작업 상태를 확인하는 것이 주기적으로 될 수 있느냐가 개발 조직의 성공을 결정하는 열쇠입니다.
c. 코드 리뷰의 목적이 모호한 경우
개발자가 리뷰하는 한, 두줄의 코드에는 너무나도 많은 맥락이 담겨있는데요. 따라서 코드 리뷰로 모든 것을 확인하는 것은 쉽지 않습니다. 코드에 있는 모든 오류를 다 찾아내겠다는 식으로 리뷰를 하면 쉽게 지치고, 또 나중에는 리뷰가 하기 싫어질 수 있는데요. 개발자가 코드 리뷰에 대한 감정이 나쁘면 코드 리뷰를 자꾸만 미루게 되고, 이는 다시 팀 전체의 개발 속도를 저하시킬 수 있는 요인이 되어버립니다. 사실 코드 리뷰로 잠재적인 버그를 찾아내는 것은 불가능에 가까운데요. 버그는 사실 테스트로 찾아야 합니다. 다만 코드 스타일이나, 하드 코딩된 코드, 오류가 발생하기 쉬운 코딩 스타일, 아키텍처 오염 등은 코드 리뷰로 찾아내기 좋죠. 많은 사람들의 오해와 달리 코드 리뷰의 목적은 버그가 없는 완벽한 코드를 만든다기보다는, 버그를 예방할 수 있는 구조로 코딩했느냐를 보는 것에 가깝습니다.
d. 코드 리뷰가 지연되면 메신저나 대면을 통해 재촉해야 합니다.
코드 리뷰에 approve가 달리지 않으면 많은 개발자들이 "뭐 사정이 있겠지", "바쁜가 보지"라며 동료에게 한껏 감정이입을 하여 이해하려고 합니다. 어찌 보면 당연한 이야기인데요. 이렇게 하면 나중에 나도 바쁠 때 코드 리뷰를 재촉받지 않을 수 있으니까요. 하지만 팀 입장에서는 머지가 느려지기 때문에 분명한 손해입니다. 사실 팀이 성장하지 못하면 개발자로서 나의 커리어도 함께 성장하지 못할 가능성이 높으며, 우리가 이 자리에 모인 이유는 돈을 번다는 것 이외에도 팀의 성장을 함께 견인하기 위함이기 때문에 팀 전체의 입장에서 생각하는 것이 필요합니다. 팀 차원에서는 재촉을 하더라도 코드 리뷰가 빠르게 되는 것이 이익이며, 대부분의 스타트업에서 팀의 이익은 곧 개인의 이익과도 직결됩니다.
앞에서 소개해드린 내용은 브랜치 전략의 성공을 위한 일종의 전술(technique)입니다. 위 전술 중 가장 중요한 것은 무엇보다도 PR 사이즈를 작게 유지하는 것입니다. PR 사이즈를 작게 유지할 수만 있다면 다양한 브랜치 전략을 시도해보며 우리 팀에 가장 맞는 것을 찾아갈 수 있습니다.
