하지 말아야 되나? – 납품 문서만 남겨두면 된다?

이건 정말 어려운 이야기다…. 개발자들은 사실 문서 쓰는 거 싫어한다. 안다 잘… 그래서 여러모 이건 좀 골때리는 내용일꺼다. 그래도 그나마 개발 좀 막 하면서 느낀 걸 이야기해보려 한다.

“문서는 납품 대상이 되는 최종 문서만 남기면 된다.” 라는 건 개발하다보면 여러모로 듣는 이야기다. 사실 진짜 바쁘기 때문에 개발하면서 문서까지 쓰고 그러려면 진짜 힘들다.

게다가 그넘의 애자일 개발 방법론에 따르면 개발 문서보다는 소프트웨어가 중요하다는 항목이 있다. (이거 적으면서도 솔직히 좀 머리 아프다.) 이 말 그대로 받아들여서 소프트웨어 소스코드만 중요하다고 생각하면 진짜 안되는데…. 안되는데….

애자일을 잘못 알아들은 인간들은 이런 표정 지을꺼다 분명…. 진짜로….. (그넘의 오씨라던가…)

그리고 슬프게도, 실제로 프로젝트 중간중간에 작성했던 모든 문서에 대해서 버전까지 관리하면서 있는 개발 현장은 거의 없을 것이다. 한국에서는 학위논문(특히 박사학위 혹은 연구노트 쓰고 있으면 그거라도 되겠네…), 정부 프로젝트 외에는 거의 없을꺼라고 장담한다.

많은 개발 현장에서 소스코드는 형상관리가 되고 있지만 문서의 경우에는 형상 관리가 되지 않는 것이 일반적이다. 그나마 위키라도 되어 있으면 칭찬해야 한다고 해야하나…;ㅅ; 테스트 시나리오나 테스트 데이터 또한 마찬가지일 가능성이 높다. (단 테스트는 테스트 프로젝트 별도로 계속 만들어서 테스트가 더 많다면 그나마 다행일지도..) 근데 여기에 추가로 개발 기간까지 짧아서 시간도 없다면..? 더 이상의 내용은 생략한다.

하지만, 아키텍쳐 설명서나 회의록 등 납품하지 않아도 되는 중간 성과물에 대한 형상관리는 굉장히 중요하다. 괴거 버전의 문서가 남아 있으면 왜 이런 아키첵쳐가 되어있는지, 왜 이런 사양으로 되었는지, 프로젝트 중간 중간의 의사 결정에 대한 이유라던지를 알 수 있다. 그것은 운영 이후에 유지 보수 과정에서도 도움이 된다. 특히 개발할 때의 다양한 상황을 이해하기 위해 중간 성과물 문서에 대한 형상 관리는 상당히 중요하다.

스타트업이나 중소기업에서는 개발자가 적은 데다가 그 개발자들이 그대로 가기 때문에 이걸 더더욱 작성 안한다. 그 개발자가 알 것이라고 생각한다. 그러나 그들도 사람이다. 그들의 기억도 한계가 있다. 그리고 그게 몇 번씩 뒤집어지면… 제대로 기억 못할 가능성 높다.

초기 개발지 짧아지면서 점점 유지보수에 관한 업무가 중요하게 여겨지므로 문서 등의 내용을 관리하는 것이 상당히 중요해지고 있다. 그리고 그걸 굳이 문서 이외의 방법으로 남기는 방법들 또한 다양해지고 있다. 문서들을 일일이 다 수작업으로 관리한다면 솔직히 엄청 힘든 내용들이긴 하다. (근데 그렇게 해야 하는 곳들도 있긴 하다…ㅠㅠ) 그렇지만 우리는 형상관리 툴들에 대해서 여러모로 널리 퍼져있고 지원되는 기능들도 다양하다. 그러므로 중간 결과물에 대해서 관리하는 것에 대해서는 여러모로 꼭 하자.

하지 말아야 되나? – Use Case를 상세하게 적는 것에 관하여…

쓰고 싶었던 시리즈의 내용이다. 잡소리 그만하고 이건 바로 시작할 것이다.

요즘 내가 기술 문서를 정리하면서 기능 요구조건에 대한 use case(유스 케이스)를 정리하고 분석하여 설계한 설계서를 찾아내었다. 이걸 보면서 내가 배웠던 내용이면서 다른 사람들이 했던 실수가 기억나서 블로그에 적어봤다. 보통 많은 사람들이 유스 케이스를 적으면서 비즈니스 케이스에 대해서 하나하나 다 추가하거나 if then 같은 로직수준까지 넣는 경우도 있는다. 이런 정보는 사실 요구조건에 대해서는 불필요한 정보가 상세화되는 케이스가 될 수 있다.

요구조건 분석 문서를 가지고 여러 의견이 나뉘는 건 어쩔 수 없다. 왜냐면 이건 상세화의 레벨을 어디까지 해야 되느냐에 따라서도 개발 프로세스를 담당하는 사람에 따라서 다르게 받아들이기 때문이다. 어느 아키텍트는 분석 마비(analysis paralysis), 즉 상세화 하지 않으면 불안하다면서 모든 유스 케이스에 구축을 위한 목적을 표편하는 것보다 기능 자체에만 집중을 하는 경우가 생긴다.

그러나 실제로 유스 케이스를 상세하게 작성하면 분석하고 설계할 때 오히려 방해가 된다. 실행 조건과 종료 상태 정도만 정확하게 작성하면 사실 그걸로도 끝난다. 그런데 왜 그러질 못할까..?

잘못된 유스 케이스는 메인 시나리오에서는 문제가 없지만 대체 시나리오, 변경 정보, 비즈니스 룰까지 포함되어 있다. 이는 개발 프로세스 문서에서의 정보의 혼재와 버전 관리를 힘들게 하며, 서로간의 결합도가 너무 높아지는 구조를 그대로 가지고 개발 단계에서 개발을 하게 되므로 프로그램 또한 나중의 유지 보수가 상당히 힘들어지게 된다.

그래서 올바른 유스 케이스를 작성하는 것은 메인 시나리오, 대체 시나리오, 변경 정보에 대해서는 전부 어느 정도 구분해서 작성하고 있으며, 시나리오 분석할 때에도 불필요한 비즈니스 부분(비즈니스 룰)에 대해서는 별도의 카탈로그화 해서 작성하게 된다. 특히 비즈니스 룰의 경우에는 동일한 비즈니스 분야라 할지라도 해당하는 회사에 따라 룰이 다르게 적용될 수 있는 부분이므로 이 부분은 확실하게 나눠서 처리하지 않으면 안된다. 별첨 꼭 해야 하는 이유이기도 하다.