리액트 쿼리는 앞으로 어떻게 될까요?

안녕하세요! 개인적으로 react-query가 최근에 떠오른 이유는 같은 문제를 다르게 풀었기 때문이라고 생각해요. 기존에는 서버/UI 상태 관리를 전역 상태 관리 툴에서 같이했다면, react-query는 서버 상태만을 위한 스토어에 여러가지 기능을 추가해서 사용하는 방식이죠. 캐싱, 로딩, 에러 처리, 리패칭 등 귀찮은 일을 대신 해주고, 쓰기 쉬웠던게 react-query를 많이 사용하는 이유라고 생각됩니다. 질문자님이 생각하시는 것처럼 미래에 서버 컴포넌트가 안정적으로 운영되기 시작하면 react-query가 내세우는 서버 상태 관리의 많은 부분을 대체할 수 있지 않을까 생각되네요. 하지만, 기존 레거시를 react 18로 올려서 서버 컴포넌트를 사용하는 것은 쉽지 않을 것 같습니다. 서버 컴포넌트라는 개념이 없던 시절에 짠 코드 베이스를 변경하는 작업은 상당히 까다로울 것 같아요. 기존에 react를 설계하고 짜왔던 방식을 조금 다르게 접근해야되니 개발자들이 습득하는데 시간이 걸릴 것 같기도 하구요. 결국, 기존 레거시가 react 18을 느리게 도입할수록 레거시에서 쓰던 react-query도 계속 사용되지 않을까 싶습니다. 저도 궁금한 주제네요 ㅎㅎ 참고했던 글들 링크 첨부할게요 - https://tech.kakaopay.com/post/react-server-components/ - https://beta.nextjs.org/docs/rendering/server-and-client-components - https://www.plasmic.app/blog/how-react-server-components-work#the-high-level-picture - https://www.youtube.com/watch?v=TQQPAU21ZUw

요즘은 BFF, Edge Computing, SSR 등 프론트엔드에 서버를 띄우는 키워드들이 많지만, 모든 프로젝트에 서버가 필요하다고 생각하진 않습니다. 트래픽이 큰 서비스에서는 오히려 서버를 운영하는 게 리스크 관점에서 허들이 되기도 합니다. 서버 사이드 기술이 발전하더라도 클라이언트 렌더링으로 충분한 프로젝트라면 여전히 React Query를 사용해서 서버 데이터 상태 관리를 하지 않을까요? 제 생각은 그렇습니다. 서버는 SEO, api, 인증 등 다양한 역할을 하지만 서버를 띄우는 데는 인프라가 필요하고 그 인프라를 유지 보수하는 데는 비용이 들어갑니다. 그 비용은 역시 트래픽에 비례해서 늘어나겠죠. 반면에 브라우저 렌더링으로만 충분한 프로젝트들은 S3에 빌드된 파일을 올리고 cloudfront 연동만 해줘도 유지보수가 가능합니다. 아무리 많은 트래픽이 들어와도 서버에 비하면 적은 유지보수 비용으로 서비스를 운영할 수가 있죠. 결론은 CSR로 충분한 프로젝트의 수요가 여전히 있기 때문에, 앞으로도 React Query는 계속 유지보수 되고 인기도 사라지지 않을 것으로 예상해봅니다 :)

Redux와 redux-saga를 대체했다기 보다는 서버에서 호출해오는 데이터를 SPA의 전역 상태에 넣어놓고 사용하는 것에 대한 의문점과, 그렇게까지 사용하기에 보다 복잡한 코드들이 react-query를 도입하게 된 계기 중 하나가 아닐까 생각합니당.. react-query를 단순히 캐싱과 redux-saga의 대안점으로만 보기엔 섬세한 기능들이 많기두 하구요! Next에 관해서는 실무에서 사용해보지 않아서 자세하게는 모르겠습니다! 저도 다른 분들의 답변이 궁금하네요 ㅎ