관공서 프로젝트 문서화 관련 1

"유스케이스 문서 내에 예외처리 관련 사항이 많이 누락된 것 같습니다. 예외 부분에 N/A로 표기한 것들은 전면 검토해서 예외항목을 추가해주세요."

작년 6월부터 올해 3월? 정도까지 프로젝트 단계에 맞추어 분석 및 설계 문서들을 다양하게 작성했습니다.
그 중 유스케이스는 작년 9월? 8월 즈음에 작성했던 문서였습니다. 물론 양식 부분에서 문제가 있어 수정 수정 하다보니 지금까지 오긴 했는데 어쨌던 리비전을 찍기 위해 수정 완료하고, 그 문서를 기반으로 쭉 하위 문서들을 작성했는데, 뜬금 저런 지적이 나오더군요. 시기적인 문제도 있지만, 아마도 관공서 프로젝트에서 수행하는 그 모습에서 있던 총괄적인 문제가 있어 그 부분을 좀 짚어보려고 블로그를 시작합니다.

핑계라면 핑계겠지만, 일단 위의 문서에서 유스케이스 작성 당시  지금 개발해야 될 제품이 어떤 모습을 갖춰야 할지 그림이 그려지지 않은 상태로 진행을 했습니다.
명백한 시작의 오류기는 하지만, 현재 처한 상황에서는 그러할 수 밖에 없었습니다.. 
프로젝트를 시작할 때, 개발 담당자들의 해당 업무의 이해도도 0%를 수렴하고 있을 정도로 이제 처음이라는 점입니다. 
개발해야 할 대상이 되는 업무 자체의 프로세스도 잘 모르는다는 점이 가장 큰 문제였습니다.
더욱이 벤치마크 대상 제품도 넘사벽 제품이였습니다. 외산 업체의 솔루션 인데, 그것도 근 40년의 역사를 밟아오고 끊임없이 업그레이드되고 있고, 업계에서 이 솔루션을 60%? 넘게 사용하고 있는 그런 제품이였습니다.거의 MS Windows 급이죠.
게다가 사업 발주 주체가 현업 담당자가 아니였습니다. 그 상위 부서로 자신들이 수행하고자하는 제품 제작에 곁가지로 붙은 업무 였죠. 그 상위 부서는 이 현업의 업무를 거의 모른다입니다. 
그저 솔루션의 국산화 외에는 이 사업이 현업 담당자에게 어느 부분이 필요하고, 불필요한지를 이해하지 못했습니다.
그러다보니, 우리 쪽이 담당한 제품이 아닌 실제 메인으로 만들어야 하는 별도 제품, 즉 상위 부서에서 중점적으로 다루는 제품에 대해서는 다각도로 확인하고 점검하지만 애석하게도 우리가 하고 있는 이 업무는 항상 후순위나 방치였죠. 아니 이 업무를 이해하고 있는 상위 부서 분들이 거의 없어서 이기도 할 겁니다.

이런 배경 속이다보니, 당연히 이 프로젝트의 첫 출발인  요구사항(RFP) 안에 이 업무에 대해서 나열된 사항은 
벤치마크 된 제품 기능 나열만을 가득채우고, 실제 현업 담당자가 원하는 항목에 대해서는 딱 한줄만 언급할 정도였습니다. 
벤치마크한 각종 기능들이 현업 업무에 몰이해로 인해 각 기능의 연관관계는 무시한채  잡다하게 기능만 나열만 되어 잇었습니다.
그러다보니 RFP를 기반으로 한 제안서는 당연히 몰이해된 기묘한 기능들만 나열되어 있고, 
절실하게 원하는 기능은 RFP상 60여줄의 내용 중 1줄이니 제안서 안에서도 언급만 된 정도로 끝내놓은 상태였습니다.
우리는 이미 이렇게 만들어진 RFP와 제안서를 들고 제품을 만들지를 공상하는데 끔찍하더군요.
각 기능 하나 하나에 대한 이해도 안되는 건 기본이고, 나열해서 정리하는데 왜 이 내용이 여기 저기 있고,
업무 프로세스 상에서도 모순이 있는 것들이 종종 보였습니다. 
그리고 업무 참여하면서 벤치마크한 제품의 메뉴얼을 보고 그 역사와 배경을 듣는 순간 좌절했죠.
없는 것을 만드는 것보다 더 끔찍한 건 정말 정말 잘 운영되고 활용되고 있는 솔루션을 그대로 만들라는 것이죠.
굳이 비교하자면, MS Windows 를 만들어달라고 MS Windows 메뉴얼만을 던저 준 꼴이라고 할까요?
덧붙이자면, 그 프로그램을 개발자가 직접 만질 수도 없었습니다. 
벤치마크 당하는 제품 회사에서 그 제품을 꽁짜로 보여줄리도 없고,
개발 사업비에 벤치마크 프로그램 라이선스 구매비용도 없고,
현업 담당자 쪽에서도 이 프로그램을 우리에게 노출시킬 생각이 1도 없었으니까, 
결국은 RFP, 제안서 그리고 벤치마크할 제품 메뉴얼, 해당 업무에 대해서 국제적으로 규정된 규정집이 우리에게 제공된 모든 것이였습니다.
(뭐 실력이 출중하신 분은 저것 만으로도 충분히 할 수 있겠지만, 저 같은 일반 개발자에게는 불가능입니다.)

물론 추후 현업 담당자와 논의해본 결과 저희들이 상상하고 오해한 내용들에 대한 거품을 덜고 어느 정도 기능 파악도 했고,
간소화나 기능적 축소 방안들을 찾을 수 있게 되긴했습니다.
기능적으로 나름대로 분류할 기준들을 하나씩 세우고 비슷한 기능 분류를 위한 부분도 정리했으며,
현업 담당자들이 가진 최고의 Pain Point를 발견했고, 그 부분을 어떻게 해결할지도 대략적인 안이 나왔으며 이에 맞게 설계 구성하면 될 것 같더군요.

이런 배경 속에서 갑자기 유스케이스부터 다시보라니....
이 문제를 좀 더 들어가보겠습니다.