구조설계서 작성 후기 - 구조 검토가 우선

총 네번의 포스트로 작성한 구조 설계서의 원본 파일을 드.디.어 깃허브에 업로드했다 -> 링크. 이 포스트를 몇 분이나 읽고 계실지는 모르겠는데 관심 있으신 분들은 얼마든지 환영이다(욕설만 하지 않는다면 태클도 받는다) 아직 채워야할 내용도 있을 뿐만 아니라 문장이 깔끔하지 않고 오타도 있는 부실한 문서지만 본래 소프트웨어 개발자는 선 릴리즈 후수정이 원칙이고(응?) 난 지금 마무리 포스트를 쓰고 싶은 관계로 일단은 올렸다. 한 달 후의 내가 꼭 수정 하기를 바란다. 혹시나 독자가 생긴다면 더 일찍 하게 될 지도 모르겠다.

처음 이기적인 총무의 구조설계서를 작성하기로 할 때는 열정이 가득차 있었던 것 같다. 한달 간의 회사 교육 프로그램을 통해 구조설계의 중요성을 뼈저리게 배웠고 심화해서 공부해보고자 교육을 마칠즈음 만들어본 소프트웨어의 구조 설계 문서를 작성 하기로 마음 먹었었다. 그때도 이미 설계서 만드는 일이 쉽지 않다는 건 알고 있었지만 그래도 제로베이스가 아니라 이미 구현되어 있는 것을 문서로 옮기는 것이기 때문에 힘들지언정 지겨움은 느끼지 않을 것 같았다.

초반에 품은 마음 가짐 덕분인지 기능적/비기능적 요구사항 작성까지는 괜찮았다. 그런데 시스템구조를 작성하는 일부터는 문서 작성이 너무 힘들었다. 이미 구조를 다 짠 상태로 그것을 문서로 옮기기만 하면 되는 일인데도 이때부터는 노트북을 켜는 것 자체가 힘들었다. 내가 게을러지기도 했고 읽을 사람도 없는 무의미한 문서를 만드는 일에 싫증이 나기도 했지만 무엇보다 잡일이 많다는 점이 컸다. 구조설계 작업에선 요구사항을 토대로 다양한 후보구조를 도출하고 꼼꼼히 검토해 최종 구조를 선정하는 것이 주요한 일인데 예상외로 이 구조들을 일일이 다이어그램으로 옮기고 문서에 설명하는 일에 손이 많이 갔다. 총 시간만 본다면 구조를 검토하는 시간보다 문서 자체를 작성하는데 시간을 더 오래 소요 했으니 정작 중요한 작업은 뒷전으로 물러난 셈이다. 시작 하기 전에 나름 간소화 한다고 UML, Class 다이어그램 문법은 무시하고 그린건데 만약 꼼꼼히 챙겨서 그렸다면 더 오랜 시간이 소요 됐을 것이다. 만약 그랬다면 난 아마 중간에 포기했을지도 모르겠다.

모두다 잘하면 좋겠지만 시간이 촉박하다면, 구조 설계서 작성은 구조 검토와 문서 작업 사이에서 적정선을 찾는 것이 중요한 것 같다. 주된 작업은 요구사항 분석을 통한 후보구조 도출이지만 다른 사람이 읽는 산출물을 만든다는 점에서 문서 작업 또한 가볍게 여길 순 없다. 그러나 가독성을 지나치게 중시해 다이어그램의 문법을 꼼꼼히 체크하고 문서의 퀄리티를 높이는데 치중한다면 정작 중요한 구조 검토는 제대로 하지 못하는 주객 전도의 상황이 발생하게 된다. 양쪽에서 얼만큼 비중을 두느냐에 따라 훌륭한 설계이지만 사람들이 읽을 수 없는 문서가 될 수도 있고 문서 퀄리티는 훌륭하나 정작 소프트웨어 결과물은 엉망이 될 수도 있다.

다시 작성 한다면 문서 작업 자체는 좀 느슨하게 하게 하고 구조 검토에 중점을 두게 될 것 같다. 문서 작업 중에서도 꽤 오랜 시간을 잡아먹는 일은 다이어그램을 그리는 일을 많이 줄이게 될 것 같다. 클래스, 시퀀스 다이어그램은 현 시스템에 대해 모르는 이해 관계자들에게 쉽게 설명하기 위한 용도로 사용되는데, 소프트웨어에 문외한 이해 관계자는(주로 고객에 해당한다) 다이어그램이 있는 시스템구조까지 읽는 경우가 흔치 않고 이 챕터를 주로 읽는 개발자들은 다이어그램에서 클래스와 컴포턴트의 이름만 추출하고 구체적인 기능은 직접 코드로 보는 것을 선호한다. 문법대로 클래스 다이어그램에 속성과 함수명까지 빼곡히 입력하고 시퀀스 다이어그램에 루프까지 넣어가며 입력하지만 실제로 참고하는 경우는 미미한 것 같다. 각 클래스간의 매핑 관계와 역할만 둬도 충분 할 것 같다. 중요한 것은 훌륭한 구조를 만드는 것이지 이쁜 문서를 만드는 것이 아니다.