티스토리 뷰

ETC...

[디자인패턴] Flux, MVC 비교

버미노트 2018. 9. 22. 22:48

React.JS의 Redux 관련 글을 포스팅하면서 그리고 MVC, MVP, MVVM 패턴에 관한 포스팅을 하면서 다른 디자인패턴에 관심을 가지게 되었습니다. Vuex는 Flux 패턴에 영감을 받아 만들어졌다고도 하고, Flux는 React.JS의 Redux의 디자인패턴이기도 합니다. Flux와 MVC를 비교하기 전에 [디자인패턴] MVC, MVP, MVVM 비교를 참고하시면 좀 더 이해하는데 도움이 될 것 같습니다.

Flux는 MVC 모델의 단점을 보안하기 위해 페이스북에서 발표한 아키텍쳐입니다.

1. MVC 문제점

페이스북에서 이야기 하는 MVC의 가장 큰 단점은 양방향 데이터 흐름이었습니다.

Facebook에서 이야기 하는 MVC의 단점
Facebook에서 이야기 하는 MVC의 단점은 양방향 데이트 흐름입니다.

MVC 패턴에서 Controller는 Model의 데이터를 조회하거나 업데이트하는 역할을 합니다. Model이 업데이트 되면, View는 화면에 반영합니다. View가 Model을 업데이트 할 수도 있습니다. Model이 업데이트 되어 View가 따라서 업데이트 되고, 업데이트 된 View가 다시 다른 Model을 업데이트 한다면, 또 다른 View가 업데이트 될 수 있습니다.

복잡하지 않은 어플리케이션에서는 양방향 데이터 흐름이 문제가 크지 않을 수 있습니다. 하지만 어플리케이션이 복잡해 진다면 이런 양방향 데이터 흐름은 새로운 기능이 추가 될 때에 시스템의 복잡도를 기하급수적으로 증가 시키고, 예측 불가능한 코드를 만들게 됩니다. 개발자가 만든 어플리케이션이 개발자도 예측 못할 버그들을 쏟아 내게 됩니다.

페이스북 알림버그
메시지 아이콘은 알림이 떠 있지만, 그 메시지 아이콘을 클릭해서 들어가보면 아무런 메시지가 없다..

페이스북에서 이야기하는 MVC의 양방향 데이터 흐름이 만들어 낸 예측하기 어려운 버그 중 하나는 알림 버그입니다. 페이스북에 로그인 했을 때, 화면 위 메시지 아이콘에 알림이 떠 있지만, 그 메시지 아이콘을 클릭하면 아무런 메시지가 없는 버그를 보신 적이 있으실 겁니다.

이 버그를 수정하고 얼마동안은 괜찮았지만 어플리케이션을 업데이트 하다 보면, 곧 다시 알림 버그가 나타나고 다시 버그를 수정하는 일이 반복되었습니다. 페이스북에서 이 문제의 해결 방법을 단방향 데이터 흐름으로 어플리케이션을 예측 가능하도록 만드는 방법에서 찾았습니다.

2. Flux로 해결

페이스북은 알람 버그의 원인을 양방향 데이터 흐름으로 보고, 단방향 데이터 흐름인 Flux를 도입했습니다.

Flux
Flux는 단방향으로 데이터가 흐르게 됩니다.

Flux의 가장 큰 특징은 단방향 데이터 흐름입니다. 데이터 흐름은 항상 Dispatcher에서 Store로, Store에서 View로, View는 Action을 통해 다시 Dispatcher로 데이터가 흐르게 됩니다. 이런 단방향 데이터 흐름은 데이터 변화를 휠씬 예측하기 쉽게 만듭니다. Flux를 크게 Dispatcher, Store, View 세 부분으로 구성됩니다.

Dispatcher

Dispatcher는 Flux의 모든 데이터 흐름을 관리하는 허브 역할을 하는 부분입니다. Action이 발생되면 Dispatcher로 전달되는데, Dispatcher는 전달된 Action을 보고, 등록된 콜백 함수를 실행하여 Store에 데이터를 전달합니다. Dispatcher는 전체 어플리케이션에서 한 개의 인스턴스만 사용됩니다.

Store

어플리케이션의 모든 상태 변경은 Store에 의해 결정이 됩니다. Dispatcher로 부터 메시지를 수신 받기 위해서는 Dispatcher에 콜백 함수를 등록해야 합니다. Store가 변경되면 View에 변경되었다는 사실을 알려주게 됩니다. Store은 싱글톤으로 관리됩니다.

View

Flux의 View는 화면에 나타내는 것 뿐만이나라, 자식 View로 데이터를 흘려 보내는 뷰 컨트롤러의 역할도 함께 합니다.

Action

Dispatcher에서 콜백 함수가 실행 되면 Store가 업데이트 되게 되는데, 이 콜백 함수를 실행 할 떼 데이터가 담겨 있는 객체가 인수로 전달 되어야 합니다. 이 전달 되는 객체를 Action이라고 하는데, Action은 대채로 액션 생성자(Action creator)에서 만들어집니다.

3. Flux에 관한 고찰

많이 이용해 보았다 할 수는 없지만.. 하지만 간단하지 않은 서비스에서 사용했다 자신있게 이야기 할 수 있습니다. MVC 패턴을 사용하면서 MVC의 양방향 데이터 흐름으로 기하급수력으로 증가하는 복잡도 때문에 고생한 경험은 없습니다. 또 전통적인 MVC 패턴 구조를 본다면, MVC 패턴은 양방향 데이트 흐름이 발생 하지 않아야 하는 것으로 이해가 됩니다. ([디자인패턴] MVC, MVP, MVVM 비교 참고) 페이스북에서 MVC 패턴을 잘못 사용하고 있었던 것은 아닐까.... 라는 생각이 조심스럽게 듭니다. 이것은 저의 고찰일 뿐이지만.... 저의 이런 생각이 이 글을 읽고 자신을 얻게 되었습니다.

참고

'ETC...' 카테고리의 다른 글

[Svelte] 스벨트 입문 A부터 Z까지  (0) 2020.08.07
[Browser] 렌더링 최적화  (0) 2019.12.09
[디자인패턴] Flux, MVC 비교  (8) 2018.09.22
[디자인패턴] MVC, MVP, MVVM 비교  (33) 2018.09.15
[webpack] webpack 4 사용하기  (1) 2018.09.06
[webpack] webpack 개념  (0) 2018.09.03
댓글
  • 프로필사진 LikeApple 페이스북이 밝힌 mvc 의 문제점을 좀더 디테일하게 볼 수 있었으면 하네요 ㅜㅜ 글잘읽었어요. 2019.05.07 18:59 신고
  • 프로필사진 조영규 페이스북은 일반적으로 알려진 "이상적 구조의 MVC"와 다른 잘못된 다이어그램을 보여줬습니다. 보면서도 이상하다 싶었습니다.
    다만, 제 생각에는 페이스북이 View로직 안에서 로직의 일부를 처리한 것 같습니다. (그러니 Controller는 하나..) 여러 뷰를 업데이트 해야하고, 채팅의 경우 사용자, 리액션등 온갖 모델을 다뤄야하니, ChatController 이런걸 하나 만들고 ChatListView, ChatInputView 안의 이벤트 리스너등에서 model로 로직을 간단히 처리한 것 같아요. 그러니 저런 그림이 그려진 것 같습니다. 이 경우, 로직이 산개되어있으니 당연히 예측도 어렵고, 작은 액션으로 루프가 생길 수도 있을 것 같아요.
    페이스북이 말하는 방식이 MVC가 완전히 아니라고 말하긴 조금 어려울 것 같습니다. 이상적이진 않아도 이런 구현을 꽤 봤습니다.
    물론 그렇지 않아도 View와 Controller와 결합이 점점 강해지며 Controller가 비대해지고 View의 변경 및 업데이트 관리가 어려워지는건 마찬가지입니다. (조금 더 쉽게 핸들링하려는 여러 시도가 있지만.)

    이런 형식의 MVC에서 데이터 흐름으로 고생하는 경우는 저는 꽤 있었어요.
    서로 다른 뷰에 업데이트가 필요한 경우, Bus등을 가지고 모델의 변화에 따라 다른 컨트롤러에 업데이트를 위한 notify를 하는 등의 처리가 필요했습니다.
    필요한만큼의 이벤트가 오지 않는 경우도 있어서 이벤트를 추가하거나 변경해야했고, 해당 이벤트를 쓰는 곳이 어딘지 모르니 이걸 없애도 되는지, 어디서 어떻게 바뀌게 될지 예측도 어려웠어요.
    그러다보니 싱글톤으로 구현한 Store(Subject/Observer)가 필요했고, 페이스북의 Flux처럼 자연스럽게 만들어서 쓰는 경우가 있었어요 :)
    아무래도 그러한 경험을 개념적으로 표현하고자 FLUX라 이름 붙이고 정리해 발표한 것 같습니다.
    2019.12.24 17:05
  • 프로필사진 버미노트 우아... 멋지십니다. 깔끔하고 이해하기 쉬운 정리 감사합니다! 2019.12.24 17:40 신고
  • 프로필사진 siyoon210 페북이 제시한 MVC 양방향 모델이 이해가 안됐는데, MVC의 안티패턴으로 얘기한것이었군요..ㅋㅋㅋ 2020.07.02 15:28 신고
  • 프로필사진 버미노트 네네 맞습니다 :) 2020.07.02 15:30 신고
  • 프로필사진 juicyjerry 잘 읽고 갑니당 2021.01.18 10:29 신고
  • 프로필사진 버미노트 감사합니다~ :) 2021.01.18 10:29 신고
  • 프로필사진 제생각은.. 저도 위의 조영규님과 비슷한 의견입니다.
    Flux패턴은 MVC 패턴을 잘 활용할 수 있도록 일종의 프레임워크화 하려는 시도에서 나온 일종의 패턴 같아요.

    MVC패턴을 잘 활용시켜줄 수 있는 좋은 프레임워크나 환경이 제공되지 않는다면, 페이스북에서 발표한대로 좋지않은 개발 패턴으로 흘러갈 가능성이 다분히 있죠.
    대표적인 예시로 IOS도 개발도 MVC 패턴으로 개발된다고 기본적으로 말하지만, MVC패턴 자체에 대한 정확한 이해를 하지 않고 개발하면, 자연스럽게 컨트롤러만 엄청 비대해지고 모델은 단순히 DTO의 역할만 하게 되는 경우가 생기죠. 그래서 결국 개발자들은 MVC를 버리고 MVVM처럼 IOS개발환경에서 사용하기 많이 불편해지더라도, 플로우를 명시적으로 표기할 수 있는 패턴으로 개발할려는 시도를 하게되는거죠.

    반면에 React.js는 어떻게 보면 잘 설계된 MVC 프레임워크라고도 볼 수 있습니다. 뷰(html)와 로직(js)은 실질적으로 분리되어있고, js 쪽에서는 실제 html과는 완전히 독립적으로 js로만으로도 개발 가능하죠 (jsx). 뷰 업데이트는 예상 가능하도록만 업데이트 되도록 유도되구요. 이런 점으로 봐서는, MVC패턴을 페이스북이 처한 문제의 상황에 맞게 프레임워크화 하려는 시도가 Flux패턴이라고 생각됩니다.
    2021.03.11 15:24
댓글쓰기 폼