제목에서 언급하였듯이 Redux를 공부하기 전에 알아두어야 할 개념이다. 그 이유는 Redux와 Flux의 관계가 다음과 같기 때문이다.

“Redux implements Flux”

Redux가 Flux라는 디자인 패턴을 실제로 구현한 구현체라는 것이다.

그래서 Flux 패턴을 공부하는 것이 추후 Redux를 빠르게 이해하는데 용이할 것이다.

Flux

Flux란 Meta에서 클라이언트 사이드 웹 어플리케이션을 위해 고안한 아키텍쳐이다.

Flux의 공식 Github 레포지토리에서는 Flux를 다음과 같이 정의하고 있다.

An application architecture for React utilizing a unidirectional data flow.

출처: https://github.com/facebookarchive/flux?tab=readme-ov-file

해석하면, ‘*단방향 데이터 흐름을 활용한 React용 어플리케이션 아키텍쳐*’이다.

여기서 제일 중요한 부분은 ‘단방향 데이터 흐름’이라는 키워드이다.

왜냐하면 당시의 Facebook이 MVC의 단점이라고 판단한 양방향 데이터 흐름을 해결하기 위해 Flux를 고안한 것이기 때문이다.

MVC란?

MVC란 Model-View-Controller의 약자로 데이터 및 논리 제어를 구현하기 위한 디자인 패턴이다.

MVC의 구조는 다음과 같다.

• Model: 데이터와 비즈니스 로직을 관리한다.
• View: 레이아웃과 화면을 처리한다.
• Controller: Model과 View로 명령을 전달한다.

Controller가 요청한 Data를 Model이 DB에서 불러와 요청에 응답하면, Controller가 해당 데이터를 View에 전송에 보여주는 형태이다.

중요한 것은 요청과 응답이 발생하여 데이터가 업데이트되면 View와 Model이 업데이트된다. 즉, View가 Model을 업데이트할 수도 있고, Model이 View를 업데이트할 수도 있다. 이를 다른 말로 양방향 데이터 흐름이라고 한다.

MVC의 문제점

Facebook이 단점으로 생각한 양방향 데이터 흐름이 문제가 되는 이유는 복잡도가 증가될 때 있다.

위 사진이 MVC의 문제점을 직관적으로 보여주고 있다.

양방향 데이터 흐름의 단점은 다음과 같다.

• 복잡도가 높아질 수록 업데이트 비용도 높아짐
• 복잡도가 높아질 수록 버그의 추적이 어려워 예측하기 어려운 코드가 됨

이러한 문제가 생기는 결정적인 이유는 요소 간의 의존도가 높기 때문이다. 위 사진과 같이 View와 Model은 상호의존적이기 때문에 한 요소의 복잡도가 올라가면 다른 요소의 복잡도도 올라간다. 그래서 어플리케이션이 복잡해지면 복잡해질수록 MVC의 구조가 무의미해진다.

FE(Front-end)에서 MVC를 적용하기 힘든 가장 큰 이유는 View가 메인이 되기 때문이다. MVC에서 View는 단순하게 요청한 데이터를 보여주는 결과에 불과하지만, FE에서는 View에서 발생하는 이벤트를 통제하는 것이 메인이기 때문에 MVC의 목적과는 모순된다. 그래서 실제로 FE에서 MVC를 구현해보면 View와 Model의 갯수가 증가함에 따라 Controller의 규모가 무지막지하게 커진다.

Flux의 구조

Flux는 MVC의 단점을 해결해기 위해 단방향 데이터 흐름으로 설계되었다.

• Action: 상태 변경 요청을 담은 JS 객체

  {
  	type: '새로운 메시지 도착',
  	payload: {
  		id: ...,
  		message: '오늘 점심 메뉴 뭐 먹을까?',
  		threadId: ...,		
  	}
  }

  • type: 액션 이름
  • payload: 데이터
• Dispatcher: 모든 데이터 변경 요청이 경유하는 중앙 허브
  • View로부터 Action을 받아 모든 Store들에게 전송
  • 내부에 상태 변경 로직이 존재하지 않음
  • Store 간 의존성 관리
    • Store A의 상태 변경 순서를 Store B 다음으로 미룰 수 있음
• Store: 어플리케이션 상태 및 로직 컨테이너
  • Dispatcher에서 전달된 Action을 통해서만 상태 변경
  • 상태가 변경되면 View에게 통지
• View: 상태에 따라 화면을 출력
  • Controller-View (React)
    • View와 Controller의 역할을 동시에 함
    • Store가 통지하는 상태 변경을 수신 받은 상태에 따라 View를 새로 렌더링
  • Dispatcher에게 Action 전달

Flux의 장점

• 단방향 데이터 흐름으로 구성하여 복잡성을 해결하였음
• 컴포넌트 간의 의존성을 줄여서 유지보수가 용이함
• 그로 인해 예측 가능성이 높아져 대규모 프로젝트에도 적합함

---

Reference

Meta Archive, flux, https://github.com/facebookarchive/flux?tab=readme-ov-file
Facebook, Flux, https://haruair.github.io/flux/
mdn web docs, MVC, https://developer.mozilla.org/ko/docs/Glossary/MVC