Skip to content

[Architecture] Clean Architecture 도입의 고민

Yoon Seong Sik edited this page Apr 20, 2023 · 5 revisions

현재 상황

현재 명식이 Android 구조는 MVVM 패턴의 구조로 되어있습니다.

스크린샷 2023-04-13 오전 9 50 09

패키지 구조는 다음과 같습니다.

스크린샷 2023-04-15 오전 12 18 58

SingleActivity로 되어있는 구조로 MainActivity, Base 가 있고, 백그라운드를 담당하고 있는 alarm, data, di, ui, util 구조로 되어있습니다.

현재 이 구조로 6개월 넘는 기간동안 잘 유지하고 있었지만, 새 학기가 시작되면서 무려 3000명의 사용자가 생겼습니다.

인문캠퍼스 식단 제공을 시작으로 자연캠퍼스 식당 4곳 추가, 리뷰, 맛평가, 주변 식당 추천 및 검색 등 다양한 기능을 추가하였고, 앞으로도 많은 기능들을 하고자 합니다.
따라서 유지보수를 조금 더 효율적으로 하고자, 도메인 계층과 데이터 계층을 나누어 앱의 사이즈가 커진다고 하더라도 소스코드 전반을 장악하고, 복잡한 수정사항이 생겼을 때 금방 파악할 수 있게끔 하고자 클린아키텍쳐 도입을 고민하고 있습니다.

같이 개발하고 있는 Android 개발자 의진님이 의견을 제시해 주셨습니다.

하지만 그 전에 클린아키텍쳐에 대해 많이 공부를 해야한다고 생각을 했고, 이론적으로만 공부를 했지 아직 프로젝트에 도입해본 적은 없었습니다.
현재는 MVVM 패턴을 사용하면서 이를 MVI + 클린아키텍쳐로 가야할지 많은 의논을 나누고 있습니다.
아직 MVI 패턴에 대해서는 많이 부족하여 먼저 클린아키텍쳐만 도입해보려고 합니다.

명식이 Android 개발팀의 목표는 다음과 같습니다.

목표

Presentation Layer

먼저, 사용자와 가장 가까운 화면에 표시되거나 입력 처리를 하는 등 UI와 관련된 모든 처리를 갖고 있는 계층을 설계합니다.
현재는 ui 패키지로 되어있지만 이를 presentation 으로 바꾸어 View와 ViewModel로 구성합니다.

Domain Layer

다음 도메인 계층입니다. 비즈니스 로직을 포함하는 UseCase, 앱의 실질적인 데이터를 담은 Model
또한 현재 명식이에는 없고, 데이터 계층의 엔티티-도메인 모델을 변환하는 mapper의 역할을 하게 되는 Translater 로 구성합니다.

Data Layer

UseCase 가 필요로 하는 데이터 저장/수정 등의 기능을 제공하는 Repository와 그것을 구현하고 있는 Impl 클래스
데이터소스(DB, 서버)와 상호작용을 담당하는 클래스로 구성합니다.

크게 그림으로 보면 다음과 같습니다.

스크린샷 2023-04-20 오전 9 06 16

이러한 구조 없이 6개월 넘는 기간동안 잘 유지보수를 했는데 꼭 적용해야하나?

이러한 생각이 충분히 들었습니다. 따라서 안드로이드 개발팀과 많은 이야기를 나누어보았습니다.
그럼에도 불구하고 결정한 이유는 다음과 같습니다.

팀원이 생겼습니다.

6개월 동안은 필자 혼자 개발을 해왔었습니다. 많은 기능들이 존재하지 않았고, 혼자서 개발해도 충분하였습니다.
많은 기능들이 존재하지 않아 패키지 구조가 간단하였고, 복잡한 로직이 존재하지 않았기에 클린아키텍쳐를 굳이 도입하지 않았어도 유지보수에는 어려움이 없었습니다.
하지만 자연캠퍼스 식당이 들어가고 사용자가 많아지면서 더욱 많은 기능들을 고민하게 되었고, 업데이트 버전이 올라갈 때 마다 최소한 2~3개의 기능은 추가되고 있습니다.
따라서 팀원을 모집하였고, 협업이 들어가는 순간 서로 유지보수가 쉬어야하고, 한 눈에 파악할 수 있어야 했기에 도입을 결정하였습니다.

앱의 기능 추가 및 유지보수

현재 날짜 기준(4/15) 2.2.6 버전에서는 식당의 인기 순위 기능까지 존재하지만, 2.2.7 버전에서는 추천순, 인기순, 거리순 등 더 많은 기능들이 추가가 될 예정입니다.
그러면서 많은 View가 생겨나고 있고 더욱 복잡한 로직도 생겨나고 있습니다. 따라서 계층을 나누어 각 계층의 책임을 명확히 하여 의존성을 최소화하고 그 결과로 유지보수가 쉽게끔 하는 것이 명식이 Android 팀의 다음 목표입니다.

우려되는 점

오히려 크게 문제가 될 만한 것이 없는 구조의 앱에 무리를 두면서 클린아키텍쳐를 도입하면서 많은 클래스를 생성해야 합니다.
이 때 생기는 부작용과 새로운 구조를 학습하면서 리팩토링을 병행해야 하는 것이 우려되는 점 입니다.
정상적인 서비스를 운영하려면 다시 전체 QA 에 들어가야하고, 사이드이펙트가 발생할 수 있습니다.
이러한 점이 우려가 되기 때문에 앞으로 명식이 Android 팀은 체계적으로 계획을 세워 도입하려고 합니다.

2.2.7 버전에서는 기능들이 업데이트 되고, 2.3 버전에서 많은 준비를 해보려고 합니다.