동기

자바스크립트 단일 페이지 애플리케이션의 요구 사항이 점점 복잡해짐에 따라 우리의 코드는 이전보다 더 많은 상태를 관리해야 합니다. 이 상태는 서버 응답과 캐시된 데이터는 물론, 아직 서버에 저장되지 않은 로컬에서 생성된 데이터를 포함할 수 있습니다. 활성 라우트, 선택된 탭, 스피너, 페이지네이션 컨트롤 등을 관리해야 하므로 UI 상태 역시 복잡성이 증가하고 있습니다.

이렇게 끊임없이 변화하는 상태를 관리하는 것은 어렵습니다. 한 모델이 다른 모델을 업데이트하면, 뷰가 모델을 업데이트하고, 이로 인해 또 다른 모델이 업데이트되며, 결국 다른 뷰까지 업데이트될 수 있습니다. 어느 순간 앱에서 무슨 일이 일어나는지 이해하지 못하게 됩니다. 상태의 시기, 이유, 방법에 대한 통제력을 잃었기 때문입니다. 시스템이 불투명하고 비결정적일 때는 버그를 재현하거나 새 기능을 추가하기 어렵습니다.

이것만으로도 충분히 나쁜데, 프론트엔드 제품 개발에서 흔히 요구되는 새로운 사항들까지 고려해야 합니다. 개발자로서 우리는 낙관적 업데이트(optimistic updates), 서버 사이드 렌더링, 라우트 전환 전 데이터 불러오기 등을 처리해야 합니다. 우리는 이전에 경험하지 못한 복잡성을 관리하려 애쓰다 보면 필연적으로 질문하게 됩니다: 포기할 때인가요? 대답은 _아니오_입니다.

이러한 복잡성은 인간의 사고로 이해하기 매우 어려운 두 개념을 혼합하기 때문에 다루기 어렵습니다: **변이(mutation)와 비동기성(asynchronicity)**이 바로 그것입니다. 저는 이를 멘토스와 콜라에 비유합니다. 각각은 분리되어 있을 때는 훌륭하지만, 함께 사용하면 엉망이 됩니다. React 같은 라이브러리는 뷰 계층에서 비동기 처리와 직접적인 DOM 조작을 제거해 이 문제를 해결하려 합니다. 그러나 데이터 상태 관리는 여러분의 몫으로 남습니다. 바로 여기서 Redux가 등장합니다.

Flux, CQRS, Event Sourcing의 발자취를 따라 Redux는 상태 변이를 예측 가능하게 만들고자 합니다. 업데이트가 발생하는 방식과 시점에 대한 특정 제약을 부과함으로써 이를 실현합니다. 이러한 제약은 Redux의 세 가지 원칙에 반영되어 있습니다.