소프트웨어 모듈화는 어떻게?
시스템 모듈화와 다르지 않다
모듈화 방식은 탑 다운, 바텀 업 방식으로 나누고, 경험적, 수치적 방식으로 나눕니다.
시스템을 구성하는 구성요소 간의 인터페이스 강도를 기초로 클러스터링 하여 모듈을 식별하는 방식은 바텀 업-수치적 방식으로 구분할 수 있습니다.
탑 다운과 바텀 업 방식만 두고 다시 설명하면, 시스템 영역의 모듈러 디자인에서는 시스템이 갖는 사양 분석, 기능 분석, 기능-구조 분석으로 이어져서 최상위부터 모듈화하는 방식인 탑 다운 방식, 기존 시스템을 역공학 후, 클러스터링 하여 모듈을 식별하는 방식인 바텀 업 방식으로 구분할 수 있죠.
소프트웨어도 동일한 방식으로 모듈화를 수행할 수 있습니다. 동일하게 사양 분석, 기능 분석으로 이어져서 모듈화를 진행하는 방식도 있고, 소스 코드를 분석하여 클러스터링 하여 모듈화하는 방식도 있습니다. 실무에서는 기구나 하드웨어와 달리 소프트웨어 분석 또는 가시화 툴을 활용하여 조금 더 손쉽게 클러스터링 할 수 있지만, 소프트웨어는 다르다는 생각에 한정된 범위에서만 활용하는 측면이 있죠.
소프트웨어 영역에서는 소프트웨어 프로덕트 라인의 개념이 전자의 방식과 유사한 측면이 있고, 후자는 모듈화하려는 목적보다는 코드 품질을 높이기 위한 방법으로 활용을 합니다. 또는 전자의 방식은 소프트웨어를 기획, 설계, 구현 순으로 차례대로 만들어 가는 과정에 적합하다면, 후자는 이미 만들어진 소프트웨어를 모듈화하여 재구조화하는 방식에 어울린다고 볼 수 있습니다.
그렇다면, 기존에 만들어진 소프트웨어가 있다면 후자의 방식으로 소프트웨어 모듈화를 쉽게 이룰 수 있을까요?
결론만 말하면 그렇게 쉽진 않습니다.
이전에 소프트웨어 모듈러 디자인인 “Software as a Module” 모듈로서의 소프트웨어와 “Software Modularization” 소프트웨어 모듈화의 개념을 구분해야 한다고 했었죠. 클러스터링을 활용하여 모듈화하는 방식에서는 시작을 “모듈로서의 소프트웨어”부터 시작해야 합니다. 당연히 현재 구조 기준으로 인터페이스 되는 수준으로 모듈화를 하면 안 되고, 소프트웨어에 영향을 주는 사양, 피처 기준으로 모듈화를 할 수 있어야 합니다.
그런데, 실제로는 소스 분석 툴로 소프트웨어 구조를 파악한 후에 현재 기준으로 의존성이 높은 구성요소를 하나의 모듈로 묶다 보니, 외부 환경에서 소프트웨어의 변화를 줄 때는 구조가 취약해지는 상황이 발생하게 됩니다.
소프트웨어 사양 분석, 피처 분석부터 시작하여 여기에 영향을 받는 소프트웨어 내부 구성요소의 모듈화를 수행해야 하고, 이것은 앞에서 언급한 자동화 툴로 해결하기 어려운 문제입니다.
그리고 한 가지 더 당연하게도 소프트웨어를 모듈화하든지, 재구조화하기 위해서는 자사에서 기획하고 설계해야 합니다. 설계와 개발을 외주에 맡기면서 구조를 개선하려고 한다는 건 어색한 일입니다. 만약 외주에 맡긴 다면 그 자체를 모듈로 보고, 해당 소프트웨어 모듈과 다른 모듈 간의 의존성을 최대한 낮추는 것이 일 순위입니다. 구조 개선은 원칙 상으로는 외주 업체에서 개선하는 것이 맞습니다.
