Redux는 왜 Redux일까?

이동준·2023년 8월 27일

리덕스

목록 보기

1/5

서론

리덕스가 리덕스라는 이름으로 불리게 된 유래로는 몇가지의 가설이 존재한다.
하지만 리덕스의 개발자인 Dan Abramov는 어떤 이유에서 리덕스가 리덕스로 이름이 지어졌는지 명확하게 밝힌 바가 없다.
그래서 인터넷에는 여러가지 가설이 존재하는데, 그 중 가장 유력한 가설 중 하나를 가져왔다.
다른 가설로는 라틴어 redux의 뜻 "되돌리다", "부활시키다" 에서 가져왔다는 설과 디자인 패턴인 리덕션(Reduction)에서 가져왔다는 설이 존재한다.
하지만 이번에 다룰 내용은 Redux = Reduce + Flux 이고 정확한 내용이 아닐 수 있으니 참고만 하자.

Redux = Reduce + Flux

리덕스는 함수형 프로그래밍의 reduce와, 페이스북의 Flux 아키텍처를 합친 뜻이라는게 있다.

reduce

reduce의 기능은 함수형 프로그래밍의 고차 함수의 개념으로 굉장히 유용한 기능을 가지고 있는데, 이름에서 알 수 있듯 감소, 축소 시키는 기능을 가지고 있다.

[1, 2, 3, 4].reduce((a, b) => a + b, 0);
// 10
[1, 2, 3, 4].reduce((a, b) => a - b, 0);
// -13

array.reduce(callback(accumulator, currentValue[, index[, array]] )[, initialValue])

예시에서 보여주듯 reduce 메서드는 2개의 인자를 받는데, 1번째 인자는 콜백 함수를 받고 2번째 인자는 initialValue, 초기값으로 필수 항목은 아니다.
reduce의 첫번째 인자 콜백 함수는 무조건 두개의 인자를 받는다. 2개의 인자 중 첫번째 값에 누적된 값을 두번째 값으로 연산될 값을 가져온다.
콜백 함수 내부에 연산이 a + b 라면 초기값 0 + 1번째 index 1을 가져와 연산을 진행하고 배열을 순회하여 마지막 index인 4까지 연산을 진행한다.

Flux

Flux는 기존에 MVC 아키텍처 방식의 양방향 데이터 흐름의 단점을 상쇄하고자 페이스북에서 개발된 아키텍처이다.

MVC 아키텍처는 Controller에서 Model의 데이터를 조회하고 업데이트하는 역할을 하고, Model은 이런 데이터를 View를 통해 반영시킨다. 또한 View에서 사용자로부터 입력받은 데이터를 가져와 Model에 영향을 주기도 한다. 이러한 구조는 에플리케이션의 규모가 커지면 커질수록 복잡도가 올라가고, 사용자와의 상호작용으로 인해 Model을 업데이트 해줘야하는 문제가 생긴다. 또한 의존성의 이유로 하나의 모델만이 아닌 다른 모델까지 모두 업데이트 해야하는 경우도 발생한다.

그렇게 상호작용으로 인한, 양방향 데이터 흐름에 의한 의존성, 복잡성에 대한 단점을 상쇄하고자 만들어진게 Flux 아키텍처이다.

Flux의 시스템 구조는 단방향 데이터 흐름이다. Dispatcher > Stroe > View의 흐름을 가지고 있고, View에서 받은 입력은 Action을 통해 Dispatcher로 향하게 된다.

Dispatcher

디스패처는 Flux 앱의 모든 데이터 흐름을 관리하는 일종의 허브이다. 액션이 발생하면 디스패처로 메세지나 액션 객체를 전달하고 디스패처에서는 이러한 메세지, 액션 객체를 콜백 함수를 통해 스토어로 전달한다. 스토어에 접근하기 위한 일종의 단계이고 액션을 통해 스토어에 접근하기 위해서는 디스패처의 단계를 거쳐야한다.

Action

디스패처를 통해 스토어에 변화를 일으킬 수 있는데, 이 경우 디스패처의 데이터 묶음을 액션이라고 한다.

dispatch({
  type: GET_POST,
})

이런 식으로 액션의 이름을 타입을 통해 명시하고 payload 값을 넣어 데이터를 관리 할 수 있다.

Store

스토어는 애플리케이션의 상태를 저장한다. 모든 상태 변경은 스토어에 의해 결정되며 상태 변경을 위한 요청을 스토어에 직접 할 수는 없다. 상태 변경을 위해서는 꼭 액션 생성자를 통해 디스패처 단계를 거친 뒤 액션을 보내야만 상태값을 변경 할 수 있다.

View, Controller View

뷰는 상태를 가져와서 보여주고 사용자로부터 입력을 받을 화면을 보여준다. 컨트롤러 뷰는 전체적으로 화면에 나타나는 자식 뷰들과 스토어를 연결하는 매개체이다. 자식 뷰들은 컨트롤러 뷰에게 변화된 상태를 받고 그 상태에 따라 다시 렌더링된다.

Redux

Flux 아키텍처의 흐름을 보면 reduce의 흐름과 굉장히 유사한 부분이 많다는 것을 알 수 있다.

내용(Action)을 함수에 전달(Dispatcher)하면 함수가 누적(Store)된 데이터를 수정한다...

리덕스는 디스패처를 없애고 리듀서(reducer)를 사용한다. 리듀서는 한 번에 하나의 액션을 소비하는 reduce 함수이다.
리덕스의 역할은 리듀서를 사용하여 한번에 한 상태변화를 저장소에 기록하는 것이다. 리듀서는 저장소를 예측 가능하게 수정 할 수 있게 해주는 순수 함수이다.

function counter(state = 0, action) {
  switch (action.type) {
  case 'INCREMENT':
    return state + 1
  case 'DECREMENT':
    return state - 1
  default:
    return state
  }
}

이 리듀서는 INCREMENT 메세지를 받을 때마다 현재 상태의 1을 더한 값을 반환한다. 그렇게 새로운 상태가 저장된다. 이러한 동작구조는 일반적인 reduce 함수와 동작 자체가 다르지 않다.

결론?

Flux 아키텍처를 기반으로 만들어진 Redux는 reducer라는 합리적인 데이터 처리 방식을 통합한 것이 Redux라는 이름의 유래라는 것이 납득이 갈만한 내용인 것 같다.
유래가 맞는지 아닌지 여부와 관계없이 리덕스 자체의 핵심 기능인 reducer와 Flux 아키텍처의 개념을 알고, 이해한다는 것 자체가 매우 중요한 듯 싶다.

참고 문서 : https://medium.com/coderblurbs/redux-reduce-flux-18c49b3daa1d

이동준

다음 포스트