Design Pattern (MVC & Flux)

1. Design Pattern

• 소프트웨어를 설계하면서 자주 발생하는 문제에 대한 모범답안 (설계 노하우를 패턴으로 정리)
• 일부 코드를 해결하기 위한 비교적 작은 범위를 다루는 것들도 존재, 애플리케이션 전체를 설계할 때 사용하는 큰 범위를 다루는 것들도 존재

 

2. MVC

 애플리케이션 전체를 다루기 위한 디자인 패턴들은 통상 여러 작은 범위의 디자인 패턴들을 함께 사용해서 만들어지기에 복합패턴이라고도 부른다. 시간이 흐름에 따라 애플리케이션의 규모는 점점 다양하고 거대해지며 이를 해결하기 위한 여러가지 디자인 패턴들도 많이 나오게 되었다. 그 중 모든 복합 패턴의 근간이라고 부를 수 있는 패턴이 MVC 패턴이다.

MVC 패턴은 애플리케이션을 Model, View, Controller 세가지 구성요소로 나눠서 설계하는 패턴이다.

1. Model - 데이터의 형태를 정의하고, 데이터를 수정하는 역할을 담당
2. Controller - 유저의 입력을 받아서 애플리케이션 내에서 어떻게 처리할지 판단 및 가공해서 모델 또는 뷰를 조작
3. View - Model을 UI로 표현, 사용자의 입력을 받아서 Controller에 전달, 기본적으로 Model에게 접근해서 데이터를 받아오지만, 때로는 Controller에서 Model을 거치지 않고 바로 View를 변화시키기도 한다.

 MVC 패턴은 애플리케이션의 구성요소를 역할에 따라 분리하였다. 그리고 각 구성요소들은 서로에게 접근할 수 있다. 즉 “양방향 통신” 이 발생한다. 모든 애플리케이션은 결국 본질적으로 데이터(모델)을 잘 조작해서 화면(View)에 보여주는 것이기에 모든 디자인패턴의 대부, 근본이 MVC 패턴이 되었다.

하지만, 프론트엔드라는 분야가 새롭게 생겨났고, 이 프론트엔드 내에서는 유저와 수많은 상호작용이 발생하고, 데이터를 빈번하게 수정해야 했으며 백엔드로부터 받아오는 데이터와, 클라이언트단에서 관리하는 데이터들을 모두 잘 관리해야 하는 복잡한 요구사항에 직면하게 된다. 이러한 복잡한 상황속에서 프론트엔드에서 기존의 MVC 패턴을 그대로 사용하기는 한계가 있었다.

 React를 만들고, 유지보수하는 Meta 에서도 이러한 어려움을 겪게된다. 당시 Facebook에서는 Direct Message 기능이 있었는데, 이 기능은 처음에는 단순하게 시작했지만, 시간이 흐르면서 여러 요구사항이 추가되면서 복잡한 시스템이 되어갔다. 그런데 이런 기능을 개발해서 운영하던 중 ‘안 읽은 메세지가 존재한다는 표시가 있는데 실제 채팅 시스템을 들어가서 확인해보면 안읽은 메세지가 없는’ 버그가 발생하게 된다.

개발자들은 이러한 버그를 인식하고 해결했지만, 해결한 뒤에도 시간이 조금 흐르면 동일한 버그가 계속해서 발생하게 되었다. Meta팀의 개발자들은 이렇게 동일한 버그가 계속 발생하고, 이를 해결하지 못하는 근본적인 원인을 “MVC 패턴의 양방향성” 으로 정의하게 되었다.

 

 

MVC 패턴은 각 구성요소들끼리 양뱡항으로 통신하게 되어있다. 이러한 양방향 통신은 애플리케이션의 규모가 단순할때는 큰 문제가 되지 않는다. 하지만, 시간이 흐름에 따라 많은 Model과 View들이 생기게 되면 ‘특정 View A에서 발생한 동작이 Model A를 수정하게 되고, Model A가 수정되었으니 이에 영향을 받는 View B가 수정되게 되고, View B가 수정되니 Model B를 수정하게 되고 ….’ 등 연쇄적인 변화가 발생하게 되고 결국 애플리케이션의 동작 흐름을 분석하거나 예측할 수 없는 문제가 발생하게 된다.

 

 

3. Flux

 MVC 패턴이 가진 문제를 해결하기 위해 당시의 페이스북팀 개발자들은 새로운 디자인 패턴이 필요하다고 생각했다. 그리고 새로운 디자인 패턴을 발표하면서 그 이름을 Flux 라고 지었다.

 

3-1. Flux 패턴은... 

• Flux의 핵심은 단방향
• 문제의 원인을 양방향으로 인한 연쇄적인 변화로 규정하였기에 자연스레 Flux는 단방향으로 애플리케이션의 변화의 흐름을 최대한 단순화하고 예측가능하게 하는데에 목표를 두었다.
• Flux 패턴은 4가지 구성요소, 그리고 각 구성요소들은 한가지 방향으로만 상호작용

• Action - 어떤 변화를 발생시킬지 정의하는 type property와 변화에 필요한 데이터를 담고있는 단순한 객체
• Dispatcher - Action을 받아서 모든 Store에 전달하는 역할을 수행
• Store - 애플리케이션의 데이터를 저장하고, Dispatch에 전달된 Action에 따라 수정
• View - Store에 저장된 데이터를 받아서, UI로 표현하고, 유저의 동작에 따라서 Action을 생성

 

3-2. Flux 패턴의 단방향성으로 인한 장점

• 애플리케이션은 특정한 순서에 따라서만 데이터와 UI가 변화
• 개발자들은 애플리케이션에서 어떤 변화가 일어나는지 파악하기가 쉬워짐
• 애플리케이션의 동작을 예측하기도 쉬워짐