Life Algorithm

Coding Horror에서 트랙백합니다.

가려운 곳을 제대로 긁은 글이네요. 구슬이 서말이라도 꿰어야 보배라...-_-

어떤 툴이든 사용하는 것만으로 모든 문제가 해결되지는 않습니다. 마찬가지로 버전 관리 도구 또한 쓰기만 한다고 소스 코드의 히스토리가 잘 관리되는 것은 아닌 것 같습니다. 그간의 경험에 비추어 보면요...

위의 글은 특히 브랜치와 머지에 관해 쓴 글인데, 버전 관리도구를 쓰면서 브랜칭을 쓰지 않으면 '왜 버전 관리 도구를 쓰는가'라고 묻고 있습니다. 브랜치 안해도 도움은 되지요, 소스의 변경 이력이 남는다는 점만 해도 매우 크다고 저는 생각합니다.
하지만 반대로 '브랜치를 제대로 하는가'에 대한 내용도 쓰고 있습니다. 이건 쉽지 않은 문제입니다.
글에서는 피해야 할 브랜치와 머지 패턴(anti-pattern)에 대해 나열해 놓았는데 재미있습니다.

머지 기피증(Merge Paranoia) : 두려움에 머지를 하지 않는다.
머지 매니아(Merge Mania) :개발보다 머지에 과도한 시간을 투자한다.
빅뱅 머지(Big Bang Merge) :머지가 개발의 끝단계로 미뤄지고 결국 모든 브랜치를 동시에 머지하면서 큰 혼란이 생긴다.
끝없는 머지(Never Ending Merge) : 머지가 끝날 것 같지 않다 -_- 머지할게 계속 나온다.
잘못된 머지(Wrong Way Merge) : 과거 버전과 머지한다(버전 관리가 잘못되어서 최신 버전이 구분안됨).
브랜치 매니아(Branch Mania) : 브랜치가 너무 자주, 별 이유없이 만들어진다.
끝없는 브랜치(Cascading Branches) : 브랜치들이 메인 브랜치로 머지되지 않고 계속 가지만 쳐 나간다
미스테리 머지(Mysterious Branches) : 누구도 그 브랜치가 왜 만들어졌는지 모른다.
임시 브랜치(Temporary Branches) : 브랜치에 계속 변경을 시도하고 쌓이면서 영원한 '임시' 브랜치가 되어버린다.
가벼운 브랜치(Volatile Branches) : 안정되지 않은 수준의 브랜치가 계속 다른 브랜치에 공유되고 머지된다.
개발 중지(Development Freeze) : 브랜치하고 머지하고 빌드를 만드는 동안 개발 자체가 진행되지 않는다.
베를린 장벽(Berlin Wall) : 브랜치가 작업에 따라 나눠지지 않고 개발자별로 나눠진다 -_-

브랜칭은 소스 관리에서 매우 중요한 요소입니다만 제대로 브랜치를 다루기는 역시 쉽지 않습니다.
어떻게 보면 개발 외적인 문제라 SVN이나 CVS 사용법을 다룬 책은 있어도 브랜칭이나 태깅의 노하우까지 다룬 책은 거의 없습니다.
위의 사항들 중 제가 있는 회사에 해당되는 것도 몇 있군요, 제게 해당되는 거라고 해야 할 지...ㅡㅡ;

여튼 위의 피해야 할 패턴들을 종합해 보면, 브랜칭 목적이 확실해야 하고 메인 브랜치에 반드시 다시 머지가 되는 것을 목표로 해야 합니다.

브랜칭 목적이란 것은 간단할 수도 있고 복잡할 수도 있지만, 최소한 버전업이나 단일 기능 추가를 위한 브랜치가 가장 바람직하지 않나 싶습니다. 크게 보면 같은 의미일 수도 있겠습니다.
대표적인 것은 리눅스 커널이나 FreeBSD 커널의 개발 방식인데 메인 브랜치는 계속 유지하면서 마이너 버전을 릴리즈하고 메이저 버전의 업데이트를 위한 브랜치는 따로 따서 머지 시점까지 계속 개발을 하는 것입니다.

메이저 버전의 업데이트란 것은 구조 변경이나 기능 추가가 중점적이기 때문에 현재 버전의 브랜치에 개발하다가는 릴리즈 버전에 불안정한 버그가 포함될 수 있습니다. 즉, 메인 브랜치는 안정화를 위해 개발력을 투자하고 메이저 버전 업데이트 브랜치는 기능을 추가하거나 구조를 변경하는 작업을 한 후 최종적으로 머지와 테스트를 해서 다음 메이저 버전을 릴리즈하는 것입니다.

단일 기능 추가를 위한 브랜치는 좀 더 직관적입니다. 브랜치 자체를 'thread 지원', '암호화 기능 지원' 등의 단일 기능 추가를 위한 목적으로 따서 개발하고 머지하는 것입니다.

말은 쉬운데, 그렇다면 왜 위에서 열거한 경우가 생기는 것일까요? ㅡㅡ
모든 경우를 경험해 보진 않았지만, 많은 경우는 프로젝트 매니징과 관련이 있습니다. 프로젝트 매니저가 확실한 개발 로드맵을 정하고 개발을 진행시켜야 하는데, 중간에 계속 우선순위가 바뀌거나 한다면 개발하던 브랜치가 쓸모없어지는 경우가 많습니다.
건드리지 않은 채로 브랜치가 오랜 시간이 지나면, 만들었던 사람조차 '내가 왜 이걸 만들었지?'라고 고민하게 되거나, '지금 상황에선 필요없어졌는데..'라거나 '작업했던게 아까우니 일단 놔두자' 이런 식으로 흘러가게 됩니다.

브랜치(branch)란 이름을 누가 붙였는지 모르겠지만, 참 잘 붙인 것 같다는 생각이 드네요. 브랜치도 실제 화분처럼 신경을 안 쓰고 냅두면 말라 비틀어집니다. 그리고 때가 되면 가지치기를 해야 하듯, 머지해야 할 시점에서는 머지가 필요하다는 판단을 내릴 수 있어야 합니다.
물론 머지하기 전에 추가한 내용에 대한 기본적인 테스트가 필요하며, 머지한 후에도 이상이 없는지 테스트를 잘 해보아야하겠지요. 머지 뿐 아니라 개발과 관련된 두려움을 없애는 가장 좋은 방법은 테스트입니다.

모든 것이 다 별개인 것처럼 보이지만 결국 다 이어져 있게 마련입니다.
개발이나 프로그래밍이란 단어에는 코딩 뿐 아니라 위에 언급한 것들까지도 모두 포함되는 것이 맞겠지요. 좋은 개발자가 된다는 것은 역시 쉽지 않습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)