모듈성의 정의
사전에서 모듈을 찾아보면, '복잡한 구조를 만드는 데 쓰이는 각각의 표준화한 부품이나 독립적인 단위'라고 나옵니다.
모듈성을 이용해 객체 지향 언어의 클래스나 함수형 언어의 함수가 될 만한 서로 연관된 코드를 노리적으로 묶습니다.
프로그래밍 언어는 대부분 모듈성 메커니즘을 제공하며, 개발자는 보통 연관된 코드를 함께 묶는 수단으로 모듈을 사용합니다.
결합도(커플링) 이란?
코드의 한 요소가 다른 것과 얼마나 강력하게 연결되어 있는지 또한 얼마나 의존적인지 나타내는 정도입니다. 프로그램의 요소가 결합도가 낮다는 것은 그것이 다른 요소들과 관계를 그다지 맺지 않은 상태를 의미합니다.
소프트웨어 공학의 전통적인 이론에 따르면, 유지보수성이 높은 소프트웨어는 프로그램의 각 요소들이 결합도는 낮게, 응집도는 높게 구성되어야 합니다.
우리는 아키텍처를 논할 때 클래스, 함수처럼 코드를 묶어 놓은 덩어리를 모듈성이라는 일반 용어로 나타냅니다. 이것은 논리적인 구분이지 물리적인 구분은 아닌데, 이 차이점이 굉장이 중요한 경우가 있습니다. 예를 들어 모놀리식 애플리케이션은 편의상 꽤 많은 클래스를 한 덩이로 묶어도 상관없지만, 아키텍처를 재구축할 때에는 이렇게 커플링된 구조가 모놀리스를 나누는 데 걸림돌이 됩니다. 따라서 모듈성은 특정 플랫폼에서 함축되어 있거나 불가피한 물리적인 분리와 다른 개념으로 바라보는 것이 좋습니다.
모놀리스란?
모놀리식 아키텍처는 단일 코드 베이스의 애플리케이션 입니다. 전체 애플리케이션은 단일 코드로 작성되어 단일 데이터베이스에 연결됩니다. 프로젝트 초기에는 코드 관리, 인지 오버헤드 및 배포의 용이성 면에서 모놀리스가 편리할 수 있습니다. 모놀리스 면에서 모든 것을 한꺼번에 릴리스 할 수 있기 때문입니다.
응집
응집은 한 모듈의 파트가 동일한 모듈 안에 얼마나 포함되어 있는지를 나타냅니다. 다시 말해, 모듈을 구성하는 파트가 서로 얼마나 연관되어 있는가, 하는 것입니다. 파트를 더 잘 쪼개려면 모듈 간 호출을 통해 파트를 묶어야 유용한 결과를 얻을 수 있기 때문입니다.
컴퓨터 과학자들은 응집도의 측정 범위를 정의했는데, 가장 좋은 것부터 나쁜 것 순으로 나열하겠습니다.
기능정 응집
모듈의 각 파트는 다른 파트와 연관되어 있고 기능상 꼭 필요한 모든 것이 모듈에 들어있습니다.
순차적 응집
두 모듈이, 한쪽이 데이터를 출력하면 다른 한쪽이 그것을 입력 받는 형태로 상호작용합니다.
소통적 응집
두 모듈이, 각자 정보에 따라 작동하고 어떤 출력을 내는 형태로 통신 체인을 형성합니다. 예를 들면, 데이터베이스에 레코드를 추가하면 그 정보에 따라 이메일이 만들어 지는 식입니다.
절차적 응집
두 모듈은 정해진 순서대로 실행되어야 합니다.
일시적 응집
모듈은 시점 의존성에 따라 연관됩니다. 예를 들어, 많은 시스템들이 시동할 때 그다지 관련이 없어 보이는 것들을 죽 초기화하는 경우가 많은데, 이런작업들이 일시적으로 응집됐다고 할 수 있습니다.
논리적 응집
모듈의 내부데이터는 기능적이 아니라, 논리적으로 연관되어 있습니다. 이를테면, 텍스트, 직렬화 객체, 스트림 형태로 받은 데이터를 변환하는 모듈이 그렇습니다. 서로 연관된 작업들이지만 하는 일은 전혀 다릅니다 .이럱 ㅗㅇ류의 응집의 좋은 예는 거의 모든 자바 프로젝트에서 사용되는 패키지에서 찾아볼 수 있습니다. 이 패키지에는 각기 다른 작업을 수행하는 정적 메서드가 많이 있지만 서로 연관성은 없습니다.
동시적 응집
같은 소스 파일에 모듈 구성요소가 들어 있지만 그 외에는 아무 연관성도 없습니다. 이는 가장 좋지 않은 형태의 응집입니다.
응집은 커플링보다는 덜 정확한 메트릭이므로 아키텍트 재량에 따라 측정된 모듈의 응집도는 다릅니다. 예를 들어, 모듈은 다음과 같이 정의했다고 합시다.
고객관리
고객 추가
고객 수정
고객 조회
고객 알림
고객 주문 조회
고객 주문 취소
마지막 두 항목은 고객 관리 모듈에 그냥 두거나, 다음과 같이 2개의 모듈로 나누어야 합니다.
고객 관리
고객 추가
고객 수정
고객 조회
고객 알림
주문 관리
고객 주문 조회
고객 주문 취소
어느쪽이 더 정확한 구성인지는 경우에 따라 다릅니다.
주문관리 작업이 2개뿐일까요? 만약 그렇다면 두 작업을 고객 관리로 다시 돌려 놓는게 더 더 합리적일 것 같습니다.
고객관리 모듈이 앞으로도 계속 확장될 예정이고 개발자가 작업을 추출할 일이 많을까요?
두 모듈이 작동하려면 반드시 주문 관리 모듈이 고객 정보를 많이 알고 있어야 할까요?
위와 같은 질문이 트레이드오프 분석입니다.
참고자료
소프트웨어 아키텍처 101 - 마크 리처즈, 닐 포드 저 한빛미디어
모놀리식 아키텍처 - https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith
커플링 - https://lazineer.tistory.com/93
