# MVC, MVP, MVVM, Redux, VIPER 비교
# 서두
지난 글에서 MVC, MVP, MVVM을 조사해 봤다. 그런데 공부하다가 생긴 질문이 있다.
구조가 달라진다 한들 있어야할 로직 코드가 없어지진 않을텐데?
잘 생각해보면 Presenter라고 해서 화면 표시 로직만 있는 것은 아닐테고, View model이라고 해서 데이타만 있는 것은 아닐텐데 말이다.
그래서 나름의 아이디어가 떠올라 그림을 그려봤다. 그리고 그 그림을 각 구조에 껴 넣어보니 나름 의미 있는 결론을 얻을 수 있었다.
시작해보자.
WARNING
아래 내용은 모두 개인적 고찰 및 의견입니다. 비판적 자세로 참고하시어 의견 개진 부탁드립니다.
# 최대한 쪼개다
서론에 언급한 질문처럼, 모든 애플리케이션에는 코드가 없을 수 없다. 그렇다면 이것들이 어딘가는 반드시 존재해야 하고
그저 어떻게 묶어내느냐에 따라 구조라는 형태를 띄게 될 것이라 예상했다.
나름 생각해본 요소들과 대략의 제어흐름이다.
- Data Object: 기본이 되는 데이타의 순수 객체 표현.
- Business Logic: 대부분의
Use Case가 구현될 부분. - Coordintor: 중앙에서 이벤트 핸들링이나 Business Logic을 제외한 기타 로직이 위치. 외부 API나 DB 호출도 여기가 적당해 보인다.
- Converter: 도메인 데이타를 표현 계층의 데이타 형태로 포매팅 하는 역할. 복잡하지 않다면 Controller나 Abstract view에 흡수될 것이다.
- Abstract view: 실제 화면에 표현되기 전의 추상화된 데이터.
- View Logic: 추상화되어있는 게 데이터가 화면에 어떻게 표현될지 구체적 로직을 포함한다.
- View: 로직이 없는 깡통 디자인. 코드가 붙어있다면 getter, setter 정도이겠다.
- Events Bundle: 사용자 입력이나 외부 요인에 의한 데이터 변경을 정의한 이벤트 모음. 발생의 근원지인 View 또는 Data쪽으로 흡수될 수 있다.
- External Interface: DB 접근, API 호출 등 외부 시스템과의 연동 인터페이스.
이정도로 잘게 나누어 놓으면 굳이 더 나눌 부분이 크게 보이지 않는다. 아래부터는 기존 구조와 매칭시켜보려 한다.
# MVC
딱히 구분에 이견이 있을것 같지 않다. 다만 그림에서는 Model과 View가 직접 참조가 없는데,
그건 세부 구현 따라 달라질 것이기 때문에 지금 그림으로도 충분히 커버된다고 본다. 그림상으로는 데이터 변화에 따른 이벤트 핸들러가 Controller에 있는 것이다. Observer 패턴으로 Model과 View가 직접 연결되는 구조도 가능할 것이고.
# MVP
그려놓고 보니 MVP는 Presenter의 부담이 큰게 느껴진다. 아마 실제는 Presenter의 역할을 조금 분할해서 사용하지 않을까 싶다.
# MVVM
역시나 그림상으로는 MVP와 큰 차이가 없다. View Logic의 소속 차이 정도. 하지만 사실은 Binding 덕분에 View Logic이 상당히 경감될 것이다.
# Redux/Flux
혹시나 하는 생각에 Redux도 짜맞추어보니 얼추 맞았다.
Action에 상당수의 로직이 존재한다는 데에는 다들 동의하실거라 생각한다. Action은 어떤 행동을 할지 정보가 담겨있는데, 이 역시 데이타이기 때문에 Data Object로 나타낼 수 있다. Flux 패턴답게 흐름의 방향은 단방향으로 변경되었다.
Reducer는 Action의 데이터를 바탕으로 Store를 변경하기 때문에 Converter 역할에 부합한다.
# Viper
ios 개발은 경험이 없어서 세부 사항은 모르지만 최근 유행하는 viper 구조를 보면 크게 다르지 않다. 조금 더 역할을 세분한 것으로 보인다.
# 결론
결국 모든 구조들은 역할의 분할 정도와 흐름에 대한 차이가 존재하는 것이지 로직이 알아서 구성되거나 하는 것은 아니다.
또한 구조가 고도화 되면서 각각의 부분은 단순해지지만 전체적 구조의 복잡성은 증가한다.
결국, Silver bullet이 존재하는 것은 아니며 상황에 따라 장단점을 고려하여 선택해야 할 것이다.
구조간 장단점보다는 조직의 크기나 구성, 이미 결정된 구성원들의 스킬에 따라 적합한 구조를 선택하는 것이 더욱 중요할 것이다. 콘웨이의 법칙 (opens new window)에 따른다면, 개발의 구조는 결국 조직의 구조를 닮아야 효율적일 것이며 역으로 구조가 정해져 있다면 조직을 그에 맞게 재편성 해야 효율적인 개발이 가능할 것이다.
결국 전형적인 구조를 그대로 사용하는 것이 아니라 조직 구성을 고려하여 적절한 후보군을 선정하고 현실에 맞게 적당히 변형하고 세밀화 또는 간소화하여 구성해야 할 것이다.
절대적인 답이란 없다.