Community

# 모바일 애플리케이션 아키텍쳐의 오해와 기초 📱 MVC, MVVM, VIPER, MVP or VIP, RIBs 등을 들어보셨나요? 이는 클라이언트 사이드의 유명한(?) 아키텍쳐 입니다. 리펙토

# 모바일 애플리케이션 아키텍쳐의 오해와 기초 📱 MVC, MVVM, VIPER, MVP or VIP, RIBs 등을 들어보셨나요? 이는 클라이언트 사이드의 유명한(?) 아키텍쳐 입니다. 리펙토링을 하거나 새로운 프로젝트가 생기면, 잘 만들어 보고 싶은 마음에 이런 아키텍쳐를 살펴보고 고려하게 되는데요. 여러개의 어려운 이름이 아니라, 모바일 애플리케이션 아키텍쳐에 대한 하나의 기초적인 설명을 잘 담은 글이 있어 공유합니다. • 아키텍쳐는 애플리케이션을 만들고 디자인할 때 패턴과 기술을 알려줍니다. 아키텍쳐는 잘 만들어진 앱으로 가는 최고의 길을 알려주는 셈이죠. 아키텍쳐 패턴은 비슷한 문제를 반복적으로 푸는 데 성공한 하나의 솔루션 입니다. • 우리는 MVC, MVVM, VIPER, MVP or VIP 등을 들어보거나 조금씩 사용해 보았을 겁니다. 그리고 선호하는 패턴도 있겠죠. 그런데 우리가 특정 패턴을 선호하거나 선택하는 이유는 대부분 '업계에서 유명하거나, 사람들이 좋다고 말하거나, 사용해보고 싶기 때문'입니다. • 우리는 정말 아키텍쳐 패턴을 이해하고 있나요? 특정 상황에서 어떤 아키텍쳐가 왜 어울리는 지 말할 수 있나요? 소위 말하는 아키텍쳐 패턴들을 잘 보면, 우리의 앱에 있는 여러 이름을 가진 파일일 뿐입니다. 아키텍쳐에 대한 논의는 요구사항에 어떤 것이 더 잘 어울리냐가 주를 이루지만, 기초적인 컴포넌트와 어떤 아키텍쳐라도 가지는 토대에 대한 이야기는 많이 없습니다. • 아키텍쳐 패턴을 살펴보면, User Interface Layer / Presentation Layer / Business Layer / Model Layer 등 여러 레이어로 나뉘어 있습니다. 그러나 코딩을 하며 레이어의 분리는 점차 희미해 지죠. 이는 패턴의 잘못이 아니라, 개발자의 오해로 인한 것입니다. 우리는 컴포넌트와 파일을 매핑하면서 패턴을 잘못 이해하기 시작합니다. 예를 들어 MVC는 Model파일, View파일, Controller파일로 이루어진다고 생각합니다. • 매핑하면서 시작된 코드는 하나의 파일을 Massive하게 만듭니다. 예를 들어 MVC에서 Controller가 Model과 View가 하지 않는 모든 일을 처리하게 되는 것이죠. • 이러한 오해는 다음과 같은 질문으로 부터 풀 수 있습니다. 'Business 로직에 대한 처리는 누가 책임이 있는가?', '네트워크 요청은 누가 책임이 있는가?', '로컬 스토리지에 데이터를 저장하고 불러오는 일은 누가 책임이 있는가?', '로우 데이터를 모델로 만드는 것은 누가 책임이 있는가?', 'UI에 그려질 데이터를 만드는 건 누가 책임이 있는가?' • 아키텍쳐의 토대이자 기초 컴포넌트는 View와 Model 입니다. Model은 model object와 data access layer를 담당하는 객체입니다. model object는 view가 아닌 정보원에서 받은 state 묶음입니다. data access layer는 데이터를 요청하고, 가져오고, 모델로 변환하는 역할을 합니다. Model은 UI와 디펜던시가 없습니다. 이것이 Model Layer입니다. • View는 사용자와 앱의 상호작용을 책임지는 UI/UX입니다. Frame부터 버튼과 같은 Control을 관리하고, View Controller Hierarchy로 관리합니다. 이것이 View Layer입니다. • View와 Model은 서로 커뮤니케이션을 합니다. 여러 아키텍쳐 패턴이 고민하는 것은 결국 커뮤니케이션 방식입니다. View Layer가 Model Layer나 다른 layer에게 통신하는 것이 Interaction Logic이고, Model Layer가 View Layer에게 통신하는 것이 Presentation Logic 입니다. • 사용자의 View Action은 Interaction Logic를 일으키고, 정보원과의 Model Layer의 커뮤니케이션은 Presentation Logic를 일으킵니다. Model Layer는 Interaction Logic을 받으면, 노티를 주거나 데이터를 업데이트 하는 등 적절한 처리를 합니다. View Layer는 Presentation Logic를 받으면, 뷰를 업데이트 합니다. • 이 둘 이외에 View의 States를 관리하는 객체, Navigation을 관리하는 객체, Business Logic을 책임지는 객체가 View&Model과 협업합니다.

알림

알림이 없습니다