소프트웨어 모듈 정의 시 고려사항

쓸모 있는 모듈러 디자인

모듈러 디자인은 모듈을 정의하는 활동인 모듈러 아키텍처링 활동과 모듈을 활용하여 제품을 개발, 운영하는 활동인 모듈러 오퍼레이팅 활동으로 나뉩니다. 

모듈러 아키텍처링 활동은 모듈러 디자인의 핵심이라고 불릴 정도로 중요한 활용입니다.

소프트웨어에서는 다를까요?

D.L. Parnas의 "시스템을 모듈로 나눌 때 사용되는 기준"에서

"모듈화의 효과는 시스템을 모듈로 나눌 때 어떤 기준을 적용하는가에 달려 있다."

모듈의 정의는 시스템의 설계 및 의도에 따라서 결정되고, 그 기준은 상황에 따라서 다릅니다. 

모듈을 나누는 기준은 여러 가지가 될 수 있으나, 기준 간의 트레이드오프가 발생하므로 하나의 정답을 지정할 수 없습니다. 

다음은 소프트웨어 모듈화 관련 서적에 나오는 모듈을 설계할 때 나오는 기준을 소개하겠습니다.

1. 이해도

모듈 간의 관계에는 시스템의 전반적인 구조와 의도가 반영되어 있다. 누구든지 사전 지식 없이 코드를 봤을 때, 전반적인 구조와 기능을 바로 파악할 수 있어야 한다. 모듈 구조는 전체 시스템에서 특정 기능을 찾을 때 개발자에게 가이드 역할을 해야 한다.

2. 변경 용이성

요구 사항은 지속적으로 변경된다. 모듈을 사용하여 변경될 가능성이 있는 로직을 캡슐화하면 변경이 발생하였을 때 시스템에 미치는 영향이 줄어든다. 기능은 유사하지만 예상되는 변경 영역이 다른 두 시스템은 서로 다른 최적의 모듈 바운더리를 가질 수 있다.

3. 재사용성

모듈은 재사용이 가능한 이상적인 단위이다. 재사용성을 높이려면 모듈에서 제공하는 기능을 최대한 적게 가져야 하며 가능한 독립적이어야 한다. 재사용 가능한 모듈은 다양한 애플리케이션에서 여러 가지 방법으로 조합하여 사용될 수 있다.

4. 팀워크 

때로는 여러 팀이 공동 작업을 하는 경우에 서로의 작업 영역을 명확하게 하기 위해 모듈 바운더리를 사용한다. 작업 영역을 구분할 때 기술적인 고려 사항을 기준으로 구분하는 대신 모듈 바운더리를 기준으로 구분할 수 있다. 

소프트웨어 모듈화 서적에 나오는 모듈 바운더리, 모듈 정의 기준은 설계 품질, 변경 용이성, 재사용성, 개발 관리 단위 등입니다. 그런데, 소프트웨어와 하드웨어, 기구 복합 시스템인 경우에는 그 외에도 제품 사양 요인, 비사양 요인도 중요 정의 기준이 됩니다. 

모듈 정의 기준은 천편일률 적으로 정할 수 없지만, 최대한 많은 기준을 활용하는 것은 도움이 됩니다. 

그렇지만, 그 기준이 정확하게 수치로 표현이 되거나, 매번 같은 결과가 나오는 정답이 있는 성격의 것이 아닙니다. 

모듈 정의는 정답을 찾는 과정이 아닌 최적화의 과정입니다.

Image by Carola68 Die Welt ist bunt...... from Pixabay