당신의 친절한 이웃, 코딩맨

프런트엔드에서 상태관리는 늘 쉽지 않았다. 그리고 계속 쉽지않아진다.처음에는 redux-toolkit이 가장 안전한 길처럼 보였다. 표준화된 구조, 많은 레퍼런스, 팀원들도 익숙했고.하지만 프로젝트가 커지면서 “안전함”보다 “답답함”이 더 크게 느껴지기 시작했다. 내가 담당한 내부 관리툴은 리스트/검색/필터/페이지네이션이 기본이고,여러 곳에서 같은 데이터를 읽고 쓰는 화면들이 많았다.이런 화면에서 redux-toolkit은 이렇게 느껴졌다.slice가 늘어나고 action이 늘어난다서버 상태와 UI 상태가 한 덩어리처럼 섞이기 시작한다“불러오는 데이터 속도가 저하되면서 개선을 내가 할 수 있는게 있을까?” 라는 의문이 계속 든다그러다 결론이 났다.클라이언트 전역 상태와 서버 상태는 분리하자.그리고 그 기..

프런트 엔드 개발자들은 보통 여러 개의 레포지토리를 갖게 된다. 이유는 다양하다. 서비스가 다양할 수 있고, 기존의 서비스를 여러 개로 분할해서 배포/관리하거나, 내부 업무를 위해 화면을 만들 때도 있기 마련이다. 내 예시로는, 패치 로그를 기록하고 검색해서 볼 수 있는 패치 로그 사이트, 서비스 화면, 관리툴, 권한툴, 디자인 시스템,... 이외에 몇 개 더 있다. 레포지토리가 많아지면 과연 좋을까? 처음엔 독립적으로 여러개의 툴을 따로따로 관리해서 작업하는 레포지토리가 분리되니까 더 효율적일 것이라 생각했다. 쉽게 생각하면 프런트 개발자 5명이서 5개의 레포지토리에서 작업을 하니 절대 컨플릭트 날일도 없고, 독립된 환경에서 병렬로 일이 진행된다 생각했었다. 문제는 사소한 곳에서 시작된다. 각각 레..