반응형
신규 프로젝트를 하면서 화면 UI는 전체 컴포즈, 그리고 모듈은 멀티모듈로 작업했습니다.
기존의 프로젝트에서 멀티모듈을 제대로 활용하지 못하고 있었는데요.
그래서 이번 프로젝트는 멀티모듈을 잘 도입하고자 했습니다.
1. ✅ 왜 멀티 모듈을 도입했는가?
- 기존 문제점
- 단일 모듈 구조에서 빌드 시간이 너무 길어짐
- 기능이 많아지면서 의존성 관리가 어려움
- 코드 변경이 전체 앱에 영향을 미침 (작은 수정 → 전체 리빌드)
- 협업 중 충돌 발생 확률 증가
- 도입 목적
- 빌드 시간 단축
- 기능 별로 독립적인 개발 및 테스트 가능
- 책임 영역 명확화 (도메인 별로 나누기)
- 병렬 개발과 CI/CD 효율화
2. 🧩 모듈 구조 어떻게 나눴는가?
- 기본 구조 예시
app/ # 엔트리포인트 (presentation)
core/ # 공통 모듈
└ util/
└ design/
└ network/
feature/ # 기능 단위 모듈
└ login/
└ home/
└ player/
domain/ # usecase, model 등 비즈니스 로직
data/ # repository, API, DB의존성 방향
- app → feature-*, core-*
- feature-* → domain, core-*
- domain → data
- 단방향 의존성 유지 (Acyclic)
3. 🛠 도입 과정에서 부딪힌 문제들
- 의존성 순환 문제
- 잘못된 의존성 추가로 순환 참조 발생
- 해결: 모듈 간 관계 명확히 하고, interface로 의존성 역전
- 문제는 보통 한 모듈이 너무 커서 발생하는 것으로 모듈이 더 작게 나눠서 해결
- 모듈 나누는 기준 고민
- 화면 단위? 기능 단위? 팀 단위?
- 일단은 큰 기능 기준으로 나누고 리팩토링 중
- 공통적으로 쓸 수 있는 화면은 또 별도의 feature:화면 으로 모듈 생성 중
- 빌드 스크립트 중복
- 공통 build.gradle.kts 추출해서 build-logic으로 정리
4. ⏱ 도입 후 효과
- 빌드 시간 단축!! -> 병렬로 돌면서 엄청 빨리 끝남!!
- 커플링이 없는 코드를 개발하게 프로그램적으로 막힌 느낌!
5. ✨ 팁 & 배운 점
- 모듈은 작게 시작해서, 점차 쪼개도 됨 (Big Bang 금지)
- feature 모듈은 항상 interface 레이어를 만들고, 구현과 분리하면 나중에 DI나 테스트가 편해짐
- core는 쓰다 보면 덩어리가 커지기 쉬우니, 진짜 공통만 넣거나 아니면 진짜 더 쪼갤 수 있는 방법이 없는지 고민해봐야함
- Gradle의 configuration caching 적극 활용
반응형