이전 게시글에서 소프트웨어 아키텍쳐가 무엇이고 왜 필요한지, 디자인 패턴과 어떤 차이점을 가지고 있는지 알아보았습니다. 이번엔 헷갈리던 개념인 MVC, Flux, Redux에 대해 정리해보도록 하겠습니다.
조각조각 - Software Architecture, Design Pattern, MVC, Flux, Redux [1]
지금까지 떠오른 의문사항
- MVC, Flux를 검색하다보면 Flux Architecture라고 하는 곳도 있고 Flux Pattern이라는 곳도 있는데 뭐가 맞는걸까?
- Redux 검색할때마다 Flux가 같이 나오고 설명도 비슷한거 같은데 둘의 차이점은 뭘까?
의문사항 답변을 정리해보자면...
- mvc와 flux는 관점에 따라 아키텍쳐 혹은 디자인 패턴으로 불립니다.
사실 그냥 혼용해서 막 사용하는거처럼 보여요 ㅠㅠ - flux가 적용되는 관점이 프로젝트 전체, 즉 flux가 프로젝트의 전체를 나타내는 큰 틀인 경우 Flux Architecture라 부를 수 있습니다. 반면에 flux가 프로젝트에 특정 부분 혹은 코드 단에서 적용되도록 관점이 좁아진다면 Flux Pattern이라 부를 수 있습니다.
- Redux는 소프트웨어 아키텍쳐나 디자인 패턴과 같은 틀을 뜻하는 것이 아닙니다. 이 큰 틀(flux)로 프로젝트가 제작하도록 도와주는 프레임워크 입니다. 즉, flux architecture, flux pattern을 사용할 수 있도록 도와주는 프레임워크를 뜻합니다.
MVC, Flux, Redux의 관계에 대해 파악하였으니 이제 각각을 좀 더 자세히 알아 보겠습니다.
MVC
MVC - 위키피디아
모델-뷰-컨트롤러(model–view–controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.
MVC 패턴 기본 형태
MVC 패턴은 위 그림과 같이 컨트롤러, 모델, 뷰로 이루어진 디자인 패턴으로 모델과 뷰 사이 양방향 데이터 바인딩이 이루어진다는 특징을 가지고있습니다.
양방향 데이터 바인딩
모델(상태)이 변경되면 뷰(화면)에 변경된 값이 반영됩니다.
뷰(화면)에서 발생하는 특정 트리거로 인해 액션이 동작하면 컨트롤러가 모델(상태)를 변화시키고 변화된 모델(상태)가 또 뷰(화면)에 반영됩니다.
데이터 바인딩이 양방향으로 동작하기 때문에 비교적 쉽게 개발자가 원하는 대로 코드를 작성, 동작하도록 할 수 있습니다. 하지만 프로젝트의 규모가 커진다면 뷰와 모델의 수가 많아지고 서로 복잡한 데이터 바인딩 관계를 가지게 되어 프로젝트가 매우 복잡해질 수 있습니다.
뷰와 모델의 데이터 바인딩이 복잡하게 발생하는 경우
프로젝트의 규모가 큰 경우 위 그림처럼 모델과 뷰가 많아지고 복잡한 데이터 바인딩 관계가 생성됩니다. 이 경우 전체적인 앱의 복잡성을 높아집니다.
복잡한 데이터 바인딩의 악영향
- 데이터 바인딩 관계가 마구잡이로 얽혀있어 새로운 개발자에게 프로젝트 지식을 공유할 때 어려움이 발생합니다.
- 복잡한 데이터 바인딩 관계로 컴포넌트간 종속 관계가 많아집니다. 때문에 특정 부분을 수정할 경우 발생하는 변화를 파악하기 어려워져 프로그램 수정이 어려워집니다. 같은 이유로 새로운 기능 추가 또한 어려워집니다. (상태 하나의 변화가 원하지 않은 다른 변화를 일으킬 수 있습니다.)
위와 같은 큰 프로젝트에서 MVC 패턴을 사용할때 발생하는 단점들을 극복하고자 페이스북이 제안한 소프트웨어 아키텍쳐가 바로 Flux 아키텍쳐입니다.
Flux
Flux 공식문서
Flux는 Facebook에서 클라이언트-사이드 웹 어플리케이션을 만들기 위해 사용하는 어플리케이션 아키텍쳐다. 단방향 데이터 흐름을 활용해 뷰 컴포넌트를 구성하는 React를 보완하는 역할을 한다. 이전까지의 프레임워크와는 달리 패턴과 같은 모습을 하고 있기 때문에 수많은 새로운 코드를 작성할 필요 없이 바로 Flux를 이용해 사용할 수 있다.
Flux Architecture 기본 형태
Flux Architecture는 Dispatcher, Stores, Views(React 컴포넌트)로 구성된 소프트웨어 아키텍쳐입니다. 가장 큰 특징은 단방향 데이터 바인딩이며 양방향 데이터 바인딩의 단점을 극복하고자 페이스북에서 제안한 아키텍쳐입니다.
Flux Architecture 구성
action
- 상태 변경 요청을 담은 자바스크립트 객체
- type, payload로 이루어지며 action 생성자로 만들어지기도 합니다.
Dispatcher
- 모든 데이터 변경 요청이 경유하는 중앙 허브
- store의 순서에 맞게 action을 전달
- 상태 변경이 이곳에서 이루어지지는 않습니다.
Stores
- 전역 상태 저장소로 Dispatcher로 전달받은 action을 통해서만 상태가 변경됩니다.
- 상태가 변경되면 view에 통지합니다.
Views(React 컴포넌트)
- 상태가 변경됨을 파악하고 화면을 업데이트
- Dispatcher에게 action을 전달합니다.
모든 액션이 하나의 Dispatcher를 거쳐야하기 때문에 단방향으로 데이터 흐름이 진행됩니다. 이 덕분에 대규모 프로젝트에서도 MVC 패턴처럼 데이터 바인딩 관계가 거미줄처럼 얽히지 않습니다.
MVC 패턴의 경우 여기 저기 흩어져 있던 상태 변화 코드를 찾아 다녀야 하지만 Flux의 경우 액션에 따른 상태 변화가 store에서 모두 이루어지기 때문에 store만 살펴보면 상태 변화가 어떤 요청에서 어떤 방식으로 일어나는지 확인할 수 있습니다.
Flux 장점
- 데이터 흐름의 구조화로 대규모 프로젝트에서도 상태관리가 쉬워집니다.
- 어떤 변경이 발생하느지 알수 있어 코드의 흐름 알기 쉽다. 그 덕분에 프로그램의 유지보수, 확장이 쉬워집니다.
- 쉬운 유닛 테스트
Flux 한계점
- 높은 학습 곡선
Redux
Redux 공식문서
Redux는 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너입니다.
Redux는 일관적으로 동작하고, 서로 다른 환경(서버, 클라이언트, 네이티브)에서 작동하고, 테스트하기 쉬운 앱을 작성하도록 도와줍니다. 여기에 더해서 시간여행형 디버거와 결합된 실시간 코드 수정과 같은 훌륭한 개발자 경험을 제공합니다.
MVC, Flux는 디자인 패턴과 소프트웨어 아키텍처로 프로젝트의 청사진 역할을 하는 큰 틀입니다. 즉 개념적인 것을 의미합니다. 하지만 Redux의 경우 프레임워크로 실질적으로 Flux Architecture로 프로젝트가 구성하도록 도와줍니다.
Redux에 대한 더 자세한 내용은 다음에 추가로 알아보도록 하겠습니다.
참고자료
