이번 포스팅은 .. MVC / MVVM / MVI를 정리하고 넘어가겠다
[MVC / MVVM / MVI 를 비교한 표]
이 세가지 디자인 패턴의 차이의 핵심은
"상태를 누가, 어떻게 어느 방향으로 관리하느냐" 에 있다
MVC ( Model - View - Controller )
Model(데이터, 비즈니스 로직) <-> View(화면) <-> Controller(사용자 입력 처리, 흐름제어)
MVC 패턴은 가장 기초적이고 널리 쓰이는 구조지만, 프로젝트 규모가 커질수록 고질적인 문제에 직면한다
1. Controller가 점점 비대해진다.
- 모든 서비스 로직이 Controller로 몰리면서 유효성 검사, 권한체크, 상태 분기, 로그 등이 쌓여 테스트 어려움, 가독성 저하와 같은 문제를 일으킨다
2. View와 Model의 의존성이 애매해진다.
- 이론상으론 Controller가 Model을 업데이트하고, Model이 변경되면 View가 갱신되어야 한다.
하지만 실제 구현 방식에 따라 View와 Model 사이에 강한 결합이 생기면서 View가 Model을 직접 참조하는 경우가 발생한다.
이때 코드의 재사용성이 급격히 떨어지는 일이 발생한다. 특정 Model에 종속된 View는 다른 화면에서 다시 쓰기 어렵다.
MVC 패턴은 구조가 단순하고 진입 장벽이 낮지만 위와 같은 문제가 발생하기 쉽다
이러한 이유로, 규모가 커지는 프로젝트에서는 MVC 외의 패턴을 고려하는 경우가 많다.
MVVM ( Model - View - VewModel )
View(UI렌더링) <-> ViewModel (UI상태 + 비즈니스 로직) -> Model(데이터, 도메인)
MVVM 패턴은 MVC의 고질적인 문제인 '비대한 Controller'와 '강한 의존성'을 해결하기 위해 등장했다
MVVM의 핵심은 상태를 관찰하며 화면을 자동으로 갱신하는 것이다
1. ViewModel이 상태관리의 중심이 된다
MVC에서 Controller가 담당하던 유효성 검사, 상태 분기, 비즈니스 로직 호출 등의 책임은 MVVM에서는 ViewModel로 이동한다
View는 사용자 이벤트를 ViewModel에 전달하고, ViewModel은 처리 결과를 UI상태로 만들어 관리한다
View는 이 상태를 관찰하며 변경이 발생할 때마다 화면을 갱신한다
2. View와 Model의 의존성이 분리된다
MVVM에서 View는 Model을 직접 참조하지 않고, 오직 ViewModel이 제공하는 상태만 바라본다
이는 데이터의 형태가 바뀌어도 ViewModel에서 가공해주면 되기 때문에 View를 수정할 일이 줄어든다.
또한 ViewModel을 공유하면서 View(디자인)만 교체하는 것도 가능해지니 UI 재사용성을 높일 수 있다
3. ViewModel도 비대해질 수 있다
MVVM이 Controller 비대화 문제를 해결해주긴 하지만, 모든 책임을 ViewModel로 옮기면 동일한 문제가 발생할거다
ViewModel에서 API 호출 세부 구현을 하고 데이터 가공, 상태 관리, 비즈니스 규칙까지 모두 처리하게 되면
결국 MVC에서 겪었던 고질적인 문제들을 되풀이하게 된다
이를 방지하기 위해 ViewModel은 상태를 관리하고 흐름을 조율하는 역할에만 집중하게 한다
실제 비즈니스 로직이나 데이터 접근은 Service 또는 UseCase 계층으로 분리해보자
ViewModel은 "무엇을 할지"를 결정하고, Service/UseCase는 "어떻게 처리할지"를 담당하는 구조가 되면
MVVM의 장점을 유지하면서도 확장성과 유지보수성을 확보할 수 있다.
MVI ( Model - View - Intent)
View(화면) -> Intent (사용자 의도, 이벤트) -> Model(현재 화면의 전체 상태) -> View(화면)
MVI 패턴은 화면의 모든 상태를 하나의 객체로 관리하고, 상태 변경을 오직 한 방향으로만 흐르게 강제한다
MVVM이 MVC의 많은 문제를 해결했지만, 프로젝트가 복잡해지면 MVVM에서도 문제가 좀 생긴다
vue, nuxt 프로젝트 기준으로 ViewModel안에 상태를 관리하는 변수인 ref가 2~30개씩 생길 수 있다
여기에 View가 ViewModel을 바꾸고, ViewModel이 View를 바꾸는 과정이 얽히면 문제가 생겼을 때 수천줄의 코드를 뒤져야 할 수도 있다
MVI는 위 문제를 해결하기 위해 나왔다 "상태를 하나로 관리하고 경로도 단방향으로 가자"
1. MVI의 핵심 개념
MVI는 아래 세가지로 구성된다
Intent -> Model -> View
가장 중요한 규칙 하나는 데이터 흐름은 반드시 단방향이라는거다
2. Intent - 상태 변경의 시작점
MVI에서 Intent는 사용자가 화면에서 어떤 행동을 했는지에 대한 선언이다
중요한 점은 Intent 자체는 단순히 "왜 상태를 바꿔야 하는지"를 명확히 드러내는 이름표에 가깝다
화면에서 상태가 바뀌는 모든 이유를 한곳에 모으고 주석을 안봐도 문서를 만들지 않아도 코드 자체가 설명서가 되도록 하자
이를 통해 상태를 변경하려면 반드시 Intent를 거쳐야 한다는 규칙이 생긴다
3. Model - 화면의 전체 상태
MVI에서 Model은 데이터베이스 모델이나 API 모델이 아닌 현재 화면이 어떤 상태인지에 대한 객체(State)를 의미한다
4. 언제 MVI를 사용하는게 좋을까 ?
MVI는 MVVM의 상태 분산으로 인한 관리 및 추적 어려움을 해소할 수 있지만 무조건 MVVM 보단 MVI 인건 아니다
상태가 단순한 화면에서는 MVVM 구조가 더 적합할 수 있다
디자인 패턴을 선택 시 MVI를 골랐다고 해서 모든 화면에 MVI를 적용하는 건 아니다
MVI는 아래와 같은 케이스에서 효과적이니 이때 적용 여부를 고민해보자
- 상태가 많을 때, 상태 변경 원인을 명확히 관리해야할 때
- 비동기 작업이 여러개 얽혀 있을 때
- 흐름이 복잡할 때
MVI는 나중에 헷갈리지 않기 위해 선택하는 구조라고 본다 ( 미래의 나와 팀원들을 위해 . . !? )
MVVM 패턴은 비교적 자유롭지만 유지보수할 때 부담이 될 수 있고
MVI는 비교적 자유롭지 못하지만 예측 가능성과 안정성을 얻을 수 있다
상황에 알맞게 잘 선택해보자
댓글