📚 자료실

MVC, MVVM, MVP, MVI 디자인 패턴과 데이터 흐름

hjinn0813 2024. 11. 29. 10:04
728x90

지난달에 Flux 패턴과 관련해서 공부하면서 잠깐 정리했었고, 정보처리기사 필기 준비할 때도 봤던 기억이 있는데, 한번도 기본 개념을 제대로 정리한 적이 없어서 이번 기회에 정리해본다. 회사에서 MVC패턴이 굉장히 자주 언급되어서, 어렴풋하게만 알고 있던걸 제대로 이해하고 있어야겠다고 생각했다.

※ Flux 패턴의 기본 개념 정리 - https://hjinn0813.tistory.com/136

 

Flux 패턴의 기본 개념

Redux, Zustand 같은 전역 상태관리 라이브러리는 Flux 패턴을 기반으로 만들어졌다.

hjinn0813.tistory.com

데이터 흐름의 차이

디자인 패턴들의 기본 개념을 정리하기 전에, 데이터 흐름에 대해서부터 알아야 한다.

"데이터 흐름"이라는건 사용자가 어떤 요청(클릭, 입력, 이벤트 등)을 했을 경우에, 그 요청이 처리되어 화면에 결과가 표시되기까지의 경로를 의미한다. 크게 양방향, 단방향으로 나눌 수 있다.

단방향 흐름 양방향 흐름
- 데이터가 한 방향으로만 흐름.
- "사용자 → Model 업데이트 → View 반영"처럼 데이터의 흐름이 순환하지 않고 한쪽 방향으로 고정된 구조.
- 변경된 데이터는 다시 원점으로 돌아오지 않음.
- 장점: 데이터 흐름이 명확하고 예측 가능.		 - 데이터가 상호작용하며 흐름.
- "사용자 → Model 업데이트 → View 업데이트 → 다시 사용자 행동 또는 데이터 수정"처럼, View와 데이터(Model)가 서로 영향을 주고받음.
- 장점: 사용자 행동과 데이터가 실시간으로 상호작용.

MVC (Model-View-Controller)

  • Model: 데이터와 비즈니스 로직을 처리한다. 데이터가 어떻게 변경되고 조작될 수 있는지에 관한 규칙을 정의한다.
  • View: 사용자에게 보여지는 UI 구성요소. 컨트롤러에서 받은 UI 데이터를 표시한다.
  • Controller: Model과 View 사이를 연결한다. Model을 통해 받은 데이터를 처리하여 결과를 View에 반영한다.

MVC 작동 순서

  1. 사용자 요청: 사용자가 버튼 클릭, 데이터 입력 등 UI를 통해 요청을 보냄.
  2. Controller 처리: Controller가 요청을 받음. 사용자의 행동을 해석하여 필요한 작업을 결정.
  3. Model 업데이트: Controller가 Model을 업데이트하거나 필요한 데이터를 요청.
  4. View 업데이트: Model이 데이터 변경 사항을 Controller에 알려주고, Controller가 View를 업데이트.
  5. 결과 표시: View가 사용자에게 결과를 보여줌.
* 예제: 로그인 화면
사용자가 아이디, 비밀번호 입력 후 로그인 시도(버튼 클릭)
→ Controller가 입력된 정보를 Model에 전달
→ Model이 서버와 통신해 결과를 반환
→ Controller가 View에 성공/실패 결과를 표시

MVC 특징

  • Controller와 View의 관계가 1:N 구조: 하나의 Controller가 여러 View를 제어할 수 있음.
    예: 동일한 데이터(Model)를 웹(브라우저)과 모바일 앱에서 다르게 보여줄 때 활용 가능.
  • View와 Controller 간의 강결합: 서로 직접적으로 참조하므로, 수정 시 서로 영향을 줄 가능성이 있음.
  • 단방향 흐름: 요청이 Controller를 통해 Model로 전달되고, 결과가 다시 View로 흘러감.
    MVC는 요청(Controller → Model)과 결과(View로 전달)가 단방향처럼 보이는 부분도 있지만, 사실 View와 Controller가 강하게 결합되어 있어서 양방향 흐름이 발생할 수 있다.
    예를 들어: View에서 사용자가 버튼을 클릭 → Controller로 요청 전달. Controller가 Model을 업데이트 → Model이 데이터를 반환하면 → View를 업데이트. 하지만 View와 Controller가 긴밀히 연결되어 다시 사용자 입력을 받을 준비 상태로 돌아감.

MVC 장단점, 대표 기술

  • 장점: 분리된 구조로 코드가 명확해짐. 소규모 프로젝트에서 쉽게 적용 가능.
  • 단점: View와 Controller의 강결합 문제로 의존성이 커지기 쉬움. 복잡한 프로젝트에서는 유지보수가 어려울 수 있음.
  • 대표 기술: Django, Ruby, Spring, ASP.NET 등 (서버 렌더링 웹사이트에서 많이 사용됨)

MVVM (Model-View-ViewModel)

  • Model: 데이터와 비즈니스 로직 처리.
  • View: 사용자 UI.
  • ViewModel: View와 Model을 중계하고, 상태 관리. 주로 데이터 바인딩을 사용해 View와 ViewModel이 연결됨.

MVVM 작동 순서

  1. 사용자 요청: 사용자가 UI를 통해 요청을 보냄.
  2. ViewModel에 전달: View는 사용자 이벤트를 ViewModel에 바인딩.
  3. Model 업데이트: ViewModel이 Model에 데이터를 요청하거나 업데이트 작업 수행.
  4. View 업데이트: Model에서 변경된 데이터가 ViewModel에 전달되고, ViewModel이 View와 바인딩되어 View가 자동으로 업데이트됨.
* 예제: 쇼핑몰 상품 검색
사용자가 쇼핑몰에서 검색어를 입력
→ ViewModel이 검색어를 Model에 전달
→ Model이 검색 결과를 반환
→ ViewModel에서 데이터가 바뀌고 View가 자동으로 결과를 업데이트.

MVVM 특징

  • View와 ViewModel의 데이터 바인딩: View는 ViewModel에 직접 연결되며, 데이터가 변경되면 자동으로 UI가 업데이트됨. 양방향 데이터 바인딩이 특징적. ViewModel의 데이터가 업데이트되면 View가 자동으로 반영되고, 반대로 View에서 사용자 입력이 발생하면 바로 ViewModel로 전송되어 데이터 변경에 영향을 줌.
  • View는 최대한 단순화, 상태 관리는 ViewModel: View는 UI를 렌더링하는 데 집중하고, 로직과 상태 관리는 ViewModel이 담당.
  • 테스트 용이성: ViewModel은 UI에 독립적이므로 단위 테스트가 쉬움.
  • 복잡한 UI 상태 관리에 강함: 복잡한 사용자 인터랙션이나 UI 상태를 효율적으로 처리할 수 있음.

MVVM 장단점, 대표 기술

  • 장점: View와 Model 간의 강결합을 줄임. 데이터 바인딩을 통해 UI 업데이트 코드가 줄어듦.
  • 단점: 데이터 바인딩 사용 시 디버깅이 어려울 수 있음. 복잡한 상태 관리를 잘 설계하지 않으면 오히려 코드가 꼬일 수 있음.
  • 대표 기술: Andriod Jetpack, Vue, Angular 등

MVP (Model-View-Presenter)

  • Model: 데이터와 비즈니스 로직 처리.
  • View: UI 담당. (Presenter가 요청한 데이터만 표시)
  • Presenter: Model과 View를 연결하며, View와 강결합을 피하기 위해 인터페이스를 활용.

MVP 작동 순서

  1. 사용자 요청: 사용자가 UI를 통해 요청을 보냄.
  2. Presenter 처리: View는 이벤트를 Presenter에 전달.
  3. Model 업데이트: Presenter가 Model에 데이터를 요청하거나 업데이트 작업 수행.
  4. View 업데이트: Model에서 데이터를 받은 Presenter가 View를 업데이트하도록 요청.
* 예제: 채팅 앱 메시지 전송
사용자가 채팅 창에 메시지 입력
→ View가 Presenter에 전달
→ Presenter가 Model에 메시지를 저장하거나 서버에 전송
→ 성공/실패 결과를 받아 Presenter가 View를 업데이트

MVP 특징

  • View와 Presenter 간의 인터페이스로 연결
    View는 Presenter와 인터페이스를 통해 통신하여 의존성을 줄임.
    Presenter는 View를 간접적으로 업데이트하므로 View를 독립적으로 테스트할 수 있음.
  • View와 Presenter의 1:1 관계
    하나의 View에 하나의 Presenter가 연결되는 구조이지만, Presenter가 너무 커질 수 있음 (이른바 "God Presenter" 문제).
  • UI 논리가 Presenter로 집중되며, View는 단순히 데이터만 렌더링.
  • 양방향 데이터 흐름: View와 Presenter 간의 상호작용을 인터페이스를 통해 처리하지만, 기본적으로 View ↔ Presenter 간 상호작용이 계속해서 반복되므로 양방향 흐름으로 볼 수 있다. 예를 들어, Presenter가 사용자 입력을 Model에 반영하고, Model의 결과를 View에 다시 보여주면서 Presenter가 View와 지속적으로 통신.

MVP 장단점, 대표 기술

  • 장점: View는 Presenter와 인터페이스로 연결되므로 독립적으로 테스트 가능. UI 논리가 Presenter로 이동해 더 간단한 View 구현이 가능.
  • 단점: Presenter의 코드가 방대해질 수 있음. 너무 많은 인터페이스가 설계되면 복잡성이 증가.
  • 대표 기술: Android MVP, Swing 기반 애플리케이션, GWT (Google Web Toolkit) 등

MVI (Model-View-Intent)

  • Model: 데이터와 상태를 관리.
  • View: UI 담당.
  • Intent: 사용자 입력(이벤트)을 처리하여 상태를 업데이트하고 Model에 반영. 단방향 데이터 흐름을 강조.

MVI 작동 순서

  1. 사용자 요청(Intent 생성): 사용자가 UI를 통해 요청을 보냄. Intent(사용자의 의도)를 생성.
  2. Intent 처리: Intent가 Model에 전달되어 작업 실행.
  3. 새로운 상태 생성: Model이 상태를 업데이트하고 새로운 상태(State)를 반환.
  4. View 렌더링: 새로운 상태를 기반으로 View를 다시 그려서 사용자에게 보여줌.
*예제: 뉴스 앱 스크롤 갱신
사용자가 새로고침 버튼 클릭
→ Intent가 서버에서 새로운 뉴스를 가져오도록 요청
→ Model이 상태 업데이트
→ View가 새로운 뉴스 상태로 다시 렌더링

MVI 특징

  • 단방향 데이터 흐름 (Unidirectional Data Flow)
    Intent(사용자 행동) → Model(상태 업데이트) → View(결과 렌더링)으로 흐름이 고정되어 있음.
    상태(State)로 전체 UI를 관리하며, 예측 가능한 동작이 가능.
  • Immutable 상태 관리
    상태(State)는 변경 불가능(Immutable)하며, 상태가 업데이트되면 새로운 상태로 View를 렌더링.
  • 테스트와 디버깅 용이성
    모든 상태와 Intent를 기록할 수 있으므로, 복잡한 애플리케이션에서 디버깅과 로깅이 쉬움.
  • 복잡한 상태 관리 가능
    비동기 작업, 여러 사용자의 입력 등 복잡한 상태를 한 곳에서 관리 가능.

MVI 장단점, 대표 기술

  • 장점: 상태 관리와 데이터 흐름이 명확. 코드의 테스트 용이성 증가.
  • 단점: 전체 상태를 관리하기 때문에 복잡성이 증가할 수 있음. 작은 프로젝트에는 과도한 설계가 될 수 있음.
  • 대표 기술: React, Flutter, Jetpack Compose 등
728x90
저작자표시 비영리 변경금지