Flux

Hunter Joe·2025년 4월 30일
0

Flux 패턴은 리액트, Redux를 통해서 한번쯤 듣게되는 디자인 패턴이다.

Good to know
Flux 패턴은 2014 페이스북 F8 컨퍼런스에서 발표된 아키텍처,
CSR 웹 어플리케이션을 만들기 위해 사용한 디자인 패턴

📌 Flux

페이스북이 기존 MVC 패턴에서 Flux 패턴을 고안했는지 보면 그 이전까지는 이렇게까지의 대규모 웹 프로젝트가 없었다. 그렇기에 대규모 프로젝트에서도 데이터 흐름을 일관성있게 관리함으로써 프로그램의 예측 가능성을 높이기 위함이였다.

MVC 패턴의 구조적 한계와 데이터 흐름의 복잡성

MVC는 Model-View-Controller의 약자로 소프트웨어 아키텍처에서 역할을 분리하여 애플리케이션을 보다 효율적으로 관리하기 위해 고안된 패턴이다.

  • Model 애플리케이션의 핵심 데이터와 로직을 관리
  • View는 사용자에게 데이터를 시각적으로 보여주는 역할을 수행
  • Controller는 사용자 입력을 받아 이를 해석하고 적절한 Model을 갱신하거나 View를 갱신하는 중재자 역할

전통적인 MVC 구조에서는 View가 직접 Model을 수정하지 않고 Controller를 통해 Model을 변경하는 단방향 흐름을 따른다.
그러나 현대의 실제 구현에서는 View가 사용자 입력을 기반으로 Model을 직접 갱신하는 양방향 데이터 흐름이 자주 발생한다.
→ 예를 들어, 프론트엔드 프레임워크에서 View와 Model 간의 양방향 바인딩을 제공하면서, View가 Model을 직접 수정할 수 있는 구조가 보편화되었다.

문제는 이처럼 View가 Model을 직접 수정하게 될 때부터 발생한다. 애플리케이션의 규모가 작을 때는 큰 문제가 없지만, 규모가 커지면서 View와 Model 사이의 의존성이 복잡하게 얽히게 된다. 구체적으로는 다음과 같은 상황이 나타난다

  • 하나의 View가 여러 개의 Model에 의존

  • 하나의 Model은 여러 개의 View를 동시에 갱신해야 함

View가 사용자 입력을 받아 Model을 변경하면 이 변경이 또 다른 View나 Model에 영향을 미치는 순환적인 변경 전파가 발생한다.

이러한 구조는

  • 데이터 흐름을 예측하기 어렵게 만듦
  • 버그 발생 시 원인을 추적하기 어려움
  • 새로운 기능을 추가하거나 기존 코드를 수정이 어려움
    → Model과 View 간의 강결합, 의존성 증폭, 변경 전파의 혼란이라는 구조적 한계에 직면

이와 같은 문제를 해결하기 위해 단방향 데이터 흐름을 강조한 아키텍처가 등장하게 된다.
1. MVVM (Model-View-ViewModel)
2. Flux : Action → Dispatcher → Store → View의 명확한 단방향 흐름을 유지 (데이터 추적 용이)

Flux 알아보기

그림과 같이 Flux 패턴은 다음과 같은 순서를 따른다.
1. 사용자 입력 기반의 Action 생성
2. 생성된 ActionDispatcher에 전달
3. Store(Model)의 데이터를 변경
4. 데이터 변경에 따른 View 반영

다시 변경이 생기면
View → Action → Dispatcher를 통해 데이터 변경 및 View 업데이트

내생각
어려운 개념은 아니다.
그저 데이터의 흐름이 단방향으로 흐른다는 것을 인지하면 된다고 생각한다.
물론 deep-dive를하면 복잡해지겠지만
개념은 이정도로만 잡아두면 될 것 같음

📌 참고 자료

https://www.frontoverflow.com/document/1/%EC%B2%98%EC%9D%8C%20%EB%A7%8C%EB%82%9C%20Redux/chapter/2/Redux%20%EC%86%8C%EA%B0%9C/section/5/Flux%20architecture
https://velog.io/@andy0011/Flux-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80

profile
Async FE 취업 준비중.. Await .. (취업완료 대기중) ..

0개의 댓글