상태관리 [1편] - Flux 패턴(아키텍처)

💡 Flux란? 왜 필요할까?

단방향 데이터 흐름을 통한 예측 가능한 상태 관리 구조

---

🧭 Flux란?

Flux는 React와 함께 자주 언급되는 클라이언트 사이드 아키텍처 패턴입니다.
단방향 데이터 흐름을 기반으로 상태를 예측 가능하게 관리할 수 있도록 설계되었습니다.

Flux는 프레임워크가 아닌 개념적인 구조입니다.

---

❓ Flux는 왜 등장했을까?

기존 MVC 패턴의 한계

• 모델과 뷰 사이의 양방향 데이터 흐름
• 상태가 여러 곳에 흩어져 있음
• 컴포넌트 간 의존성 증가
• 유지보수와 디버깅 어려움

---

📌 예시로 쉽게 이해해보기

상황: 사용자에게 새로운 알림이 도착했습니다.
헤더에 알림 아이콘이 있고, 목록 페이지에서도 알림을 확인할 수 있어야 합니다.

❌ 기존 방식

• 알림을 읽으면 헤더와 목록 상태를 각각 업데이트
• 여러 컴포넌트에서 상태가 중복 관리됨

✅ Flux 방식

1. Action을 발생시키고
2. Dispatcher가 이를 전달
3. Store가 상태를 변경
4. View(컴포넌트)는 Store를 구독

// 예시: 알림 읽기 액션
dispatch({ type: 'MARK_AS_READ', payload: { id: 123 } });

// Store에서 처리하는 reducer
function notificationsReducer(state, action) {
  switch (action.type) {
    case 'MARK_AS_READ':
      return state.map(n =>
        n.id === action.payload.id ? { ...n, read: true } : n
      );
    default:
      return state;
  }
}

---

🔄 Flux의 데이터 흐름

[View] → (Action 발생)
         ↓
[Dispatcher] → (Action 중계)
         ↓
[Store] → (상태 변경 및 View에 알림)
         ↓
[View]

모든 상태 변경은 오직 Action → Store를 통해서만 일어나며, 컴포넌트 간 직접 호출은 없습니다.

---

🆚 MVC vs Flux

항목	MVC (양방향)	Flux (단방향)
상태 변경	컴포넌트 간 직접 호출	Action → Store
유지 보수	복잡, 버그 많음	예측 가능, 추적 쉬움
테스트 용이성	UI 의존 높음	상태만 테스트 가능

---

✅ Flux의 장점

• 상태 변경 흐름이 명확하고 예측 가능
• Store만 테스트하면 되므로 유닛 테스트 용이
• 외부 UI나 상태에 영향받지 않음
• Reducer는 순수 함수로 구성 가능

❌ Flux의 단점

• 기본 구조 구현에도 많은 코드량 필요
• 학습 곡선이 가파름
• 단순한 프로젝트에는 과도할 수 있음

---

✍️ 마무리

Flux는 특히 대규모 SPA에서 강력한 상태 관리 패턴을 제공합니다.
모든 상태 변경이 Action을 통해 흐르고, 중앙의 Store에서 상태가 관리되므로
복잡한 애플리케이션에서도 유지보수가 쉬워집니다.

💡 참고로 Redux 역시 이 Flux 아키텍처를 기반으로 만들어졌습니다!