"Baseline"이라는 용어가 생소한 개발자들이 있을 수 있습니다.
우리말로 번역을 하면 "기준선"이라고도 하는데, 헷갈리므로 그냥 Baseline이라고 사용해도 무관할 것입니다.
소스코드는 살아 있습니다. 매 순간 변화하고 있다고 봐도 됩니다. 실제로 몇 천명의 개발자가 참여하는 프로젝트에서는 소스코드 관리시스템의 로그를 보면 거의 매 순간 소스코드가 바뀌는 것을 알 수 있습니다. 또 작은 프로젝트라고 하더라도 어느 순간에 소스코드가 바뀔지는 알 수 없습니다. 그래서 Baseline을 관리하지 않으면 소스코드의 어느 의미 있는 순간을 잡아내는 것이 쉽지 않습니다. 그래서 Baseline을 관리합니다.
Baseline을 설정하는 방법은 여러 가지가 있습니다. 소스코드를 통째로 특정 디렉터리에 복사를 해 놓는 것도 Baseline설정의 한 방법입니다. 그 순간의 소스코드를 언제든지 꺼내 올 수 있죠. 하지만, 더 편리하고 일반적인 방법은 소스코드관리시스템의 Baseline설정 기능을 이용하면 됩니다. Visual SouceSafe에서는 Label이라고 하며 CVS, SVN에서는 Tag라고 합니다. 이중에서 SVN이 Baseline을 설정하는데 탁월한 성능적인 우위를 가지고 있습니다.
Baseline 설정이 왜 필요할지 해보지 않고 선뜻 이해를 한다는 것은 불가능합니다. 여태 Baseline 설정 한번 하지 않고도 소프트웨어를 잘 개발해 왔으니까요. 그럼 Baseline을 설정하지 않으면 어떠한 부작용들이 있는지 알아보죠.
가장 먼저 버그가 발생했을 경우 정확하게 버그가 발생한 그 버전에 대한 소스코드를 찾기가 어려워서 정확한 버그 재현이 곤란해질 수 있습니다. 그리고 릴리즈가 통제가 되지 않을 수도 있습니다. 즉, 1.5버전을 빌드해서 만들어 놓고, 은근 슬쩍 소스코드 몇 개 바꾸고 그냥 1.5버전을 다시 빌드해서 그냥 내보내는 겁니다. 사소한 것으로 생각해서 이렇게 하는 경우도 있지만, Baseline이 관리되지 않은 조직에서는 흔히 볼 수 있는 일입니다.
Baseline은 주민등록과 같이 개발팀에서 낳은 모든 아이(소프트웨어)의 기록입니다. 개발팀에서는 아무리 많이 소스코드를 바꾸어도 출생기록이 남는 것은 아닙니다. 하지만, 일단 소프트웨어가 빌드 되어서 개발팀 바깥으로 나가서 테스트팀으로 넘기던, 고객이 소프트웨어를 사용하던, Baseline라인이 관리되어야 합니다. 소스코드 한 줄을 바꿔서 다시 릴리즈를 했어도 Baseline은 바뀐 것이고, 다른 소프트웨어로 관리가 되어야 합니다. 그렇지 않으면 아이는 수십명 낳아놓고 각 아이들의 출생 기록도 없고, 이름도 없는 아이들이 많아지는 겁니다. 많은 아이 중에서 한 아이가 아픈데, 누가 아픈 것인지 정확하게 지칭도 못하는 일이 발생하기도 합니다.
소스코드관리시스템을 이용하면 아주 쉽게 Baseline을 설정할 수 있습니다. 기존에 Baseline을 설정하지 않고도 소프트웨어 개발에 문제가 없다고 하더라도, 기존의 방법에 익숙해진 것 뿐이지 문제가 없는 것도 아니고 효율적이지도 못합니다. 소프트웨어를 빌드하고 릴리즈하는 기준을 현재변화하고 있는 소스코드가 아닌 Baseline을 이용하는 방법으로 전환을 해야 합니다. 각론에 들어가면 회사마다 Baseline설정 규칙이 달라질 수는 있겠지만, 소프트웨어를 공식 빌드하고 릴리즈하기 위해서는 Baseline을 설정한다는 규칙은 바뀌지 않습니다.
이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
