Android 구조 개편기 기본구조 -> MVVM → 클린아키텍처 + 멀티모듈 → Compose + MVI 현업 적용기 (2부 클린아키텍처)

안녕하세요, 구구집사입니다.

시작하며

클린 아키텍처 도입기 — 구조적 고민에서 확장성까지
"현업에서의 클린 아키텍처 도입은 어떤 의미였는지"
"그리고 실제로 어떤 고민과 시행착오가 있었는지" 담아봅니다.

 

1. 왜 클린 아키텍처를 적용하려고 했는가?

출처 https://scaleyourapp.com/spaghetti-code-explained/

 

• 초반에는 단일 액티비티 구조에서 출발이 되어 1부의 MVVM 구조로 진행 되고 있었으나 문제가 발생하였습니다.
  • 기존 1편에서의 View , ViewModel , Repostiroy 를 나누기는 하였으나 프로젝트의 규모가 크다보니
    결국에는 ViewModel 이 무거워지는 형태가 발생 
  • 단순 MVVM + Repository 분리만으로는 부족
    
    
• 또한 팀원이 늘어나면서 문제가 발생했습니다.
  • 본인 스타일대로 코드를 작성하는 상황이 늘어남.
  • 코드 일관성 붕괴 → 유지보수와 확장성 문제 가시화.
  • 새로운 기능 추가/버그 수정 시 사이드 이펙트 발생.

 결국 "규모가 커진 팀 개발"에는 강력한 구조화가 필요하다고 판단했습니다.

 

 

2. 클린 아키텍처 구조를 어떻게 잡을 것인가?

 

MVVM 구조로 개발을 진행하면서 시간이 지날수록 ViewModel이 점점 무거워지는 문제가 발생하기 시작했습니다.
처음에는 단순히 화면 상태를 관리하고 네트워크 요청을 보내는 정도였던 ViewModel이,
비즈니스 로직과 데이터 변환 처리까지 모두 맡다 보니 자연스럽게 덩치가 커지고 복잡해졌습니다.

이런 상황을 개선하기 위해 ViewModel의 역할을 명확하게 나누는 것을 목표로 삼았습니다.

• ViewModel은 "화면 상태 관리" 와 "UI 이벤트 처리" 에만 집중하게 하고,
• 복잡한 비즈니스 로직은 UseCase(도메인 계층)로 분리하여 책임을 분산시켰습니다.
• 데이터 가져오기나 저장 같은 세부 구현은 Repository로 이동시켜 ViewModel이 직접 데이터 소스에 접근하지 않도록 했습니다.

이를 통해 구조를 클린 아키텍처 스타일로 정비하기 시작했습니다.

즉, ViewModel 하나에서 모든 것을 처리하는 구조 → ViewModel, UseCase, Repository 각각이 명확한 책임을 갖는 구조로 전환하는 것이 이번 구조 개편의 핵심 목표였습니다.

 

출처-구구집사

 

저희 프로젝트의 대략적인 클린아키텍처의 구조도 입니다.

어디서나 쉽게 볼수있는 구조도로 잡았습니다.

 

3. 구조를 잡다 보니, 멀티모듈의 필요성까지

• 클린 아키텍처를 적용하면서 기능별로 역할을 나누는 데는 성공했지만,
  여전히 프로젝트는 하나의 단일 모듈 안에서 패키지 분리만 되어 있는 상태였습니다.
  그러다 보니 다음과 같은 고민이 생겼습니다.
  
  • 도메인 계층은 외부에 의존하지 않아야 한다는 클린 아키텍처의 원칙을 완벽히 지키기 어렵다.
  • 기능은 나눴지만 여전히 모든 코드가 같은 모듈에 있다 보니 진정한 의미의 독립성과 책임 분리가 부족하다.

'독립성 강화'와 '책임 명확화'를 위해,
저희는 멀티모듈 구조로 전환하기로 결정했습니다.

그래서, 모듈을 다음과 같이 분리했습니다.

• Domain 모듈 : 비즈니스 로직만 담당, 다른 모듈에 의존하지 않음.
• Data 모듈 : Repository 구현, 네트워크/DB 등 외부 데이터 처리 담당.
• Presenter 모듈 : ViewModel 및 UI 처리.
• App 모듈 : 각 모듈을 조립하는 역할 , DI 관리 , Manifest 관리

출처 - 구구집사

 

왜 App 모듈에서 DI를 담당하는가?

전체 프로젝트의 DI(의존성 주입) 설정과 관리를 담당하도록 설계했습니다.
그 이유는,
각 기능 모듈에 DI 설정을 분산시킬 경우 관리가 복잡해지고 일관성이 떨어질 수 있기 때문입니다.

DI는 프로젝트 전반에 영향을 미치는 핵심 인프라이기 때문에,
App 모듈 한 곳에 집중하여 제어함으로써 관리 효율성을 높이고, 전체 구조를 보다 명확하고 일관되게 유지할 수 있도록 설계 방향을 잡았습니다.

 

멀티모듈로 전환하면서 얻은 효과

• 각 계층이 물리적으로도 분리되어 진정한 독립성 확보
• 기능별 변경 범위 최소화로 유지보수성 대폭 향상
• 팀원별로 역할을 나누어 병렬 개발이 가능해짐

 

4. 클린 아키텍처 + 멀티모듈의 러닝커브

출처 - https://kim-dragon.tistory.com/235

 

기존 팀원들은 단일 모듈 기반과 Activity/Fragment 중심 개발에 익숙한 상황이었습니다.
그러나 클린 아키텍처와 모듈화를 도입하면서,

• 레이어 별 역할과 책임 구분
• DI 흐름과 방향성 준수
• 모듈 간 통신을 위한 인터페이스(Repository Interface) 개념

등 새로운 패러다임을 익혀야 했기에 초기에는 분명 러닝커브가 존재했습니다.

하지만 이러한 어려움을 극복하기 위해,
저는 직접 스터디를 주도하고,
코드 곳곳에 설명 주석을 추가하는 방식으로 팀원들과 적극적으로 지식을 공유했습니다.
덕분에 비교적 짧은 시간 안에 팀 전체가 새로운 구조에 익숙해질 수 있었고,
결국 더 탄탄하고 유지보수성이 뛰어난 코드베이스를 만들어 갈 수 있었습니다.

 

5. 구조 적용 이후 느낀 장점

• 코드 일관성 확보 → 기능 추가/변경 시 사이드 이펙트 감소
• 대형 기능 추가 시 기존 코드 영향 최소화
• 신규 인원 온보딩 속도 개선 (구조 이해만 하면 전체 흐름 파악 가능)

6. 구조 적용 이후 느낀 단점

• 초반 학습 비용이 분명히 존재함 (특히 신입 개발자 입장에서는 장벽이 높음)
• 작은 수정 작업(1~2줄 수정)도 레이어를 따라가야 해서 작업 속도가 느려질 수 있음
• 모듈간 버전, 의존성 관리 이슈 (Gradle 세팅에 민감)

 

마무리 느낀점

클린 아키텍처를 적용하면서 느낀 가장 큰 장점은,
신규 인원이 투입될 때 구조만 이해하고 있다면 빠르게 업무에 적응할 수 있다는 점이었습니다.

 

업계에서 오랜 시간 다양한 개발자들과 협업해오면서 느낀 것은,

실력의 좋고 나쁨을 단순히 경력으로 구분하기는 어렵다는 것이었습니다.

하지만 클린 아키텍처와 같은 기본적인 소프트웨어 설계 개념을 이해하고 적용할 수 있는 사람이라면,

적어도 일정 수준 이상의 개발 역량을 갖춘 인재라고 판단할 수 있다고 생각합니다.

 

물론, 클린 아키텍처를 적용하면

하나의 기능을 추가할 때도 여러 파일을 생성하고, 더 많은 코드를 작성해야 하는 번거로움이 생길 수 있습니다.

작업 속도 측면에서는 초기에는 느려질 수도 있습니다.

 

그러나 프로젝트를 장기적인 관점에서 본다면 코드 품질 유지와 유지보수 비용 절감 측면에서

아주 큰 이점을 가져올 수 있는 선택이었다고 확신합니다.

 

 

👉 3편 예고: Compose 도입기 — Compose 도입을 하면서 MVI 의 필요성

Compose + MVI 를 왜 같이 써야하는가 에 대한 저의 생각