사이드 프로젝트에 적용할 멀티 모듈 구조를 어떻게 설계할지 고민 중이다. 이전에 안드로이드 멀티 모듈 구조에 대해 정리하면서 크게 기능별 모듈 분리 방식과 Core 모듈 통합 방식으로 나눠볼 수 있다는 것을 알게 되었다. 이번 사이드 프로젝트에서는 어떤 구조로 시작하는 것이 효율적일지 정리해보려 한다.
현재 상황을 정리해보면 다음과 같은데,
이런 경우에 너무 과도한 모듈 세분화를 할 경우 오히려 속도만 늦추고, 관리할 게 많아져서 비효율적일 수 있다.
- 사이드 프로젝트
- 안드로이드 개발자 2명
- 작은 규모 앱
- 우선 MVP 개발 → 배포 예정
- 이후 유지보수 및 확장 가능성 있음
단순한 계층 분리만 필요할 경우
Core 모듈을 하나로 통합하되, 내부 디렉토리를 domain, data, network 등으로 명확히 분리하면 Gradle 수준에서는 구조를 단순하게 유지하면서도 설계 측면에서는 아키텍처 분리를 갖춘 효율적인 구조를 설계할 수 있다.
이는 현재와 같은 개발 상황에서 효과적인 선택지가 될 수 있다.
구조 예시
초기에는 Gradle 모듈 수를 줄여 개발 속도를 높이고 관리 부담을 줄인다.
내부 디렉토리 구조는 기술 계층(domain, data 등)으로 나누어 아키텍처 기준을 세운다.
이렇게 구조를 설계하면 추후에 리팩토링이 단순한 분리 작업으로 이어질 수 있다.
:app
:core/
├─ domain/ // usecase, entity 등
├─ data/ // repository, datasource 등
├─ network/ // retrofit, api client 등
└─ ui/ // 공통 컴포넌트, theme 등
:feature-login
:feature-home위의 구조에서 나중에 앱이 커지면 다음과 같이 분리가 가능하여 확장 가능한 구조로 볼 수 있다.
디렉토리로 관리하던 기술 계층을 독립 Gradle 모듈로 분리한다.
기능과 계층이 완전히 분리되어 빌드 성능, 유지보수성 모두 확보 가능하다.
:app
:core-domain
:core-data
:core-network
:core-ui
:feature-login
:feature-home장점 요약
| 구조 | 장점 |
|---|---|
| core 내부 디렉토리 분리 | 초기 개발 속도 빠르고 관리 간편 |
| 필요 시 Gradle 모듈로 분리 가능 | 앱 확장 시 유연하게 대응 가능 |
| feature 별도 분리 | 화면 수 증가에도 안정적인 구조 유지 |
feature 모듈은 왜 분리할까?
작은 앱이라도 core는 통합해도 괜찮지만 feature는 기능(화면)에 따라 분리하는 것이 유지보수성과 확장성 측면에서 유리하다.
- 기능 단위로 관심사 분리
기능(화면)마다 ViewModel, State, UI가 따로 존재하므로 각자 독립적인 feature 모듈로 관리하는 게 구조적으로 더 깔끔함- 협업과 테스트 유리
다른 개발자가 다른 feature 작업 가능하며 각 feature만 독립적으로 테스트 가능함- 확장에 유리
추후 기능 추가하거나 제거할 때 모듈 단위로 손대면 됨
Clean Architecture 기반일 경우
멀티 모듈 구조를 설계할 때, 단순한 계층 분리만 필요하다면 core 모듈에 통합해도 무방하다. 하지만 Clean Architecture를 기반으로 한다면, domain과 data를 core에서 분리해 계층별 책임을 명확히 나누는 것이 더 적절하며, 이는 유지보수나 테스트 측면에서도 훨씬 효과적이다.
구조 예시
:app :core ├─ ui // 공통 UI 요소 ├─ network // API 통신 관련 └─ database // Room 등 로컬 DB 관련 :domain ├─ model // Entity ├─ usecase // 비즈니스 로직 └─ repository // 인터페이스 정의 :data ├─ repositoryImpl // 인터페이스 구현체 └─ datasource // network, database를 통한 데이터 소스 구현 :feature-login :feature-home
그래서 어떻게 설계하는게 좋을까?
Clean Architecture를 기반으로 설계할 예정이기에 core 모듈은 유지하되 domain과 data는 각각 독립된 모듈로 분리하는 것이 적절하다. Gradle 수준에서는 모듈 수를 과도하게 늘리지 않으면서도, 설계 측면에서는 계층별 책임을 명확히 하고 아키텍처의 기반을 탄탄히 다질 수 있다. 기능별 feature는 모듈로 분리해 화면이 많아져도 구조를 깔끔하게 유지할 수 있으며, 테스트나 확장에도 유리하다.따라서 지금과 같은 상황에서는 이러한 Clean Architecture 기반의 확장 가능한 구조가 가장 현실적이고 효과적인 선택이 될 수 있다.
