Clean 과 Google Recommended Architecture 이야기

동훈이·2023년 2월 24일

architecture clean clean architecture google google recommneded google recommneded architecture

story

목록 보기

1/1

안드로이드를 개발하면서 프로젝트를 만든 뒤 가장 우선적으로 정해야 하는게 바로 패턴과 아키텍쳐 입니다. 패턴으로는 MVC, MVP, MVVM, MVI 등이 있고 아키텍처로는 Clean 와 Google Recommended 가 있습니다. 두개의 아키텍처 모두 소프트웨어 아키텍처에 대한 가이드라인입니다. 그러나 두 가지 방법론은 서로 다른 목표와 관점을 가지고 있습니다. 그래서 이 둘의 차이와 무엇을 써야 하는지에 대해서도 같이 이야기를 해보려고 합니다.

Clean Architecture?

Clean Architecture는 소프트웨어 시스템을 간단하게 만들기 위한 것입니다. 이 방법론은 의존성 역전 원칙을 기반으로 하며, 각 계층은 하위 계층에 의존하지만, 상위 계층에 대해서는 알지 못합니다. 이러한 방식으로 시스템은 더욱 모듈화되고 유연해지며, 수정과 유지보수가 용이해집니다.

정의를 찾아보았는데 많이 어렵네요.. 그래서 우선 의존성 역전 원칙에 대해서 개념을 잡고가야 CleanArchitecture 를 이해하기 쉬울 것 같아 의존성 역전 원칙에 대해 이야기를 해보려고 합니다.

💡 의존성 역전(Dependency Inversion)은 객체 지향 설계 원칙 중 하나입니다.

위에 사진은 많이 보던 이미지와는 좀 다르지만 흔히 돌아다니는 Clean Architecture 를 안드로이드에 맞추어 변형시켜놓은 이미지 입니다. 의존성 역전에 대해 정의를 하면 아래와 같이 2개로 정의할 수 있습니다.

상위 수준의 모듈은 하위 수준의 모듈이 구체적으로 어떤 객체를 사용하는지 알지 못해야 한다.
추상화에 의존하여 구체적인 구현을 분리해야 한다

💡 저희는 개발자니깐 코드로 이야기를 해보자구요!

의존성 역전 원칙 위배 예시 코드 Domain -> Data

<Domain>
class GetUserUseCase @Inject construct(
	userRepository: UserRepository
)

<Data>
class UserRepository @Inject construct(
	userDataSource: UserDataSource
)

위에서 나와있는 예시 코드에는 GetUserUseCase 가 UserRepository 에 의존합니다. 이것은 하위 수준인 UseCase 가 상위 수준인 Repository 에 의존하는 것이므로 Clean Architecture 가 이야기 하는 의존성 역전 원칙의 2가지를 모두 위배를 하였습니다.

위의 코드에서 의존성 역전을 적용하려면 GetUserUseCase가 UserRepository에 의존하지 않도록 추상화를 적용해야 합니다. 쉽게 말해 UserRepository를 인터페이스로 추상화하고, GetUserUseCase는 이 인터페이스에 의존하도록 구현하면 됩니다. 이렇게 하면 UserRepository의 구체적인 구현에 대한 의존성을 분리하고, GetUserUseCase가 UserRepository의 구체적인 구현에 대한 변경 없이도 유연하게 동작할 수 있습니다.

의존성 역전 예시 코드 Data -> Domain

<Domain>
class GetUserUseCase @Inject construct(
	userRepository: UserRepository
)

interface UserRepository

<Data>
class UserRepositoryImpl @Inject construct(
	userDataSource: UserDataSource
): UserRepository

위와 같이 의존성 역전 위배가 된 코드를 수정하면 상위 수준의 모듈이 하위 수준의 모듈에 의존하지 않도록 하고, 추상화에 의존하도록 구현함으로써 모듈 간의 결합도를 낮추고 유연성과 확장성을 높일 수 있습니다. 최종적으로 아래와 같은 레이어를 구성하게 됩니다. 이러한 걸 의존성 역전이라고 하고 이를 기반으로 CleanArchitecture 를 구성합니다.

위와 같이 적용하였을때 실제 안드로이드 프로젝트에서 파일 구조는 아래와 같이 구성 될 수 있습니다.

💡 Presentation Layer -> Domain Layer <- Data Layer

해당 아키텍처의 장점으로는 중간에 도메인 모듈 자체가 어떠한 언어로든 프레임워크나 라이브러리에 종속되지 않아 모듈화와 유연함이라는 장점이 있습니다.

대표적으로 헤이딜러에서 위와 같은 구성으로 프로젝트를 구성하였습니다. 아래 페이지에서 확인해보세요!
https://github.com/PRNDcompany/android-style-guide/blob/main/Architecture.md

Google Recommended?

Google Recommended는 Google에서 공식적으로 권장하는 Android 앱 개발 방법론입니다. 이 방법론은 개발자의 생산성을 높이기 위해 최적화된 것입니다. Google Recommended는 MVVM(Model-View-ViewModel) 패턴을 기반으로 하며, 데이터와 UI의 분리를 강조합니다. 이러한 방식으로 앱을 구성하면 UI 구성 요소와 비즈니스 로직이 분리되어 개발이 더욱 용이해집니다.

💡 구조가 Clean Architecture 와 많이 비슷한데 다른점은?

Clean Architecture 와 비슷하게 구성될 순 있지만, 단 1가지의 차이점이라고 하면 도메인 레이어의 필수 여부가 있습니다. 도메인 레이어가 필수 여부에 대한 차이는 Clean Architecture와 Google Recommended Architecture 사이의 중요한 차이 중 하나입니다.

Clean Architecture에서는 도메인 레이어가 반드시 존재해야 하며, 비즈니스 로직과 유즈케이스를 처리해야 합니다. 그러나 Google Recommended Architecture에서는 도메인 레이어가 선택 사항으로 취급됩니다. 즉, 모든 비즈니스 로직을 도메인 레이어에 넣지 않아도 되며, 필요한 경우에만 도메인 레이어를 추가하여 사용할 수 있습니다.

그래서 Repository 의 Interface 또한 선택 사항인 도메인에 위치하지 않고 데이터에 위치하게 되며 도메인이 데이터를 아는 구조를 가져가게 됩니다.

위와 같이 적용하였을때 실제 안드로이드 프로젝트에서 파일 구조는 아래와 같이 구성 될 수 있습니다.

Presentation Layer -> Domain Layer -> Data Layer

해당 아키텍처의 장점으로는 안드로이드에서의 구현을 고려한 가이드라인으로, 안드로이드에서의 개발 특성을 고려하여 좀 더 실용적이고 쉽게 적용할 수 있도록 설계되어 있습니다. 따라서 Clean Architecture보다는 좀 더 유연하게 적용할 수 있지만, 구체적인 가이드라인이 부족할 수 있습니다.

그래서 무엇을 써야해?

두 방법론 모두 소프트웨어 아키텍처의 구조를 간결하게 만들고 유지보수성을 향상시키는 것이 목표입니다. 그러나 Clean Architecture는 보다 일반적인 방법론이고, Google Recommended는 Android 앱 개발을 위한 구체적인 방법론입니다.

Google Recommended Architecture 장단점

장점

빠르게 구현 가능하다.
UI 레이어와 도메인 레이어 사이의 직접적인 의존성이 없기 때문에, 유닛 테스트 작성이 용이함

단점

모듈이 늘어날수록 모듈간 의존성이 복잡해지는 단점이 있음
완전한 의존성 역전 원칙을 지키지 않는다.

Clean Architecture 장단점

장점

독립적인 모듈 구성이 가능하므로, 모듈 간 의존성이 낮아 유지보수가 용이함
높은 유연성과 확장성을 제공하므로 요구사항 변경에 대응하기 용이함
도메인 레이어를 통해 비즈니스 로직과 기술적인 구현을 분리하여, 독립적인 개발이 가능함

단점

Google Recommended Architecture보다 더 많은 코드를 작성해야 하므로 개발 비용이 증가할 수 있음
개발자들이 개발할 때, 알아야 할 지식이 많기 때문에 초기 학습 곡선이 높을 수 있음

따라서 개발자는 프로젝트 요구 사항과 선호도를 고려하여 두 가지 방법론 중 하나를 선택할 수 있습니다.

💡 그런데 여기서 말하는 개발 비용이라는 부분 얼마나 유효할까요?

이 부분은 개발팀의 크기와 경험에 따라 다를 수 있습니다.

Google Recommended Architecture는 안드로이드 앱 개발을 간편하게 만들어주기 때문에, 개발팀이 작거나 안드로이드 앱 개발 경험이 부족한 경우 개발 비용이 절감될 수 있습니다.

반면 Clean Architecture는 모듈화된 구조를 갖춘 소프트웨어를 만들기 때문에, 개발팀이 크거나 경험이 풍부한 경우 개발 비용이 절감될 수 있습니다. 이는 소프트웨어를 유지보수하고 확장하기 위한 비용을 줄일 수 있기 때문입니다.

💡 결론은 개발 비용 이외의 다른 측면에서도 두 아키텍처를 비교해야 합니다.

예를 들어, Google Recommended Architecture는 도메인 레이어가 선택적이여서 개발 속도가 빠르고 초기 개발 비용이 저렴할 수 있습니다.

반면 Clean Architecture는 모듈화된 구조를 갖춘 소프트웨어를 만들기 때문에, 소프트웨어를 유지보수하고 확장하기가 용이하며, 이로 인해 장기적인 비용 절감 효과가 있을 수 있습니다.

따라서, 개발비용만을 고려한다면 두 아키텍처 중 어느 것이 우수하다고 말하기는 어려울 것 같습니다.

나는..?

저라면.. 간단한 프로젝트에서는 Google Recommended 그 외의 프로젝트에서는 Clean Architecture 를 사용 할 것 같아요! 대공사 이긴 하겠지만 Google Recommended 를 하다가 Clean 으로 바꿀 수 있으니깐요!

이미지 참고 : https://meetup.nhncloud.com/posts/345

동훈이