파일 변수 Deep-Dive

카카오엔터테인먼트 스토리FE개발팀이 모든 상태를 Redux 하나로 관리하다 한계에 부딪혀, 특정 유형의 상태에는 파일 변수를 쓰기로 한 기록이다. 프로젝트 규모가 작을 때는 전역 스토어 하나로 충분했지만 커질수록 문제가 드러났다. 저자는 Redux 자체에 문제가 있는 것이 아니라 모든 상태를 Redux에 넣으려 한 팀에게 책임이 있다고 분명히 짚는다.

핵심 포인트

서버에서 받아오는 상태를 관리하려고 추가한 saga 코드가 많아지며 가독성이 떨어져 하나의 Redux 플로우를 따라가기 어려워졌다.
특정 페이지에서 한 번에 너무 많은 액션을 트리거해 Redux Devtools가 부하를 못 버티고 다운되는 상황이 종종 발생했다.
어떤 값이 주기적으로 변경되고 어떤 값이 한 번 초기화된 뒤 변하지 않는지를 한눈에 파악하기 힘들어졌다.
Redux는 모든 상태를 하나의 저장소에서 관리한다는 원칙을 충실히 지키고 있을 뿐이다.
Redux 메인테이너 본인이 Redux가 불필요한 영역까지 남용되고 있다고 지적한 것을 인용하며, 팀이 정확히 그 사례였다고 인정한다.

상세 정리

팀 상황: 카카오페이지·카카오웹툰·타파스 등 여러 웹 서비스를 개발하고 운영하는데, 규모가 커지고 기능이 늘면서 다양한 유형의 상태를 효율적으로 관리할 방법을 고민해야 했다.
초기 판단: 모든 상태를 한 곳에서 통으로 관리해도 충분하다고 봤고 실제로 규모가 작을 때는 전혀 문제가 없었다.
Redux를 고른 이유 1 미들웨어: 액션이 트리거되어 상태 변경이 스토어에 반영되기까지의 과정을 제어하고 확장할 수 있으며, redux-thunk나 redux-saga가 여기에 속한다.
Redux를 고른 이유 2 보일러플레이트 축소: 하나의 플로우를 정의하려면 액션 정의와 리듀서 구현, 스토어 등록, 비동기 처리를 위한 thunk나 saga까지 상당한 코드가 필요한데 Redux Toolkit이 이를 간단하게 만들어 준다.
Redux를 고른 이유 3 추적성: 상태의 불변성을 유지해 변경 히스토리를 쉽게 추적할 수 있고 devtools로 그 히스토리를 확인할 수 있다.
한계가 드러난 지점은 세 가지로, 코드 가독성과 도구 성능, 그리고 상태의 성격 구분 불가였다.
진단의 방향: 문제를 라이브러리 탓으로 돌리지 않고 사용 방식의 문제로 규정한 것이 이 글의 태도다.
글의 구성으로 특정 유형의 상태를 관리하는 방법인 파일 변수를 소개하고 그 운영 노하우를 공유한다고 밝힌다.

왜 읽나Redux 하나에 모든 상태를 넣고 saga가 비대해진 프론트엔드 팀에게, 무엇이 Redux에 맞지 않는 상태인지 구분하는 관점과 그 대안을 제시한다.

카카오 엔터테인먼트 FE 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

파일 변수 Deep-Dive

이 글과 비슷한

토스는 어떻게 광고 속에 게임을 넣었을까

RxJS로 우아하게 사이드 이펙트 통제하기

항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다