Release Branch, Function Branch and Customer Branch

서영아빠님의 "브랜치를 이용하여 운영환경에 선별적으로 배포하기"란 글을 보고 소프트웨어 프로젝트에서 브랜치란 어떤 의미를 가지는지 "소프트웨어 개발의 모든것"이라는 책에서 이에 대하여 소개한 내용이 있는데 이를 인용하여 설명을 하려고 합니다.

여기서 소개하는 브랜치에 대한 얘기의 핵심은 브랜치의 위험성에 대한 "경고"입니다.

브랜치는 위험하지만 소프트웨어 개발에서는 흔히 꼭 필요하게 되어서 철저히 통제가 되어야 한다는 것입니다.

브랜치(Branch)

브랜치란 필요에 의해서 소스코드를 분기하는 것이다. 

브랜치를 얼마나 잘 통제하는가가 훌륭한 소프트웨어 회사와 평범한 소프트웨어 회사를 구별하는 핵심 요소 중 하나이다. 

브랜치를 해야 하는 경우를 예로 들면 다음과 같다.

• 제품을 출시 후 유지보수를 하면서 동시에 업그레이드 프로젝트를 진행할 경우
• 이미 출시 된 제품에 복잡한 기능을 추가하려고 할 경우
• 고객이 제품에 특정 기능을 넣어 달라고 요구를 하는데, 그 기능이 제품의 표준 기능에서 벗어날 경우
• 고객이 제품에 특정 기능을 넣어 달라고 요구를 하는데, 표준 기능으로 넣을 시간이 부족한 경우

제품 출시 후 유지보수와 업그레이드 프로젝트를 진행하면서 하나의 소스코드를 같이 사용한다면 완전히 뒤죽박죽이 될 것이다. 아직 완성되지 않은 기능들이 고객에게 전달 될 수도 있다. 이 경우 소스코드를 브랜치하여 브랜치 된 소스코드를 유지보수를 위해 사용할 수도 있고, 업그레이드 용으로 사용할 수도 있다. 상황에 따라서 적절하게 선택하면 된다. 가능하면 적게 바뀔 것을 브랜치로 사용하는 것이 좋을 것이다. 왜냐하면 브랜치는 나중에 트렁크(Trunk)와 머지를 할 것이기 때문이다. 이렇게 서로 다른 소스코드를 가지고 개발하다가 업그레이드 프로젝트가 끝날 때쯤 그 동안 유지보수를 하면서 버그를 수정하거나 일부 기능을 추가한 것들을 서로 머지하게 된다. 이러한 브랜치를 릴리즈 브랜치(Release Branch)라고 부른다.

이미 제품이 출시되어서 유지보수를 하고 있을 경우, 시간이 많이 걸리거나 리스크가 큰 기능을 추가할 때도 브랜치를 사용할 수 있다. 예를 들어 어떤 제품이 2주일에 한번씩 업데이트를 한다고 할 때, 어떤 기능은 구현하는데 4주가 걸린다면 2주 만에 업데이트를 할 때, 완성되지 않은 기능이 포함될 수 있다. 또는 구현의 가능성이 확실하지 않은 기능을 원래 소스코드에서 개발하느라고 소스코드를 마구 건드릴 경우 나중에 기능을 빼려고 해도 깔끔하게 원래대로 되돌려 놓기가 쉽지 않다. 이럴 때 브랜치를 해서 해당 기능이 완성된 후 메인 소스코드와 머지를 하면 된다. 이러한 브랜치를 기능브랜치(Function Branch, Feature Branch)라고 부른다.

브랜치 중에 가장 문제가 되는 경우는 고객의 특수한 요구를 만족시키기 위해서 제품이 분기되는 경우(Customer Branch)이다. 제품이 분기된 뒤, 나중에 머지되지 않고 영원히 브랜치가 유지되는 경우가 많다. 브랜치를 만들고 어느 시점이 지나면 원래 소스코드와 브랜치가 너무 차이가 많이 나서 머지가 거의 불가능해지기 때문이다. 

브랜치를 쉽게 생각하고 일단 소스코드를 분기해서 별도의 제품을 만들기 시작하는 것은 되돌아 올 수 없는 강을 건넌 것이나 다름없다. 경험이 부족한 개발자는 브랜치의 부담을 우습게 생각하기 쉽다. 실제로 초기에는 브랜치가 있어도 견딜만하고 관리할 만 하다. 특히 브랜치를 해야만 매출을 일으키는 경우라면 브랜치의 유혹을 뿌리치기가 쉽지 않다.

그러나 이렇게 브랜치를 계속 만들다 보면 더 이상 감당이 안 되는 때가 오게 된다. 회사가 어느 정도 매출이 일어나고 잘되기 시작하면 과거에 많이 만들어 놓은 브랜치가 더욱 발목을 잡는다. 어차피 제품이 많이 팔리지도 않았다면 문제가 될 것도 없다. 오히려 회사가 잘될 때 문제가 된다. 이쯤 되면 제품의 업그레이드나 신제품 개발보다는 브랜치 관리에 더 많은 노력을 기울일 수밖에 없게 된다. 버그를 하나 고쳐도 여기저기 브랜치를 다 손대야 한다. 어느 브랜치를 어느 고객이 쓰고 있는지 헷갈려서 배포 사고도 가끔 발생한다. 무슨 툴을 하나 만들어도 각 브랜치마다 다르게 개발해야 하는 어려움이 발생한다. 

브랜치가 많아지면 웬만큼 관리를 잘하지 않고는 어느 브랜치에 무슨 기능이 포함되어 있는지 정확하게 파악하기 힘들어 진다. 초기에 브랜치를 만들었던 개발자들도 얼마 간은 브랜치 내용을 정확하게 기억하고 있을지 모르지만, 시간이 지나면 브랜치를 만든 개발자마저도 브랜치 내용을 정확하게 기억하기 어려워진다. 게다가 문서는 없고, 사람마저 바뀌어버리면 정말 알 수 없는 상황이 된다. 이로 인한 문제를 말하자면 끝이 없지만, 한마디로 아수라장이 되어버린다고 할 수 있다.

브랜치가 필요하다고 해서 개발자가 원할 때마다 브랜치를 해서는 안 된다. 브랜치를 하려면 개발 조직의 최고 책임자나 위원회의 허락을 받도록 하는 것이 좋다. 이 때는 브랜치를 해야 하는 이유를 타당하게 설명해야 하고 가능하면 빨리 머지를 할 수 있는 계획도 세워야 할 것이다.

특히 영업 지향의 회사에서는 브랜치의 위험성에 대해서 이해하지 못하는 경우가 많다. 단기적인 매출의 유혹이 회사의 미래를 망치는 경우를 종종 보게 된다. 고객마다 소스코드가 다르고 매번 각 사이트를 지원하기 위해 개발자들이 고객 전용 소스코드를 수정하고 있어도 이를 당연한 것으로 생각하기 쉽다. 이렇게 되풀이 되는 일들이 개발자들의 사기를 떨어뜨리는 것은 물론이다.