클린 아키텍처 파헤쳐보기

 

 

안녕하세요! 이번에는 저번에 소개한 클린 아키텍처에 대해 좀 더 깊게 파헤쳐보도록 하겠습니다!

 

혹시 어플 사용하실 때 시간이 지남에 따라 UI 가 조금씩 바뀌는걸 체감하시나요? 이처럼 UI 는 디자이너나 앱 사용자의 요청으로 쉽게 변할 수 있는 부분입니다. 따라서 UI 를 격리하는 부분, 이에 초점을 맞춘 디자인 패턴이 고민거리였습니다. MVP, MVVM, MVI 등 여러 디자인 패턴 등이 언급되었고, compose 같은 선언형 UI 도 등장했습니다. 앱의 규모가 커질수록 아키텍처 설계에 대한 중요성이 커지게 되어 이에 대한 관심도가 높아졌습니다.

 

안드로이드 공식 문서에서도 앱 권장 아키텍처를 소개하고 있습니다.

안드로이드 권장 앱 아키텍처

 

여기서는 UI, Domain, Data 로 세 개의 계층으로 구분합니다. UI 계층은 데이터를 화면에 보여주며, Domain 계층은 비즈니스 로직을 캡슐화하며, Data 계층은 네트워크나 로컬로부터 데이터를 불러오는 역할을 합니다. 의존성의 방향은 UI Layer → Data Layer 으로 향합니다. 즉, UI 계층이 Data 계층을 의존합니다.

 

클린 아키텍처

 

안드로이드 권장 앱 아키텍처와 클린 아키텍처의 공통점은 무엇일까요? 바로 계층 별로 분리했다는 점입니다. 계층을 나누는 이유는 무엇일까요? 관심사 분리를 통해 변경 사항이 있을 때 각 계층에 최대한 영향을 최소화합니다.

두 아키텍처의 차이점은 무엇일까요? 바로 계층간의 의존성 방향입니다. 앱 아키텍처는 UI가 Data를 의존하는 반면, 클린 아키텍처는 동심원 바깥쪽에서 안쪽으로 의존하기에 Data가 UI를 의존하지 않습니다.

또한, 클린 아키텍처는 대규모 앱 프로젝트에 적합한데 비해 앱 아키텍처는 소규모 앱 프로젝트에 적합합니다.

 

안드로이드 공식 문서에서는 클린 아키텍처에 대한 언급을 하지 않습니다. 클린 아키텍처가 아닌 앱 아키텍처를 공식 문서에 소개하는 이유가 무엇일까요? 바로 범용적인 가이드를 위해서입니다. 가이드를 참고하는 사람들이 이해하기 비교적 쉽도록 의존 방향이 단방향이고, 계층은 3개로 비교적 간단하게 구조화된 앱 아키텍처를 설명하는 것입니다. 

 

우리가 비교적 간단한 구조의 앱 아키텍처를 안드로이드 공식 문서에서 설명함에도 불구하고 클린 아키텍처를 배워야 하는 이유는 무엇일까요? 바로 의존성 규칙 때문입니다. 권장 앱 아키텍처는 UI 가 Data 를 의존하는 구조로 Data 가 변경이 되면, UI 와 Domain 계층도 영향을 받습니다. 클린 아키텍처 같은 경우 의존성 방향을 보았을 때 UI와 DB가 완전히 분리되어 있습니다. 또한 Entity나 Use Case가 변경되지 않는 강건한 구조를 갖습니다. 계층이 확실히 분리되어 있는 클린 아키텍처는 확장성, Unit Test 용이성, 빌드 시간 단축 등 여러 측면에서 안드로이드 앱 아키텍처보다 많은 장점이 있습니다.

---

앱의 전형적인 시나리오

 

위의 그림은 앱의 전형적인 시나리오로, 화살표는 의존 관계의 방향을 의미합니다. View 는 ViewModel 을 의존합니다. 더 자세하게 말하자면, View 는 ViewModel 의 LiveData 를 observing 하여 UI 를 갱신합니다. ViewModel 은 UseCase 를 의존하여 Repository의 DataSource 로부터 데이터를 불러옵니다. 이런 일련의 흐름은 GUI 를 갖는 어플리케이션의 전형적인 시나리오입니다. 이 개념들이 클린 아키텍처의 동심원에서 각각 어디에 위치할까요?

---

전형적 시나리오와 클린 아키텍처 연관성

 

검은 선은 클린 아키텍처에서의 경계를 의미합니다. View 와 ViewModel 은 클린 아키텍처의 가장 바깥쪽 동심원 계층인 UI 에 해당하며, Repository 및 DataSource 는 DB 에 해당합니다. database 나 network 통신 모듈이 이에 해당합니다. data 가 UI 에 표시되기 위해서는 이 둘간의 커뮤니케이션이 필요한데, 이를 위해 안쪽 경계에 인터페이스 추상체를 둡니다. Repository 구현체는 의존성 역전 원칙에 통해 계층을 횡단하고, UseCase 의 반환 타입으로 데이터가 View 에 넘어가서 UI 와 Data 의 의존관계를 끊어냅니다.

 

클린 아키텍처를 기반한 모듈화

 

클린 아키텍처를 본격적으로 도입하기 위해 안드로이드 모듈화 진행과정이 필요합니다. 각 경계를 구분하고 영역을 분리하는 것은 모듈로 분리하는 것을 말합니다. presentation 모듈, domain 모듈, data 모듈 총 3가지의 모듈이 있습니다.

presentaion 모듈은 UI 에 연관된 로직이나 클래스가 포함됩니다. Android View나 composable, viewmodel 등이 이에 포함됩니다. domain 모듈은 UseCase, Entity, repository(추상체) 가 포함됩니다. data 모듈은 room, retrofit, preference, repository(구현체) 가 포함됩니다. 

 

모듈 간 의존성

 

모듈 간 의존성에서 data 모듈과 presentation 모듈은 domain 모듈에 의존합니다. 이러한 의존성 방향을 가진 모듈은 어떤 점이 용이할까요? 바로, 독립적인 테스트가 가능해집니다. 예를 들어, presentation 모듈을 테스트할 경우 이가 의존하는 domain 모듈까지만 빌드를 하여 unit test 가 가능해집니다. 클린 아키텍처와 달리 안드로이드 앱 아키텍처는 UI 를 테스트할 경우, 모든 모듈을 포함해서 빌드를 해야합니다. 반면, 클린 아키텍처는 필요한 모듈만 선택적으로 빌드를 할 수 있기 때문에, 컴파일 코드량도 줄어들고 빌드 시간도 단축됩니다.

 

오늘은 안드로이드 앱 아키텍처와 클린 아키텍처의 비교, 앱의 전형적인 시나리오, 클린 아키텍처를 위한 모듈화와 의존성 관계에 대해 살펴보았습니다. 도움이 되셨다면 하트 한번 부탁드릴게요!