넥슨이라는곳에 입사를 했을때 결과물에 대한 파일 전달을 FTP의 특정 서버나 사내 공유폴더에 업로드하는것이 아닌 CVS라는 툴을 통해서 업로드 해야한다는 이야기를 듣게 되었다. 그때는 정말 결과물 업로드의 용도로만 알고 있었기 때문에 왜 내가 내손으로 작업할걸 업로드하는데 log comment등을 같이 작성해야하는지 몰랐다. CVS가 스타크래프트의 SCV처럼 뭔가를 운반하는 의미로 상통하지 않을까 이런 또라이 같은 생각을 하기도 했다. 좀 지나고 CVS가 버전 관리툴이라는것을 알게 되었고 난 좀 감동했다. ‘그럼 작업하다가 잘못 업로드 한게 있어도 이전 버전으로 돌릴 수 있는것이 아닌가!!!’ 라면서 감동했고 좀 더 자유롭게 좀 더 내맘대로 작업을 해볼 수 있는 기회도 생겼었다. 물론 남들의 작업 로그를 보면서 공부를 하기도 했다. 그때는 그냥 일하다 시간이 남아서 다른 팀원들의 각종 코드나 로그를 보는것이었는데 지금 생각해 보면 내가 지금까지 일해 오면서 버틸 수 있는 원동력이 거기서 비롯된것같다.

시간이 지나면서 난 CVS, SVN, Mercurial를 겪게 되었고 수많은 conflict와 merge를 겪으면서 내 자신도 성장했을거다 아마;;;;
넥슨에서는 commit log를 남길때 내가 이 commit을 하는 목적과 이유에 대해서 분명히 작성하는걸 규칙으로 세웠다. 그 덕분에 다른 사람의 코드를 보기가 더욱 쉬웠고, 담당자가 바뀌어도 인수 인계 절차가 간소화 될 수 있었다.
오페라에서는 더욱 그랬다. 오페라는 Bug tracking System으로 JIRA를 쓰고 있었고 그곳에서는 JIRA의 bug number나, Task number를 commit log 작성시에 포함하여 연동시키는 방법을 쓰고 있었다. 실제 내가 회사를 떠나도 내가 짠 코드와 내가 기록한 로그들은 남아있을것이다. 내가 만든 코드를 고칠 경우나 분석 할 일이 있을 때, 퇴사한 나에게 전화를 하지 않아도 되는점이라고 해야할까? 그렇게 나는 버전관리도구에 익숙해져갔다.

오페라를 관두고 잠깐 일을 하던 회사가 있었는데 그곳도 분명히 SVN을 사용하는 회사였다. 아 그럼 로그들을 보면서 내가 히스토리를 파악하면 되겠구나 생각했는데, 이게 웬걸? commit log의 절반 이상이 “.”이었다. 어느 정도 정보를 기록하는 사람도 있었지만 그 마저도 적절한 log는 아니었다. 이곳은 SVN에 커밋을 하면 특정 테스트 웹 서버에 동기화되어 웹에서 확인 가능한 상태가 되는 방식이었다. 그리고 그 URL을 협업하는 담당자에게 공유하는 방식이었다.  왜 log를 제대로 작성하지 않는가? 라고 물었더니… 대부분의 대답은

“어짜피 이 작업은 나만 하지 이걸 누가 본다고?”는 것이었다… 충격적이었다.
난 다시 물었다. 만약에 담당자가 바뀌면 어쩔것인가? 라는 질문을 했고 안 바꾸면 되지 와 그러기 위해 인수인계가 있는거다. 라는 답이 돌아왔다.
어안이 벙벙해서 SVN담당자와 팀장에게 따지듯이 물었다. 근데 이 두 사람은 이 이상한 상황을 개선하려고 엄청 노력을 했다는것이었다.
대부분 SVN은 테스트 서버에 파일을 올리기 위한 용도로 쓰는상황에서, 난 commit log를 의미있게 입력하게끔 만들고 싶었다.

불편하지만 commit log를 작성하는 규칙을 만들었고, 따르기를 바랬다.

그러다 한서비스만 4~5년 맡아서 진행하는 동료의 프로젝트에 내가 추가로 애드온을 작성할일이 생겼다. 난 그냥 아무 생각없이 작업을 했는데 페이지 레이아웃이 뒤틀리는 현상이 발생했고, 원인을 찾아서 쓸데없는 CSS코드가 삽입되어 있음을 찾아냈다. 내 입장에서야 쓸데없지만 담당자에게는 중요한 코드니까 넣었겠지라고 생각하며 물어봤는데, 그 코드가 뭔지는 모르겠지만 절대 지울수 없다고 한다. 그래서 반대로 해당 이슈에 대해 물어봤고, 그런 이슈는 듣도 보도 못했다는것; 결국 SVN에서 그 쓸데없는 CSS파일을 업로드한 시점을 찾았고 거기에는 당연히 commit log가 “.” 되어 있었다. 물어봐도 당연히 답이 안나왔다.
commit log가 조금이라도 작성이 되었으면 나중에 귀찮지 않았을것이다.
현재 자신이 작업하는 것이 혼자 버전관리를 한다고 해도 작업에 대한 로그는 남겨져야 한다. 당연한 얘기지만 버전관리툴은 결과물을 서버에 업로드하는 툴이 아니다 =_=

버전관리는 사용하면서 파일을 날짜별로 분기하는곳도 있다. 파일안에 보면 주석으로 변경사항을 기록한다. 버전관리는 왜 쓰는지 모르겠다.  예전의 파일에서 문제점이 생겨서 왜 이런 문제가 생겼는지 찾아보려고 해도 절대 답이 나오지않는다. 사람의 기억에 의존한다. 배포되는 파일과 작업하는 파일의 위치가 다르게 존재하고 작업하는 사람의 리비전과 배포하는사람의 리비전은 별도로 존재한다. 그 사이에 어떤 수정을 가하는지 알 수가 없다. 알 수 없기 때문에 추가 작업은 결과물에서 파일을 다운받아 작업한다. 버전관리가 될리없다. 버전관리의 최대장점이 여러사람이 작업하고 그 로그를 관리할 수 있다는것인데, 그게 안된다.

버전관리 주기도 엄청 중요하고 내 개인적인 기준으로는  최소한의 태스크로 구분을 하는편인데… 위의 상황에서 이런게 강조되는게 맞는가 싶다.