소프트웨어 모듈러 디자인에 대한 견해
소프트웨어는 특별하다?
소프트웨어 모듈러 디자인에 대한 세미나를 하면 보통 두 가지 상반된 반응이 나옵니다.
"우린 이미 모듈러 디자인, 모듈화 설계를 하고 있다."
"그건 기구나 하드웨어에서나 가능한 이야기이지 소프트웨어에서 적용하기 어렵다."
어느 정도 두 의견 맞는 면이 있습니다.
첫 번째 주장을 하는 쪽에는 모듈러 디자인, 모듈화 설계 이상의
무엇을 더 해야 하는지 설명을 해줘야 하고,
두 번째 주장을 하는 쪽에는 소프트웨어 영역에서 왜 모듈러 디자인을
적용해야 하는지 설명을 해줘야 합니다.
기본적으로 소프트웨어는 기능 블록 단위로 설계가 이루어집니다.
물리적인 형태를 갖추고 있지 않기 때문에, 기능 단위로 어떤 식으로든 묶어서 설계를 할 수밖에 없습니다.
이 과정을 모듈화 설계라고 지칭할 수도 있죠.
또는 자사에서 소프트웨어를 개발하고 관리하지 않거나,
임베디드 소프트웨어로 굉장히 규모가 작거나, 성능이 중요한 분야로 모노리딕 형태로
만드는 경우도 있을 수 있겠죠.
그래서, 가장 먼저 해야 할 일은 콘텍스트, 대상 소프트웨어가 처한
비즈니스 환경, 제품 특성을 먼저 파악해야 합니다.
제약사항도 같이 파악을 해야겠죠.
반응 속도 때문에 최대한 계층을 두지 않고 설계를 해야 한다던지
가혹 조건에서도 동작을 해야 하므로, 무엇보다도 신뢰성을 최우선을 해야 한다던지
공인된 아키텍처를 두고 설계를 해야 한다던지 산업마다 제약사항이 있을 겁니다.
그러고 나서 해결할 문제는 정해야겠죠.
무작정 모듈러 디자인을 적용하라고 하니까 적용하는 건 아무 소용이 없을 뿐만 아니라,
조직 구성원의 반발만 하게 됩니다.
설계 리소스 절감, 리드타임 단축, 원가 절감 등 뚜렷한 목적성을 가지고 일을 진행해야 합니다.
모듈러 디자인을 해야 한다는 목적성도 명확하다면
이후에는 현 수준을 진단해야 합니다.
가장 먼저 살펴볼 것이 현재 소프트웨어 아키텍처를 파악해야 합니다.
명확한 아키텍처가 정의가 되어 있는지 살펴보아야 합니다.
정의되어 있는 아키텍처가 몇 종이나 있는지 살펴보아야 합니다.
아키텍처 내 기능 블록이 어떻게 구성되어 있고, 기능 블록 간 결합도 수준이 어떠한지 측정해보아야 합니다.
신제품 개발 단계에서 기능 블록 단위로 재사용하는지, 재사용 범위와 재사용 프로세스를 점검해봐야 합니다.
아키텍처를 관리하는 조직이 있는지 살펴보아야 합니다.
제품 파생이 일어날 때 변동이 일어나는 기능 블록이 어느 정도인지 파악해야 합니다.
제품의 특성 별로 어떤 기능 블록이 영향을 받고 실제로 그 부분만 파생이 일어나는지 확인해봐야 합니다.
신제품 개발 시 아키텍처 내 기능 블록 단위로 재사용할 영역과 신규로 개발한 영역을 사전에 정의하는지,
정의한 것을 개발 과정에서 점검하는지, 점검 후 개선하는지 살펴보아야 합니다.
기능 블록 간의 결합도 수준을 낮추기 위해서 지속적으로 아키텍처를 최적화하는지 살펴보아야 합니다.
기능 블록 간의 인터페이스가 표준화가 되어 있고, 표준화된 결과가 설계 규칙으로 문서화되어 있는지 확인해봐야 합니다.
몇 개의 아키텍처를 운영하고 있다면, 통합의 필요성이나 통합 노력이 있는지 살펴봐야 합니다.
모듈러 디자인을 수행하기 위한 원리는 기구, 하드웨어, 소프트웨어 모두 동일합니다.
그것을 실행하는 방법이 다를 뿐입니다.
