쓸모 있는 모듈러 디자인
커플링 (Coupling)은 소프트웨어 설계 품질을 평가하는 요소 중 하나입니다. 소프트웨어 기능 블록 간의 커플링이 크면 소프트웨어 설계 품질이 떨어지는 것으로, 커플링이 작으면 소프트웨어 설계 품질이 높은 것으로 평가합니다.
그렇지만, 하나의 시스템을 구성하는 기능 블록은 커플링을 제로로 만들 순 없습니다. 서로 협업하고, 연결되어 작동해야만 시스템의 목적을 달성할 수 있다면 거기서 발생하는 커플링은 필연적인 것으로 볼 수밖에 없습니다.
모듈러 디자인에서도 모듈을 정의할 때 모듈 간의 의존 관계, 즉 커플링을 최소화하라고 합니다.
동일하게 모듈러 디자인에서도 모듈들이 꼭 필요한 커플링이 없는 상황에서는 하나의 시스템으로 시스템의 목적을 달성할 수 없기 때문에 커플링을 없애라고 하지 않고, 최소화하라고 가이드합니다.
두 가지를 서로 나눠서 설명했지만, 동일합니다.
특정 목적에 따라서 모듈 간의, 또는 기능 블록 간의 커플링을 낮추는 노력과 동시에 시스템의 목적을 위해서는 서로 간의 커플링을 용인해야만 합니다.
그래서, 모듈을 정의하는 과정, 모듈 간의 커플링 수준을 정하는 과정은 정답을 구할 수 있는 수학 문제가 아니라, 최적해를 찾는 최적화 문제입니다.
최적화 문제를 풀기 위해서는 모듈러 디자인 관점에서는 소프트웨어 커플링이 어떤 특징을 갖는지 알아야만 합니다.
그렇다면, 모듈러 디자인 관점에서 소프트웨어 커플링은 어떻게 다를까요?
첫 번째, 소프트웨어 커플링의 대상은 계획되어 있어야 합니다.
두 개 이상의 소프트웨어 기능 블록이나 모듈들의 커플링은 사전에 계획이 되어 있어야 합니다. 즉, 갑작스러운 커플링이 있어선 안됩니다. 계획이 되어 있다는 것은 불필요한 연결 관계를 갖지 않는다는 것을 의미하고, 특정 모듈이나 기능 블록의 변화에 대해서도 계획에 따라서 대응할 수 있음을 의미합니다.
두 번째, 소프트웨어 커플링의 종류와 형태는 가장 단순해야 합니다.
두 개 이상의 소프트웨어 기능 블록이나 모듈들의 커플링의 종류가 많거나 복잡하면 서로 독립적으로 설계/개발을 하거나 변화에 대응할 수가 없습니다. 서로 독립적으로 운영하고, 최소한의 리소스만으로 상호 간의 변화에 대응하기 위해서는 연결 관계가 복잡하지 않아야 합니다.
세 번째, 소프트웨어 커플링의 방식은 사전에 정의되어야 합니다.
앞에서 소프트웨어 기능 블록, 모듈들 간의 커플링의 대상이 계획되어 있다고 한다면, 그렇게 계획된 연결 관계는 그 방식이 미리 정의되어 있어야 합니다. 미리 정의된 연결관계에 따라서 상호 간의 구현을 진행해야만 연결되는 상대방의 변화에 의존하지 않게 됩니다.
마지막, 소프트웨어 커플링의 결과는 상호 간의 약속으로 표현해야 합니다.
블록 간, 모듈 간의 커플링은 약속으로 표현해야 합니다. 그것은 설계 규칙일 수도 있고, 제약 조건일 수도 있습니다. 이렇게 표현하지 않으면 사람이 바뀜에 따라서 상황이 바뀜에 따라서 지켜지지 않게 됩니다.
이렇게 만들어진 소프트웨어 커플링의 결과물은 모듈 간의 인터페이스가 되고, 위 활동을 한 마디로 표준화라고 하여 표준 인터페이스라고 부릅니다.
Image by Markus Spiske from Pixabay