Life Algorithm

제목을 잘 하지도 못하는 영어로 써서 죄송합니다 -_-

SCM은... 쉽게 말하면 버전 관리라고들 하죠. Source Configuration Management의 약자입니다.
CVS, Subversion같은 거요. 아니면 비주얼 소스 세이프라든가... 돈 많은 회사면 Clear Case 쓸 수도 있고...
이런 거 안 쓰세요? 쓰자고 건의하세요, 힘들어 죽어버릴 거 같다고...ㅡㅡ; 못 쓰겠대요? 옮기세요... 그 회사엔 붙어 있어도 좋은 꼴 못 봅니다 -_-;

CVS든 SVN이든 여기저기 많이 쓰긴 하지만, 기본적인 SCM의 기능들이랄까 그 개념은 잘 모르고 쓰는 경우가 많은 것 같습니다.
프로그래밍 언어, 자료구조, 알고리즘 등은 학교에서 가르치지만 막상 이런 실용적인 것들은 가르치지 않지요. GDB나 CVS 처음 써보고 무척 감탄했던 기억이 나는군요. '세상에 이런 것도 있었구나'하는 느낌...? -_-

SCM 툴도 기본적인 원리나 개념들은 관련 S/W들이 오랜동안 개발되고 숙성되어 오면서 충분히 정립된 상태라고 볼 수 있을 것 같습니다. 그런 것들에 대해 쓰는 글입니다.


관리 방식

SCM은 '협업'을 위한 툴이므로 소스 파일을 어떻게 관리하는 지가 중요하죠.
일단 간단한 방식은 파일에 lock을 거는 것입니다. 비주얼 소스 세이프나 소스 오프사이트가 이런 방식입니다.
한 사람이 파일 고치고 있으면 아무도 못 건드립니다. 제가 lock 걸어놓고 깜박 잊고 퇴근했다가 두바이에서 걸려온 전화를 받은 적이 있습니다(실화입니다). -_-;;;
구현은 간단하지만 협업에 불편한 점이 많죠 아무래도...

실제 많이 쓰는 방식은 Version Merge입니다. CVS부터 해서 많은 툴들이 이 방식을 씁니다.
이 방식은 여러 개발자가 동시에 같은 파일을 수정할 수 있다는 장점이 있습니다. 수정이 끝나고 저장소에 체크인할 때, 앞번 개발자가 체크인한 코드와 merge를 해야 되는 거죠. 물론 이 merge 과정은 기본적으로 툴이 제공해주어야 하는 기능입니다만, 같은 부분을 수정했을 경우 conflict가 날 수 있습니다. 이 때는 개발자가 직접 manual merge를 해야겠죠. 그래도 이 방식이 훨씬 편합니다 -_- 하지만 auto merge에 대한 알고리즘 구현이 중요하겠죠.


구 조

대개는 클라이언트-서버 방식으로 구현되었습니다만 최근엔 분산 관리방식의 툴들도 많습니다. 서버가 필요없이 개개인의 작업 디렉토리가 저장소가 되는, P2P에 가까운 방식이라고 할 수 있겠군요.
좀 유명한 것들은 대개 CS 방식이고, 분산 관리도구는 리눅스 커널의 버전 관리 툴은 GIT와 요즘 뜨고 있는 Mercurial, Darcs 등이 있습니다.

CS방식은 굳이 설명할 필요가 없을 것 같고... 분산 관리방식은 서로 변경 내용을 보내주거나 받는 방식으로(보통 pull, push라고 칭하더군요) 공유가 되는데, 직접 개발에 적용해 본 적이 없어서 무어라 평가하긴 힘들지만 쉽지는 않을 것 같은 생각이 듭니다.
즉, 기준이 되는 저장소가 없을 경우 커뮤니케이션 관리가 제대로 되지 않는다면 같은 버그가 여러 번 수정되는 경우가 생길 수도 있을 것 같기도 하군요. 하긴 회사든 오픈 소스든 개발하는 사람들끼리 그 정도도 커뮤니케이션이 안되면 문제가 있는 거겠죠 -_-
공유하는 방식은 http 프로토콜을 쓰기도 하고 email로 패치를 보내주는 방식도 쓰고 다양합니다. 자체 서버를 마련할 수 없는 경우라든가 또 서버가 자주 먹통이 되는 경우 -_- 도움이 많이 되겠지요.


Branch

개발하다 보면 기능 추가를 하거나 등등 '기존 소스 트리를 유지하면서 개발'할 필요가 꼭 생깁니다. 이럴 때에 브랜칭을 하게 되지요. 현재의 소스 트리가 복제된다고 보시면 됩니다. 소스 트리에 '가지'가 하나 더 생기는 것입니다.
물론 유지한다고 해도 기존 트리를 전혀 수정하지 않는단 얘기는 아니지요. 안정성에 문제가 없는 한에서는 기존 소스 트리도 수정은 계속 이루어지고 브랜치는 기능 개발을 계속 하게 됩니다. 그리고 어느 시점이 되면 다시 메인 트리에 브랜치를 머지합니다.
브랜치 기능은 SCM 툴에 반드시 필요한 기능 중에 하나라고 할 수 있습니다.


Tag

소스 스냅샷에 꼬리표(tag)를 다는 기능입니다. 보통은 버전에 따라 달게 되겠지요.
물리적인 특정 시점의(예를 들면 몇월 몇일 당시의 소스) 소스 스냅샷을 얻는 것은 툴에서 제공하므로 대개 어렵지 않지만 논리적인 시점이라면 툴이 판단할 수 없는 문제지요. 1.0-beta를 릴리즈한 시점의 소스라든가 하는 경우는 체크해 놓지 않으면 소스 스냅샷을 찾아 보기는 힘들겠죠.
태그를 설정해 놓으면 태그 이름만 입력하는 것으로 해당 태그 시점의 스냅샷을 얻을 수 있습니다.

이것도 매우 기본적인 기능의 하나입니다만, 가장 유명한 SCM 툴의 하나인 Subversion의 경우는 브랜치나 태그를 모두 지원하지 않습니다. 저장소 내의 소스 디렉토리 카피를 통해서 브랜칭이나 태깅을 할 수 있도록 지원하는데 내부 구조는 모르지만 디렉토리 카피가 저장소 용량을 늘리는 거 같지는 않더군요.


Merge

Locking 방식 툴에서는 필요없는 부분이지만 Version Merge 방식의 툴에서는 반드시 필요한 기능입니다.
하지만 이 기능은 내부적으로 수행되며 Merge 알고리즘도 여러가지가 있다고 하는데 잘 모르겠네요 ^^;


Blame

annoatate라고 부르는게 일반적인지도 모르겠습니다만... 개인적으로는 이 기능을 중요시 여깁니다. 문제 생겼을 때에 범인 추적하기에 좋거든요 -_-;
소스 라인별로 최종 수정된 리비전과 수정자의 id를 표시해주는 기능입니다.


Hook

커밋 전이나 커밋 후에 자동적으로 스크립트를 실행하게 해 줍니다.
커밋 될 때마다 코딩 스타일 툴을 실행해서 코딩 스타일을 맞춘다거나 커밋 전에 유닛 테스팅을 실행한다거나 하면 아주 도움이 되겠죠.


대략 이 정도면 기본적인 기능들인 거 같군요.
제가 써 본 건 사실, CVS, Subversion, 소스 오프사이트(비주얼 소스세이프) 정도 뿐입니다만 요즘은 분산 관리툴이 많이 유명한 거 같아 다음에는 그것들에 관해 정리해 볼까 합니다.

SCM 툴을 쓰더라도 태그나 브랜치 등등을 활용하지 않는다면 기능을 절반도 사용하지 못하는 것이나 마찬가지입니다. 안 쓰신다면 꼭 도입하고, 쓰신다면 기능을 더욱 활용해 보시기 바랍니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)