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

5.6 KiB Raw Blame History

State Management

📌 Brief Summary

📖 Core Content

⚖️ Trade-offs & Caveats

5.6 KiB

Raw Blame History