Dev/Android

[Android] Android Multi-Module

ragabys 2024. 7. 18. 19:19

 

 

서론

 

 

 

 

멀티 모듈이란?

 

 

안드로이드 멀티 모듈(Multi-module)은 대규모 프로젝트를 여러 개의 모듈로 나눠서 관리하는 방법이다.

 

 

모듈은 프로젝트의 독립적인 단위로, 독립적으로 빌드되고 테스트 될 수 있다.

 

 

멀티 모듈 왜 쓰나요?

 

 

멀티 모듈을 사용하는 이유는 크게 다음의 이유로 구분할 수 있다.

 

 

1. 코드 재사용성
 - 공통 기능을 라이브러리 모듈로 분리하여 여러 기능 모듈에서 재사용할 수 있음( 추후 사용될 Build - logic Module에서 자주 적용할 예정)

2. 빌드 시간 단축
- 모듈별로 독립적인 빌드가 가능하므로, 변경된 모듈만 빌드하여 전체 빌드 시간을 단축할 수 있음

3. 코드 가독성
- 각 모듈이 독립적으로 관리되므로 코드의 가독성이 향상됨

4. 유지 보수성
- 모듈별로 책임이 분리되므로, 특정 기능이나 모듈을 쉽게 수정할 수 있음

5. 테스트 용이성
- 각 모듈을 독립적으로 테스트할 수 있어 테스트 작성이 용이함

 

 

이와 같은 이유들로, 멀티 모듈을 많은 프로젝트들에서 활용하고 있다.

 

 

 

 

멀티 모듈 예시

 

 

모듈화를 하는 과정에 있어서 개개인의 차이는 있을 수 있지만, 그 중 2번의 프로젝트에서 크게 2가지 방식을 각각 차용하여 적용했다.

 

 

우선 각각의 방식을 설명하기에 앞서, 모듈을 어떻게 생성하는 지부터 설명하겠다.

 

 

Module 생성 방식1

 

 

우선 안드로이드 스튜디오 상단 File - New - New Module을 클릭하면 다음과 같은 창이 뜨게 된다.

 

 

 

 

위의 창이 나타나게 되면, Module name에 생성할 Module의 이름을 적고 Finish를 누르면 된다.

 

 

만약 Module 안에 하위 모듈을 생성하려 하는 경우, Module name에 상위모듈이름:하위모듈이름

 

 

이런 형태로 작성하면 된다.

 

 

그리고 모듈로 분리한 이후 다른 모듈에 포함되어야 할 경우

 

 

각각의 모듈단위 build.gradle.kts에서 다른 모듈에 대한 참조가 필요하며, 다음과 같은 형태로 추가되어야 한다.

 

 

dependencies {
    implementation(project(":presentation"))
    implementation(project(":domain"))
    implementation(project(":data"))
}

 

 

위 예시의 경우, 바로 아래에 나올 Clean Architecture layer 기반 모듈화를 했을 때 App Module의 build.gradle.kts 파일에 포함된 코드이다.

 

 

1. Clean Architecture Layer 모듈화

 

 

Clean Architecture Layer 모듈화 예시

 

 

크게 App, Data, Domain, Presentation(Feature) 모듈로 구분하는 방식이다.

 

 

App 모듈의 경우 어플리케이션의 진입점으로, 나머지 Data, Domain, Presentation 모듈을 포함하고 어플리케이션을 빌드하는 역할을 한다.

 

 

이 프로젝트의 경우 Hilt를 통한 DI 관리도 App 모듈에서 담당했다.

 

 

Data 모듈의 경우 데이터 소스 및 데이터 관리와 관련된 모든 것을 포함하는 역할을 하고,

 

 

내가 진행한 프로젝트에서는 API, Datasource, Data Model, Repository(Domain에 존재하는 Repository의 Implement, 구현체)

 

 

및 Util(token Encryption, Authenticator 등)을 포함했다.

 

 

Domain 모듈의 경우 어플리케이션의 비즈니스 로직과 관련된 모든 것을 포함하는 역할을 하며, UI나 데이터 소스에 의존하지 않는다.

 

 

Domain 모듈에서는 Repository(Data 모듈에서 구현될 interface), Usecase를 포함하도록 프로젝트를 설계했다.

 

 

Presentation 모듈의 경우 UI 및 사용자 인터페이스와 관련된 모든 것을 포함하는 역할을 하며,

 

 

각 Screen 및 Viewmodel, Event, State, Navigation 등을 포함하는 방식으로 설계했다.

 

 

프로젝트의 규모가 작을 경우 사용하기 적합하지만, 화면의 수가 늘어나

 

 

Presentation Module에 포함되는 내용이 많아질 경우에는 단위 테스트가 힘들어진다.

 

 

이를 고려하여 진행하는 방식이 바로 아래에 나올 Feature 중심으로 모듈화를 하는 방식이다.

 

 

2. Feature 중심 모듈화

 

 

Feature 기반 모듈화 예시

 

 

이 프로젝트에서는 App, Build-logic, Core, Feature 모듈로 구분하고

 

 

Core 모듈의 하위에 Base, Data, Designsystem, Domain, Model 모듈을,

 

 

Feature 모듈의 하위에는 각각의 화면 모듈을 포함하는 형식으로 구현했다.

 

 

참고로 Wearable까지 활용한 프로젝트 였기 때문에, Wear 모듈을 별도로 두고,  App Module에서 다음과 같은 형태로 의존성을 추가했다.

 

 

dependencies {
    wearApp(project(":wear"))
}

 

 

앞서 모듈 분리를 하는 이유 중 코드 재사용성을 높일 수 있다는 장점을 갖고 있다는 언급을 했는데,

 

 

이 부분이 가장 잘 드러나는 곳이 Build-logic Module이라고 볼 수 있다.

 

 

모듈을 하나 생성할 때마다 다음과 같이 여러개의 수많은 build.gradle.kts 파일들이 생겨나는데, 

 

 

수 많은 gradle

 

 

Feature 모듈에 포함된 각각의 화면들의 경우에도 같은 dependency들을 갖게 되고,

 

 

그렇다보니 중복되는 코드가 상당히 많아지게 된다.

 

 

이러한 dependency를 하나로 통합해서 각각에 맞는 기능만 가져다 쓸 수 있게 모아서 정리해두는 것을 plugin이라고 하는데,

 

 

해당 부분을 담당하는 모듈이 바로 Build-logic Module이다.

 

 

Plugin을 작성하는 방법에 대해서는 내용이 상당히 길어질 것이라, 다음 글에서 마저 이어가도록 하겠다.