대다수의 개발자들은 버전 관리 도구를 사용해서 처음 개발에 착수한 시점에서 고객에게 제품을 인도할 시점까지의 모든 변화를 기록하고 관리하고 있다. 버전 관리는 팀 단위로 개발을 진행해 나가는데 있어서 필수적인 형상 관리 요소의 하나이기 때문이다. 특집 5부에서는 아직도 버전 관리를 실천하지 않는 개발자들을 위해 그 필요성과 대표적인 도구들의 사용 방법에 대해 살펴볼 것이다.

소프트웨어 형상 관리(SCM: Software Configuration Management)는 크게 1)소프트웨어 변경 요구가 발생한 것부터 구현까지의 전 과정을 제어하고 기록하고 보고하는 변경 관리와 2)그러한 개발 주기 동안의 변화하는 코드와 라이브러리, 관련 문서 등을 저장하고 관리하는 버전 관리, 3)제품의 릴리즈나 빌드에 반영된 변경을 감사하고 관리하는 릴리즈 관리 등으로 구성된다.

이러한 형상 관리 절차 중에서 이 장에서 소개할 버전 관리를 하지 않을 경우 어떤 문제들이 일어나는지 살펴보자.

버전 관리의 필요성

여러 사람이 함께 작업할 경우 작업 결과를 모아두는 곳이 필요하다. 이때 쉽게 떠올릴 수 있는 것이 FTP 서버나 공유 서버에 작업 결과물을 모아둘 저장소를 만들어 두는 것이다. 그 저장소에는 프로그램의 소스 코드도 있을 것이고, 개발 과정을 정리한 문서, 프로그램에서 사용하는 라이브러리 등도 있을 것이다.

각각의 개발자는 작업을 하기 위해서 그 저장소에 저장된 파일을 가져와서 자신의 로컬 PC에 복사본을 만들어서 작업을 수행한다. 그런 다음 작업이 끝나면 다시 그 결과물을 저장소에 넣어둘 것이다. 이런 상황에서는 몇 가지 문제점이 발견된다.

우선 서로 다른 두 명의 개발자가 동시에 같은 파일을 복사해서 작업한 다음 저장소에 올리는 경우를 생각해보자. 열심히 작업을 해서 한 명이 먼저 작업을 끝내서 저장소에 올렸다. 잠시 후에 그 사실을 모르고 있는 또 다른 개발자가 저장소에 자신의 작업 결과물을 저장소에 보내는 순간 덮어쓰기가 일어나며 앞선 개발자의 작업은 덧없이 날아가 버린다.

물론 저장소에 올리기 전에 내가 내려 받은 파일의 최종 수정일을 기록해뒀다가, 올리기 전에 서버의 최종수정일이 변하지 않았는지를 확인하면 되지만 너무나 귀찮은 일이다.

혹 그런 귀찮음을 무릅쓰고 철저하게 확인을 한다 하더라도, 날짜가 변경되어 있을 때 도대체 누가 어떤 목적으로 그 파일의 어떤 부분을 수정했는지 알아내려면 모든 개발팀에게 “누가 언제 왜 어떤 목적으로 어떤 부분을 수정했나요?”하고 일일이 물어봐야 한다.

물론 이러한 확인이 이뤄진 후에도 앞서 작업한 개발자와 상의해서 서로 다른 두 개의 결과물을 조정해서 합의된 최종 결과물을 만든 후에 서버에 올리는 것도 여러분의 몫이다.

또 다른 경우는 며칠 전의 상태로 작업 결과를 되돌려야 하는 상황이 발생할 때이다. 1차 개발을 완료한 시점에서 추가적인 요구 사항을 처리하기 시작했다고 가정해보자. 이 때 잘못된 판단으로 도저히 회복하기 힘든 큰 실수를 저질러서 차라리 1차 개발이 완료된 시점에서 다시 개발하는 것이 좋을 때도 있을 것이다.

단순한 공유 서버를 사용했을 때 이런 상황을 해결하기 위한 방법은 전체 작업 결과물을 특정 날짜 별로 복사해서 따로 관리하는 것이다.

이 방법은 물론 특정 날짜의 작업으로 되돌릴 수 있지만, 작업 결과물의 덩치가 크고 개발기간이 길수록 불필요한 디스크의 낭비가 심해진다. 만일 2시간 전의 상태로 저장소를 되돌리고 싶다면 어떻게 할까?

매 시간마다 또 특정 태그를 붙인 복사본을 만들면서 작업을 할 것인가? 또 어떤 내용은 그대로 두고 특정 파일만을 이틀 전의 상태로 되돌리고 싶을 때는 어떻게 할 것인가?

소프트웨어의 큰 특징 중 하나는 프로젝트가 진행되는 기간 동안 그 소프트웨어는 계속해서 변경된다는 것이다. 이 때 변경되는 것은 여러분이 작성한 코드 뿐 아니라, 관련된 문서나 적용하는 라이브러리를 포함한 프로젝트의 모든 산출물이다.

여러 명이 동시에 작업하는 프로젝트라면 그러한 변경으로 인해 모든 개발자의 작업이 영향을 받게 된다. 바로 이런 문제들을 해결하기 위해 등장한 것이 바로 버전관리 시스템이다.

버전 관리시스템 유형

버전 관리 시스템은 수십 개의 제품이 알려져 있는데 크게 세 가지 기준에 의해 구분할 수 있다. 첫 번째 기준은 저장소 구조의 차이다. 개발자 개개인이 공유된 저장소를 가지는 형태의 분산 모델 유형과, 서버에 저장소를 두고 각자 복사본을 가지고 작업하는 형태의 클라이언트-서버 모델 유형이 있다.

두 번째는 소스 공개 유형에 따라 오픈소스 제품과 상용 제품으로 구분된다. 마지막 세 번째 기준은 서로의 작업이 충돌하는 것에 대한 인식의 차이다.

작업 충돌이 잘 발생하지 않기 때문에 자유롭게 사용하고 충돌이 나면 해결하자는 낙관적 잠금 방식을 채택한 제품과, 충돌이 발생하면 처리 과정이 복잡하기 때문에 한 사람이 작업을 할 때는 다른 사람이 작업을 할 수 없도록 막아버리는 비관적 잠금 방식을 채택한 제품으로 구별된다.

많이 알려진 제품들 중에서 Gnu Arch는 분산 모델을 채택한 오픈소스 제품이고, IBM의 ClearCase는 클라이언트-서버 모델을 채택한 상용 제품이다.

분산 모델보다는 클라이언트-서버 모델이 일반적으로 사용된다. 클라이언트-서버 모델 중에서도 마이크로소프트의 Visual SourceSafe는 비관적 잠금 방식을 채택한 상용 제품이고, 이 글에서 소개할 CVS와 SVN은 낙관적 잠금 방식을 채택한 오픈소스 제품이다. 그럼 이제부터 CVS와 SVN에 대해 살펴보자.

CVS를 극복한 SVN

CVS(Concurrent Version System)는 1986년 Dick Grune에 의해서 개발된 가장 대중적인 버전관리 시스템이다. 오랜 시간 개발자들에게 버전관리 시스템의 대명사로 불리다 보니, 버전관리를 위한 다양한 기법들이 연구되었다. 그 결과로 윈도우 버전과 웹 버전, 편리한 GUI 클라이언트 등도 개발되었다. 현재까지도 많은 프로젝트나 기업에서 CVS를 버전관리 시스템으로 사용하고 있다.

그러나 CVS 프로토콜은 한 번 등록된 디렉토리나 파일의 이동이나 이름 변경을 허용하지 않았으며, 역사적으로 RCS를 따라 나왔기 때문에 개별 파일 단위로만 버전관리가 되었다.

그 뿐 아니라 아스키코드로 된 파일명만 지원할 뿐 유니코드에 대한 지원이 제한적이어서 우리나라처럼 유니코드로 지원되는 언어를 쓰는 국가에서는 파일 이름을 모두 영어로 변경해야 했다.

2004년부터 CVS의 핵심 개발자들이 보다 나은 CVS를 표방하며 개발하기 시작한 SVN(SubVersion : 서브버전)이 등장한 이후에는 버전관리 시스템의 대명사라는 자리는 빠르게 SVN으로 옮겨가고 있다. CVS와 비교한 SVN의 장점은 다음과 같다.

• 소스코드 뿐 아니라 바이너리(문서/라이브러리 등)도 지원한다.
• 커밋의 단위가 개별 파일이 아닌 변경된 작업 단위이다.
• 디렉토리나 파일 별로 세밀한 접근제어가 가능하다.
• CVS에 비해 빠르다.
• CVS와 개념 및 사용법이 거의 같아서, CVS 사용자가 쉽게 옮겨올 수 있다.

이미 CVS로 오랜 기간 버전관리를 수행해 왔으며, CVS의 상대적인 약점을 전혀 불편해 하지 않는 사용자를 제외한다면 버전관리 시스템으로 SVN을 선택하는 것은 당연한 것처럼 느껴진다.

SVN 서버 설치

SVN을 사용하려면 우선 서버에 SVN을 설치해야 한다. SVN의 설치와 사용에 관한 내용은 Subversion HOW-TO(한글) 문서에 잘 정리되어 있다. SVN을 통한 버전관리를 주제로 책 한 권이 나올 정도로 깊이 소개하자면 끝이 없기 때문에 여기서는 핵심적인 몇 가지 내용만을 짚고 넘어가고자 한다.

SVN은 클라이언트-서버 모델을 채택하고 있기 때문에 클라이언트와 서버가 통신할 표준 프로토콜을 결정해야 한다. 사용하는 프로토콜은 svn이다.

따라서 접속할 저장소의 URL은 ‘svn://서버명:[포트]/repos/저장소명’의 구조를 가진다. 설정에 따라 웹을 통한 접근을 허용한 경우 http로 시작하는 URL을 통해서도 내용을 볼 수 있으며, 중요한 데이터라면 SSH를 통해 보안성을 높일 수도 있다.

SVN의 저장소(Repository)는 버전 관리되는 대상들이 저장되는 곳이다. 저장소 안에는 어떤 파일이 어떤 이유에서 누가 언제 어떻게 변경했는지와 같은 메타정보도 함께 저장된다.

SVN은 내부적으로 Berkeley DB를 사용해서 파일을 관리한다. SVN의 저장소는 관례적으로 trunk, branches, tags라는 세 개의 디렉토리를 가지고 시작하는 것이 좋다. Trunk는 나무의 몸통을 뜻하는데 프로젝트의 원본이 관리되는 곳이다.

Branches는 몸통에서 뻗어 나온 나뭇가지를 뜻하는데, 개발을 하다 보면 고객시연용 개발 등과 같이 원본과는 다른 목적으로 프로젝트가 분기되는 경우가 있다. 이런 경우, 프로젝트의 원본을 분기시킨 버전을 Branches에 만들어 관리하게 된다. Tags는 꼬리표를 뜻하며, 정기적으로 1.0 버전, 2.0 버전과 같은 식으로 특정 시점의 릴리즈를 따로 관리하기 위한 곳이다.

SVN 관련 용어

● 체크아웃(CheckOut) : SVN에 의해 관리되는 프로젝트에 참여하기 위해 맨 처음 저장소에서 작업할 대상 파일을 받아오는 것을 뜻한다. 체크아웃을 하기 위해서는 익명 권한을 허용하도록 설정되어 있지 않은 이상 해당 시스템의 계정과 비밀번호를 필요로 한다. 성공적으로 체크아웃이 이뤄지면 SVN 저장소의 복사본이 로컬 PC에 생성되어 독자적으로 개발을 진행할 수 있다. ● 커밋(Commit) : 체크아웃한 로컬 PC에서 작업을 수행(파일 추가, 내용 수정, 파일 삭제, 이름 변경)하면 저장소에 있는 파일과 다른 형태가 된다. 커밋은 로컬 PC에 있는 복사본을 기준으로 저장소와 동기화하는 기능이며, 작업 내용이 서버의 저장소에 반영된다. ● 업데이트(Update) : 일정 시간이 지나면 다른 사람이 작업한 결과를 커밋하기 때문에 로컬 PC의 복사본이 최신의 것이 아닐 수 있다. 이럴 경우 업데이트를 수행해서 저장소를 기준으로 로컬 PC의 복사본을 동기화하는 것이 업데이트다. 체크아웃과 달리 업데이트는 프로젝트 진행기간 동안 빈번하게 발생하며, 적절한 주기로 자주 업데이트를 받는 것이 좋다. 특히 작업 내용을 커밋하기 전에 한번 업데이트를 진행해서 충돌 여부를 확인한 다음, 충돌을 해결하고 커밋 하는 것이 효과적이다. ● 리비전(Revision) : SVN에서는 커밋을 단위로 저장소에 있는 리비전 정보가 증가한다. 체크아웃을 받을 때 리비전 번호가 6500이라면, 팀 동료들에 의해 6,500회의 커밋이 이뤄진 프로젝트란 걸 알 수 있다. ● 임포트(Import) : 처음 저장소를 만든 시점에서 저장소에 맨 처음 파일을 넣는 작업을 뜻한다. ● 익스포트(Export) : 체크아웃과 같이 저장소에서 로컬 PC로 작업 결과물을 가져온다. 차이점은 버전 관리를 위한 메타 정보를 제외한 순수한 작업 결과물만을 가져온다는 점이다.

SVN을 설치 후에 해야 할 필수적인 일은 저장소를 만들고 그 저장소의 권한을 설정하고 사용자를 추가하는 일이다. 다음의 명령은 SVN 관리 툴인 svnadmin을 이용해서 sample이라는 이름의 저장소를 만드는 과정을 보여준다.

[root@devcais11 repos]# pwd
/home/svn/repos
[root@devcais11 repos]# svnadmin create --fs-type fsfs sample
[root@devcais11 repos]# ls -l
drwxrwxrwx 7 root root 4096 11월 17 14:23 sample
[root@devcais11 repos]# chmod 777 -R sample

이렇게 생성한 sample 저장소를 누구에게 어떤 권한으로 사용을 허락할 것인지를 지정해야 하는데, 이 정보는 svn-authz-file에 담겨있다. 해당 파일을 에디터로 열어서 저장소에 필요한 권한 설정을 추가한다. 다음 예제는 접근한 모든 사용자에게 읽기/쓰기 권한을 부여하도록 sample 저장소를 구성한 것이다.

[root@devcais11 etc]# vi svn-authz-file
[sample:/]
* = rw

이제 저장소를 이용한 사용자를 추가할 차례다. /etc에 svn-auth-file에는 사용자 정보가 담겨 있다(앞에서 본 파일명에 z가 빠져있음). 사용자는 htpasswd 명령으로 쉽게 추가할 수 있다. 사용자 추가 시 입력한 비밀번호는 해시 값으로 해당 파일에 덧붙여진다.

[root@devcais11 etc]# htpasswd –m svn-auth-file seal
[root@devcais11 etc]# cat svn-auth-file
seal:$apr1$AaEkN...$cL/nC1OGQ/k8L5WVWoL/a/

기타 자세한 설정은 참고 자료에 명시된 자료들을 참고하길 바란다.

SVN 클라이언트

팀에 소속된 개발자가 각자의 개발 환경에서 SVN을 사용하려면 별도의 클라이언트 프로그램이 필요하다. 자바 개발자의 경우를 예로 들면, 일반적으로 개발을 위해 이클립스와 같은 IDE를 사용하고 있을 것이다.

CVS는 버전관리 시스템의 대명사로 통하기 때문에 별도의 설치 없이 사용할 수 있지만, SVN을 사용하려면 추가적인 플러그인 형태로 클라이언트를 설치해야 한다.

이클립스 플러그인 Subversive
예전에는 SVN을 개발한 tigris에서 배포하는 Subclipse라는 플러그인을 주로 사용했지만, 지나치게 불안정해서 많은 자바개발자로 하여금 다시 CVS로 되돌아가게 만드는 원인이 되곤 했다.

최근에는 Subversive라는 플러그인이 그것을 대체하여 사랑받고 있다(Subclipse는 이클립스 프로젝트에 공식적으로 채택되어서 이클립스 3.2 버전부터는 Callisto내에 포함된다). Subversive의 장점은 trunk/branches/tags와 같은 관용적 표현을 툴 자체적으로 지원하며, 저장소를 보여주는 기능이 개선되었다는 것이다.

또, Subclipse와 같은 불안정한 오동작도 거의 없다. Subversive는 이클립스 [Help]-[Software Updates] 메뉴를 이용해서 http://www.polarion.org/projects/subversive/download/1.1/update-site/ URL을 입력하면 손쉽게 설치 가능하다.

설치한 후에는 우선 SVN Repository Perspective로 이동해서 저장소를 등록해야 한다. 저장소 등록이 이뤄지면, 서버에서 버전 관리를 하고자 하는 프로젝트를 선택하고 [team]-[share project] 기능을 통해 저장소에 해당 프로젝트를 등록한다.

<화면 1> 이클립스에서 Subversive 동작 샘플?Java 관점

그 저장소에 등록한 프로젝트에 속한 개발자는 같은 저장소를 등록하고, 등록된 내용과 똑같은 프로젝트를 갖기 위해 최초에 한번 체크아웃을 수행해야 한다. 체크아웃이 이뤄지고 나면 Subclipse의 다양한 기능을 통해 팀 차원의 버전 관리를 수행할 수 있다.

<화면 2> 이클립스에서 Subversive 동작 샘플 ? SVN 저장소 관점

Subversive에서 실행하는 기능들 중에서 몇 가지 추천할 만한 기능과 주의할 사항에 대해 간단히 알아보자. SVN 서버는 대소문자를 구별하는 유닉스 계열을 사용하고, 이클립스는 대소문자를 구별하지 않는 윈도우 환경을 사용한다면 파일의 대소문자 관리에 주의를 기울여야 한다.

윈도우에서는 AA.java와 Aa.java가 같은 이름이기 때문에 이름을 변경해도 상관이 없지만, 유닉스에서는 AA.java와 Aa.java를 다른 이름으로 받아들이기 때문에 커밋을 해버리면 AA.java는 그대로 있고 Aa.java가 추가된 형태로 저장소는 인식한다. 이때 누군가 업데이트를 요청하면 AA.java가 있는 상태에서 새로운 Aa.java를 업데이트 받는데 이미 파일이 존재하기 때문에 기대했던 업데이트는 이뤄지지 않는다.

Subversive에서 작업 결과를 커밋 할 때는 귀찮더라도 Comment에 의도가 드러나도록 작업에 대한 요약을 적어주는 것이 좋다. 이런 히스토리는 SVN Resource History 탭에서 확인할 수 있는데, 특정 버전으로 돌아가기 위해 변경 시점을 찾을 때 도움이 된다.

특히 시스템이 오동작 할 때 그런 일이 일어나지 않도록 정한 약속을 어긴 범인을 찾을 때에도 History 정보는 도움이 된다.

또 한 가지의 유용한 기능은 Revert이다. Revert는 가장 최근에 저장소에서 업데이트 받은 상태로 돌려준다. 업데이트를 받고 나서 1시간 정도 작업을 했는데, 뭔가 꼬인 것 같아 작업하기 이전 상태로 되돌아가고 싶을 때 Revert를 실행하면 고민이 해결된다.

마지막으로 소개할 팁은 Synchronized 기능이다. 복잡한 변경을 수행하고 나서 변경 결과를 커밋 하는데 한참을 진행하다가 그제서 충돌을 발견하고 전체 결과가 롤백 되어 버리면 굉장히 허탈할 것이다.

그래서 커밋하기 전에 먼저 Synchronized 기능으로 서버와 동기화 시켜 추가된 부분이 있다면 업데이트를 받고 충돌이 있다면 diff 기능으로 충돌을 해결하고, 그런 다음에 커밋을 수행하는 것이 좋다.

충돌이 발생했을 때 양쪽을 비교해보면서 서버 쪽 작업이 옳아서 내 작업을 취소해야 한다면 ‘Override and Update’ 기능을 실행하고, 충돌을 해결한 자신의 코드를 서버에 등록하고 싶다면 ‘Override and Commint’ 기능을 실행한다.

<화면 3> Subversive의 Synchronized View 기능

익스플로러에 녹아드는 TortoieSVN
Subversive외에 추천하고 싶은 SVN 클라이언트는 일명 거북이라고 불리는 TortoiseSVN이다. GPL 라이선스이기 때문에 누구나 설치해서 사용할 수 있다. TortoiseSVN은 IDE와 연동되는 형태가 아닌 다른 형태의 산출물을 버전관리 하는 목적으로 사용될 때 아주 탁월한 SVN 클라이언트이다.

예를 들어 공동으로 특정 기술을 연구하는 과정에서 나오는 각종 오피스 문서들을 버전관리 한다거나, 웹 에이전시에서 나오는 홈페이지 제작에 필요한 산출물을 버전관리 할 때 유용하다.

<화면 4> 윈도우 탐색기에서 TortoiseSVN 동작 샘플

TortoiseSVN은 플러그인 될 별도의 IDE가 없기 때문에 윈도우 탐색기와 결합된 형태로 동작한다. 특정 폴더에서 마우스 오른쪽 버튼을 누르면 나타나는 메뉴에 SVN의 클라이언트 기능이 추가되는 식이다. TortoiseSVN을 설치하면 버전 관리되는 파일은 특수한 형태의 아이콘으로 변경되어 버전관리 대상임이 표시된다.

한 가지 특이한 점은 TortoiseSVN은 ‘Create Repository hear’ 메뉴를 통해 서버 없이 그 자체만으로도 저장소를 만들 수 있다는 것이다. 이 경우 로컬에서 저장소를 운영하기 때문에 svn 프로토콜이 아닌 file 프로토콜을 이용해서 ‘file:///C:\repos\maso’와 같은 식으로 저장소 URL이 결정된다.

필자의 경우는 이 기능을 통해 TortoiseSVN을 개인 문서 작업용 버전관리 도구로 사용하고 있다.

지금까지 버전관리의 필요성을 언급하고, 버전관리 시스템의 유형과 대표적인 버전관리 시스템인 SVN에 대해 살펴보았다. 상세한 설명은 참고자료에 소개된 웹페이지나 책을 통해 얻을 수 있다. 버전관리 시스템을 이해하는 것은 협업을 기본으로 하는 개발자에게 있어서 기본적인 예의이다.

현재까지도 버전관리 시스템에 익숙하지 않은 개발자가 있다면, 이번 기회에 도전해 보길 바란다.


참고자료
(1) 버전관리시스템의 종류
- http://en.wikipedia.org/wiki/List_of_revision_control_software
(2) CVS - http://www.nongnu.org/cvs/
(3) Subversion HOW-TO(한글) - www.pyrasis.com/main/Subversion-HOWTO
(4) Subclipse - http://subclipse.tigris.org/
(5) TortoiseSVN - http://tortoisesvn.tigris.org/
(6) Subversive
- http://www.polarion.org/index.php?page=overview&project=subversive
(7) 서브버전을 이용한 실용적인 버전관리, Mike Mason, 정보문화사
(8) 서브버전 : 실무자가 꼭 알아두어야 할 차세대 버전관리 시스템, 에이콘


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.