형상관리와 버전관리

형상관리

소프트웨어는 한번 만들어졌다고 해서 그걸로 끝나는 것이 아니다. 환경의 변화나 기술의 변화에 따라 지속적으로 변경이 이루어지기 때문이다. 그렇지만 새로 적용한 방식, 변화가 완벽하기만 한 것은 아닐 것이다. 따라서 특정 소프트웨어가 변화해 온 과정, 이력을 관리하는 것이 필요하다. 형상관리란 이런 소프트웨어의 변경사항을 체계적으로 관리하는 것을 의미한다.

버전관리

버전관리는 동일한 정보에 대한 여러 버전을 관리하는 것이다. 소프트웨어공학에서는 일반적으로 소스 코드만을 관리하는 것을 버전관리라고 정의한다. 이보다 더 세밀한 개념으로 변경관리가 있는데, 변경관리는 '소스코드'의 변경사항을 관리하는 것이고 버전관리는 이러한 변경사항을 '버전'이라는 개념을 통해 관리한다는 점에서 그 차이가 있다.

형상관리와 버전관리는 언뜻 개념에 차이가 없는 것처럼 보인다. 그러나 정확히 말하자면 형상관리 안에 버전관리가 포함되어 있다고 볼 수 있다. 형상관리는 버전관리를 포함하여, 소프트웨어 프로젝트와 관련된 모든 변경사항을 관리한다는 점에서, 단순히 변화를 관리하던 버전관리와, 버전관리 기반의 소프트웨어 운용을 조금 더 넓힐 수 있었다고 볼 수 있기 때문이다.

그러나 실무에서는 변경관리, 버전관리, 형상관리가 명확하게 구분되고 있지는 않고, 대체로 비슷한 의미로 사용된다고 한다.

버전관리 도구의 시대별 변화

• 1982년 RCS(Revision Control System) - 로컬 장비의 파일 관리용 / 공유 불가
• 1990년대 CVS(Concurrent Versions System) - RCS를 다수가 공유할 수 있도록 개선. 클라이언트-서버 모델로 구축 / 리비전 관리가 파일 기반으로 구현, 파일별로 리비전 번호 부여하는 불편함이 있었음
• 2000년대 SVN(Sebversion) - CVS에 체인지 셋이라는 개념을 추가하여 관련 파일들을 하나로 묶어 리비전 번호를 부여할 수 있게 됨. 브랜치 작성 쉬움 / 기존 메인과의 소스코드 병합이 어렵다는 단점이 있었음
• 2005년 GIT - 중앙 Repository를 가지지 않는 완벽한 peer-to-peer모델
• Git, Mercurial, Bazaar - 분산 버전 관리 시스템을 기반으로 한 버전 관리. 클라이언트-서버 모델이 아니라 Repository 전체가 로컬 환경에 보유하는 형태. 네트워크를 경유하지 않아도 버전관리가 가능하게 되었다. 브랜치 역시 로컬이기 때문에 자유롭게 브랜치 생성이 가능하게 되었고, 서버에 브랜치를 생성하지 않아도 되는 장점이 생겼다. 이 외에 remote Repository로 소스코드를 업/다운하는 기존 SVN 모델과 change set, merge 모델은 그대로 따르는 형태이다.

사용 추이를 보면 CVS는 2004년 이후 지속적으로 감소하고 있고, 그동안 SVN 사용이 급격히 상승하는 추세를 보인다. 그러나 2007년 이후 SVN 역시 사용이 감소하게 되었고, 2012년에는 GIT이 SVN의 사용을 넘어서게 된다. 그리고 2016년 이후, GIT은 가장 널리 사용되는 버전 관리 도구가 되었다.