모듈화의 장단점
앱을 모듈화 하는 과정은 정말 어렵습니다. 처음부터 멀티 모듈로 설계된 앱이라면 모를까 이미 만들어져 있는 프로그램 그것도 어느정도 규모가 있는 프로그램이라면 프로젝트 구조의 근간을 바꾸는 모듈화가 결코 쉽게 느껴질 수 없을 것입니다. 그렇다면 이미 잘 돌아가고 있는 서비스를 여러개의 모듈로 쪼개야만 할까요? 정확한 판단을 위해 모듈화를 결정하면 어떤일이 벌어질지 짚어보겠습니다.
장점
생산성 증가
모듈들의 책임과 경계가 명확하게 나뉘어져 있을 수록 생산성이 커지는 효과를 기대할 수 있습니다. 어플리케이션의 사이즈가 커질 수록 여러사람이 협력하여 하나의 앱을 만들어 가게 되는데, monolithic한 구조에서는 동료들의 작업 결과물이 충돌을 일으킬 수 있고, 선행되어야 하는 작업으로 인해 병목이 발생할 수도 있습니다. 하지만 멀티 모듈의 구조가 잘 잡혀있다면 정해진 인터페이스안에서 개발함으로써 충돌과 병목을 방지할 수 있습니다.
확장엔 열려있고, 수정엔 닫혀있다
사실 모듈화의 많은 장점들은 OOP적인 관점에서 봤을 때 좋은 코드 구조가 가져다 주는 장점과 겹쳐있습니다. 프로그램을 논리적으로 분리시키는 것이 객체의 책임을 분리시키는 것과 크게 다르지 않기 때문이죠. 따라서 SRP, OCP등을 모듈화에도 동일하게 적용시킬 수 있다고 생각합니다.
모듈의 책임과 경계가 명확하고 모듈간의 의존성이 느슨하다면, 수정사항이 생겼을 때 필요한 모듈만을 수정하도록 관리포인트를 최소화 할 수 있고, 모듈끼리는 추상화된 형태로만 의존하기 때문에 해당 인터페이스를 구현하는 다른 구현체로 모듈을 교체하기도 쉬워집니다.
구조를 파악하기 쉽다
모듈과 의존관계만으로 프로젝트의 전체적인 구조를 파악하기가 쉬워집니다. 게다가 구조 파악이 쉬워지니 디버깅 포인트를 찾기도 쉽습니다.
테스트가 용이하다
우리가 클래스의 책임을 최소화 하고 coupling을 제거하는 이유중 하나는 testability를 높이기 위함입니다. 이는 모듈에도 동일하게 적용되어 각 모듈의 테스트를 용이하게 만들어 줍니다.
재사용성 증가
모듈화가 잘되어 있다면 프로그램 전체의 코드 재사용성이 크게 증가합니다. 단순히 OOP에서 클래스를 재사용하는 수준이 아닌, 필요한 모듈들을 조합하여 데모앱을 만들어 볼 수 도 있습니다.
빌드타임 감소
incremental build 와 clean build 시간 모두를 감소시킬 수 있습니다. 모듈을 잘게 쪼개어 놓는 다면 incremental build과정에서 수정한 모듈만 빌드하게 되기 때문에 incremental build 시간을 획기적으로 줄일 수 있습니다.
clean build 시간을 줄이는 방법에는 크게 세 가지가 있다고 생각하는데, 먼저는 병렬빌드를 최대한 활용하는 것입니다. 앱이 여려개의 모듈로 쪼개지면 모듈 각각을 병렬적으로 빌드할 수 있게 되고, 이들의 의존관계를 잘 설정한다면 병렬빌드를 효율적으로 활용 할 수 있게 됩니다. 모듈의 빌드를 바이너리 형태로 캐싱함으로써 빌드를 건너뛸수도 있고, 개발하고 있는 기능의 피쳐앱 타겟을 만들어 빌드의 양 자체를 대폭 줄일 수도 있습니다.
단점
모듈화를 위한 리소스
앞서 이야기 했듯이 이미 만들어져 있는 프로그램은 여러개의 모듈로 쪼개는 일은 정말 많은 고민과 노력을 필요로 합니다. 지금까지 살펴본 모듈화의 장점을 얻기 위해선 모듈의 경계에 대한 많은 고민을 필요로 하고, 프로젝트의 구조 자체를 바꾸는 것이기에 모든 구성원들의 동의와 노력이 필요로 합니다.
관리포인트 증가
모듈화를 했을 때 향상되는 유지보수성에 대해 이야기 했지만 반면에 관리포인트가 증가하는 면도 있습니다. 프로젝트 유지보수를 위해 모듈 레벨의 관리가 추가로 필요해 지는 것입니다. 특정 모듈에 대한 의존성이 많아지면 이를 어떻게 분산시킬지, 모듈이 커지게되면 이를 또 어떻게 나눌지 등등에 대한 고민이 추가로 필요하게 됩니다.