클린 아키텍처를 왜 써야할까?
[RoomDB를 처음 배웠을 때 메모장 앱을 구현한 디렉터리]
안드로이드를 개발하다 보면 한번쯤은 마주치는 클린아키텍처란 무엇일까요?
알아보기전에! 초심으로 돌아가서 저는 안드로이드를 처음 공부 할 때 Xml로 UI를 구성하고, 각 UI맞게 코드를 작성하고... 또 작성하고... 이런식으로 구현했습니다! 아마 안드로이드를 처음 접하신분이라면 대부분 구현 중심으로 하셨을겁니다! (구현 중심으로 해도 쉽지않은 안드로이드)
하지만 구현만 되었다고 해서 좋은 코드일까요? 전혀 아닙니다!
부끄러움을 마다하고 제가 올린 디렉토리를 보면(대략 1년전입니다) 클래스, 인터페이스 등등.. 전부 구분을 안하고 넣은 모습을 볼 수 있습니다.
제가 작성했던 코드입니다. 이 코드는 MainActivity에 작성한 코드인데 이렇게만 봐도 너무 복잡하고 정신이 없죠? 만약 여기서 추가적인 기능이 있다면 모든 코드를 다읽어봐야 할거에요
이런 코드는 개발효율성을 크게 감소시키고 보는사람도 지치게 만드는 코드입니다.
개발은 혼자하는 것이 아니기 때문에 코드 구조를 잘 설계해야 유지보수성 측면에서도 아주 큰 강점을 가져올 수 있어요! 그래서 등장한 것이 클린 아키텍처입니다!
그래서 클린아키텍처가 뭔데?
먼저 클린 아키텍처의 가장 중요한 규칙을 말씀드리면
그림 기준으로 내부원은 절대로 외부원을 의존해서는 안된다! 라는 것인데요.
왜 이런 규칙이 생겨났을까요?
사실 클린 아키텍처를 완벽히 이해하려면 책 한권도 부족한 것 같습니다.
그만큼 클린 아키텍처에 대해 갑론을박도 많고 규칙도 정말, 매우 많습니다
(더 자세히 알고싶으시면 로버트.C 클린아키텍처 서적을 구매하시는 것을 추천드립니다!)
하지만 전체적인 맥락에서 공통적으로 외치는 것이 있습니다.
" 소프트웨어 모듈(함수)은 서로 독립적이고 커플링을 최소화 시켜야한다! "
왜 이런 규칙이 나왔을까요? 사실 입문자들에겐 와닿지 않은 말입니다. 아직 큰 프로젝트를 경험하지 못하기도 했고 현재 코드로 써내려가는 방식이 크게 불편하지 않기두 하구요! (전 납득하는데 정말 오래걸린 것 같습니다)
실제 안드로이드에서 클린아키텍처를 적용하려면 초반부터 많은 작업이 필요하고 설계하는데 시간이 많이 소요됩니다. 이렇게 불편한 것을 굳이, 왜 사용해야하는 걸까요?
바로 유지보수성측면에서 굉장히 유리하기 때문입니다.
어떻게 유지보수성이 유리한건데?
메모장 앱을 만든다고 가정해볼까요?
메모장에 수정, 삭제, 저장 기능을 만들고
한달뒤에 고객의 요청으로 좋아요 기능까지 구현해야 하는 상황입니다.
메모장을 개발한 개발자는 수정, 삭제, 저장 기능이 메모장 데이터베이스를 참조하게 구현했습니다.
좋아요 기능을 넣는과정에서 데이터베이스 관련 함수들을 수정해야하는 작업이 생겼습니다.
개발자는 능숙하게 수정 후에 테스트를 해봅니다.
좋아요를 눌렀더니 갑자기 작성했던 메모가 사라지는 현상이 발생했습니다
예시이지만 정말 종종 발생하는 현상입니다..(실제로 겪어봤기도 했구요)
나는 분명 좋아요 기능에서만 수정을 했는데 왜 삭제가 되는걸까요?
메모장 기능을 다루는 함수와 메모장 데이터를 다루는 함수들이 서로 의존성이 깊었기 때문입니다.
개발자가 의도하지 않는 버그가 이런 곳에서 터지는 것이죠!
만약 이 둘의 계층을 분리했더라면 어땟을까요?
좋아요만을 구현하기 위한 기능만 추가했더라면 어땟을까요?
적어도 코드를 갈아엎어야 할 상황은 안나올 것입니다!
이건 자신이 겪어봐야 더 와닿는 것 같습니다!
실수에서 얻은 교훈이 더 기억에 오래남는 것 처럼 말이죠!
아직 와닿지 않은 분들은 이정도 배경지식만 갖춰도 될 것 같습니다!
그럼 안드로이드에서 클린 아키텍처를 어떻게 적용할까?
많은 안드로이드 프로젝트에서 볼 수 있는 계층입니다! (요즘은 계층을 모듈화 시켜서 따로 컴파일 할 수 있도록 하더라구요)
data 계층
앱에서 필요한 데이터들을 관리하는 계층입니다!
주로 서버에 접근하는 코드나, RoomDB같은 데이터베이스 등등 Back단에서 이뤄지는 기능들이 속합니다!
domain 계층 (선택)
도메인 계층은 필수는 아닙니다.
순수 코틀린 코드만 존재 해야하며, 비즈니스 로직이 담겨져 있는 부분입니다.
비즈니스 로직은 서비스의 핵심적인 가이드라인이 담겨져 있는 코드를 의미합니다!
예를 들어 메모장에서 메모를 저장하는 리포지토리가 존재한다고 가정해보면, 도메인계층에선 리포지토리의 인터페이스만 작성하고 구현은 data 계층에서 실시합니다!
이런식으로 서비스에 필수적인 요소의 코드를 가이드라인이 존재한다고 생각하시면 될 것 같습니다.
presentation 계층
앱의 UI를 담당하는 계층입니다.
data가 back이라면 presentation은 front단이라고 생각하시면 됩니다!
이 계층에선 뷰, 뷰모델 같이 뷰에 관한 기능이 담겨져 있습니다.
계층들의 의존성
위 그림을 보면 알 수 있듯이, Presentation 계층은 Data와 Domain을 알고있고, Data 계층은 Presentation 계층의 존재를 몰라야합니다.
즉, 내부원이 외부원의 존재를 모르게해야한다는 것입니다!
이런식으로 구분을 한다면, 추후에 여러 수정사항이 생겨도 수월하게 리팩토링이 가능합니다.
마무리
이번 글은 클린아키텍처를 왜써야하는지에 대한 중점으로 글을 작성해봤습니다! 아마 다음글엔 실제로 클린아키텍처를 적용하고, 클린아키텍처를 사용하기 위해 Dagger Hilt를 적용한 간단한 토이 프로젝트에 대해 소개할 예정입니다!
처음엔 어렵고 복잡하지만 점차 쓰다보면 분명 클린아키텍처의 매력과 필요성에 대해 느낄 수 있을거라고 생각합니다!
참고 문헌
