이건 정말 어려운 이야기다…. 개발자들은 사실 문서 쓰는 거 싫어한다. 안다 잘… 그래서 여러모 이건 좀 골때리는 내용일꺼다. 그래도 그나마 개발 좀 막 하면서 느낀 걸 이야기해보려 한다.
“문서는 납품 대상이 되는 최종 문서만 남기면 된다.” 라는 건 개발하다보면 여러모로 듣는 이야기다. 사실 진짜 바쁘기 때문에 개발하면서 문서까지 쓰고 그러려면 진짜 힘들다.
게다가 그넘의 애자일 개발 방법론에 따르면 개발 문서보다는 소프트웨어가 중요하다는 항목이 있다. (이거 적으면서도 솔직히 좀 머리 아프다.) 이 말 그대로 받아들여서 소프트웨어 소스코드만 중요하다고 생각하면 진짜 안되는데…. 안되는데….
그리고 슬프게도, 실제로 프로젝트 중간중간에 작성했던 모든 문서에 대해서 버전까지 관리하면서 있는 개발 현장은 거의 없을 것이다. 한국에서는 학위논문(특히 박사학위 혹은 연구노트 쓰고 있으면 그거라도 되겠네…), 정부 프로젝트 외에는 거의 없을꺼라고 장담한다.
많은 개발 현장에서 소스코드는 형상관리가 되고 있지만 문서의 경우에는 형상 관리가 되지 않는 것이 일반적이다. 그나마 위키라도 되어 있으면 칭찬해야 한다고 해야하나…;ㅅ; 테스트 시나리오나 테스트 데이터 또한 마찬가지일 가능성이 높다. (단 테스트는 테스트 프로젝트 별도로 계속 만들어서 테스트가 더 많다면 그나마 다행일지도..) 근데 여기에 추가로 개발 기간까지 짧아서 시간도 없다면..? 더 이상의 내용은 생략한다.
하지만, 아키텍쳐 설명서나 회의록 등 납품하지 않아도 되는 중간 성과물에 대한 형상관리는 굉장히 중요하다. 괴거 버전의 문서가 남아 있으면 왜 이런 아키첵쳐가 되어있는지, 왜 이런 사양으로 되었는지, 프로젝트 중간 중간의 의사 결정에 대한 이유라던지를 알 수 있다. 그것은 운영 이후에 유지 보수 과정에서도 도움이 된다. 특히 개발할 때의 다양한 상황을 이해하기 위해 중간 성과물 문서에 대한 형상 관리는 상당히 중요하다.
스타트업이나 중소기업에서는 개발자가 적은 데다가 그 개발자들이 그대로 가기 때문에 이걸 더더욱 작성 안한다. 그 개발자가 알 것이라고 생각한다. 그러나 그들도 사람이다. 그들의 기억도 한계가 있다. 그리고 그게 몇 번씩 뒤집어지면… 제대로 기억 못할 가능성 높다.
초기 개발지 짧아지면서 점점 유지보수에 관한 업무가 중요하게 여겨지므로 문서 등의 내용을 관리하는 것이 상당히 중요해지고 있다. 그리고 그걸 굳이 문서 이외의 방법으로 남기는 방법들 또한 다양해지고 있다. 문서들을 일일이 다 수작업으로 관리한다면 솔직히 엄청 힘든 내용들이긴 하다. (근데 그렇게 해야 하는 곳들도 있긴 하다…ㅠㅠ) 그렇지만 우리는 형상관리 툴들에 대해서 여러모로 널리 퍼져있고 지원되는 기능들도 다양하다. 그러므로 중간 결과물에 대해서 관리하는 것에 대해서는 여러모로 꼭 하자.