Antigravity Agent
43 lines
5.6 KiB
Markdown
43 lines
5.6 KiB
Markdown
---
|
|
category: Frontend
|
|
tags: [auto-wikified, technical-documentation, frontend]
|
|
title: State Management
|
|
description: "상태 관리(State Management)는 프론트엔드 및 크로스 플랫폼 애플리케이션에서 여러 컴포넌트 간에 데이터를 공유하고 동기화하는 방법론 및 패턴을 의미한다 [1-3]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# State Management
|
|
|
|
## 📌 Brief Summary
|
|
상태 관리(State Management)는 프론트엔드 및 크로스 플랫폼 애플리케이션에서 여러 컴포넌트 간에 데이터를 공유하고 동기화하는 방법론 및 패턴을 의미한다 [1-3]. 단일 컴포넌트 내부의 지역 상태를 넘어 전역 상태를 효과적으로 관리함으로써, 컴포넌트 트리가 깊어질 때 발생하는 'Prop Drilling' 문제를 방지하고 단일 진실 공급원(Single Source of Truth)을 유지할 수 있다 [1, 3, 4]. 현대의 프레임워크들은 Pinia, BLoC, React Query 등 목적에 맞는 전용 라이브러리나 Composition API, Custom Hooks 등의 내장 기능을 통해 UI 렌더링과 상태 비즈니스 로직을 명확히 분리하는 방향으로 발전하고 있다 [1, 5, 6].
|
|
|
|
## 📖 Core Content
|
|
|
|
* **Vue.js의 상태 관리 패턴**
|
|
* Vue 3의 Composition API 환경에서는 `ref()`와 `reactive()`를 사용하여 지역 상태를 유연하게 선언하고 관리한다 [4, 7].
|
|
* 여러 컴포넌트가 공유하는 상태는 단순한 전역 반응형 객체(Global Singleton)로 추출할 수 있으나, 안전한 상태 변경을 위해 컴포넌트 외부에서 의도를 명확히 표현하는 메서드(액션)와 함께 정의하는 것이 좋다 [8].
|
|
* 대규모 프로젝트의 경우 기존 Vuex를 대체한 **Pinia**가 공식적이고 현대적인 상태 관리 표준으로 사용된다 [6, 9]. Pinia는 불필요한 보일러플레이트를 줄인 Composition API 스타일을 제공하며, 완벽한 TypeScript 타입 추론과 Vue DevTools 통합(타임 트래블 디버깅), 핫 모듈 교체(HMR)를 지원한다 [10-12].
|
|
|
|
* **React의 상태 관리 패턴**
|
|
* **커스텀 훅(Custom Hooks)**을 통해 상태 기반 로직(Stateful logic)을 외부 함수로 추출하여 컴포넌트 중첩 없이 여러 컴포넌트에서 재사용한다 [13, 14].
|
|
* 복합 컴포넌트(Compound Components) 패턴에서는 **Context API**를 통해 부모 컴포넌트와 하위 컴포넌트 간에 암시적으로 상태를 공유하여 유연한 UI 구조를 만든다 [15, 16].
|
|
* 비동기 데이터 페칭 및 서버 상태 동기화를 위해서는 **React Query (TanStack Query)**가 적극적으로 활용되며, 이를 통해 클라이언트 상태를 극도로 단순화시킬 수 있다 [5, 17]. 그 외의 전역 상태 관리를 위해서는 Redux Toolkit, Zustand, Jotai 등이 비교 및 활용된다 [5, 18].
|
|
|
|
* **모바일 프레임워크 (Flutter vs React Native)**
|
|
* **Flutter**: 프로젝트 규모와 아키텍처 취향에 따라 상태 관리 방식이 다양하다. 스트림(Stream) 기반으로 엄격한 관심사 분리와 높은 테스트 용이성을 제공하는 **BLoC**(엔터프라이즈급에 적합), 배우기 쉽고 유연한 **Provider**, 그리고 Provider의 한계를 극복하여 MVVM 아키텍처 결합도가 높은 **Riverpod** 패턴이 주로 쓰인다 [5, 19].
|
|
* **React Native**: React 웹 생태계의 성숙한 도구들을 그대로 차용한다. Redux Toolkit이 여전히 많이 사용되지만, 최근에는 보일러플레이트가 적은 **Zustand**나 서버 상태 캐싱에 특화된 **TanStack Query**가 실전 표준으로 자리 잡았다 [5, 20].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
|
|
* **Vue의 SSR 환경에서 싱글톤 상태 오염 위험**
|
|
단순한 `reactive()` 객체를 전역 싱글톤으로 사용하여 상태를 관리할 경우, 서버 사이드 렌더링(SSR) 환경에서는 여러 요청 간에 상태가 공유되어 데이터가 유출되는 심각한 문제가 발생할 수 있다 [21, 22]. 이를 방지하기 위해 요청마다 새로운 스토어 인스턴스를 격리 생성하는 Pinia를 도입하는 것이 필수적이다 [10, 22].
|
|
* **Vue 반응형 객체의 구조 분해 제약**
|
|
Vue 3에서 `reactive()`는 원시 값(Primitive values)에 사용할 수 없으며, 객체를 직접 구조 분해 할당(Destructuring)할 경우 반응성 연결이 끊어지는 단점이 있다 [23]. 반응성을 유지하려면 `toRefs()`를 사용하거나, 제약이 적고 명시적인 `.value` 구문을 사용하는 `ref()`를 기본 API로 채택하는 것이 안전하다 [23, 24].
|
|
* **React 훅과 컨텍스트의 기술적 함정**
|
|
* **Context API 안전성**: 복합 컴포넌트 패턴 적용 시, 하위 컴포넌트가 부모 Context 범위를 벗어나 렌더링될 경우를 대비해 명확한 에러(Descriptive error)를 발생시키는 가드 로직이 없다면 런타임 디버깅이 매우 고통스러워진다 [25, 26].
|
|
* **Stale Closure (오래된 클로저)**: `useEffect`나 커스텀 훅을 설계할 때 의존성 배열(Dependency Array)에 참조된 모든 값을 명시하지 않으면, 컴포넌트가 과거 렌더링 시점의 상태 값을 참조하는 문제가 발생한다 [27].
|
|
* **과도한 아키텍처 적용(Over-engineering) 경계**
|
|
모든 소규모 컴포넌트나 단순한 상태에까지 무거운 상태 관리 라이브러리(Redux, BLoC 등)를 강제하는 것은 불필요한 보일러플레이트와 학습 곡선을 유발한다 [28]. 복잡성이나 재사용성에 대한 실질적인 요구사항(Pain points)이 발생할 때 적절한 패턴과 도구를 도입하는 것이 원칙이다 [28-30].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |