프로젝트 중 문서 산출물의 버전 관리 방법

문서 산출물 관리에 대한 나름의 Best Practice를 공유하려고 한다.

참고로 필자는 지금 보안컨설턴트이지만, 과거에 개발조직을 대상으로 개발프로세스에 대한 체계정립과 개선을 담당하여 성공적으로 조직에 구현 한 경험이 있어 소프트웨어의 버전관리에 대해서도 많이 고민을 한 편이다.

컨설팅 프로젝트의 산출물은 문서다. 

뿐만 아니라 프로젝트에서 대부분의 산출물은 문서이고, 신경써서 버전 관리를 해야 할만한 산출물 역시 문서다. 소스코드가 주요 산출물인 프로젝트의 경우 SVN,Git과 같은 관리도구를 사용하여 버전 문만 아니라 변경이력까지 자동화 하여 관리하게 되니, 최종 버전이 무엇인지 수동으로 확인 할 필요가 없기 때문이다.

일반적으로 문서의 버전은 파일명을 통하여 관리한다.

이 때에 버전명을 소프트웨어에서 버전을 부여하는 관례에 따라 V0.1 등으로 지정하는 경우가 대부분이다.

예를 들면 "문서명_V1.0.docx" 등으로 말이다.

그런데, 과연 이렇게 관리하는 것이 효과적일까?

프로젝트 산출물은 고객에게 제출 될 때 1.0이 된다. 그 전엔 별다른 기준이 없는 경우 0.1이기도 하고, 0.11이기도 하고, 별다른 기준 없이 0,1이 0.2가 되기도 하곤 한다. 결과적으로는 가장 마지막 버전이 무엇인지 식별만 되는 경우가 대다수인데, 이렇게 Major 버전과 Minor 버전의 의미가 부여된 "1.0" 체계를 따르는 것은 효과적이지도, 효율적이지도 않다.

"빌드" 개념을 사용

결과적으로 "버전" 대신  "빌드"의 개념을 사용하는 것이 좋겠다.

예를 들면, "문서명_yyyyMMdd_Incremental_작성자명.확장자"의 형태이다.

파일명 중간의 yyyyMMdd_Incremental 부분이 빌드명과 같은 형태인데, 

오늘(2014년 2월 27일) 첫 번째 배포하는 파일이라면 "문서명_20140227_1_Ez군.docx" 의 형태일 것이다. 

그리고, 일부 수정을 하여 오늘 다시 배포를 해야 한다면 "문서명_20140227_2_Ez군.docx"가 된다.

다음날 배포를 하게 되년 경우 "문서명_20140228_1_Ez군.docx" 으로 날짜가 변경되고, 해당 일에 첫번째 배포이므로 Incremental 부분은 1이 되는 것이다.

몇가지 문서 관리를 위한 추가적인 팁 

• 물론, 프로젝트 종료 시에는 문서명_V1.0.확장자" 등으로 정리를 한 후 산출물을 제출하는 것이 필요하다.
• 개정되어 배포되는 최신 문서가 생성되면 지난 문서는 해당 폴더 하위에 "obsolete"이라는 폴더를 만들고 거기에 넣어둔다. 종종 과거에 배포된 문서를 꺼내 볼 일이 생기기 때문이다.
• 그리고, 습관적으로 해당 문서 산출물을 수정 할 일이 있으면 문서를 복사하여 새로운 파일을 만들어 거기에 수정을 시작한다.  예를 들어 어제 작업 한 파일이 20140226_2 라면 Copy&Paste하여 오늘 작업 할 20140227_1을 만들고 작업을 하는 것이다.
• 작업 중간중간 Save를 위한 Shortcut을 눌러(Ctrl + S) 저장하는 습관이 있어 갑자기 PC가 이상해지는 경우에도 일 한 결과물을 날리는 경우를 최소화 한다.
• 각 버전 마다 진척율을 관리하기 위한 목적으로 "버전" 개념을 사용하기도 한다. 예를 들어 작성 담당자가 작성을 완료하면 "0.6", 해당 PL의 검토가 완료되면 "0.7", PM 검토가 완료되면 "0.8", PMO 검토가 완료되면 "0.9" 그리고, 고객 승인이 완료되면 "1.0"으로 관리하는 식이다. 그래서 0.6의 경우 진척률을 60% 완료 한 것으로 하고, 고객 승인이 완료되면 100% 완료 한 것으로 하는 등으로 관리를 하기도 한다.