지극히 편파적인 버전 관리 시스템에 대한 기억

버전 관리가 대체 뭔가요, 먹는 건가요?

처음 버전 관리란 걸 시작할 당시에는 툴에 대해서는 전혀 모르던 때였습니다. 필요에 의해 버전 관리를 해야 한다는 건 느끼고 있었지만 어떻게 해야 하는지 알려 주는 사람은 없었죠. 주변에서 가장 많이 쓰는 방법은 소스 코드를 모두 압축해서 보관하는 방법이었습니다. 새 기능을 추가하기 전에 소스 코드를 모두 압축하고 파일 이름에 날짜와 간단한 설명을 추가한 후 보관합니다. 정말 간단해 보이지만 문제도 많은 방법입니다.

  • 종종 코드 보관하는 걸 잊고 이미 수정을 하고 있다.
  • 많은 압축 파일 중 변경 내용이 어디에 있는지 찾기 어렵다.
  • 여러 압축 파일 내용 사이에 어떤 차이가 있는지 비교하기 어렵다.
  • 이미 만든 기능을 다른 쪽에 추가하려면 눈이 빠진다.

더불어 언제 누가 수정했는지 표시한 주석도 항상 빠지지 않습니다. 사실 이러한 문제가 바로 버전 관리 시스템을 사용해야 하는 이유이기도 합니다.

소스 세이프(Microsoft Visual Source Safe, VSS)

Visual Source Safe 6.0

압축 프로그램을 사용해 버전 관리(?)를 하는 방식에는 한계가 명확합니다. 사실 버전 관리라기보다 제대로 활용하기도 어려운 자료를 그저 불안감에 모으는 것에 불과하죠. 그래서 해결할 좋은 방법이 없을지 찾던 중 알게 된 게 소스 세이프입니다. 이 제품은 Visual Studio에 포함되어 있어 쉽게 접할 수 있습니다. 너무도 오래되어 이젠 흐릿하지만 개인적으로도 그리 나쁜 기억은 없습니다. 다만 몇 가지 단점이 있습니다.

  • Lock – Modify – Unlock 방식이므로 같은 파일을 여럿이 함께 수정하지 못한다.
  • 파일 단위로 이력(history)을 관리한다.
  • 항상 수정 전 해당 파일을 체크 아웃(check out)해 줘야 한다.

Lock - Modify - Unlock 모델

세 번째는 단점이라고 하긴 그렇지만 불편한 건 사실입니다. 항상 체크 아웃을 명시적으로 해야 수정할 수 있으니까요. 무엇보다 가장 큰 단점은 두 번째라고 할 수 있습니다. 변경은 특정 파일 하나에서만 생길 수도 있지만 여러 파일을 함께 변경하는 일도 많습니다. 그런데 이를 하나로 묶어 관리하지는 않으므로 체크 인(check in)할 때 적은 로그로 확인할 수 밖에 없습니다. 파일이 많으면 그 많은 파일을 일일이 찾아 가며 보긴 좀 힘들죠. 이런 시스템 특성 때문에 레이블 붙이는 시점을 놓치면 상당히 곤란해 집니다.

사실 VSS는 클라이언트/서버 형태가 아니라 로컬에 저장소를 만들어 쓰는 방식입니다. 즉 계정을 여럿 만들어 다른 PC에서도 접속할 수 있긴 하지만 저장소가 있는 디렉터리를 파일 공유해야 합니다. 하지만 무엇보다 소스 세이프를 미련 없이 버린 가장 큰 이유는 저장소가 잘 망가진다는 점입니다. 당시엔 혼자만 쓰고 있었기에 개인적으로 망가지는 일을 겪진 않았으나, 공동으로 작업할 때는 저장소 망가지는 문제로 말이 정말 많았습니다.

CVS(Concurrent Version System, CVS)

WinCvs

소스 세이프 다음으로 사용한 게 CVS입니다. 당시 CVS는 오픈 소스 개발에서 매우 큰 비중을 차지하고 있던 버전 관리 시스템입니다. 소스 세이프처럼 저장소가 망가질 일도 없었습니다. 이 때는 혼자 쓰면서 좀 익숙해진 후 팀에 버전 관리를 소개하며 도입을 시도했던 때이기도 합니다. Copy – Modify – Merge 방식이므로 같은 파일을 여럿이 수정할 수도 있습니다. 사용했던 서버는 CVSNT, 클라이언트는 WinCvs였습니다.

  • Copy – Modify – Merge 방식이므로 같은 파일을 여럿이 수정할 수 있다.
  • 파일 단위로 이력을 관리한다.
  • 원자적 커밋을 지원하지 않으므로 커밋 중 네트워크가 끊어지는 등 문제가 생기면 해결하기가 꽤나 귀찮다.
  • 디렉터리와 파일 이름 변경을 지원하지 않는다.

Copy - Modify - Merge 모델 Step 1

Copy - Modify - Merge 모델 Step 2

이러한 단점 중에서도 가장 큰 것은 이력을 파일 단위로 관리하는 점입니다. 소스 세이프와 마찬가지로 변경 내용을 파일 단위로 관리하므로 태그를 적절한 시점에 만들지 못하면 특정 시점 소스를 얻기가 상당히 곤란합니다. 또한 특정 기능이 여러 파일에 흩어져 있으면 일일이 찾는 게 좀 불편합니다. 즉 소스 세이프보다는 낫지만 이력 관리에는 여전히 신경을 써야 합니다.

간혹 커밋 중 네트워크 문제 등으로 연결이 끊어지거나 실수로 커밋을 완료하지 못하면, 이력 관리를 파일 단위로 하므로 커밋 완료한 것은 저장소에 추가되고 실패한 것만 빠집니다. 이 때문에 불완전한 커밋이 되는데 이를 처리하는 게 꽤나 귀찮습니다. CVS 안내서에는 이런 경우 처리하는 방법을 상세히 설명할 정도니까요.

서브버전(Subversion, SVN)

TortoiseSVN Repository Browser

서브버전은 현재 오픈 소스 버전 관리 시스템의 대표 주자라고 할 수 있습니다. CVS의 단점을 극복하기 위해 CVS 핵심 개발자들이 참여해 만든 시스템입니다. 목적부터 명확하지 않나요? 이런 이유로 간편하면서도 CVS에 비해 더욱 편리한 시스템이 됐습니다. 처음 접하더라도 그다지 어렵지 않게 사용할 수 있습니다. 윈도 환경에서는 간편하게 설치할 수 있는 여러 패키지가 있지만 서버는 아파치 웹 서버에 직접 설치하는 방법을 썼고 클라이언트는 TortoiseSVN을 사용했습니다. TortoiseSVN은 무료이면서도 윈도 환경 클라이언트 중 최고라고 할 수 있습니다.

  • Copy – Modify – Merge 방식이므로 같은 파일을 여럿이 수정할 수 있다.
  • 변경 내용을 리비전 단위로 관리하므로 이력 추적이 매우 쉽다.
  • 원자적 커밋을 지원해 불완전한 커밋이 생기지 않는다.
  • 파일, 디렉터리 이름 변경을 지원한다.
  • 저장소가 망가지는 경우가 간혹 있었다.
  • 저장소 내 일부 디텍터리 경로만 체크 아웃할 수 있다.

서브버전은 이전에 비해 매우 발전한 모습입니다. CVS에서 SVN으로 옮긴 이후 가장 오랫동안 쓴 시스템이기도 합니다. 특히 저장소 전체를 받지 않고, 특정 디렉터리 경로만 체크 아웃할 수 있는 기능은 프로젝트가 크거나 필요한 부분만 가져 와 작업할 때 매우 편리합니다. 클라이언트/서버 형식이면서도 가장 마지막으로 업데이트한 정보를 로컬 PC에 저장하므로 오프라인일 때도 무엇이 바뀌었는지 쉽게 알 수 있고 되돌릴 수도 있습니다.

이런 편리한 시스템에도 물론 단점은 있습니다. 중앙 집중형 모델, 즉 클라이언트/서버 형식이라는 게 가장 큰 단점입니다. 오프라인 상태에서는 할 수 있는 게 거의 없습니다. 심지어 이력도 볼 수 없습니다. 물론 항상 온라인 상태로 작업하는 환경이라면 전혀 문제될 것이 없겠지만요.

머큐리얼(Mercurial, Hg)

TortoiseHg Workbench

머큐리얼은 최근 각광을 받고 있는 분산형 버전 관리 시스템(Distributed Version Control System) 중 하나입니다. 사실 DVCS에는 여럿이 있지만 그 중 가장 많이 알려진 것은 Git입니다. 리눅스 커널 개발에 사용하려고 리누스 투르발스(Linus Benedict Torvalds)가 만든 버전 관리 시스템이지만 그보다는 오히려 GitHub로 인해 더욱 널리 알려졌습니다.

중앙 집중형 시스템인 SVN에서 DVCS로 이전한 이유는 말 그대로 분산 환경이라는 점 때문이었습니다. 분산형 시스템에서는 오프라인이라는 의미가 없습니다. 사실 중앙 저장소가 없으므로 개발자의 로컬 PC에 저장소가 있고 필요하면 그 저장소를 복제해 다른 저장소를 또 만들 수 있습니다. 즉 필요에 따라 저장소를 나눠 개발과 시험을 할 수 있고 필요 없으면 그냥 지우면 됩니다. 또한 이력을 저장소마다 따로 관리할 수 있습니다.

Git과 Hg 중 무엇을 선택할 것이냐는 어찌보면 지극히 주관적일 수 밖에 없습니다. 기본적으로 제공하는 기능에서 큰 차이가 있다고 생각하지는 않습니다. 개인적으로 Git에 대한 첫 느낌은 꽤 복잡하다는 겁니다. 알고 나면 그리 어려운 일은 아니겠지만 알기까지 혼란이 문제입니다. 특히 개인적으로 쓸 게 아니라 팀에 도입할 것이기 때문에 더욱 그렇습니다. 개발자 대부분은 버전 관리 시스템에 대해 그리 깊게 알고 싶어하지 않으며 GitHub 이런 건 관심조차 없습니다. 버전 관리를 불편하게 느끼는 사람도 많습니다. 사실 그렇게 쉽다는 SVN조차 잘 못 쓰는 개발자도 많습니다. 즉 관심의 차이입니다. 그러므로 DVCS의 장점은 얻으면서 SVN만큼 쉽고 간편한 시스템이 필요했고 무엇보다 쓰기 편한 GUI 환경이 있어야 했습니다. 그래서 선택한 게 바로 머큐리얼입니다. 머큐리얼 클라이언트 역시 여러가지가 있지만 윈도 환경에서는 TortoiseHg만큼 편한 게 없습니다.

  • 병렬 개발 방식이므로 처음 접하면 혼란스러울 수 있다.
  • 3-way 병합을 지원해 SVN보다 더욱 쉽게 병합 처리를 할 수 있다.
  • 중앙 서버 없이 각자 개발하고 변경 내용을 서로 교환할 수 있다.
  • 로컬 PC에서 이력을 모두 관리할 수 있다.
  • 특정 디렉터리 경로만 복제할 수 없고 항상 저장소 전체를 가져 와야 한다.
  • 다른 저장소와 동기화하려면 PUSH, PULL 단계를 추가로 거쳐야 하는 걸 곧잘 잊는다.

분산형 시스템은 중앙 집중형 시스템에 비해 다소 혼란스럽게 느껴질 수도 있습니다. 하지만 그 과정만 살짝 넘어가면 훨씬 편리한 세상을 만날 수 있습니다. 기본적으로 분산형은 서버가 없기 때문에 변경이 매우 자유롭습니다. 저장소를 따로 복제해 이리저리 코드를 고치며 시험해 보다 필요 없으면 버리면 됩니다. 중앙 집중형 시스템에서는 서버에 브랜치를 따로 만들지 않으면 이렇게 하기가 쉽지 않습니다.

SVN과 달리 저장소를 모두 복제해야 하므로 큰 프로젝트를 처음 가져 올 때는 시간이 많이 걸립니다. 또한 복제할 때마다 저장소 크기만큼 늘어나므로 상황에 따라서는 용량도 문제가 될 수 있습니다. 이 때문에 덩치 큰 프로젝트를 작게 나눠야 할 수도 있습니다.

그 외…

한 때 버전 관리 시스템을 도입하려고 국내 여러 곳을 다녀 보기도 하고 교육이나 제품 소개를 받아 본 적도 있어 아주 간략히 적어 봅니다.

클리어케이스(ClearCase)

일단 비쌉니다. CVS와 마찬가지로 파일 단위로 이력을 관리하는데 솔직히 관리 방법이 매우 복잡합니다.

시너지(Synergy)

원래 Telelogic 제품이었는데 IBM에서 합병했습니다. 당연히 상용이고 비쌉니다. 아무튼 이 제품도 관리 방법이 복잡하고 심하게 맘에 안 듭니다. 기본적으로 파일 단위로 이력을 관리하는데 문제는 이력 추적이 심하게 어렵습니다. 더구나 브랜치 분리해 개발하다 이전 내용으로 되돌리거나 병합 등을 해야 할 때가 종종 있는데 이 게 잘 안 됩니다. 심지어 저장소 구조 바꾸는 건 아예 생각도 하지 말아야 합니다. 딱 정해진 순서대로 하지 않으면 저장소가 홀라당 망가지는데 국내 서비스하는 개발자들도 이런 내용을 잘 모릅니다. 그 순서 역시 경험적으로 알아 낸 건데 지금은 기억도 안 나네요. 결론은 SVN보다도 못 하다는 생각 밖에 안 듭니다.

PVCS

CVS랑 별 차이 없는데 돈 주고 사야 합니다.

국내 제품들

이름은 기억이 안 나는데 국내에서도 버전 관리 시스템이라며 만드는 곳이 몇 군데 있었습니다. 그 중에는 금융권에 많이 들어간 제품도 있었습니다. 아무튼 중요한 건 돈 주고 사야 할 만큼 좋아 보이지는 않았습니다. 특히 금융권에서 많이 쓴다는 제품은 아무래도 그 쪽에 특화되어 있던 탓인지 결재 과정이 엄청 많이 들어 갑니다. 금융권 같이 중요한 곳에서 함부로 코드를 변경하게 둬서는 안 될 테니까요. 아무튼 우리와는 맞지 않았습니다.

마치며…

그동안 전통적으로 많은 곳에서 쓰고 있다는 상용 시스템과 오픈 소스 시스템을 비교해 보면 솔직히 그 비용을 들여 상용 시스템을 사야할 필요가 있을지 회의적입니다. 물론 시스템을 관리하는 문제 등과 얽히면 실용적보다는 정치적으로 바뀌는 경우도 있습니다. 요즘은 오픈 소스 시스템으로 서비스를 제공하는 곳도 많으므로 예전과는 달리 선택의 폭도 더 넓긴 하겠죠. 아무튼 제 기억에 버전 관리 시스템만큼은 맘에 드는 상용 시스템이 없었습니다.

개인적으로는 버전 관리 시스템을 처음 시작한다면 DVCS, 그 중에서도 머큐리얼을 권하고 싶습니다. 일단 배우는 게 쉽고 그다지 복잡한 개념이 없습니다. 그러면서 DVCS 장점을 모두 누릴 수 있습니다.

Notes:
1. 모니터를 뚫어져라 노려 봐야 하니까.
2. 이는 Lock – Modify – Unlock 방식이니까 어쩔 수 없다.
3. 저장소 형식을 버클리 DB로 쓸 때 저장소가 깨지는 문제가 있었지만 현재는 FSFS가 기본이며 이런 문제는 더 이상 없습니다.
4. 이슈 추적 시스템과 연동을 생각한다면 이 점은 제약이 좀 있습니다. 커밋 로그에 이슈 번호를 적어야 한다면 로컬에서 임의로 커밋을 하는 건 피할 수 밖에 없죠.
5. 인터넷에는 서로의  장단점에 대한 많은 글이 있습니다.
모니터를 뚫어져라 노려 봐야 하니까.
이는 Lock – Modify – Unlock 방식이니까 어쩔 수 없다.
저장소 형식을 버클리 DB로 쓸 때 저장소가 깨지는 문제가 있었지만 현재는 FSFS가 기본이며 이런 문제는 더 이상 없습니다.
이슈 추적 시스템과 연동을 생각한다면 이 점은 제약이 좀 있습니다. 커밋 로그에 이슈 번호를 적어야 한다면 로컬에서 임의로 커밋을 하는 건 피할 수 밖에 없죠.
인터넷에는 서로의  장단점에 대한 많은 글이 있습니다.

You may also like...

One Pingback/Trackback