[독서광] Mercurial: The Definitive Guide

소시적에 RCS(Revision Control System)부터 시작해 CVS를 찍고 SVN(Subversion)을 거쳐 요즘에는 분산 버전 관리 시스템인 Hg(라고 쓰고 mercurial이라 읽는다)를 사용하고 있다. 전사(응?)적으로 사용하기 시작한지 6개월이 넘었기에 회사 내부에서는 어느 정도 사용이 정착되었다고 보지만 단순한 중앙집중식 버전 관리 시스템에 비해 여전히 배우고 익혀야할 내용이 많다는 생각이다. 오늘은 오라일리에서 나온 Mercurial 서적인 'Mercurial: The Definitive Guide'를 읽고 느낀 점을 정리해보겠다.

요즘 들어 아주 좋은 컴퓨터 관련 도구와 기술이 적극적으로 공개되고 있는데, 그 만큼 보고 듣고 읽고 익혀야할 내용도 많아져서 인지적인 과부하가 걸리는 상황이다. 개발자에게 있어 가장 중요한 무기인 코드 관리 시스템 역시 발전에 발전을 거듭해 요즘에는 git가 견고한 SVN의 벽을 허물고 주류로 등장하는 상황이다. 특히 소셜 코딩을 기치로 내걸고 등장한 긱스런 회사인 github가 뜨면서 git에 대한 관심이 무척 높아지고 있다. 하지만 git 사용법은 절대로 쉽지 않다. 원래 리눅스 커널 관리를 위해 만든 시스템이다보니 메인테이너의 편의성을 극대화한 측면이 많기 때문이다. 복잡한 명령 구조와 시나리오에 따른 활용법을 익히지 않고서는 git도 또 하나의 백업 시스템으로 전락할 가능성이 높아보인다. 그렇다면 RCS와 git라는 양 스펙트럼 사이에 적절한 타협점은 없을까? B급 프로그래머 생각으로는 hg가 어느 정도 해법을 제시한다고 본다. git보다 자유도와 기능이 떨어지지만 꼭 필요한 기능은 빠짐없이 제공하며, svn보다 배우기는 어렵지만 유연성이 아주 높고 다양한 버전과 브랜치를 손쉽게 관리할 수 있다는 특징으로 인해 일단 DVCS를 적용하려는 조직에 적용하기 좋다는 장점이 있다. 게다가 git와는 달리 Hg는 유닉스/맥은 물론이고 윈도우와도 아주 친하다(이게 무슨 소리인지는 git를 윈도우에서 직접 사용해보면 바로 알게 된다. ㅋㅋ)

기존 SVN 사용자를 위해 Hg의 특징을 간략하게 정리해보자면, 가장 큰 차이점은 모든 개발자 PC(클라이언트)가 서버가 될 수 있다는 점이다. 중앙 집중식 아키텍처로 설계된 SVN과는 달리 Hg는 모든 이력을 클라이언트마다 다 들고 있고, 필요에 따라 밀고(push), 당기는(pull) 방법으로 중앙 저장소로 지정한(OnDemand로 bitbucket.org와 같은 온라인 서비스에 호스팅을 해도 되고, 내부에 직접 서버를 꾸려도 무방하다) 서버에(서) 변경된 이력을 가져오고/내보낸다. 이렇다보니 SVN과는 달리 커밋을 하더라도 중앙 서버에 반영되는 대신 지역 클라이언트 쪽에만 반영되기 때문에 개발자가 소스 코드를 지역적으로 관리하는 책임과 의무가 커진다. 물론 책임과 의무가 있는 대신 자유도가 높아지므로, 개발자는 자기 페이스에 맞춰 여러 커밋을 한 단위로 묶어 중앙 서버에 반영시킬 수 있으므로 여러 명이 동시에 작업하는 과정에서 빌드를 깨먹거나 버전이 이리저리 뒤엉켜 관리하느라 난리가 날 확률이 줄어든다. 개발자가 1~2명이라면 SVN으로 충분하지면 3~4명만 되더라도 Hg와 같은 DVCS를 사용하는 편이 생산성을 급격하게 높일 수 있으므로, 어느 정도 규모가 되는 프로젝트를 진행하기 앞서 버전 관리 시스템을 선택할 때 반드시 git나 hg도 고려 대상에 넣으면 좋겠다.

서론이 너무 길었다. 상용 Hg 서버인 Kiln을 만든 조엘 스폴스키가 작성한 튜토리얼인 Hg Init: a Mercurial tutorial를 읽었다면 그 다음 차례가 바로 Mercurial: The Definitive Guide가 아닌가 싶다. 오라일리에서 책을 구입할 수도 있고 앞서 소개한 홈페이지에서 전자책 형태로도 읽을 수 있으므로, 아이패드나 킨들이 있는 분들에게는 멋진 선물이 될 것 같다. 이 책은 Hg에서 가장 중요한 기능을 중심으로 실제 예를 들면서 설명을 전개해 나가므로 바로 적용할 수 있다는 장점이 있다. 물론 기존 CVS나 SVN을 제대로 활용하고 있던 사용자일지라도 새로운 설계 사상과 개념으로 인해 직접 해보지 않고서는 도저히 감을 잡기 어려운 난관이 있으므로 책과 실습을 병행하는 방식을 강력하게 추천한다. 목차를 보면 알겠지만, Hg의 튜토리얼은 2장과 3장에서 끝나고 4장부터는 본격적인 설명으로 들어가기에 DVCS 개념이 안 잡힌 독자라면 조엘이 작성한 튜토리얼을 먼저 읽는 편이 정신 건강에 이롭다는 생각이다.

B급 프로그래머 생각에 이 책에서 가장 중요한 부분은 4장이다. Hg를 사용하다보면 (심지어 복잡하게 브랜치나 릴리스 관리를 하지 않더라도) 내부 동작 방식을 반드시 알아야 하는 사태가 발생하기 마련이다. 예를 들어, 열심히 코드를 고친 다음 커밋을 하고 중앙 서버에 push를 하려 했는데, 갑자기 중앙 서버가 거부를 하는 상황에서 pull을 해서 다른 사람이 변경한 내용을 가져온 다음 이를 하나로 합쳐야 하는데, 완전히 orthogonal한 작업(예: A는 a.c를 고쳤고 B는 b.c만 고친 경우)에도 merge를 해야 한다는 사실이 처음에는 도저히 이해가 가지 않을지도 모른다(물론 rebase라는 확장(이라고 쓰고 야매라고 읽어야지)을 사용하면 지역 클라이언트에서 일어난 변경 내용을 잠시 분리해 중앙 서버의 내용을 선 반영한 다음에 그 위에 변경 내용을 반영하므로 merge를 회피할 수 있다). 게다가 update 명령이 클라이언트 코드 저장소와 현재 작업 디렉터리를 동기화한다는 사실을 모르고 pull만 해놓은 다음에 tip이 과거 parent를 가리킨다는 사실을 인지하지 못한 상태로 실컷 코드를 고친 다음 commit할 때 발생하는 거부 상황(해법은? update하고 나서 펑펑 터져 나오는 충돌 상황을 적절히 풀면 된다.), -F 옵션을 사용해 강제로 push해 새로운 head를 만들고 나서 동료들이 어떤 head가 작업 대상인지 몰라 우왕좌왕하는 모습(해법은? head 둘을 merge하면 된다. 참 쉽죠?) ... SVN 세계에서는 찾아보기 어려운 멘탈 붕괴 상태에서 잘 빠져나오려면 4장에 나오는 그림과 시나리오를 여러 번 읽어 충분히 숙지한 다음에 실전으로 뛰어드는 편이 좋겠다. 그리고 처음 Hg를 접하는 분들께는 9장도 많은 도움이 될 것 같다. 사용하다보면 분명히 문제는 생기기 마련인데, 9장은 자주 일어나는 현상(이라고 쓰고 문제점이라고 읽어야지...)과 해법을 제시하고 있으므로 평상시에 잘 숙지해두면 나중에 실수를 적게하고 설령 실수를 하더라도 정석대로 빠져나올 수 있게 된다.

책을 한 번 읽고서는 감이 _전혀_ 오지 않을 수도 있으므로, 일단 실제 작은 프로젝트(테스트용)에 적용한 다음에 다시 한번 책을 읽어보면 그 때 아하!하고 깨닫는 바가 클 것이다. 이렇게 말하는 B급 프로그래머도 다시 한번 천천히 본문을 정독해봐야겠다. 낄낄...

EOB