소프트웨어 디자인 패턴 - 7. 소프트웨어 디자인 패턴 비교 및 선택 기준

2025. 1. 20. 15:27소프트웨어/디자인 패턴

소개

소프트웨어 설계에서 다양한 디자인 패턴은 프로젝트의 요구사항에 따라 선택됩니다. 대표적인 패턴으로 MVC, MVP, MVVM, MVU, PAC, Flux가 있습니다. 이 문서는 각 패턴의 특징, 사용 사례, 비교, 그리고 선택 기준을 설명합니다.


1. 패턴 설명 및 특징

1.1. MVC (Model-View-Controller)

사용 사례:

  • 전통적인 웹 애플리케이션.
  • Ruby on Rails, ASP.NET MVC 같은 프레임워크.

산업 표준:

  • 간단한 블로그 플랫폼.
  • CRUD 기반의 애플리케이션.
  • Model: 데이터를 관리하고 비즈니스 로직을 수행. 독립적으로 동작하여 다른 구성 요소와의 의존성을 줄임.
  • View: 사용자 인터페이스(UI)를 담당. Model에서 데이터를 받아 화면에 렌더링.
  • Controller: 사용자 입력을 처리하고 Model과 View를 연결. Model의 상태를 변경하거나 View를 업데이트.

특징:

  • 간단한 구조로 이해하기 쉬움.
  • View와 Controller 간 강한 결합.
  • 전통적인 웹 애플리케이션에 적합.

1.2. MVP (Model-View-Presenter)

사용 사례:

  • 데스크톱 애플리케이션 (예: Windows Forms).
  • 모바일 애플리케이션.

산업 표준:

  • Android에서 Activity와 Presenter의 조합.
  • 게임 개발 UI 모듈.
  • Model: 데이터를 관리하고 상태를 유지. 비즈니스 로직과 데이터 저장소 역할 수행.
  • View: UI를 담당하며 Presenter로부터 데이터를 받아 화면에 표시. 사용자의 모든 입력은 Presenter로 전달됨.
  • Presenter: 비즈니스 로직을 처리하며 Model과 View를 연결. View와 1:1 관계를 유지.

특징:

  • View는 UI만 담당하고 모든 로직은 Presenter가 처리.
  • 테스트 용이성이 높아 단위 테스트에 유리.
  • View와 Presenter가 명확히 분리되어 유지보수에 유리.

1.3. MVVM (Model-View-ViewModel)

사용 사례:

  • 데이터 바인딩이 중요한 환경.
  • Angular, WPF(Windows Presentation Foundation).

산업 표준:

  • 금융 서비스 대시보드.
  • 실시간 데이터 기반 애플리케이션.
  • Model: 데이터를 관리하고 상태를 유지.
  • View: UI를 담당하며 ViewModel과 바인딩.
  • ViewModel: View와 Model 간의 중재자 역할. 데이터 바인딩을 통해 View와 통신.

특징:

  • 양방향 데이터 바인딩.
  • Angular와 같은 프레임워크에 적합.
  • 복잡한 UI와 상태 관리에 유리하며 대규모 애플리케이션에 적합.

1.4. MVU (Model-View-Update)

사용 사례:

  • 단방향 데이터 흐름이 중요한 환경.
  • Elm, React와 함께 사용.

산업 표준:

  • 채팅 애플리케이션.
  • 복잡한 상태 관리를 요구하는 대화형 웹 UI.
  • Model: 애플리케이션 상태를 표현. 불변성을 유지하며 새로운 상태를 생성.
  • View: 상태를 렌더링하며 사용자와 상호작용.
  • Update: 사용자 이벤트를 처리하고 새로운 상태를 반환.

특징:

  • Elm 아키텍처에서 파생된 패턴.
  • 단방향 데이터 흐름으로 상태 변경이 예측 가능.
  • 불변성을 유지해 디버깅과 상태 추적이 쉬움.

1.5. PAC (Presentation-Abstraction-Control)

사용 사례:

  • 계층적 시스템.
  • 멀티탭 브라우저, 대규모 UI 모듈.

산업 표준:

  • 내비게이션 시스템.
  • 독립적 모듈 설계를 요구하는 대형 애플리케이션.
  • Presentation: 사용자 인터페이스 및 입력 처리. 사용자와 상호작용하며 요청을 Control에 전달.
  • Abstraction: 데이터 처리 및 비즈니스 로직 담당. Presentation과 독립적으로 작동.
  • Control: Presentation과 Abstraction 간의 흐름을 제어하며 모듈 간 상호작용을 조정.

특징:

  • 계층적 구조로 구성되어 각 PAC 단위가 독립적으로 동작.
  • 예: 멀티탭 브라우저에서 각 탭이 독립적인 PAC 단위로 작동.

1.6. Flux

사용 사례:

  • React 애플리케이션.
  • 상태 관리가 복잡한 대규모 웹 애플리케이션.

산업 표준:

  • Facebook, Instagram.
  • 소셜 미디어 플랫폼, 대화형 웹 UI.
  • Store: 상태와 비즈니스 로직을 관리하며, 애플리케이션의 단일 진실 공급자 역할을 함.
  • Action: 사용자 또는 시스템 이벤트를 나타냄.
  • Dispatcher: Action을 Store로 전달하는 중앙 허브 역할.
  • View: Store의 상태를 받아 UI를 렌더링하고 사용자와 상호작용.

특징:

  • 단방향 데이터 흐름: Action -> Dispatcher -> Store -> View의 순서.
  • 상태 변경이 명확하며 디버깅이 쉬움.
  • React와 같은 프레임워크에서 적합하며 대규모 애플리케이션에서 유리.

2. 패턴 비교

기준  MVC  MVP  MVVM MVU  PAC  Flux
복잡성 낮음 중간 높음 높음 중간 높음
테스트 용이성 낮음 높음 높음 높음 중간 높음
상태 관리 단순 단순 복잡한 상태 관리 가능 복잡한 상태 관리 가능 계층적 상태 관리 복잡한 상태 관리 가능
프레임워크 적합성 전통적인 웹 앱 독립적 Angular 등 Elm 등 독립적 React 등

3. 선택 기준

프로젝트 규모

  • 간단한 UI: MVC 또는 MVP.
  • 복잡한 상태 관리: MVVM, Flux, MVU.

테스트 가능성

  • 로직이 View에서 분리된 패턴(MVP, MVVM, PAC)이 테스트에 유리.

프레임워크와의 적합성

  • Angular: MVVM.
  • React: Flux 또는 MVU.
  • Elm 기반 시스템: MVU.
  • 전통적인 웹 앱: MVC.