상용 툴 이야기 - 버전/이슈관리 툴

|

요즘은 IDE들이 잘 나오면서 의미가 약간 퇴색되긴 했지만 기본적으로 프로그래밍에 필요한 3대 툴을 꼽으라면 에디터-컴파일러-디버거를 얘기할 수 있다. 사실 컴파일러만 있으면 나머지 두 가지는 이 대신 잇몸으로라도 해결이 가능하긴 하지만...

개인적인 생각으로는 컴파일러가 없는 건 당연히 말이 안 되고, 나머지 두 가지는 생산성 향상을 위해서는 꼭 필요하다는 것이 좀 더 정확한 표현일 듯 하다.


그리고 위 세 가지 이외에 최근 필수적인 툴로 떠오른 것이 바로 버전관리 툴이다. 최근이라고 하기엔 이미 많이 지나긴 했지만... SCM(Source Configuration Management) 툴이라고도 하지만 여기서는 그냥 이해하기 쉽게 버전관리 툴이라고 하겠다.


내가 가장 먼저 접한 버전관리 툴은 그야말로 '원조' 타이틀이 어색하지 않은 CVS(Concurrent Version System)였다.

원래 유닉스에는 RCS(Revision Control System)라는 툴이 존재했는데 파일의 변경 내역을 관리해 주는 툴이다. 헷갈리면 안 된다. 저 툴은 파일 하나만 관리할 수 있다 -_-;

소스 변경 내역 관리 자체가 안 되던 시점에는 RCS만 해도 쓸만하지 않았을까 싶다. 하지만 소스란게 파일 하나만 있는 것도 아니고... 그래서 RCS를 기반으로 여러 파일을 같이 관리할 수 있는 툴이 제작되었고 그것이 CVS다.


대학교 때 어떻게 알고선 혼자서 처음 CVS를 써보고서 '오~' 이랬던 기억이 아직도 생생하다. 교수들도 협업에 대한 노하우는 가르치지 않았으니깐...


그리고 입사한 첫 회사... 버전관리 툴이란게 존재하지 않았다 -_-;;

FTP에 개인이 작업한 소스를 압축해서 "개나소_20001010.zip" 이런 식으로 파일명을 붙여서 며칠에 한 번씩 올려놓는 식으로 작업하고 있는 것이었다. 오마이갓... 물론 작은 회사였다.

결국 선임 개발자들에게 CVS란 걸 가르쳐 주고 설득시켜서 적용시킬 수 밖에 없었다. 당연히 그 분들도 '오~'하고 감탄... 지금 생각해도 나보다 선임인 개발자가 서너명 있었는데 아무도 몰랐다는게 더 신기하다 -_-;

여튼 작은 회사였으니 상용 툴을 쓰는 건 뭐 거의 기대할 수 없었고... 개발도 gcc랑 vi로만 했고... 물론 ctags와 csope까지 포함... 아 이것도 내가 전파했군 -_-;


두번째 입사한 회사에서는 Source Offsite를 쓰고 있었다. 지금도 그런지는 모르겠지만 당시에는 솔직히 왜 돈 주고 사서 쓰는지 이해가 안 되는 툴이었다. 그 회사는 그래도 비교적 잘 나가던 회사였고 툴에도 그럭저럭 투자를 하는 편이었는데... 소스 오프사이트는 정말 아니었다.

예전 VS의 비주얼 소스세이프의 원격판인 셈이었는데 문제는 방식이 Lock-Check in-Unlock이었다. 변경할 파일에 Lock을 걸고 수정을 하고 Unlock을 해야 하는 방식인데 지금은 이런 방식의 툴이 거의 없지만 구현하기는 간단하다는 장점은 있을라나... 뭐 그것도 제작사 입장이고...-_-;


결정적인 문제는 File에 Lock을 걸면 다른 사람들은 아무도 Lock을 걸 수 없었다. Lock을 걸지 않으면 파일이 read-only라 수정이 불가능했다.

한 명이 이리저리 고쳐보면서 고민하는 시간이 길어지는 경우가 생기면 다른 사람들은 손가락 빨고 있어야 되는 구조였다.

강제로 read-only를 풀 수야 있지만 버전관리 툴에서 관리를 해 주지 않으므로 별로 의미가 없다. 그냥 자기가 고친 파일들 기억해 놓고 있다가 Lock이 풀리면 체크인하거나 해야 했다.

그래서 저 당시 내가 썼던 방법은 노트북에 SVN을 깔아 소스오프사이트 Working Copy를 복제해서 따로 작업하는 것이었다 -_-;


그리고 다른 문제를 말하자면, 해외 출장 개발이 많았던 회사이고 네트웍이 열악한 지역으로 출장을 가다 보니 해외에서는 하도 느려서 소스 서버에 붙어서 작업한다는게 거의 불가능했다. 같이 출장나가던 팀원들을 설득해서 내 노트북의 SVN에 붙어서 작업하도록 한 적도 있었는데... 초반엔 쓸만했지만 일이 있어서 내가 일찍 귀국하자 결국 흐지부지 되어버렸다. 그 때 지금의 git나 mercurial이 있었으면 굉장히 유용하지 않았을까 싶다.


소스 오프사이트에 학을 뗐던 에피소드 중 결정적인 것은 팀에서 두바이 출장을 가 있었고 나는 국내에 있었을 때였다. 내가 Lock을 걸고 일하다가 깜박하고 그대로 퇴근을 했는데 한두시간 후 두바이에서 국제전화가 걸려왔다. 파일에 Lock 걸려 있다고 -_-;;;

집의 컴퓨터에서는 회사일이 불가능했기 때문에 결국 내 소스 서버 계정을 알려줘서 두바이에서 직접 Lock을 풀도록 할 수 밖에 없었다 ;;


그리고 지금 회사는... Perforce를 쓰고 있다.

가격도 꽤 비싼 버전관리 툴인데... 1명당 라이센스가 대략 $600?

성능이나 기능은 만족하고 있다. 대규모 프로젝트에도 무리가 없고... 소스 오프사이트처럼 락을 걸어야 하는 방식이 살짝 마음에 안들긴 하지만 락을 걸어도 다른 사람이 수정 가능하기 때문에 별 문제는 없다.


지금은 이슈관리 툴 또한 꽤 좋은 상용 툴인 Jira를 쓰고 있다(이전 회사들은 죄다 Trac이나 BugZilla 같은 오픈 소스 아니면 엑셀 -_- 이었다).

버전 관리에 비해 이슈 관리는 약간 중요성이 떨어져 보이기도 하는데 사실 간단하게는 엑셀로도 할 수 있는 일이 맞긴 하다. 실제로도 그렇게 하는 경우도 많고...

하지만 이슈 관리는 Issue Tracking이라고도 불리는 만큼 문제의 '추적'이 중요하고, 예전에 발생했던 문제인지를 확인하는 등의 기능과 다중사용자를 위한 UI에서는 아무래도 엑셀보다 전문 툴을 사용하는 것이더 바람직하다고 할 것이다.


버전 관리나 이슈 관리는 사실 오픈 소스 툴도 잘 되어 있긴 하지만... 생산성 제고를 위해서 적합하고 좋은 툴을 선택하는 것도 회사가 신경써야 할 일이 아닐까 싶다.

Trackback 0 And Comment 4
prev | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ··· | 68 | next