Flux 아키텍처란 무엇인가요?

Question

Flux 아키텍처란 무엇인가요?

Accepted Answer

**Flux**는 **단방향(one-way) 데이터 흐름**으로 state를 관리하기 위한 아키텍처 패턴(Facebook 출처)입니다. Redux의 개념적 토대가 되었고 대부분의 현대 state 라이브러리에 영향을 주었습니다. 핵심 아이디어는 데이터가 단일하고 예측 가능한 방향으로 흐른다는 것입니다.

## 단방향 사이클

```text
  Action  →  Dispatcher  →  Store  →  View
    ↑                                   │
    └───────────────────────────────────┘
         (사용자 상호작용이 새로운 Action을 생성함)
```

```text
1. Action     — 무슨 일이 일어났는지 기술하는 일반 객체({ type: 'ADD_TODO', text })
2. Dispatcher — 모든 action을 store로 보내는 중앙 허브
3. Store      — state + 로직 보유; action에 응답하여 스스로 갱신
4. View       — store로부터 렌더링; 사용자 상호작용이 새 action을 dispatch
```

루프는 엄격히 단방향입니다. 뷰는 store를 직접 수정하지 않고 *action을 dispatch*하며, 이것이 dispatcher를 거쳐 store로 흐르고, store가 뷰를 갱신합니다.

## 단방향 흐름이 중요한 이유

```text
양방향 바인딩(데이터가 양쪽으로 흐름) → state가 왜 바뀌었는지 추적하기 어렵고,
                                          갱신이 예측 불가하게 연쇄됨.
Flux(단방향) → 모든 변경이 action에서 시작 → 예측 가능, 추적 가능,
               디버깅 쉬움(모든 action을 로깅할 수 있음).
```

Flux가 (대형 MVC 앱에서) 해결한 문제는 무엇이 무엇을 바꿨는지 알 수 없는, 뒤엉킨 양방향 데이터 흐름이었습니다. 모든 변경을 dispatch된 action을 거치도록 강제하면 데이터 흐름이 명시적이고 디버깅 가능해집니다.

## Flux vs Redux

```text
Flux:  여러 store, 중앙 dispatcher
Redux: 단일 store, 별도 dispatcher 없음(store의 dispatch + reducer),
       순수 reducer 함수 — Flux 아이디어의 단순화
```

Redux는 Flux의 단방향 흐름 원칙을 가져와 간소화했습니다: 하나의 store, 로직을 가진 store 대신 순수 reducer 함수, 명시적 dispatcher 없음.

## 지속되는 유산

```text
단방향 데이터 흐름은 이제 표준입니다 — Redux, Vuex/Pinia, NgRx, Zustand,
심지어 React 자체의 state 모델까지 모두 "action/event는 한 방향으로 흐른다"를 구현합니다.
```

## 왜 중요한가

Flux는 사실상 모든 현대 state management의 토대가 되는 **단방향 데이터 흐름** 원칙을 도입했습니다.

이를 이해하면 Redux 및 유사 도구가 왜 그런 구조로 되어 있는지(action을 dispatch → reducer/store 갱신 → 뷰 리렌더링), 그리고 왜 단방향 흐름이 선호되는지(state 변경을 예측 가능, 추적 가능, 디버깅 가능하게 함)를 설명할 수 있습니다.

"고전" Flux를 결코 쓰지 않더라도, 그 핵심 아이디어는 생태계 전체의 개념적 기초입니다.