MVVM편집자 확인

모델 (Model)은 MVVM 아키텍처에서 애플리케이션의 핵심 데이터와 비즈니스 로직을 캡슐화하는 구성 요소이다. 모델은 애플리케이션이 다루는 실제 데이터, 데이터에 대한 유효성 검사 규칙, 그리고 데이터를 처리하는 계산이나 알고리즘을 포함한다. 이 계층은 뷰 (View)나 뷰모델 (ViewModel)과는 독립적으로 설계되며, 사용자 인터페이스가 어떻게 표시되는지에 대해서는 전혀 알지 못한다. 모델의 주요 책임은 데이터의 상태를 관리하고, 데이터 소스(예: 데이터베이스, 네트워크 API, 파일 시스템)와의 상호작용을 처리하며, 순수한 비즈니스 규칙을 적용하는 것이다.

모델은 일반적으로 다음과 같은 요소들로 구성된다.

* 데이터 엔티티(Entities): 애플리케이션에서 사용하는 실제 데이터 객체나 구조체를 정의한다. 예를 들어, 사용자 정보, 상품 목록, 설정값 등이 이에 해당한다.

* 비즈니스 로직(Business Logic): 데이터를 생성, 조회, 수정, 삭제(CRUD)하는 규칙과 알고리즘을 포함한다. 데이터의 유효성을 검사하거나 특정 조건에 따른 계산을 수행하는 코드가 여기에 위치한다.

* 데이터 접근 계층(Data Access Layer): 지속적 저장소나 외부 서비스로부터 데이터를 가져오거나 저장하는 로직을 담당한다. 이는 리포지토리(Repository) 패턴이나 데이터 서비스 클래스로 구현되는 경우가 많다.

모델은 뷰모델에 의해 소비된다. 뷰모델은 모델로부터 데이터를 요청하고, 필요에 따라 가공하여 뷰에 제공하기 적합한 형태로 변환한다. 모델 자체는 데이터 바인딩이나 UI 업데이트 알림 메커니즘을 직접 구현하지 않는다. 대신, 모델의 상태 변경은 일반적으로 옵저버 패턴이나 이벤트를 통해 뷰모델에 통지되거나, 뷰모델이 주기적으로 모델의 상태를 폴링(polling)하는 방식으로 전파된다. 이렇게 함으로써 모델은 프레젠테이션 로직이나 플랫폼 의존성으로부터 완전히 분리되어 재사용성과 테스트 용이성이 크게 향상된다.

뷰는 사용자에게 정보를 시각적으로 표시하고 사용자의 입력을 받는 역할을 한다. GUI 애플리케이션에서 UI를 구성하는 모든 요소, 즉 창, 버튼, 텍스트 상자, 목록 등을 포함한다. 뷰는 애플리케이션의 비즈니스 로직이나 데이터 상태를 직접 알지 못하며, 오직 뷰모델에 의해 제공되는 데이터와 명령에 의존하여 화면을 구성한다.

뷰의 주요 책임은 데이터 바인딩을 통해 뷰모델의 속성과 자신의 UI 요소를 연결하고, 사용자의 상호작용(예: 버튼 클릭, 텍스트 입력)을 뷰모델에 정의된 명령(Command)으로 전달하는 것이다. 이로 인해 뷰는 최소한의 코드, 주로 XAML, HTML, XML과 같은 선언적 마크업으로 작성된다. 코드-비하인드(Code-Behind) 파일이 존재할 수 있지만, 그 목적은 UI 관련 로직(예: 애니메이션 제어)에 국한되어야 하며 데이터 조작이나 비즈니스 규칙을 포함해서는 안 된다.

이러한 분리는 뷰를 독립적으로 개발하고 테스트할 수 있게 하며, 특히 디자이너와 개발자의 협업을 용이하게 한다. 디자이너는 실제 데이터나 로직 없이도 뷰모델의 구조만 참조하여 UI 디자인에 집중할 수 있다. 또한, 동일한 뷰모델에 바인딩되는 여러 뷰(예: 데스크톱용 뷰와 모바일용 뷰)를 만들어 재사용성을 높일 수 있다.

뷰모델은 MVVM 패턴의 핵심 구성 요소로, 뷰와 모델 사이의 중개자 역할을 한다. 뷰모델은 모델의 데이터를 가져와 뷰에서 표시하기 적합한 형태로 가공하고, 뷰로부터의 사용자 입력을 처리하여 모델을 업데이트하는 로직을 포함한다. 뷰모델은 뷰에 대한 직접적인 참조를 가지지 않으며, 이는 두 계층 간의 강한 결합을 제거하는 데 기여한다.

뷰모델의 주요 책임은 뷰를 위한 상태와 동작을 제공하는 것이다. 여기에는 모델 데이터를 변환한 속성(Property)과 사용자 상호작용에 반응하는 명령(Command)이 포함된다. 예를 들어, 날짜 데이터를 특정 형식의 문자열로 변환하거나, 여러 데이터 항목을 집계하여 하나의 요약 정보를 생성하는 작업을 수행한다. 이러한 변환 로직은 뷰모델에 캡슐화되어 뷰는 단순히 제공된 데이터를 표시하는 데 집중할 수 있다.

뷰모델은 종종 데이터 바인딩 메커니즘을 통해 뷰와 연결된다. 뷰모델이 구현하는 속성 변경 알림 인터페이스(예: INotifyPropertyChanged)를 통해, 속성 값이 변경되면 뷰에 자동으로 알림이 전달되어 UI가 갱신된다. 마찬가지로, 뷰모델이 제공하는 ICommand 인터페이스를 구현한 명령 객체는 버튼 클릭과 같은 사용자 액션을 뷰모델의 메서드에 바인딩하는 데 사용된다.

뷰모델의 설계는 특정 UI 기술이나 플랫폼에 의존하지 않도록 하는 것이 이상적이다. 이는 뷰모델을 다양한 뷰(예: 데스크톱 앱의 창, 웹 페이지, 모바일 앱의 화면)에서 재사용하거나 단위 테스트하기 쉽게 만든다. 테스트 가능성은 MVVM의 주요 장점 중 하나로, 뷰 없이도 뷰모델의 비즈니스 로직과 상태 변환 로직을 독립적으로 검증할 수 있다.

데이터 바인딩은 뷰의 UI 요소와 뷰모델의 속성을 선언적으로 연결하는 메커니즘이다. 이 연결을 통해 뷰모델의 데이터 상태가 변경되면 자동으로 뷰에 반영되고, 사용자가 뷰를 조작하면 그 변경 사항이 다시 뷰모델의 속성에 자동으로 업데이트된다. 이는 양방향 또는 단방향으로 설정할 수 있으며, 뷰와 비즈니스 로직 사이의 동기화를 위한 상용구 코드(boilerplate code)를 크게 줄여준다.

구현 방식은 플랫폼에 따라 다르다. WPF에서는 XAML 마크업 내에서 Binding 구문을 사용하고, 안드로이드 Jetpack에서는 LiveData나 StateFlow와 함께 데이터 바인딩 라이브러리를 활용한다. SwiftUI는 @State, @ObservedObject와 같은 속성 래퍼를 통해 선언적 바인딩을 제공한다. 이러한 프레임워크들은 내부적으로 옵저버 패턴을 사용하여 데이터 변경을 감지하고 뷰를 갱신한다.

데이터 바인딩의 주요 이점은 뷰와 뷰모델 간의 명시적 참조를 최소화한다는 점이다. 뷰는 뷰모델의 구체적 구현을 알 필요 없이, 단순히 노출된 속성에 바인딩하기만 하면 된다. 이로 인해 뷰의 코드는 주로 레이아웃과 사용자 인터페이스를 정의하는 데 집중할 수 있고, 단위 테스트 가능성이 높아진다. 그러나 과도하거나 복잡한 바인딩 표현식은 디버깅을 어렵게 만들 수 있으며, 뷰와 뷰모델 사이의 의존성을 오히려 숨길 위험이 있다.

명령(Command)은 MVVM 아키텍처에서 뷰모델(ViewModel)이 뷰(View)로부터 사용자 상호작용(예: 버튼 클릭, 메뉴 선택)을 수신하고 처리하기 위한 메커니즘이다. 이는 뷰의 코드-비하인드(Code-Behind)에 이벤트 핸들러를 직접 작성하는 전통적인 방식을 대체하여, 뷰와 뷰모델 간의 결합도를 낮추는 데 핵심적인 역할을 한다.

명령은 일반적으로 ICommand 인터페이스(또는 해당 플랫폼의 동등한 추상화)를 구현하여 생성된다. 이 인터페이스는 명령의 실행 가능 여부를 판단하는 CanExecute 메서드와 실제 로직을 수행하는 Execute 메서드로 구성된다. 뷰의 UI 요소(예: 버튼)는 이 명령 객체에 바인딩되며, 사용자 동작이 발생하면 바인딩된 명령의 Execute 메서드가 호출된다. 동시에 CanExecute 메서드의 반환값에 따라 UI 요소의 활성화 상태(Enabled/Disabled)가 자동으로 제어된다.

구현 방식은 플랫폼에 따라 다르다. WPF와 Xamarin에서는 ICommand 인터페이스와 DelegateCommand 또는 RelayCommand 같은 헬퍼 클래스를 주로 사용한다. Android Jetpack에서는 LiveData나 Kotlin 코루틴과 함께 사용되는 별도의 패턴을 제공하며, SwiftUI에서는 @Published 속성과 액션 클로저를 조합하여 유사한 패턴을 구현한다. 명령 패턴의 적절한 적용은 뷰모델의 순수성과 테스트 용이성을 크게 향상시킨다.

MVVM에서 뷰와 뷰모델 간의 통신은 주로 데이터 바인딩과 명령(Command)을 통해 이루어진다. 그러나 특정 상태 변화나 비동기 작업 완료와 같은 사건을 알리기 위해서는 추가적인 이벤트 또는 알림 메커니즘이 필요하다. 이러한 메커니즘은 뷰모델이 뷰에게 직접적인 참조 없이도 특정 동작(예: 페이지 전환, 다이얼로그 표시)을 요청할 수 있게 한다.

주요 구현 방식으로는 이벤트 집합자(Event Aggregator)나 메시지 버스(Message Bus) 패턴을 활용하는 방법이 있다. 뷰모델은 이벤트를 발행(Publish)하고, 뷰는 해당 이벤트를 구독(Subscribe)하여 처리한다. 또한, 옵저버 패턴을 구현한 Reactive Extensions(Rx) 라이브러리나 플랫폼별 알림 시스템(예: Android의 LiveData 관찰, SwiftUI의 @Published 속성)을 사용하기도 한다. 이는 두 계층 간의 강한 결합을 피하면서도 유연한 상호작용을 가능하게 한다.

이러한 알림 시스템을 설계할 때는 메모리 누수를 방지하기 위해 구독 해제 로직을 명확히 관리해야 한다. 또한, 과도한 이벤트 사용은 흐름을 복잡하게 만들 수 있으므로, 단순 상태 전달은 데이터 바인딩을 우선적으로 고려하는 것이 바람직하다.

WPF는 마이크로소프트가 .NET Framework 3.0과 함께 도입한 GUI 프레임워크이다. WPF는 MVVM 패턴의 채택과 발전에 결정적인 역할을 했다. WPF의 핵심 기능인 강력한 데이터 바인딩 시스템, XAML 선언형 마크업 언어, 그리고 의존성 속성과 커맨드 패턴과 같은 기능들은 MVVM 패턴을 구현하기에 이상적인 기반을 제공했다.

WPF에서 뷰모델은 보통 일반 CLR 객체로 구현되며, INotifyPropertyChanged 인터페이스를 구현하여 속성 변경 알림을 제공한다. 뷰의 UI 요소는 XAML을 통해 이러한 뷰모델의 속성에 바인딩된다. 사용자 상호작용은 ICommand 인터페이스를 구현한 커맨드 객체를 통해 뷰모델에 전달되어 비즈니스 로직이 실행된다. 이 구조는 뷰의 코드-비하인드 파일을 최소화하고, 뷰와 로직의 명확한 분리를 가능하게 한다.

WPF의 MVVM 구현을 지원하는 주요 도구와 패턴은 다음과 같다.

이러한 WPF의 특성 덕분에 MVVM 패턴은 윈도우 데스크톱 애플리케이션 개발에서 사실상의 표준 아키텍처 패턴으로 자리 잡았다. WPF의 사례는 이후 안드로이드의 Jetpack, 애플의 SwiftUI와 같은 다른 플랫폼의 현대적 UI 프레임워크 설계에도 영향을 미쳤다.

Android Jetpack은 안드로이드 앱 개발을 위한 라이브러리, 도구, 가이드 모음이다. Jetpack의 아키텍처 컴포넌트는 MVVM 패턴을 구현하는 데 필수적인 요소들을 공식적으로 제공하여 생산성과 앱의 견고성을 높인다. 그중 ViewModel과 LiveData는 뷰와 데이터의 생명주기를 분리하고, 데이터 변화를 관찰 가능하게 하는 핵심 컴포넌트이다.

ViewModel 클래스는 화면 회전과 같은 구성 변경(configuration change) 동안에도 데이터를 유지하도록 설계되었다. 이는 액티비티나 프래그먼트의 라이프사이클보다 더 긴 수명을 가지며, 뷰가 파괴되고 재생성되는 과정에서도 데이터를 안전하게 보관한다. 뷰모델은 일반적으로 LiveData나 StateFlow와 같은 관찰 가능한 데이터 홀더를 포함하여, 뷰(액티비티/프래그먼트)가 이 데이터를 구독하고 자동으로 UI를 갱신할 수 있게 한다.

LiveData는 수명 주기를 인식하는(lifecycle-aware) 관찰 가능한(observable) 데이터 홀더 클래스이다. LiveData는 활성 상태(예: STARTED 또는 RESUMED)인 라이프사이클 소유자(주로 액티비티나 프래그먼트)만을 관찰자로 등록하며, 이 소유자의 라이프사이클이 DESTROYED 상태가 되면 자동으로 관찰을 중지하여 메모리 누수를 방지한다. 데이터가 변경되면 활성 상태의 관찰자들에게만 알림을 보내 UI를 갱신한다. ViewModel과 LiveData의 일반적인 사용 패턴은 다음과 같다.

이 조합은 데이터 바인딩 라이브러리와 함께 사용될 때 더욱 강력해진다. 데이터 바인딩을 사용하면 XML 레이아웃 파일에서 직접 LiveData를 참조하여 선언적으로 UI를 업데이트할 수 있어, 액티비티/프래그먼트의 관찰 코드를 더욱 간소화한다.

SwiftUI는 애플의 선언형 UI 프레임워크로, MVVM 패턴을 구현하기에 매우 적합한 환경을 제공한다. SwiftUI의 뷰는 상태(State)와 바인딩(Binding)을 통해 뷰모델의 데이터 변화를 자동으로 반영하며, 뷰의 구조 자체가 데이터의 함수와 같다는 선언적 특성을 지닌다. 이는 명령형 프로그래밍 방식의 UIKit과 대비되는 핵심 차이점이다.

Combine 프레임워크는 SwiftUI와 함께 MVVM의 뷰모델 계층을 구성하는 데 중요한 역할을 한다. Combine은 시간에 따라 변하는 값을 나타내는 Publisher와 이를 구독하는 Subscriber 패턴을 제공하여, 비동기 이벤트 스트림을 선언적으로 처리할 수 있게 한다. 뷰모델은 @Published 프로퍼티 래퍼를 사용하여 상태를 발행하고, SwiftUI 뷰는 @ObservedObject 또는 @StateObject를 통해 이를 관찰하고 자동으로 UI를 업데이트한다.

SwiftUI와 Combine을 활용한 MVVM 구현의 일반적인 구조는 다음과 같다.

이 조합은 데이터 흐름이 단방향으로 명확하며, 뷰와 비즈니스 로직의 분리가 강제된다는 장점이 있다. 그러나 뷰모델이 ObservableObject에 강하게 결합되고, 복잡한 데이터 변환 파이프라인을 구성할 때 Combine 오퍼레이터의 학습 곡선이 존재한다는 점은 고려해야 한다.

Vue.js는 선언적 렌더링과 반응형 데이터 시스템을 기반으로 MVVM 패턴을 공식적으로 채택하고 구현한 대표적인 프론트엔드 프레임워크이다. Vue 인스턴스나 컴포넌트가 뷰모델의 역할을 수행하며, data 객체는 모델의 상태를, template(또는 SFC의 <template> 블록)은 뷰를 담당한다. Vue의 반응성 시스템은 데이터 변경을 자동으로 감지하여 뷰를 업데이트하는 강력한 데이터 바인딩을 제공한다. v-model 디렉티브는 양방향 바인딩을, v-bind는 단방향 바인딩을 구현하는 전형적인 예시이다.

반면, React는 자체적으로 MVVM 패턴을 명시적으로 지향하지는 않지만, 그 핵심 개념을 컴포넌트 기반 아키텍처에 효과적으로 적용할 수 있다. React에서 뷰는 컴포넌트의 render 메서드 또는 함수형 컴포넌트의 반환값에 해당한다. 모델은 컴포넌트의 state 객체나 외부 상태 관리 라이브러리(예: Redux, MobX, Recoil)의 상태 저장소로 볼 수 있다. 뷰모델에 해당하는 계층은 명확하게 분리되어 있지 않으나, 컴포넌트 자체의 로직(useState, useEffect 훅을 포함한), 또는 상태와 비즈니스 로직을 관리하는 커스텀 훅이 그 역할을 수행한다고 해석할 수 있다.

두 라이브러리의 접근 방식은 다음과 같이 비교된다.

결론적으로, Vue.js는 MVVM 패턴을 프레임워크 수준에서 직접 지원하는 반면, React는 선언적 UI와 상태 관리 원칙을 통해 유사한 분리와 관심사를 달성한다. React 애플리케이션에서 Flux 아키텍처나 Observer 패턴을 기반으로 한 상태 관리 라이브러리를 도입하면, 뷰모델의 책임을 더 명확하게 외부로 분리하는 구조를 만들 수 있다.

MVC는 소프트웨어 아키텍처 패턴의 하나로, 애플리케이션의 구성 요소를 모델, 뷰, 컨트롤러의 세 가지 역할로 분리하여 개발하는 방식을 말한다. 이 패턴은 1970년대 제록스 팰로앨토 연구소에서 소개되었으며, 주로 데스크톱 애플리케이션과 웹 애플리케이션 개발에 널리 사용되었다[2].

MVC 패턴에서 각 구성 요소의 역할은 다음과 같다.

동작 흐름은 일반적으로 사용자 입력이 컨트롤러에 전달되고, 컨트롤러는 모델의 상태를 변경하거나 업데이트를 요청한다. 모델이 변경되면, 뷰는 해당 변경 사항을 자동으로 감지하거나 컨트롤러의 지시에 따라 화면을 갱신한다. 이는 뷰와 모델 사이의 직접적인 연결을 최소화하려는 의도이다.

그러나 전통적인 MVC 구현에서는 뷰가 모델을 직접 관찰하여 업데이트하는 경우가 많았고, 이로 인해 뷰와 모델 사이에 의존성이 생기는 문제가 발생하기도 했다. 또한 컨트롤러의 역할이 비대해지고 테스트가 어려워질 수 있다는 점이 지적되었다. 이러한 한계점을 보완하고자 MVP나 MVVM과 같은 변형 패턴들이 등장하게 되었다.

MVP는 MVC 패턴의 변형으로, 뷰와 모델 사이의 상호작용을 중재하는 프레젠터 컴포넌트를 도입한 소프트웨어 아키텍처 패턴이다. 이 패턴은 주로 GUI 애플리케이션에서 뷰의 책임을 줄이고 테스트 가능성을 높이기 위해 개발되었다.

MVP는 세 가지 핵심 구성 요소로 이루어진다. 모델은 애플리케이션의 데이터와 비즈니스 로직을 캡슐화한다. 뷰는 사용자 인터페이스를 표시하고 사용자 입력을 수신하는 수동적인 컴포넌트이다. 프레젠터는 뷰와 모델 사이의 중개자 역할을 하며, 뷰로부터의 사용자 입력을 처리하고, 모델에서 데이터를 가져와 가공한 후, 뷰에 표시할 형식으로 변환하여 업데이트를 지시한다. 뷰와 프레젠터는 일반적으로 1:1 관계를 가지며, 뷰는 프레젠터에 대한 참조를 갖는 경우가 많다.

MVP의 주요 장점은 뷰를 가능한 한 멍청하게 만들어 UI 로직을 프레젠터로 분리함으로써 단위 테스트를 용이하게 한다는 점이다. 뷰는 인터페이스를 통해 프레젠터와 통신하므로, 실제 UI 없이도 프레젠터의 로직을 테스트할 수 있다. 그러나 단점으로는 프레젠터가 뷰의 상태와 강하게 결합될 수 있어, 프레젠터 자체가 복잡해지고 재사용성이 떨어질 수 있다는 점이 지적된다. 이는 MVVM 패턴이 데이터 바인딩을 통해 뷰와의 결합도를 더 낮추는 동기를 제공했다.

뷰모델의 라이프사이클 관리는 MVVM 아키텍처를 올바르게 구현하고 메모리 누수를 방지하는 데 핵심적인 요소이다. 뷰모델은 일반적으로 뷰와 독립적인 생명주기를 가지도록 설계되며, 이는 뷰가 파괴되고 재생성되는 상황(예: 기기 회전, 구성 변경)에서도 데이터를 유지할 수 있게 해준다. 그러나 뷰모델이 더 이상 필요하지 않을 때 적절하게 정리되지 않으면, 뷰나 다른 객체에 대한 참조를 계속 유지하여 메모리 누수가 발생할 수 있다.

주요 플랫폼별 라이프사이클 관리 접근법은 다음과 같다.

관리 전략으로는, 뷰모델이 뷰나 안드로이드 컨텍스트 같은 라이프사이클이 짧은 객체에 대한 직접 참조를 보유하지 않도록 하는 것이 중요하다. 대신 라이브데이터나 플로우 같은 관찰 가능한 데이터 홀더를 사용하여 간접적으로 통신해야 한다. 또한 뷰모델 내부에서 시작된 비동기 작업이나 이벤트 구독은 뷰모델이 소멸될 때 반드시 취소되거나 정리되어야 한다. 많은 프레임워크는 뷰모델 소멸 시 호출되는 콜백 메서드(예: 안드로이드의 onCleared())를 제공하여 이러한 정리 작업을 수행할 수 있는 기회를 준다.

적절한 라이프사이클 관리는 뷰모델이 필요한 기간 동안만 존재하도록 보장하며, 애플리케이션의 성능과 안정성을 크게 향상시킨다. 이는 특히 모바일 애플리케이션처럼 제한된 시스템 자원 환경에서 중요하다.

데이터 바인딩은 MVVM 패턴의 핵심 메커니즘으로, 뷰와 뷰모델 간의 동기화를 자동화하여 생산성을 높인다. 그러나 과도하거나 부적절하게 사용된 데이터 바인딩은 성능 저하와 유지보수성을 떨어뜨리는 주요 원인이 된다. 특히 복잡한 UI를 가진 화면에서 수십 개의 컨트롤이 하나의 뷰모델 속성에 바인딩되거나, 깊은 객체 그래프를 가진 데이터를 바인딩할 때 성능 문제가 발생할 수 있다[4].

과도한 데이터 바인딩을 방지하기 위한 주요 접근법은 다음과 같다. 첫째, 바인딩 대상이 되는 데이터의 양과 복잡성을 최소화한다. 뷰에 표시하기 위해 필요한 최소한의 데이터만 뷰모델이 제공하도록 설계하고, 필요 이상으로 큰 객체 전체를 바인딩하지 않는다. 둘째, 바인딩 모드를 적절히 선택한다. 모든 바인딩을 기본 양방향(TwoWay)으로 설정하기보다, 읽기 전용인 경우 단방향(OneWay) 또는 일회성(OneTime) 바인딩을 사용하여 불필요한 변경 감지 오버헤드를 줄인다. 셋째, 가상화(Virtualization)가 지원되는 컨트롤(예: 리스트, 그리드)을 사용하여 화면에 보이는 항목만 실제로 렌더링하고 바인딩하도록 한다.

또한, 바인딩 경로가 너무 길거나 복잡한 계산을 포함하는 경우 성능에 영향을 미칠 수 있다. 이러한 경우, 뷰모델에서 미리 계산된 값을 별도의 속성으로 제공하는 것이 바람직하다. 메모리 누수를 방지하기 위해 이벤트 핸들러나 구독(Subscription)을 적절한 시점(예: 뷰의 라이프사이클 종료 시)에 해제하는 것도 중요하다. 프레임워크별로 제공되는 도구(예: WPF의 성능 프로파일러, Android Studio의 Layout Inspector)를 활용하여 바인딩 성능 병목 현상을 식별하고 최적화할 수 있다.