Flux와 MVC의 차이에 대해 공부하기

학습했던 내용을 정리하기 위해 작성된 글이며 다소 부정확한 내용이 포함될 수 있음을 양해바랍니다.

이미 게시된 글이라도 복습하는 과정에서 내용이 보완 또는 수정될 수 있습니다.

 

Flux는 왜 등장했나?

출처: https://haruair.github.io/flux/docs/overview.html#content

Flux의 도입 배경에 MVC가 등장한다. MVC는 양방향 데이터 흐름의 특징을 갖고 있는데 이 특징이 문제가 될 수 있다. 만약 어플리케이션이 복잡해지고 비대해진다면, 양방향으로 흐르는 데이터가 어플리케이션의 복잡도를 기하급수적으로 증가시킬 수 있다. 이는 우리의 코드가 읽기 어려워지고 예측이 불가능해진다는 것을 의미한다.

 

MVC란?

 

Flux와 MVC를 비교하기에 앞서, MVC를 살펴본다. MVC라는 이름은 Model, View, Controller의 이니셜이다.

각각은 다음과 같은 기능을 수행한다.

 

• Model: 어플리케이션에 사용되는 데이터와 비지니스 로직을 관리한다.
• View: 레이아웃과 화면을 처리한다.
• Controller: 사용자의 입력(Action)을 Model과 View로 라우팅한다.

 

바닐라 자바스크립트로 유튜브 클론 페이지를 만들 때 MVC 패턴을 사용하기는 했다. Model에서는 데이터의 스키마를 정의했고 pug와 javascript를 통해 View를 구현했다. controller는 View를 통한 렌더링 로직을 포함하고, 때로는 Model을 업데이트 했다. 이런 요소들이 정확하게 MVC 패턴에 의해 작성된 것인지에 대해서는 확신이 없다.

 

(좀 더 깊게 생각해보니 컨트롤러가 모델 작업까지 함께 수행했던 것 같다. 컨트롤러가 데이터를 변경하고 작은 비지니스 로직들을 담고 있었다. 그리고 변경된 데이터를 다시 뷰에 전달했다. 최근에 엘리스에서 팀 프로젝트를 진행하면서 이 부분에 대한 의문을 가진 적이 있다. 데이터를 변경하는 작업이 비지니스 로직이라고 할 수 있는가? 코치님은 무리가 있다고 대답해주셨고 비지니스 로직을 분리시키는 것도 프로젝트 규모에 따라 오버 프로그래밍이 될 수도 있다고 조언해주셨다.)

 

출처: 위키백과

 

Model은 애플리케이션의 정보(데이터)를 나타내며, View는 사용자의 인터페이스, Controller는 데이터와 비지니스 로직 사이의 상호동작을 관리한다. MVC에 대한 자료를 검색하다가 약간은 상반된 설명을 보기도 했는데, 대부분의 자료가 위 그림과 유사한 MVC 패턴을 설명하고 있다. (맨 위 그림이랑은 조금 다른데??)

 

상호작용은

• Model: 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다.
• View: 모델로부터 얻은 정보로 최신의 결과를 보여준다.
• Controller: 사용자의 요청에 따라 View를 조작하여 뭔가를 보여주거나, Model에 뭔가를 업뎃한다.

 

각각의 요소가 상호작용한다는 것은 양방향으로 데이터가 흐른다는 것을 의미한다. 각각의 요소가 다른 요소를 변경시키거나 다른 요소에 의해 변경될 수 있다. 하나의 컨트롤러가 여러 모델과 뷰를 포함할 수 있고 모델과 뷰 또한 서로 복잡하게 얽힐 수 있다. 설계에 신경을 쓴다면 이를 최소화할 수 있겠지만, 프로젝트의 규모 자체가 커지고 구조가 복잡해짐에 따라 서로 간에 강한 의존성을 갖게 되는 것은 피하기 어렵다.

 

Flux란?

출처: https://haruair.github.io/flux/docs/overview.html#content

 

Flux는 이러한 배경하에 등장했다. 페이스북에서 도입한 Flux 패턴은 단방향의 데이터 흐름을 가지고 있다. 모든 데이터는 메인 허브라고 할 수 있는 Dispatcher를 통해 흐른다. 애플리케이션 내의 모든 변화는 Action을 거쳐 Dispatcher에 의해 실행된다.

 

• Action: action은 type과 data를 갖고 있는 일종의 객체와 같다. type을 통해 action이 해석되고, 덕분에 action에 따른 적절한 응답을 기대할 수 있다.
• Dispatcher: dispatcher는 모든 데이터의 흐름을 관리한다. action creator가 새로운 action이 있다고 dispatcher에게 알려주면, 애플리케이션의 모든 store는 해당 action에 앞서 등록된 callback으로 해당 action을 파라미터로 받는다.
• Store: store는 자신을 dispatcher에 등록하고 callback을 제공한다. 이러한 callback은 앞서 언급한 바와 같이, action을 파라미터로 받는다. type을 통해 action을 해석하고 이를 store 내부 로직에 연결시킨다. 결과적으로 action은 dispatcher를 거쳐 store를 갱신한다. store가 업데이트되면, view에게 새로운 상태가 전달된다.
• View: view는 페이지를 관리하는 controller-view를 포함한다. 컨트롤러-뷰는 최상위에서 마치 컨트롤러와 같은 역할을 수행한다. 컨트롤러-뷰를 통해 store에서 얻은 데이터에 접근할 수 있고 함수적으로 유지될 수 있다.

이처럼 Flux는 MVC와는 다르게, diaptcher를 통한 단방향의 데이터 흐름이 강제된다. 이는 애플리케이션 내의 데이터 흐름을 명확하게 파악하는데 큰 도움을 주고, 프로젝트가 확장됨에 따라 복잡도가 증가하는 것을 방지할 수 있다.

 

Reference

https://opentutorials.org/course/697/3828

https://dogbirdfoot.tistory.com/14

https://beomy.tistory.com/44

https://ko.wikipedia.org/wiki/모델-뷰-컨트롤러

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