brunch

라이킷 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이경종 Dec 12. 2018

#44 소스코드 브랜치 전략

현명한 코드 관리에 대해

언제 어떻게 소스코드를 브랜치(Branch)하는 것이 좋을까? 우선 소스코드 관리 시스템에 있어 소스코드의 브랜치 및 머지(Merge) 관련 용어부터 정리해 보자.

● 트렁크(Trunk) : 나무의 둥치, 즉 메인 스트림(Main Stream) 소스코드이다

● 태그(Tag) : 브랜치되지만, 잎이 붙지 않는 나뭇가지라고 할 수 있다. 다시 말해, 마일스톤이나 숏컷(Shortcut)으로 활용되는 읽기 전용 브랜지이다.

● 브랜치(Branch): 둥치에서 뻗어나온 나뭇가지로 나뭇잎들이 붙으며(소스코드 변경), 또 다른 나뭇가지(branch)가 생겨날 수 있다.

프로젝트를 진행하는 동안 만들 수 있는 브랜치들에 대해서는 적지 않은 전략들이 존재한다. 사실 프로젝트 팀원들이 작업하는 각각의 소스코드들이 하나의 브랜치이며, 하나의 프로젝트 라이프 사이클 동안 개별 브랜치에서 트렁크로의 머지가 빈번하게 발생한다. 하지만 이런 브랜치들은 트렁크와 결국 동기화되고, 결국 코드의 차이가 발생하지 않는다는 점에서 이 글에서 다루고자 하는 일반적인 브랜치와는 다른 개별 개발자용 임시 브랜치라고 할 수 있다.

개발용 브랜치는 개발상황에 따라 제각각 가져갈 수 있다. 업무가 할당된 부분에 따라 소팀별로 브랜치를 가져갈 수도 있다. UI 개발팀과 플랫폼 개발팀의 브랜치는 분명히 다르다. 구현하는 기능별로 브랜치(Feature Branch)할 수도 있다. 다양한 상황에 맞는 브랜치가 필요하므로 그때그때 필요한 전략을 취하면 된다.

어느 정도 개발이 완료되면, 릴리즈 브랜치(Release Branch)를 하기도 하는데, 배포한 소프트웨어별로 소스코드를 브랜치하는 방식이다. 소프트웨어를 배포할 때 태그를 하는데, 이 태그로 다른 코딩 작업이 진행되면 바로 그것이 릴리즈 브랜치가 되는 것이다. 이 역시, 다양한 상황에서 특정한 조건에 의해 발생되므로, 상황에 맞는 브랜치 전략을 가져가면 된다.

그럼 신규 프로젝트의 브랜치 전략은 어떻게 가져가야 하는가?

신규 프로젝트의 베이스라인(Baseline) 소스코드를 무조건 트렁크(Trunk)로 가져가는 방식이 맞는 것일까?

하늘 아래 새로운 것은 없다는 말처럼, 신규 프로젝트라고 해도 그 소소코드는 기존의 프로젝트에서 온 것일 가능성이 크다. 특히 파생 프로젝트의 경우에는 대부분의 소스코드가 유사하다. 한두가지 부가적인 기능이 추가되는 경우에는 기능별 브랜치(Feature Branch)를 하는 전략을 가져가는 것이 현명한 선택일 수 있다.

하지만 실제 프로젝트를 진행해보면 소스코드 전반에 걸친 수정이 발생할 수 밖에 없고, 결국 브랜치(파생된 프로젝트의 소스코드)와 트렁크(기존 프로젝트 소스코드)의 머지는 초반에만 잘 진행되고, 이런저런 피치 못할(?) 사정때문에 미루고 미루고 또 미뤄지다가 결국은 머지가 거의 불가능해지는 상황에 직면한다. 결국 파생 프로젝트의 소스코드 역시 별도의 트렁크로 존재하게 되고, 개발조직에서 관리해야 하는 소스코드는 늘어나게 된다.

브랜치를 한다는 것은 트렁크에 지속적인 머지를 하겠다는 것이다. 따라서 브랜치를 한다는 것은 브랜치를 하고 머지를 하는데 따르는 비용이 독자적인 트렁크를 가져가는 비용보다 적다고 판단되는 경우에 할 수 있다. 또한 이 비용은 개발기간에만 국한되는 것이 아니라, 소프트웨어의 유지보수를 포함하는 소프트웨어의 라이프사이클에 발생하는 비용을 얘기한다.

그 판단은 누가 언제 어떻게 해야 하는 것인가? 프로젝트 매니져와 프로젝트 리더가 이 판단에 대한 책임을 가지며, 그 판단에는 프로젝트의 일정, 난이도, 할당된 개발자 등 프로젝트의 모든 요소가 고려되어야 한다. 결정권자의 경험 및 통찰력이 판단의 주요한 요소가 된다. 물론 그 결론이 잘못될 가능성 또한 존재한다. 향후 상황에 따라 잘못된 선택인 것으로 드러날 수도 있다.

솔직하게 말해서 브랜치에 따른 비용을 예측하는 것은 거의 불가능하다. 소프트웨어 및 비지니스 환경은 무생물과도 같아서, 상황이 어떻게 변할지는 아무도 정확히 예측할 수 없다. 브랜치 후 머지에 소요되는 비용(개발자 리소스) 때문에 결국 브랜치를 포기하는 경우도 비일비재하다.

그럼 아예 처음부터 모든 프로젝트를 독자적인 트렁크로 가져가는 것이 나을까? 그렇지 않다. 브랜치 전략을 고민하지 않고, 조삼모사의 달콤함에 무조건 트렁크로 프로젝트를 시작하는 것은 결국 유지보수의 늪에 개발자들을 내모는 결과를 초래하고 만다. 치열한 고민과 분석에 기반한 브랜치 전략은 소스코드의 효율적인 관리를 가능하게 한다. 잘 관리되는 브랜치는 유지보수의 비용을 크게 줄일 수 있으며, 소프트웨어 품질을 높이는 데 중요한 역할을 한다. 작은 개발조직임에도 불구하고 과거의 프로젝트 팀에서 이미 수정한 버그가 파생 프로젝트들의 소프트웨어에서 왕왕 발생하는 문제는 브랜치 및 머지를 효과적으로 수행하지 못 하기 때문이다.

한가지 더 얘기하고 싶은 것은 브랜치와 머지는 소스코드의 신뢰성이 확보될때 가능하다는 것이다. 기본이 안 되어 있는 개발조직에서 브랜치 전략에 대해 고민하는 것은 의미없는 일이다. 개발자들은 본인의 코드에 책임을 저야 하고, 소스코드 커밋 이전에 코드 리뷰 및 유닛 테스트를 100% 완료하는 것은 기본이다. 그렇지 않은 상태에서 브랜치 전략을 세워보았자 말짱 꽝이며, 그런 조직이라면 머지를 할때마다 폭탄을 맞을 것은 자명한 일이다.

keyword