Android Clean Architecture 와 Android App Architecture - 3

 기존에 작성했던 게시글을 이어서 작성하는 내용입니다. 1편에서는 안드로이드의 클린 아키텍처에 대해서, 2편에서는 안드로이드에서 권장하는 앱 아키텍처에 대해서 적어보았습니다. 이번 게시글에서는 두 아키텍처의 공통점과 차이점에 대해서 적어볼 예정입니다.

---

공통점

 두 아키텍처의 공통점은 이전 글을 작성하면서 어느 정도 설명한 적이 있던 부분입니다.

 먼저 관심사가 분리되어 계층형 아키텍처 구조를 이룬다는 점이 있는데요. 안드로이드 앱 아키텍처는 UI Layer - Domain Layer(optional) - Data Layer로 구성되어 있고, 클린 아키텍처 역시 안드로이드에서 Presentation Layer - Domain Layer - Data Layer로 구성되어 있습니다. 세부적인 내용은 조금 다르지만, 동일한 형태의 계층을 이루고 있다는 것을 확인할 수 있습니다.

 또한 두 아키텍처 모두 단방향 데이터 흐름을 요구한다는 점인데요. 두 아키텍처는 모두 UI의 이벤트에서 시작해 Data Layer까지 흘러갔다가 다시 UI의 State를 변화시키는 플로우를 지니고 있습니다(모든 이벤트가 동일하게 움직이는 것은 아닙니다만).

 위 두가지의 큰 틀이 동일하게 움직임으로서 두 아키텍처는 굉장히 유사한 형태를 띄게 됩니다. 일단 이름은 다르지만 UI를 다루는 두 계층(Ui Layer, Presentation Layer)은 동일하게 작성할 수 있고(동일한 패턴이나 방식을 활용한다면), 사용자가 보는 엔드포인트를 구성하며, Domain Layer에 의존한다는 부분까지 동일합니다. 또 Domain Layer에서 UseCase를 사용한다는 점과, Data Layer에서 Repository 패턴을 사용한다는 점도 동일합니다(이때 하는 역할 역시 동일합니다).

 

 

차이점

 비슷하지만 다른 점이 많은 두 아키텍처를 레이어 별로 차이점을 확인해 보겠습니다. 일단 가장 큰 차이점은 각 계층별 의존성 방향이 다르다는 점인데요. 이전 글들에서 소개했지만, 클린 아키텍처의 경우 Domain이 유일하게 독립되어 있고 각 레이어가 모두 Domain Layer를 바라보는 형태로 구성되어 있지만 안드로이드 가이드에서는 UI -> Domain -> Data 처럼 한 방향으로만 의존성이 구성되어 있습니다.

 이러한 의존성의 방향의 차이는 Domain Layer가 Repository Interface를 지니느냐 마느냐에 대한 차이로 나타나게 되는데요. Domain Layer가 독립적인 클린 아키텍처의 경우, 다른 계층을 참조할 수 없기 때문에 Domain Layer에서 작동할 매개체가 필요하고 이를 Repository interface의 형태로 전달하게 됩니다. 그러나 단방향으로 의존성을 가지는 안드로이드 앱 아키텍처의 경우, Domain Layer가 Data Layer를 알고 있으므로, Data Layer에 생성된 Repository를 그대로 UseCase가 사용할 수 있게 됩니다.

 또한 가장 큰 차이점은 Domain Layer일 텐데요. 클린 아키텍처에서는 이 Domain Layer가 중요한 역할을 하지만, 안드로이드 앱 아키텍처에서는 Optional로 존재하고 있습니다. 이는 공식문서에서 왜 그런지 잘 설명하고 있는데, 클린 아키텍처를 사용할 때 많이 마주하는 부분 중 하나인데, 안드로이드에서 UseCase를 설정하려고 보면 단순하게 Repository의 메소드 하나를 불러오는 수준의 역할에 그치는 경우가 많습니다. 이러한 부분은 아키텍처를 지키는 측면에서 어쩔 수 없는 리소스의 사용이지만, 불필요한 코드가 생산되고 있다는 느낌을 지울 수 없습니다. 안드로이드 앱 아키텍처는 그래서 불필요한 코드는 과감하게 생략해도 괜찮다는 주의인 것 같습니다. ViewModel이 바로 Repository를 참조하더라도 아키텍처에 알맞은 코드가 되니까요.

 

 

[정리]

	Android clean architecture	Android App Architecture
공통점	관심사 분리(계층형), 단일 데이터 흐름(UDF)
Layer	Presentation - Domain - Data	UI - Domain(optional) - Data
의존성 방향	Presentation → Domain ← Data	UI → Domain → Data
Presentation(UI) Layer	View - Presenter	Ui element - State holders
Domain Layer	UseCase - Repository Interface -Entity	UseCase
Data Layer	Repository - DataSource - DataModel	Repository - DataSource
데이터 관리	의존성을 참조하는 레이어의 데이터에 종속적	따로 데이터 관리에 대한 가이드는 존재하지 않음

 

Android Clean Architecture =/= Android App Architecture Guide

두 아키텍처의 공통점은 주로 안드로이드에서 사용하는 대부분의 아키텍처에서 사용하는 공통점이며 큰 틀에서는 비슷하게 작성할 수 있는 형태입니다. 그러나 디테일적인 측면에서 보면 여러 부분들이 다른데, 기본적으로 안드로이드 앱 아키텍처 가이드에서는 프레임워크 종속적임을 분명히 하고 있고 이에 맞는 가이드를 제공합니다. 그러나 클린 아키텍처의 경우, Presentation 을 제외하고는 안드로이드라는 프레임워크에서 독립적으로 사용할 수 있도록 Kotlin 및 Java에서 제공되는 것들로 구성합니다.

 또한 위 표와 같이 각 레이어의 작업 방식 및 의존성의 방향이 다릅니다. 그리고 앱 아키텍처 가이드는 좀 더 애플리케이션이라는 측면에 초점을 두어 '불필요한 코드는 굳이 작성하지 않아도 된다'는 효율성이라는 부분을 강조해 까다롭게 틀에 맞춰진 클린 아키텍처보다는 덜 정형화되어 있습니다. 그래서 실제 프로젝트를 작성할 때 클린 아키텍처보다는 앱 아키텍처 가이드를 따르는 것이 훨씬 자유도가 높다고 느낄 수 있습니다. 디테일한 부분을 살펴보면 실제로 클린 아키텍처 쪽이 훨씬 신경쓸 것이 많다는 것을 알 수 있죠.

 

---

 결국 아키텍처는 자신의 프로젝트에 제일 알맞는 것으로 선택하면 좋을 것 같습니다. 쓰다보면 아키텍처에 의한 코드들이 생겨나기 마련인데, 이런 불필요한 코드가 많다면 굳이 그 아키텍처를 적용해야 할 필요는 없는 거죠.

 예전에 학생때 아키텍처 관련 수업을 들을 때 '아키텍처는 정답이 아니다. 필요에 의해 수정되어질 수 있고, 이는 합의에 의해 도출되는 것으로 충분하다'라는 문구(100% 정확하지는 않습니다)를 본 적이 있는데 확실히 프로젝트를 여러개 하다보니 아키텍처를 적용하는게 훨씬 비효율적인 작은 프로젝트도 있고, 아키텍처를 적용하지 않고서는 진행이 어려운 프로젝트들도 있었습니다. 이제야 경험에 의해 조금씩 학습했던 내용들이 습득되는 중인 것 같아요.

 회사에서 업무하면서 틈틈히 정리한 내용인데, 아직도 제대로 정리한 게 맞는지 모르겠습니다(😄). 그래서 글을 작성할 때 마다 괜히 한 번 더 검색해보고 제가 사용했던 방식에 대해 고민해보게 되서 좋았습니다. 다른 사람들에게 글을 보여주면서 틀리지 않기 위해 한 번 더 점검하게 되니 어색하던 부분도 잡을 수 있고 생각도 많아지더라구요. 이 주제로 한 번 글을 작성하는 게 그래도 도움이 된 것 같습니다.