멀티모듈 알아보기 (1) - 멀티 모듈이란?

멀티 모듈?

최근에 JetPack Compose를 공부하면서 개인 프로젝트를 진행해보기로 하였다.

이왕 시작하는 거 화두로 떠오르고 있는 멀티모듈을 도입하여 시작해보면 좋을 것 같다고 생각하여 나름대로 공부하고 정리해 본 내용을 기록해보기로 하였다.

일반적인 모듈화 패턴  |  Android Developers

일단 시작에 앞서 일반적인 모듈화 패턴에 대해 먼저 공부해보았다.

 

 

모듈화의 장점

다음 내용은 nowinandroid의 모듈화 내용에 대한 문서를 변역한 글이다.

 

확장성 - 단단히 결합된 코드베이스에서 단일 변경은 일련의 변경을 유발할 수 있다. 적절하게 모듈화된 프로젝트는 관심사 분리 원칙을 채택하며, 이를 통해 기여자에게 더 많은 자율권을 부여하는 동시에 아키텍처 패턴을 적용한다.

병렬 작업 가능 - 모듈화는 버전 제어 충돌을 줄이는 데 도움이 되며 대규모 팀의 개발자에게는 병렬 작업의 효율성이 높아니다.

소유권 - 모듈에는 코드와 테스트 유지 관리, 버그 수정, 변경 사항 검토를 담당하는 전담 소유자가 있을 수 있다.

캡슐화 - 격리된 코드는 읽고, 이해하고, 테스트하고, 유지 관리하기가 더 쉽다.

빌드 시간 단축 - Gradle의 병렬 및 증분 빌드를 활용하면 빌드 시간을 줄일 수 있다.

동적 제공 - 모듈화는 앱의 특정 기능을 조건부로 제공하거나 수요에 따라 다운로드할 수 있도록 하는 Play Feature Delivery 의 필수 사항이다.

재사용성 - 적절한 모듈화를 통해 동일한 기반에서 다양한 플랫폼에 걸쳐 코드 공유와 여러 앱을 빌드할 수 있는 기회가 생긴다.

 

 

이중 모듈화의 가장 큰 목표는 낮은 결합도와 높은 응집도에 있다.

위와 같이 설계하면 코드의 가독성과 유지보수가 쉬워지고, 관심사 분리에 용이하다.

 

 

 

모듈화의 단점

다음 내용은 nowinandroid의 모듈화 내용에 대한 문서를 변역한 글이다.

 

모듈이 너무 많음 - 각 모듈에는 빌드 구성의 복잡성 증가라는 형태로 발생하는 오버헤드가 있습니다. 이로 인해 Gradle 동기화 시간이 증가하고 지속적인 유지 관리 비용이 발생할 수 있습니다. 또한 모듈을 더 추가하면 단일 모놀리식 모듈과 비교할 때 프로젝트의 Gradle 설정의 복잡성이 증가한다. 이는 컨벤션 플러그인을 사용하여 재사용 가능하고 구성 가능한 빌드 구성을 유형 안전한 Kotlin 코드로 추출하여 완화할 수 있습니다.

모듈이 충분하지 않음 - 반대로 모듈이 적고 크고 밀접하게 결합되어 있다면 또 다른 모놀리스가 생깁니다. 즉, 모듈화의 이점을 일부 잃게 된다. 모듈이 부풀어 오르고 단일하고 잘 정의된 목적이 없다면 분할을 고려해야 한다.

너무 복잡함 - 사실, 프로젝트를 모듈화하는 것이 항상 합리적인 것은 아닙니다. 지배적인 요소는 코드베이스의 크기와 상대적 복잡성입니다. 프로젝트가 특정 임계값을 넘어 성장하지 않을 것으로 예상되면 확장성과 빌드 시간 이득이 적용되지 않는다.

 

중요한 것은, 모듈의 크기가 많아질수록 복잡한 프로젝트가 되고, 특정 임계값을 넘지 않는 이상 이점으로 판단되는 확장성과 빌드 시간은 더이상 이점이 아니게 되며, 프로젝트 설계에 많은 시간을 써야한다는 점이 있다.

 

 

 

모듈화 전략

기본적으로 모듈화의 전략은 공식 문서에서도 추천하는 nowinandroid의 깃허브를 참조하였다.

nowinandroid/docs/ModularizationLearningJourney.md at main · android/nowinandroid

 

 

아래 내용은 nowinandroid에서 발췌한 내용이다.

 

 app 모듈 - 나머지 코드베이스를 바인딩하는 앱 수준 및 스캐폴딩 클래스가 포함되어 있습니다(예: MainActivity, NiaApp앱 수준 제어 탐색). 이에 대한 좋은 예는 를 통한 탐색 설정 NiaNavHost과 를 통한 하단 탐색 모음 설정 입니다 TopLevelDestination. 모듈은 모든 모듈과 필수 모듈 app에 종속됩니다 .featurecore

feature:모듈 - 앱에서 단일 책임을 처리하도록 범위가 지정된 기능별 모듈입니다. 이러한 모듈은 테스트 또는 기타 플레이버 앱을 포함하여 필요할 때 모든 앱에서 재사용할 수 있지만 여전히 분리되고 고립된 상태를 유지합니다. 클래스가 한 feature 모듈에만 필요한 경우 해당 모듈 내에 남아 있어야 합니다. 그렇지 않은 경우 적절한 core모듈로 추출해야 합니다. feature모듈은 다른 기능 모듈에 종속성이 없어야 합니다. core필요한 모듈에만 종속됩니다.

core:모듈 - 앱의 다른 모듈 간에 공유해야 하는 보조 코드와 특정 종속성을 포함하는 공통 라이브러리 모듈. 이러한 모듈은 다른 핵심 모듈에 의존할 수 있지만 기능이나 앱 모듈에 의존해서는 안 됩니다.

다양한 모듈(예: sync, 모듈 benchmark) test과 app-nia-catalog디자인 시스템을 빠르게 표시해주는 카탈로그 앱이 있습니다.

 

구조를 보면 크게 app, feature, core 모듈이 베이스가 된다는 것을 알 수 있다.

이름	책임	주요 수업과 좋은 예
app	앱이 올바르게 기능하는 데 필요한 모든 것을 하나로 모읍니다. 여기에는 UI 스캐폴딩과 탐색이 포함됩니다.	NiaApp, MainActivity 앱 수준에서 제어되는 탐색NiaNavHost, NiaAppState, TopLevelDestination
feature:1, feature:2 ...	특정 기능 또는 사용자 여정과 관련된 기능입니다. 일반적으로 다른 모듈에서 데이터를 읽는 UI 구성 요소와 ViewModel을 포함합니다. 예를 들어 다음과 같습니다. feature:topicTopicScreen에 주제에 대한 정보를 표시합니다. feature:foryou사용자의 뉴스 피드와 첫 번째 실행 시의 온보딩을 For You 화면에 표시합니다.	TopicScreen TopicViewModel
core:data	다양한 기능에서 공유되는 여러 소스에서 앱 데이터를 가져옵니다.	TopicsRepository
core:designsystem	Core UI 구성 요소(대부분은 사용자 정의된 Material 3 구성 요소), 앱 테마 및 아이콘을 포함하는 디자인 시스템입니다. 디자인 시스템은 app-nia-catalog실행 구성을 실행하여 볼 수 있습니다.	NiaIcons NiaButton NiaTheme
core:ui	뉴스 피드와 같은 기능 모듈에서 사용하는 복합 UI 구성 요소 및 리소스입니다. designsystem모듈과 달리 뉴스 리소스와 같이 모델을 렌더링하기 때문에 데이터 계층에 종속됩니다.	NewsFeed NewsResourceCardExpanded
core:common	모듈 간에 공유되는 공통 클래스.	NiaDispatchers Result
core:network	원격 데이터 소스에 대한 네트워크 요청을 하고 응답을 처리합니다.	RetrofitNiaNetworkApi
core:testing	종속성, 저장소 및 유틸 클래스 테스트.	NiaTestRunner TestDispatcherRule
core:datastore	DataStore를 사용하여 영구 데이터를 저장합니다.	NiaPreferences UserPreferencesSerializer
core:database	Room을 사용한 로컬 데이터베이스 저장.	NiaDatabase DatabaseMigrations Dao수업
core:model	앱 전체에서 사용되는 모델 클래스입니다.	Topic Episode NewsResource

 

위 내용을 바탕으로 초기 프로젝트에 적용해 볼 모듈은 다음과 같다.

 

1. 핵심 모듈 구조

• app: 메인 애플리케이션 모듈
• core: 공통 유틸리티, 확장 함수
• domain: 비즈니스 로직, 엔티티, 유스케이스
• data: 데이터 소스, 레포지토리
• feature: 화면별 기능 모듈

 

2. 각 모듈의 역할

• app:
  • 전체 앱 설정
  • 앱 진입점
  • 네비게이션 설정
• core:
  • 공통 유틸리티
  • 기본 확장 함수
  • 기본 인터페이스
• domain:
  • 데이터 모델
  • 비즈니스 로직
  • 유스케이스 정의
• data:
  • 네트워크 데이터 소스
  • 로컬 데이터베이스
  • 레포지토리 구현체
• feature:
  • UI 컴포넌트
  • 뷰모델
  • 화면별 로직

 

3. 장점

• 관심사 분리
• 모듈별 독립성
• 재사용성 증가
• 유지보수 용이

 

4. 의존성

app → feature, domain, data, core feature → domain, core data → domain, core domain: 다른 모듈 의존 X