소프트웨어 프로젝트는 하나의 제품을 빌드하기 위해 서로 연동되어야 하는 많은 파일을 보유하고 있다. 특히 프로젝트에 복수의 개발자가 개입되어 작업을 수행하는 경우, 이들 파일에 대한 추적관리를 유지하기 위해서는 많은 노력이 필요하다. 그래서 소프트웨어 개발 팀들이 수년 간 이러한 것들을 관리하기 위한 툴을 만들었다는 사실은 그리 놀랄 일이 아니다. 소스코드 관리 툴, 형상관리 툴, 버전관리 시스템, 저장소등의 다양한 이름으로 불리우는 이러한 툴은 대다수 개발 프로젝트에서 필수 불가결하게 구비해야 하는 부분이다 . 하지만 안타깝게도 모든 프로젝트가 이들을 활용하여 진행되지는 않는다. 드문 일이긴 하지만, 나는 앞서 얘기한 시스템들을 사용하지 않고, 엄청나게 많은 로컬 및 공유디렉토리를 이용하여 프로젝트를 진행한 적도 있다.
기본적인 사항으로서, 먼저 괜찮은 소스코드 관리시스템을 확보해야 한다. 좋은 품질의 오픈소스 툴들이 있으므로 비용은 이슈가 되지 않는다. 최신 오픈소스 저장소는 Subversion이다. (오래된 오픈소스 툴인 CVS가 아직도 널리 쓰이고 있고, 아무것도 안쓰는 것보다 CVS를 쓰는게 낫긴 하지만, 최신의 선택은 Subversion이다.) 흥미롭게도 나는 개발자들에게 Subversion만한 상용툴은 없다고 얘기한다. 가격을 치룰만 하다고 사람들로부터 한결같이 듣게 되는 단 하나의 툴은 Perforce이다.
일단 소스코드관리 시스템을 확보했다면, 소스는 그 저장소에 있다는 것을 누구든지 알 수 있어야 한다. “내 ‘방구파일’이 어디에 있는지 모르겠어요.” 이런 말이 나와서는 안된다. 모든 것은 저장소에 있어야 한다.
저장소를 쓰고 있는 많은 팀들이 일반적으로 저지르는 실수 중 하나가 모든 것을 저장소에 집어넣지 않는 것이다. 소스만 저장소에 집어넣는 것이 아니라 빌드에 필요한 모든것( 테스트 스크립트, 환경파일, 데이타베이스 스키마, 설치스크립트, 제3자 라이브러리를 포함한 기타등등)들을 저장소에서 관리해야 한다. 나는 (C++컴파일러 초창기 때는 중요했던) 컴파일러를 저장소에 집어넣은 프로젝트도 본 적이 있다. 내 경험 상 원칙을 얘기하자면, 최소한의 것들 -OS, java개발환경, DB시스템등 같이 일반적으로 규모가 크고, 설치하기 복잡하며, 안정된 형태의 것들-만 설치된 초기화 머신이 있는 프로젝트에서 체크아웃을 수행하여 시스템을 완전히 빌드 할 수 있어야 한다.
소스코드 통제 시스템에 넣어야 하는 것들은 소스를 빌드하기 위해 필요한 모든 것들이며, 이에 더하여 사람들이 작업할 때 필요한 것들을 모두 넣을 필요가 있다. IDE 환경 설정 같은 것은 개발자들이 IDE 셋업을 쉽게 하기 위해서 필요하므로 저장소에 넣어두는 것이 좋다.
버전 통제 시스템의 특징 중에 하나는 개발과정에서 다른 스트림들을 조작하기 위해 복수의 브랜치를 사용할 수 있다는 점이다. 이는 효과적인, 아니 필수불가결한 기능이지만 남용되는 경우가 많으며, 사람들을 문제에 빠트린다. 브랜치를 최소한만 사용해라. 특히 단일 메인라인-현재 개발중인 프로젝트의 단일 브랜치-을 유지해야 한다. 꽤 많은 개발자들이 대부분의 시간을 특히 이 메인라인에서 작업해야 한다.(버그픽스, 임시 실험용, 이전 제품릴리즈 등 만이 브랜치를 사용하게되는 합리적인 경우이다.)
일반적으로 빌드 한 결과물만 빼고 빌드에 필요한 모든것을 소스코드 컨트롤에 저장해야 한다. 어떤 이는 빌드결과물을 소스코드 컨트롤에 집어넣기도 하는데, 나는 이를 냄새(smell)-더 깊은 문제(통상 확실하게 빌드결과물을 재생성 할 수 없는 문제)의 조짐-로 간주한다
본 포스트는 Martin Fowler 선생께서 쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)
