Android 프로젝트가 점점 커질수록 코드 관리, 빌드 속도, 팀 협업 등 다양한 문제가 발생하기 시작합니다. 이 때, 해결책으로 많이 선택되는 구조가 바로 Multi-Module 아키텍처입니다.
이번 글에서는 멀티 모듈이 무엇인지, 왜 사용해야 하는지, 어떻게 구성하면 좋은지까지 전부 정리해보겠습니다.
🚀 멀티 모듈(Multi-Module)이란?
멀티 모듈이란 하나의 Android 프로젝트를 여러 개의 독립된 모듈로 나누어 구성하는 아키텍처 방식입니다. 각 모듈은 하나의 "프로젝트 단위"처럼 동작하며, 자신만의 역할과 책임을 가집니다. 즉, 큰 앱을 여러 조각으로 나누어 더 효율적으로 관리하는 방식입니다.
모듈의 종류
- Application 모듈: 앱의 진입점이 되는 모듈로, 최종 APK를 생성합니다.
- Library 모듈: 다른 모듈에서 재사용할 수 있는 독립적인 기능 단위입니다.
각 모듈은 자체적인 build.gradle 파일을 가지며, 필요한 의존성만 선언하여 사용할 수 있습니다.
🧠 왜 멀티 모듈이 필요할까?
Android 앱을 단일 모듈로 개발하면 다음과 같은 문제가 발생합니다.
- 패키지가 너무 많아 구조가 복잡해지고 원하는 파일을 찾기 어려움
- 작은 수정에도 전체 프로젝트를 빌드해야 해서 빌드 속도가 점점 느려짐
- 같은 파일을 여러 명이 수정하면서 Merge Conflict가 빈번하게 발생함
- 비슷한 로직이 여기저기 중복되어 존재해 공통 코드 재사용이 어려움
- 어떤 클래스가 어디에 의존하는지 파악이 불가능해 유지보수가 어려워짐
규모가 커질수록 이러한 문제는 더욱 심각해지며, 결국 프로젝트의 속도와 안정성을 방해하게 됩니다.
⭐ 멀티 모듈의 장점
1. 빌드 속도 향상
변경된 모듈만 다시 빌드하므로, 전체 빌드 시간이 눈에 띄게 줄어듭니다. Gradle의 증분 빌드(Incremental Build) 기능과 결합하면 개발 생산성이 크게 향상됩니다.
- 단일 모듈: UI 하나만 수정해도 전체 프로젝트 빌드 (3~5분)
- 멀티 모듈: presentation 모듈만 빌드 (30초~1분)
2. 유지보수성 증가
기능과 레이어가 분리되어 있어 문제 발생 시 어느 모듈을 수정해야 할지 명확합니다. 코드 수정 범위가 한정되어 Side Effect를 최소화할 수 있습니다.
3. 팀 협업 최적화
여러 개발자가 서로 다른 모듈을 작업하면서 충돌을 최소화할 수 있습니다.
- A 개발자 → :feature:home 모듈
- B 개발자 → :feature:profile 모듈
- C 개발자 → :core:data 모듈
각자 독립된 모듈에서 작업하므로 Git Conflict가 거의 발생하지 않습니다.
4. 재사용성 증가
여러 화면에서 반복적으로 사용하는 로직을 별도 모듈로 분리하여 공통으로 사용 가능합니다. 예를 들어, 네트워크 레이어나 인증 로직을 별도 모듈로 만들면 여러 Feature에서 쉽게 재사용할 수 있습니다.
5. 구조적 안전성 증가
모듈의 접근 범위를 적절히 제한할 수 있어 의존성 설계가 명확해지고 아키텍처 자체가 단단해집니다. internal 키워드를 활용하면 모듈 외부로 노출하지 않아야 할 클래스를 감출 수 있습니다.
6. 테스트 용이성
각 모듈을 독립적으로 테스트할 수 있어 단위 테스트 작성이 쉬워집니다. 특정 모듈만 분리하여 테스트 환경을 구성할 수 있습니다.
📦 멀티 모듈 기본 구조 (presentation / domain / data)
멀티 모듈은 보통 클린 아키텍처(Clean Architecture) 기반으로 구성합니다. 가장 기본적인 3-Layer 구조는 다음과 같습니다.
1. Presentation 모듈
UI 및 화면(View)과 관련된 요소를 담당하는 계층입니다. 사용자와의 상호작용을 처리하고, Domain Layer의 UseCase를 호출하여 비즈니스 로직을 실행합니다. 포함 요소는 다음과 같습니다.
- Activity, Fragment
- ViewModel
- Compose UI 컴포넌트
- UI State, UI Event
- Screen/Navigation 로직
2. Domain 모듈
프로젝트의 가장 중요한 비즈니스 로직을 담당하는 계층입니다. 플랫폼에 독립적인 순수한 Kotlin 코드로만 구성되며, Android Framework에 의존하지 않습니다. 이를 통해 테스트가 용이하고 재사용성이 높아집니다. 특징으로는 Android SDK 의존성이 없고, 가장 변경이 적은 계층입니다. 또한 Domain 모듈은 다른 모듈에 의존하지 않는 가장 독립적인 모듈입니다. 포함 요소는 다음과 같습니다.
- UseCase (Interactor)
- Entity (도메인 모델)
- Repository Interface (추상화)
3. Data 모듈
데이터를 실제로 가져오는 계층입니다. DB, 네트워크, 캐시 등 모든 데이터 소스의 구체 구현이 존재합니다. Domain Layer에서 정의한 Repository Interface를 실제로 구현하며, 데이터의 출처(네트워크, 로컬 DB 등)를 관리합니다. 포함 요소는 다음과 같습니다.
- Repository 구현체 (RepositoryImpl)
- DataSource (Remote, Local)
- API Service (Retrofit Interface)
- DAO (Room Database)
- DTO (Data Transfer Object)
- Mapper (DTO ↔ Entity 변환)
🔗 모듈 간 의존성 규칙
모듈 간 정상적인 의존성 흐름은 다음과 같습니다.
Presentation → Domain ← Data
- Presentation → Domain: UI는 UseCase를 통해 비즈니스 로직을 호출
- Data → Domain: Data는 Domain의 Repository 인터페이스를 구현
- Domain은 Presentation/Data에 의존하지 않음 (가장 독립적 계층)
이 구조를 지키면 UI/Business/Data 로직이 확실히 분리되어 유지보수성이 향상됩니다. Domain이 구체적인 구현이 아닌 추상화(Interface)에만 의존하므로, Data Layer의 구현 변경이 Domain에 영향을 주지 않습니다.
🎯 결론
멀티 모듈 구조는 반드시 presentation / domain / data로 나눠야만 효과가 생기는 것은 아닙니다.
핵심은 프로젝트를 역할별로 분리하여 독립성을 높이고, 빌드 효율과 유지보수성을 확보하는 것입니다.
presentation / domain / data 구조는 가장 많이 사용되는 기본 형태일 뿐이며, 상황에 따라 feature 모듈, core 모듈, design-system 모듈 등으로 확장할 수도 있습니다.
즉, 멀티 모듈의 진짜 장점은 다음과 같습니다.
- 프로젝트 규모가 커져도 구조가 유지됨
- 빌드 속도가 빨라짐
- 책임이 분리되어 유지보수와 확장성이 향상됨
- 코드 재사용성이 높아짐
- 팀 협업 충돌이 줄어듦
- 테스트 가능성이 높아짐
3개의 레이어 구조는 멀티 모듈의 출발점일 뿐이며, 앱이 커짐에 따라 자유롭게 확장해 나갈 수 있는 유연한 구조입니다. 멀티 모듈을 도입하는 순간, 프로젝트는 더 견고하고 관리하기 좋은 아키텍처로 발전하게 됩니다.
