🌊 Flux 패턴

물 흐르듯이 데이터를 처리하기

배경

참고 및 사진 출처: TOAST UI 번역글

MVC에 대한 자료를 찾다보면 자주 보이는 예시가 있다. 바로 페이스북의 버그다.

사용자에게 읽지 않은 메시지 알림이 생겼는데 막상 찾아가면 새로운 메시지가 없다. 그리고 다른 작업을 하면 다시 또 알림이 생기고 새로운 메시지는 여전히 없는 상태다.

정확한 원인은 모르겠지만 위의 그림같은 구조가 아마 그 원인이지 않을까?

MVC에서 View는 Model과 직접적으로 연결되어있지 않지만 Model의 정보를 기반으로 렌더링된다.

만약 Model의 데이터 변화가 View의 변화를 발생시키고 그 View의 변화가 또다른 Model의 변화를 일으킨다면?

소규모의 앱에서는 빠르게 원인을 수정할 수 있겠지만, 대규모 서비스에서는 매우 힘들 것이다.

페이스북 개발팀은 이런 고질적인 문제를 타파하기 위해 과감한 수를 꺼냈다. 새로운 패턴의 등장, 그것이 Flux다.

그래서 Flux 패턴이 뭐예요?

페이스북 개발팀은 데이터의 흐름을 한 방향으로 바꾸려했다.

• 뷰에서 액션을 발생시키면 디스패쳐가 그것을 처리하고 스토어에 반영한다.
• 스토어는 데이터의 변화를 컨트롤러 뷰(그림만 그리는 뷰와 다름)에게 알린다.
• 뷰는 컨트롤러 뷰에게 받은 정보를 기반으로 렌더링된다.

위 작업을 위해서 5명의 노동자가 필요하다.

1. Action Creator
2. Dispatcher
3. Store
4. Controller View
5. View

액션 생성자는 말 그대로 액션을 생성한다. 뷰에서 이벤트가 발생하면 특정 규칙에 따라 액션을 생성한다.

디스패쳐는 액션을 스토어에게 전달한다. 이때 특정 스토어에게만 전달하는 것이 아니라 모든 스토어에게 액션이 전달된다.

스토어는 액션이 오기를 기다렸다가 자신이 처리할 액션을 감지한다. 보통은 switch 문으로 액션을 잡는다. 그리고 자신의 변화를 컨트롤러 뷰에게 알린다.

컨트롤러 뷰는 스토어에게서 받은 정보를 알맞는 뷰에게 전달한다. 이때 뷰는 데이터가 어떻게 조작되는지 모른다. 그저 전달된 데이터를 그릴 뿐이다.

요약하자면

뷰 -> 액션 -> 디스패쳐 -> 스토어 -> 뷰 형식으로 한 방향의 데이터 흐름이 만들어진다.

디자인 패턴과 개발

MVC에 이어 Flux 패턴에 대해서도 알아봤다. 중간중간 MVVM 등 다른 패턴에 대해서도 살짝 읽어봤는데 점점 이런 생각이 든다.

모든 디자인 패턴은 개발자들이 개발을 편하게 하기 위해서 나타난 게 아닐까?

Flux 또한 데이터의 흐름을 단방향으로 바꿔 시스템을 예측하기 쉽게 만드는데 의의가 있다.

대규모 서비스를 제공하는 개발자들이 몸소 체감한 깨달음이기도 하다.

나는 아직 그런 서비스를 제공할 역량도, 경험도 많이 부족하다. 하지만 이런 패턴을 조금이나마 알고 있다면 추후 비슷한 상황이 생겼을 때 도움이 되지 않을까? 🙂

다양한 경험들을 쌓아봐야겠다.