[SaaS] 왜 우리는 뷰모델링을 중요하게 생각하는가

Context

클라이언트 애플리케이션이 정적 페이지에서 동적 페이지로 변화하면서 다양한 상태 관리, 사용자 입력, 네트워크 환경 등을 고려해야 하는 복잡도가 증가했다. 도메인 모델을 직접 뷰에 차용하면 추후 도메인 모델과 UI 변화에 취약해지고 지속적인 가치 제공이 어려워진다.

Technical Solution

• 뷰모델링을 도메인 모델링처럼 UI 상태와 액션을 추상화하고 설계하는 작업으로 정의: UI 표현에 필요한 상태 정의, 상태 저장 및 관리 방식, 액션 발생 시 상태 변환 과정 전체 포함
• FLUX 패턴 도입으로 단방향 데이터 흐름 구현: Action을 통한 단일 진입점으로 상태 변경을 제어하고 부수 효과 최소화
• State, Action, Store 3계층 구조로 상태 관리 체계화: State는 UI 렌더링을 위한 최신 스냅샷, Action은 상태 변화 인터페이스, Store는 상태 보관 및 Action 처리
• 도메인 모델과 UI 상태를 명확히 격리: BFF나 SDUI 응답 구조도 뷰모델로 정의하여 양쪽 계층 간 결합도 감소
• 복잡도 수준별로 뷰모델링 추상화 수준 차등 적용: 단순 CRUD는 로컬 상태 + TanStack Query 활용, 중간 복잡도는 Context + 커스텀 훅 사용, 엔터프라이즈 급은 UI/도메인 상태 분리 및 Mapper 제공

Key Takeaway

프론트엔드 상태 관리는 기술 메커니즘(Redux, Recoil 등) 선택이 아니라 화면에 필요한 데이터와 동작을 추상화해 "무엇을 어떻게 관리할지" 먼저 정의하는 개념적 설계 과정이며, DDD의 사고방식을 프론트엔드에 적용하면 복잡한 UI 상태와 백엔드 통신을 효과적으로 처리할 수 있다.