오늘 면접에서 받았던 질문 중에 Redux를 왜 사용하였는가, 또 Redux-toolkit에 thunk가 내장되어 있는데 saga를 미들웨어로 사용한 이유가 무엇인가에 대한 질문을 받았다.
첫 번째 질문에 내가 답한 답변은 프로젝트 규모가 작을 시에는 Redux를 사용해 전역상태로 상태를 관리해주지 않아도 상위 컴포넌트에서 props를 통해 하위 컴포넌트로 넘겨주는 데이터가 적기 때문에 사용할 필요성을 못느꼈었는데 프로젝트 규모가 확장됨에 있어 컴포넌트 트리의 뎁스가 깊어지는데 혹여 형제 간의 공유하고자하는 데이터가 있을 시에는 이를 최상단 컴포넌트(형제의 부모)로 끌어올려주어야하는 불편함이 있어 이를 더 깔끔하고 직관적이게, 편리하게 상태를 관리하고자 전역상태 라이브러리인 Redux를 사용했다고 답하였다.
그리고 받았던 질문은 그러면 굳이 Redux라는 라이브러리를 사용하지 않고도 전역에 변수를 선언하여 값을 저장해주면 되는것 아니냐?는 역질문을 받았다.
그러다 문득 이전에 공부한 Flux 아키텍처, 단방향 데이터 흐름이 머릿 속에 스쳐지나갔다. 이에 대해 최대한 답변을 해보려고 하였으나 제대로 이해하지 못했던 개념이기에 깊이있게 대답하지 못했다.
그래서 오늘은 이 Flux architecture에 대해 확실히 짚고 넘어가고자 정리를 해보려고한다.
⛔️ 정리내용은 우테코의 10분 테크톡 강의영상을 참고하였다.
그 전에,
이전 MVC 패턴에 대해 먼저 살펴보자.
부트캠프에서 React를 익혀보기 전, Vanilla JavaScript로만 프로젝트를 만들었을 때 MVC 패턴을 사용하여 만든 적이 있었는데 당시에는 해당 패턴에 대해 완벽히 숙지를 하지 못하였었다. 무얼 의미하고 어떻게 동작하는지는 알았으나 왜 이러한 패턴을 사용하는지에 대해서 깊이있게 체감하진 못했었다는 뜻이다.
Model | View | Controller
이미지 링크) Web Dev Simplified
MVC pattern에 한계
작은 프로젝트에서는 상관이 없지만, 프로젝트나 서비스가 확장됨에 따라 기능이 추가되고 서비스가 커지면 과연 어떻게 될까?
프로젝트가 확장됨에 따라 위의 그림이 수십 개가 된다면?
아마 여러 컨트롤러와 모델 뷰가 이리저리 엉키어 유지보수도 힘들 뿐만 아니라 소스 분석이나 테스트 이 외에 많은 문제점들이 생겨나게 될 것이다. 위 그림을 보면 알 수 있듯이 데이터를 서로 주고받고 영향을 받게 되는데 컨트롤러와 뷰 양쪽의 데이터 일치가 모두 가능한 데이터 흐름을 "양방향 데이터 흐름" 이라고 한다.
이러한 한계를 보완한 여러 다양한 패턴들이 이후에 나오게 되었는데 그 중 하나가 바로 Flux 아키텍처이다.
Flux란?
단방향 데이터 흐름을 통해 보다 예측가능하게 상태를 관리할 수 있는 클라이언트 사이드 웹 어플리케이션 아키텍쳐
Flux는 구체적인 구현이나 프레임워크가 아니라 어플리케이션 구성을 도와주는 추상적인 웹 어플리케이션 아키텍쳐이다.
단방향 데이터 흐름을 사용하여 어플리케이션의 구조를 단순화하고 유지보수를 쉽게 만들어준다. 또한 단방향 데이터 흐름과 독립적인 스토어와 같은 제약사항은 상태를 보다 예측가능하게 만들어준다.
Flux의 장점 (대규모 웹 어플리케이션서도 상태관리 쉽게 가능)
- 데이터 흐름의 구조화, 쉬운 유닛 테스트
-> 더 이상 전체 흐름을 파악하고 있는 일부 개발자에게 의존하는 것이 아니라 팀원 누구나 각각의 액션을 따라가면 어떤 변경이 발생하는지 알 수 있어 코드의 흐름을 파악하기가 쉬워짐. 이는 곧 코드를 더 유지보수하기 쉽게 만들고 새로운 기능 확장에 열려있는 어플리케이션을 만들어준다.
-> 유닛 테스트도 쉬운 코드가 만들어짐. 디스패치는 액션을 받아 상태를 변경하는 순수함수이다. 외부의 상태에 영향을 받지 않기 때문에 격리된 환경에서 쉽게 테스트할 수 있음.
Flux의 단점
- 높은 학습 곡선, 장황한 문법
-> 초기에 작은 기능을 정리하기 위해 상대적으로 많은 코드가 필요하다. 이는 학습 곡선을 높이고 개발 시 불필요한 프로그래밍 오버헤드를 발생시킬 수 있음.
결론
즉, MVC 패턴의 큰 특징 중 하나는 "양방향 데이터 흐름".
모델이 변경된다면 뷰 또한 변경되고, 사용자에 의해 뷰에서 변경이 일어난다면 모델 또한 변경이 됨. 이러한 양방향 데이터 흐름은 설계하기 간단하고 코드를 작성하기 쉽다는 장점이 있지만, 프로젝트 규모가 커진다면 한 개의 모델이 여러 개의 뷰를 조작하고 한 개의 뷰가 여러 개의 모델을 조작하는, 데이터 흐름을 이해하기 힘들어지는 큰 단점이 있음. 이는 버그를 찾기 어려워지고 데이터 흐름을 추적하는 데 많은 시간을 투자해야 함.
이를 개선하기 위해 나온 것이 Flux 아키텍처 패턴.
Flux - View는 MVC 패턴과 달리 데이터를 변경시키지 않고 Action을 넘겨주고 Action은 반드시 Dispatcher를 지나 Dispatcher를 통해서 데이터 변경이 일어남. View는 변경된 데이터를 Store를 통해서 전달 받게 되는데 이러한 단방향 데이터 흐름은 기존의 MVC 패턴에 있던 "상태의 전이"(뷰와 모델 사이의 데이터 변경이 연결된 수많은 곳으로 따라 변경되는 현상) 현상을 없애주고 "예측 가능하다" 는 큰 장점이 있음.
MVC의 한계 및 단점을 해결하기 위해 나온 것이 Redux나 Mobx와 같은 Flux를 발전시킨 다양한 구현 라이브러리들이 등장하게 된 것❗️
또, Redux를 사용하면서 비동기 처리를 하고자 미들웨어인 saga를 사용했었는데, 조금 더 상세한 이유를 하나하나 되짚어보기 위해 해당 링크를 참고하였는데 많이 도움이 되었다.
참고 링크) 우테코
