FLUX 아키텍쳐에 대해 알아보자

Flux 아키텍쳐

Flux는 Facebook이 만든 애플리케이션 아키텍처 패턴으로, 데이터 흐름과 상태 관리를 단방향으로 구성한 것이 특징이다. 이렇게 아키텍쳐를 한 줄로 요약하면 이해가 잘 가지 않으니 더 깊게 알아보자. 

등장 배경

MVC 패턴 구조

 Facebook은 서비스가 성장하고, 더 많은 기능들이 추가되면서 상태 관리의 어려움이 점점 커졌다. 기존에 Facebook 서비스는  MVC(Model-View-Controller) 패턴을 사용하였는데, MVC 패턴은 여러 컴포넌트가 상호작용하면서 각자의 상태를 변화시키는 양방향 데이터 바인딩을 사용하게 된다. 하지만 이렇게 될 경우 하나의 컴포넌트에서 발생한 상태 변화가 다른 컴포넌트에 영향을 미치고, 이는 다시 또 다른 컴포넌트에 영향을 미치면서, 복잡한 상호작용 구조가 형성되는 문제를 만들게 되었다. 결과적으로 디버깅이 어려워지고, 상태 추적이 복잡해지며, 전체 애플리케이션의 유지 보수가 힘들어지는 상황이 발생하였다. 이러한 문제를 해결하기 위해 Facebook에서는 Flux 아키텍처를 도입하게 되었다. Flux 아키텍쳐를 통해 단방향 데이터 흐름을 통해 상태 관리를 단순화하고, 상태 변화의 원인을 명확하게 추적할 수 있게 하여 애플리케이션의 복잡성을 해결할 수 있었다. 

Flux 아키텍쳐란?

Flux 패턴 구조

Flux 아키텍처는 단방향 데이터 흐름을 기반으로 하는 애플리케이션 구조로 데이터의 일관성과 예측 가능성을 유지하는 데 중점을 두고 있다. Flux 아키텍처에 대해 더 알아보기 위해  구성 요소와 사이클에 대해 알아보자.

구성 요소

• Action (액션) : 애플리케이션 내에서 발생하는 이벤트를 나타내는 객체로, Dispatcher에게 전달되어 Store에 전달되는 역할을 하며 애플리케이션에서 발생하는 모든 이벤트를 표준화된 형식으로 표현한다.
• Dispatcher (디스패처) : Flux 아키텍처의 중앙 허브로, 모든 액션을 수신하고 이를 모든 Store에 전달하는 역할을 한다. 액션을 각 Store에 분배하며, Store는 필요한 액션에만 반응하도록 설계해야 한다.
• Store (스토어) : 애플리케이션의 상태와 비즈니스 로직을 관리하는 객체로, Flux에서는 여러 개의 Store가 존재할 수 있으며, 각 Store는 특정 도메인에 대한 상태를 관리하게 된다. 직접적으로 View를 업데이트하지 않도록 설계해야한다. 또한 상태가 변경될 경우 View에 변경 사항을 알리는 역할을 한다.  
• View (뷰) : 사용자 인터페이스를 담당하는 컴포넌트이다. Store로부터 상태를 구독하고, 상태가 변경되면 다시 렌더링하는 구조로 이루어져 있으며, 만약 사용자가 입력과 같은 상호작용이 발생 할 때 이를 액션으로 디스패치한다. 

사이클

사용자가 "상품 추가"를 하는 과정을 예시로 사이클을 생각해보자

 

 

1. 사용자 인터랙션 또는 이벤트 발생 : 사용자가 "상품 추가" 버튼을 클릭한다. 
2. Action 생성 및 디스패치 : 애플리케이션은 ADD_PRODUCT 액션을 생성하고 Dispatcher를 통해 디스패치한다.
3. Dispatcher에서 Store로 액션 전달 : Dispatcher는 ADD_PRODUCT 액션을 ProductStore에 전달한다. 
4. Store에서 상태 업데이트 : ProductStore는 액션을 처리하여 상품 목록에 새 상품을 추가하고, 변경 사항을 View에 알린다.
5. View에서 상태 반영 : ProductList 컴포넌트는 업데이트된 상품 목록을 받아 UI를 다시 렌더링하여 사용자가 변경된 상태를 확인할 수 있게 한다. 

이렇게 구성 요소와 사이클에 대해 알아보니, Flux의 구조의 경우 명확한 역할 분리와 함께, 스토어를 통해 기능들이 모듈화되어 있어 확장에 용이할 수 있겠다는 생각이 들었다.