CIP(Cat Image Provider) 개발 회고

최근 Clean Architectur를 사용하면서 이러한 구조가 필요한 이유로 책임을 분리하고 유지보수를 쉽게한다는것을 느꼈습니다.

그래서 이전에 만들었던 앱이나 특정동작이나 기능을 CleanArchitecture 구조로 만들어보자 생각하였습니다.

 

그래서 이번에는 Retrofit과 Room 그리고 paging을 사용해보기로하고 Cat Image Provider 라는 앱을 만들었습니다.

사용 기술스택

구분	원본
UI	xml
디자인패턴	MVVM
아키텍처 패턴	멀티모듈 + 클린아키텍처
DI	Hilt
통신	Retrofit
DB	Room
이미지 로딩	glide
Paging	Jetpack Paging, Room-Paging

 

과정

우선 RestApi를 찾았습니다. 그러다가

https://developers.thecatapi.com/view-account/ylX4blBYT9FaoVd6OhvR?report=bOoHBz-8t

Report Wrapper - Report Dashboards

 

 

고양이 사진 Api를 찾았습니다. 이 Api에 요청을 하면 고양이 사진url들을 json형태로 가져올수 있습니다. 이걸 이용하면 간단하게 이미지 UI만으로 paging이나 통신을 확인할수 있게다고 생각하여 해당 Api를 선택하고 개발하였습니다.

결과물

https://github.com/PotatoMeme/Android-UI-Test/tree/dev/screen/cat-image-provider

Android-UI-Test/screen/cat-image-provider at dev · PotatoMeme/Android-UI-Test

 

 

느낀점

개발을 진행하면서 배울 것이 많다는 것을 다시 한 번 실감했습니다. 특히, Paging 처리와 관련된 문제를 해결하는 과정에서 멀티모듈 구조의 필요성을 깊이 고민하게 되었습니다. 현재는 데이터(data), 도메인(domain), 프레젠테이션(presentation) 레이어로 나뉘어 있지만, 더 복잡한 구조의 앱에서는 모듈을 세분화하는 것이 필요할 수 있음을 깨달았습니다. 모듈을 세분화하면 각각의 책임이 분리되어 유지보수가 용이하지만, 작은 앱에서는 오히려 관리가 더 복잡해질 수 있다는 점도 느꼈습니다.

 

그 예시 중 하나가 "Now in Android"라는 프로젝트입니다. 이 프로젝트는 Clean Architecture라기보다는 구글의 앱 아키텍처를 따르고 있지만, 모듈화된 구조로 구성되어 있습니다.

 

이 프로젝트는 크게 app, core, feature로 나뉘며, 그 안에도 여러 모듈이 존재합니다. 처음에는 복잡해 보일 수 있지만, 전체적인 의존성은 위에서 아래로 흐르는 형태로 구성되어 있어 각 모듈의 책임이 명확하게 분리됩니다. 예를 들어, 큰 앱에서 데이터베이스를 다룬다고 가정해 봅시다. 데이터베이스는 글을 저장하는 기능뿐만 아니라, 영상, 음성, 위치 정보까지 저장할 수 있습니다. 이러한 경우, 단순히 DataStore에 저장하는 것보다 데이터베이스를 사용하는 것이 더 적합할 수 있습니다. 이때, 데이터베이스에서 사용하는 모델, DTO, 마이그레이션 등의 파일을 나누어 관리하게 됩니다. 이처럼 다양한 기능을 모두 하나의 data 레이어에서 관리하는 것은 어려워 보이기 때문에, 모듈화를 통한 관리가 필요합니다.

 

하지만, 작은 앱의 경우 모듈화를 통해 유지보수를 용이하게 만들려는 시도가 오히려 복잡성을 더할 수 있다는 점도 고려해야 합니다. 그럼에도 불구하고 모듈화를 통해 관리하는 것은 좋은 경험이 될 것입니다.

 

멀티모듈 구성 중 Paging 관련 이슈도 있었습니다. 이 부분은 이후 글에서 더 자세히 다루겠지만, Paging의 책임을 Data 레이어에서 Domain 레이어로 넘길 때, 일반적인 Flow<List<Model>> 형태가 아니라 Flow<PagingData<Model>> 형태를 사용해야 했습니다. 그렇다면 PagingData의 책임을 Domain 레이어까지 끌고 와야 할지 고민하게 되었고, 이를 어떻게 구현할지에 대해 많은 생각을 하게 되었습니다.

 

결과적으로 PagingData라는 형태를 사용해야 하기 때문에, Presentation 레이어보다는 Data 모듈에서 이를 처리하는 것이 적절하다고 판단했습니다. 또한, 코틀린 도메인 라이브러리를 안드로이드 라이브러리로 만들 필요 없이, androidx.paging:paging-common-ktx와 같은 라이브러리를 통해 해당 기능을 사용할 수 있었습니다.

 

이번 개발 과정에서 Paging 처리와 멀티모듈 구조에 대해 깊이 고민하고 학습할 수 있는 기회를 가졌습니다. 모듈을 세분화하는 것은 큰 앱에서 유지보수와 관리의 효율성을 높이는 중요한 전략이 될 수 있지만, 작은 앱에서는 복잡성을 유발할 수 있다는 양면성을 알게 되었습니다. 그럼에도 불구하고 다양한 모듈을 나누어 각각의 책임을 명확히 하는 경험은 개발자로서의 역량을 한 단계 성장시키는 계기가 되었습니다.

 

PagingData와 같은 특정 기능을 Domain 레이어로 끌어올릴지에 대한 고민은, 결국 적절한 모듈 분리와 레이어의 역할에 대한 깊은 이해가 중요하다는 결론에 도달했습니다. 코틀린과 안드로이드 라이브러리를 적절히 조합하여 문제를 해결할 수 있었던 것도 큰 성과입니다. 이번 경험을 통해 앞으로 더욱 효율적인 구조로 앱을 개발할 수 있는 능력을 키울 수 있을 것 같습니다.