작년 여름부터 학회활동을 했는데 학회의 대미를 장식할 마지막 프로젝트에서 한 어플을 개발했다. 10월 & 11월 꽉채워 개발을 했는데 마감에 쫓겨서 아주그냥 급하게 진행했다.
그리고 꽤 좋은 평가를 받고 마무리했는데 팀원들과 마음이 맞아 2월부터 다시 리부트해서 하기로 했다! 🚀
모든 마감기한이 있는 프로젝트가 그렇듯 시간에 쫓겨서 하다보니 클린 코드와 클린 아키텍처를 추구하였으나 의존성의 방향이 꼬이고 코드가 레거시해지는 문제가 있었다. 그래서 프로젝트를 다시 리부트 시키며 무조건 클린하고 또 클린하게 다시 리팩토링 하기로 결정했다.
그러면서 최대한 android의 신기술을 많이 적용하고자 사용할 기술 스택을 리스트 업 했다.
무지성으로 신기술을 집어넣는거 보다는 왜 이 기술을 도입했고 써야하는지, 또 이전에 썼던 기술보다 이것이 왜 좋은지 정리해보고자 한다.
멀티모듈 도입
기존 우리는 아래와 같이 단일 모듈로 구축해 개발을 진행하였다.
사실 지금까지 모든 프로젝트들을 단일 모듈로 구축해 개발을 진행했는데 이때 가장 큰 문제점은 의존성 규칙을 위반하기가 쉽다는 것과 소스코드 간의 결합도가 높아지기 쉽다는 것 이었다.
클린 아키텍처에서 가장 중요한 원리중 하나는 내부 원은 외부 원에 대해 아무것도 몰라야 한다.
본래 기존 프로젝트에서는 Layer간 알지 않아도 될 부분까지 알게 되어 클린 아키텍처에 위반되는 사항들이 존재했다. 또한 단위 테스트 하기 어려웠다. ui의 상태를 업데이트하는 부분에 ui를 설정(디자인?)하는 부분도 있는 등 분리가 안되어있는 부분도 많이 있었다.
멀티 모듈을 도입하였을때 얻을 수 있는 이점이 있다면 레이어간 의존 관계를 명확히 끊어낼 수 있고 presentation layer내에 feature 들을 모듈로 각각 분리함으로써 알 필요 없는 feature들 간의 의존성을 느슨히 할 수 있다. 또한 common이라는 모듈을 두어 앱에서 공통적으로 쓰이는 디자인 시스템이나 로직을 정의할 수 있어 재사용이 가능하도록 설계가능하다.
아래 사진은 새로 멀티모듈을 적용한 대피로의 아키텍처 구조도이다.
Compose 도입
기존의 전통적 XML 방식에서 compose로 전환을 하고자 결정했다.
jetpack compose는 ui를 선언형 프로그래밍으로 구축하는 도구이다. 이 기술스택을 선정한데 가장 큰 이유는 신기술을 배우고자 하는 점, UI개발의 복잡성을 줄여 한층 빠른 개발 속도를 구축하고자 함에 있다.
선언형 프로그래밍 방식을 따르는 compose는 Composable 함수라는 독립적인 ui를 구성해 직관적이고 재사용성이 높은 코드를 만들 수 있다.
실제로 사용해보니 단적으로 compose가 작업속도가 훨씬 빠르다는 것을 몸소 체감했다.
예를 들어 Recyclerview를 만든다고 가정해보자.
기존 XML방식에서 이를 만들때에는 item.xml, Adapter, 리스트를 배치할 Activity 혹은 Fragment 파일이 필요하다. 하지만 compose로 한다면? 단 하나의 파일에 단 몇줄의 코드로 구현할 수 있다.
또한 불필요한 보일러플레이트 코드를 줄일 수 있다. 공통적으로 쓰일 ui는 따로 빼두어 재사용 가능하게 구현할 수 있기 때문이다.
MVI 패턴의 도입
기존 프로젝트에서 우리는 전통적인 MVVM 패턴을 사용했다. 하지만 compose를 도입하면서 패턴도 MVI로 바꾸고자 한다.
MVVM 패턴이 가지는 문제점
-
상태관리의 복잡성: viewModel에서 ui 상태관리를 하고 또한 서버로부터 받은 데이터의 가공처리도 여기서 진행하였다. 이렇게 되면 당연하게도 viewModel의 로직이 과도하게 복잡해지는 문제가 발생한다. 실제로 개발을 할때에도 모든걸 viewmodel에 의존한다는 느낌이 들었다.
ui는 내가 표시할게 데이터 관리랑 아무튼 남은 모든 관리는 viewmodel이 하는걸로 하자 -
불명확한 데이터 흐름: MVVM에서는 데이터 흐름이 viewmodel을 중심으로 양방향으로 이루어진다. 이는 데이터의 흐름 추적을 어렵게 하여 상태가 변화하는 과정을 파악하기 어렵게 만든다.
MVI 패턴의 이점
MVI 패턴은 앱의 상태를 명확하게 정의된 불변의 모델로 관리하여 단방향 데이터 흐름을 통해 처리하게 된다.
모든 데이터 흐름이 단방향으로 이루어지기에 앱의 상태가 어떻게 변하는지 이해하고 추적하기 쉽다.
또한 Compose에서 remember. mutableStateOf와 같은 방식을 사용해 상태를 관리하고 이 변화에 따라 ui를 자동으로 재구성한다.
또한 recomposition은 상태가 변경될때만 발생하기 때문에 불변의 상태를 사용하면 ui의 예측 가능한 업데이트가 가능해진다.
Room DB 적용
대피로에서는 오프라인 환경에서도 대피소 조회, 행동요령 조회 등의 기능을 수행해야한다. 대피소 조회를 위해서는 사용자가 직접 조회하고자 하는 지역을 선택해야하는데 현재 그냥 로컬의 파일에 수기로 서울 구,동 을 입력해서 가져오고 있다. 특별한 로컬 데이터베이스가 없이 그냥 raw.xml에서 가져오고 있는데 보다 효율적이고 안정적으로 만들기 위해서 Room DB를 구축하고자 한다.
Room DB 이점
- 오프라인 상태에서도 지역 데이터에 대한 원활한 접근성을 보장한다.
- 로컬 데이터베이스에서의 데이터 조회는 네트워크 요청보다 훨씬 빠르기에 속도와 성능이 향상된다.
- 데이터가 수정될 때 업데이트하여 데이터의 일관성을 보장할 수 있다.
이러한 이점으로 Room DB에 전국 시군구 데이터를 넣어놓고자 한다.
이외에 프로젝트를 진행하며 추가할 기술들을 리스트업하고 왜 적용해야하는지 명확한 이유를 찾아 나갈려고 한다.
새로운걸 배워나갈 생각에 심장이 뛴다..클린하다 못해 광이 나는 어플을 만드는 그날까지💪
