Redux Saga => React Query 전환 시 수치화 가능한 이점이 있을까요?

Redux-saga 를 react-query로 전환한다는 것이 단순히 비동기 로직을 교체한다기 보다는, redux로만 관리하던 전역 상태를, 서버 데이터의 상태와 클라이언트 데이터의 상태로 분리해서 관리한다는 개념으로 이해하시면 좋을 것 같습니다. 윗 분의 답변에서도 확인하실수 있듯이 아키텍쳐 전환을 정확히 수치화 하는것은 힘들지 않을까 싶습니다. 프로젝트나 팀마다 보일러 플레이트도 다르고 코드 스타일도 다르기 때문입니다. 만약 정말 수치화된 정보를 확인하고 싶으시다면, 단순히 LoC를 측정해보시는것이 좋을것 같습니다. React-query 를 도입한다는 것은 단순한 비동기 라이브러리의 마이그레이션이 아닌 아키텍쳐 자체를 뒤엎는 것입니다. 기존에 redux 플로우에서 react-query 의 플로우로 마이그레이션 함으로써 저희 팀에서는 유의미한 LoC 의 변화가 있었고 모두가 상당히 만족했습니다. 또한 기존의 복잡했던 redux 를 걷어내고 나니 유지보수에 있어서 한결 편해진 점도 있었습니다. 이에 관해서 이전에 제가 남겨놓은 포스팅이 있는데 첨부해드립니다. https://tech.osci.kr/react-query/

안녕하세요 :) 제 생각에는 react saga에서 react query 전환했을 때 이점이 있다는 게 주관적인 거라 수치화가 어려울 것 같아요. 수치화할 만한 게 개발 생산성이나 버그 발생 빈도수인데 같은 프로젝트하는 인원이 3명 이상은 돼야 의미 있는 수치를 측정할 수 있을 것 같습니다. 만약에 도구 도입을 위한 설득이나 이력서에 기록하실 예정이라면 1) react saga를 사용해서 어떤 문제가 발생했고 2) 해결하기 위해 어떤 도구들을 검토했으며 3) react query를 선택해서 해결했다 형태로 기입하면 도움 되실 것 같습니다!

캐시 컨트롤을 어떻게 하셨는지에 따라 실제 api 요청의 응답 속도 차이가 있을 거라 보이네요. redux의 보일러 플레이트가 정리되면서 리렌더링의 수도 감소할 수 있고요. 동일한 작업을 카카오가 한 적이 있던 걸로 기억하는데요. 유튜브에서 "redux에서 react-query로 마이그레이션" 이란 키워드로 검색해보세요. 위 2가지 내용 모두 해당 영상에서도 언급하고 있습니다.