최은만(2017), 『객체지향 소프트웨어 공학』을 읽다

o 최은만(2017), 『객체지향 소프트웨어 공학-객체지향 소프트웨어 개발의 모든 것-』, 서울 : 한빛아카데미, 초판 발행 2017. 4. 10.

       

2018년 8월 3일에 업무와 관련하여 참고하기 위해 사 놓았던 이 책을 읽었다. 업무와 관련된 책에 대해서는 포스팅 하지 않았는데, 이 책을 소프트웨어 과제 관리자나 소프트웨어 엔지니어들에게 소개해야겠다는 생각이 들어서 이 글을 쓰게 되었다.

 

저자 최은만 교수는 현재 동국대학교 컴퓨터과학과 교수이다. 저자는 머리말에서 ‘원론적인 이해를 넘어 실제 개발에 적용할 수 있기를 바라며’라는 제목 하에 ‘대규모 소프트웨어를 개발하는 일은 히말라야를 등반하는 것과 같습니다.’라고 약간은 과장이 섞인 강조의 말로 책을 열고 있다. 저자의 의도를 읽을 수 있는 말이고 실제로 이 책은 실무에서도 잘 활용할 수 있는 내용으로 엮어져 있다. 국방M&S(Modeling & Simulation) 분야의 검증, 확인 및 인정(VV&A, Verification Validation & Accreditation) 업무를 하면서 객체지향 개발방법론에 대해 다시 한 번 더 기본적인 지식들을 확인하고 기초를 다지기 위해서 책을 찾다가 이 책을 사게 되었다. 저자가 서문에서 밝혔듯이 실제 소프트웨어를 개발하는 엔지니어와 프로젝트 관리자들이 최신 기술을 배우고 정리하는데 가장 좋은 책이라고 생각된다. 업무를 수행하는 동안에 무엇인가 궁금할 때 인터넷을 통해 지식을 얻는 것 보다는 총괄적으로 앞 뒤 맥락을 파악할 수 있는 이런 교과서를 옆에 두고 일 하기를 추천한다.

  

요구분석 활동의 하나인 도메인 분석과 관련한 내용을 읽다가, 국방 M&S 분야에서 워게임 등 훈련모델이나 분석모델 등을 개발하는 과정에서 어려움을 겪는 분야가 생각나서 몇 자 적어보기로 한다. 국방 M&S 분야의 개발 업무에는 모의논리서라는 문서가 있다. 국내에 워게임 모델이나 분석모델에 대한 기반 기술이 부족하던 시절에 분석가를 위한 가이드(Guide for Analyst)로서 개발 후에 발간된 모의논리서를 보고 시스템을 개발했던 관행이 아직도 살아있다. 신규 개발 프로젝트에서도 놀랍게도 그리고 어처구니없게도 사업 초기에 도메인 분석 결과가 아닌 설계서로서의 모의논리서를 작성할 것을 요구하고 있다. 무기체계가 개발이 완료된 후 사용자가 무기체계를 잘 사용(Correct Use)할 수 있도록 제공되던 무기체계의 원리 교범과 같이 M&S 체계가 개발된 후 분석가들을 위해 제공하던 가이드가 모의논리서이다. 현재까지도 모의논리서는 소프트웨어 개발자를 위한 설계문서처럼 인식되어 개발자는 모의논리서가 불충분하여 설계할 수 없다하고, 모의논리서 작성자는 도메인 전문가로서 소프트웨어 개발에 대해 잘 모르니 소프트웨어 개발을 위한 설계서로서의 모의논리서를 작성하지 못하고 있는 실정이라 개발 프로젝트에서 적지 않은 불협화음을 일으키는 주체가 되어 버렸다. 특히 일부 소프트웨어 개발자들이 예전처럼 모의논리서를 보고 코딩하는 것이 소프트웨어 개발자의 임무라고 오해하는 데서 큰 문제가 발생하고 있다.

    

도메인 전문가들이 어떻게 시스템이 개발된 후 작성되는 원리 교범과 같은 모의논리서를 개발할 수 있기를 기대하는가? 70년대에 무기체계 개발 기술이 미천할 때 무기체계 원리 교범과 TDP(Technical Data Package)를 갖고 개발하면서, 원리 교범에 따라 시제품을 만들고 소프트웨어를 개발하여 테스트를 거치면서 수 많은 시행착오를 통해 기술을 축적했던 기억이 난다. 초창기 무기체계 개발과정에서 겪었던 일을 국방 M&S 분야에서는 심하게 말해서 지금도 겪고 있는 실정이다. 어쩌면 업체주도 사업이 주를 이루다 보니 설계 기술이 축적 되지 않아 생긴 후유증이라는 생각도 들었다. 기술이 축적되면서 무기체계에서는 원리 교범을 먼저 만들고 이를 개발문서로 참고하여 개발하는 방법은 생각도 못한 일이었는데, 어쩌다 국방 M&S 분야에서는 아직도 그 낡은 관행을 고수하면서 모의논리서를 설계문서로 작성하고자하는 우를 범하며 갈등을 겪고 있다. 책에 대해 포스팅하다가 엉뚱한 방향으로 흘러 한참을 이야기한 꼴이 되었다. 이 문제에 대해서는 추후 좀 더 자세히 언급할 예정이다.

       

요구분석 활동의 하나인 도메인 분석과 관련하여 저자는 소프트웨어 엔진니어들에게 중요한 이야기를 하고 있다. 소프트웨어 개발자로 일하는 경우, 도메인 전문가가 될 정도로는 아니더라도 도메인 분석 작업에 상당히 많은 노력을 쏟게 된다고 말하고 있다. 당연한 말이며 소프트웨어 엔지니어는 개발하고자 하는 시스템의 도메인 정보를 습득하는 것이 당연한 일이고 마땅히 해야 하는 일이다. 소프트웨어 엔지니어는 코딩하는 기능인이 아니기 때문이다. 도메인 분석은 요구분석 단게에서 소프트웨어 엔지니어가 개발하려는 분야의 배경 지식을 알아가는 과정이라는 것을 잊으면 안 된다.

   

이 책에서는 프로토타이핑(Prototyping)에 대해서도 명쾌하게 정의하고 있다. 소프트웨어 관리자들은 포로토타입(Prototyppe)이라는 용어에 대해서는 많이 들었지만 정확한 의미와 목적을 모르고 있는 경우를 종종 보게 된다. 프로토타이핑이란 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램이다. 그리고 프로토타이핑의 목적은 소프트웨어 엔지니어의 아이디어에 대한 피드백을 조기에 받아서 요구사항을 취합하는 것이다. 프로토타입은 바로 최종 시스템으로 전환하지 말고 요구를 취합하는 도구로만 사용하는 것이 좋다라고 저자는 강조하고 있다. 프로토타입은 사용자 인터페이스뿐만 아니라 알고리즘이나 데이터베이스를 시험하고 검증하기 위해서도 개발한다. 프로토타이핑이라는 말은 누구나 알기 때문에 그 용도나 목적에 대한 오해와 부작용도 그 만큼 크다. 프로토타입 소프트웨어가 요구분석 단계의 도구라는 사실을 잊는 경우가 많다, 프로토타입을 수정 보완하여 최종 시스템을 개발해야지 프로토타입을 요구분석이 끝나면 폐기한다 것에 대해 역정을 내고 화를 내는 관리자들을 많이 보았다. 물론 사업 초기에 요구사항 분석을 위해 빠르게 개발한 프로토타입을 기반으로 최종 시스템을 개발하기도 한다. 이럴 경우에는 사업초기부터 프로토타입의 명확한 목적과 향후 용도를 명확하게 정의한 후 프로토타입을 개발하지 않으면 안된다.

            

요구검토와 관련하여 파레토 법칙(Pareto Principle)을 언급하고 있어서 인상적이다. 파레토 법칙은 80대 20 법칙이라고도 한다. 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 말한다. 소프트웨어 공학에서 지키는 중요한 원칙 중의 하나는 80대20 법칙이다. 사용자가 안고 있는 문제의 80%는 작업의 20%가 해결할 수 있는데 이를 파레토 법칙이라 한다. 따라서 시스템에 대한 요구를 우선 순위가 높은 상위 20%만 먼저 개발하는 것을 고려할만 하다고 말하고 있다. 사업 초기에 우선 순위를 정확하게 식별할 수 없는 상황에서는 조심스럽게 적용해야할 법칙인듯 하다.

       

이 책은 애자일 방법론, 리팩토링, 디자인 패턴, 익스티림 개발방법론, 스크럼 개발방법론 등 많은 신기술에 대해서도 자세히 기술하고 있다. 제12장에서는 시험평가 개념의 Verification과 Validation을 설명하고 있다. Verification과 Validation에 대한 우리말 해석이 항상 문제가 되어 왔다. 국방기술 분야에서는 오래 전부터 Verification을 검증으로, Validation을 확인으로 결정하여 방위사업관리규정 등에서 공식적으로 사용하고 있는데, 이 책에서는 Verification을 확인으로, Validation을 검증으로 해석하고 있다. 어느 것이 맞다 틀리다의 문제는 아니지만, 이왕이면 먼저 고민했던 분야의 엔지니어들이 결정한 용어를 쓰는 것이 좋았을 텐데라는 아쉬움이 있다.

        

소프트웨어 개발에 참여하는 기술자들 중에서는 전산 전공이 아니고 소프트웨공학 과목을 수강하지도 공부하지도 않은 전자공학 전공자나 산업공학 전공자 등 기타 전공자들이 많다. 그러다 보니 실제 산업 현장에서는 소프트웨어 공학에 대한 지식이 약한 엔지니어들이 개발하는 소프트웨어의 품질이 떨어지는 경우를 종종 접하게 된다. 물론 소프트우에 공학에 대한 지식과 소프트웨어 품질의 연관성을 주장하는 것은 아니지만, 소프트웨어 엔지니어에게는 소프트웨어 공학 지식이 기반이 되어야 한다는 것은 강조하고 싶다. 객체지향 시스템을 개발하는 소프트웨어 기술자들은 꼭 이 책을 읽어보기를 권한다. 더불어 한국방송통신대학교 컴퓨터과학과의 김희천 교수가 쓴 『소프트웨어 공학』 책도 필수적으로 읽어야할 책이다. 대부분의 국내 소프트웨어 공학 책들이 많은 내용을 담고 있어서 두꺼운 것이 흠인데, 위의 두 책은 내용이 깔끔하게 정리되어 있어서 추천한다.