[Programming] Flux 아키텍처

시작에 앞서

지난번에 MVC 패턴을 공부하다가 Flux 아키텍처에 대해 알게 되었고, 과연 페이스북은 MVC의 Massive View Controller라는 문제를 어떻게 해결했을까?

 

Flux 공식 홈페이지

Flux에 대한 공식 홈페이지가 있었다! Flux에 대한 대략적인 설명, React를 사용한다면 어떻게 Flux아키텍처를 적용할 수 있는지, Github 레포지토리, 가이드 등이 나와있다.

Flux | Flux

 

Facebook이 찾은 MVC의 문제점

9년 전에 Facebook에서 발표한 Flux소개 영상이다. 이 영상을 요약해 보자면 초기에 MVC는 문제가 없었다고 한다. Facebook에서 사용한 MVC는 다음과 같다.

여기서 약간??? 할 수 있는데, 왜냐하면 보통의 MVC는 아래와 같기 때문이다. Controller가 View와 Model을 제어하고, View는 Model의 데이터를 표시해 주고, Controller가 다했는데...?

 

Facebook에서 사용한 MVC패턴은 아래와 같다. Action은 Controller가 받아 Model을 업데이트하고, Model의 데이터는 View에 표시되고, View도 Model을 업데이트하는 방식으로 MVC를 사용했던 것 같다. Model과 View가 서로를 직접 업데이트하게 된다. MVC에서 아래로 바꾼 이유는 업데이트 실시간 반영을 위해서 View와 Model의 더 긴밀한 연결이 필요했고, 새로고침과 같은 Action이 없어도 뷰 업데이트가 필요하기 때문이 아니었을까? 감히 추측해 본다.

 

Facebook의 MVC사용에서 문제점이 생겼다. Youtube에서 한 말을 가져와보면 "MVC works pretty well for small applications. The problem is that it doesn't make room for new features."라고 말한다. 해석해 보면 MVC는 작은 애플리케이션에서는 잘 작동하지만 새로운 기능을 추가하기 너무 어렵다는 말이다.

 

많은 Model과 View가 추가된다면 아래와 같은 문제들이 생겼다고 한다. 분명 Model하나를 여러뷰가 표시할 수도 있고, View에서의 변경사항을 많은 Model이 반영해야 할 수 있게 된다. 여기서 큰 문제는 Model이 View를 업데이트했는데 그것 때문에 View가 다른 Model을 업데이트하게 된다면, 그 모델이 또 다른 View를 업데이트해야 하고.... 그 View가 또 Model을.... 엄청난 루프에 빠질 수도 있다는 것이다. 그렇게 되면 당연히 유지보수가 힘들어지고, 새로운 기능을 넣기도 힘들어졌다고 한다.

 

그래서 Facebook에서는 아래와 같은 단방향 데이터 흐름을 가진 아키텍처를 고안해 냈다.

어떻게 이러한 데이터 흐름이 나오게 되었는지 알아보자. MVC든 뭐든 잊고 새로 시작해 보자...

 

우선 각 View가 있고, 새로운 Action이 들어온다면 Handler가 각 뷰에 어떠한 데이터를 보여줄지 관리하게 된다.

하지만 여기서도 문제가 있다. 각 View가 서로에게 영향을 준다면, 채팅처럼 어느 한 곳에서 읽어서 다른 곳에서 읽었음을 표시해야 한다면 한 View의 어떠한 행동을 Handler가 확인하고, 다른 View에 알려줘야 하기 때문에 이것 또한 데이터 흐름이 양방향이 되게 된다. 그리고 점점 Handler의 역할이 커지게 된다.

 

Handler라는 용어를 계속 쓰는 게 맞는지 모르겠지만... 이렇게 바뀌었다. 각 액션이 들어오면 각 뷰에서 알아서 해! 가 될 수 있다.

하지만 문제가 있다. 이러면 결국 다른 뷰가 어떠한 행동을 해도 다른 뷰에서 모르게 된다. 그러면 다른뷰에 영향을 주는 액션을 다시 액션에 전달해 주면 되는 것이다.

흠...

여기서 Facebook은 아래의 세가지를 알게 되었다고 한다.

 

1. Use explicit data instead of derived data
2. Separate data from view state

3. Avoid cascading effects by preventing nested updates

 

서로 연결된 데이터보다 독립적인 데이터가 필요하다. View와 Data는 분리되어야 한다. 이것에 의해서 아래의 형식으로 발전된다. Action은 Store의 상태를 업데이트하고, Store는 View를 업데이트한다.

 

 

그리고 다양한 Action들의 교통정리가 필요하다. 다양한 Action들이 앱의 상태를 업데이트하는데, 어떠한 액션이 어떠한 상태를 업데이트할지를 결정하는 Dispatcher를 두게 되었다.

여기서 Action은 상태 변경 요청을 담은 단순한 객체이다. Dispatcher의 경우 Store에게 모든 Action을 전송하고, Store 간의 순서도 관리한다. Store의 경우 Action을 받아 상태를 관리한다. View는 관심 있는 Store에 따라 View를 업데이트한다. 

 

Controller와 Dispatcher의 차이는 Controller의 경우 Model과 View사이의 상호작용을 관리하고 제어하는 역할이다. 사용자의 입력을 받아서 모델을 업데이트하거나 모델의 상태를 기반으로 뷰를 업데이트한다. Dispatcher의 경우 액션을 받아 스토어에 전달하는 전달의 역할만 하고, 데이터 흐름만 관리하게 된다. 내부에 상태 변경 로직이 존재하지 않는다.

 

그렇다면 비즈니스 모델은 어디 들어갈까? MVC의 경우 Model에 들어가 있지만, Flux의 경우는 Action Creater(액션 생성자)에 들어가 있다고 한다.

 

Flux 패턴의 핵심

바로 단방향 데이터 흐름이다. 모든 데이터는 Dispatcher라는 중앙 허브를 통해 흐르게 된다. 

https://haruair.github.io/flux/docs/overview.html

 

아래에 자세한 설명이 나와있으니 읽어보는 걸 추천한다.

Flux | 사용자 인터페이스를 만들기 위한 어플리케이션 아키텍쳐