나는 왜 TanStack Query를 사용할까?

소개

안녕하세요! 프론트엔드 개발자 김동규입니다. 오늘은 오랜만에 'AWSKRUG 프론트엔드 소모임'에 참여하고 왔는데요. 발표 주제는 'TanStack Query(=React Query)'였고 발표자는 김민수님(데브크라)이었어요. 실무에서 자주 사용하는 기술에 대한 발표여서 흥미를 느껴 재빨리 신청했었어요. 오늘 글에서는 발표를 들은 후기와 제가 'TanStack Query'를 사용하는 이유에 대해 공유하고자 해요. 사용법에 대해서는 다루지 않으니 참고 부탁드려요.

AWSKRUG 프론트엔드 소모임 후기

오늘의 소모임은 '무신사 캠퍼스 N1' 2층 타운홀에서 진행되었어요. 퇴근하자마자 강남에서 성수역까지 30분 정도 걸려서 가느라 너무 배고팠었어요. 도착하니 햄버거를 나눠주셔서 발표를 집중해서 들을 수 있었어요😄.

발표는 왜 'TanStack Query'를 사용하는지, 용어와 개념, 간단하게 투두리스트를 만들어보고 QA를 받는 순으로 진행되었어요. 발표를 듣고는 이곳저곳 흩어져있던 지식이 차곡차곡 정리되는 느낌을 받았어요. 그만큼 발표자가 정리를 잘해서 가려운 곳을 잘 긁어줬던 것 같아요. 근래 들었던 기술 지식 공유 관련 스터디, 세미나, 컨퍼런스 중에서 최고의 경험이었어요.

또한, 발표를 준비하신 자료들이 레퍼런스들을 기반으로 만들어졌기 때문에 신뢰성이 엄청 높았어요. 또한 중간중간 확인해 보면 좋은 정보들도 공유해주시고 마지막엔 다음 발표자들을 위한 주제를 추천해 주셨어요. 저는 이 발표를 듣고 평소에 나는 'TanStack Query'에 대해 어떻게 생각하고 있었는지 정리해 보고 싶다는 생각이 들었어요.

TanStack Query를 사용하는 이유

저는 개발을 하면서 전역 상태 관리를 위해 Redux, Zotai, Zustand, Recoil 등의 라이브러리를 사용해요. 클라이언트 상태와 서버 상태 관리를 분리하기 위해서 많은 분들이 'TanStack Query'를 사용하실 것 같아요. 저도 마찬가지지만, 좀 더 자세하게 제 생각을 공유드려요.

직관성

첫 번째, 서버로부터 응답받은 데이터를 위의 라이브러리들로 관리한다고 가정해 볼게요. 클라이언트와 서버의 상태를 직관적으로 보여주기 위해서는 상태 관리를 위한 훅을 선언할 때, 네이밍을 상당히 신경 써야 해요. 왜냐면 둘 다 라이브러리에서 제공하는 공통의 훅을 사용하기 때문에 제공된 훅 네이밍만으로는 어떤 상태를 관리하는지 알 수가 없어요.

서버에게 받은 데이터는 모두 'TanStack Query'에서 제공하는 훅을 사용하면 이 문제를 단번에 해결할 수 있어요. 'useQuery', 'useMutation'만 보더라도 우리들은 서버 상태 관리를 위한 로직이라는 것을 쉽게 알 수 있어요.

신뢰성

두 번째, 클라이언트 상태는 프론트엔드 개발자가 변경을 예상하고 지속적으로 동기화하고 관리하기 수월해요. 하지만 서버 상태는 언제 변경이 발생할지 알 수가 없어요. 이런 예측 불가능한 상태는 엔드유저에게 신뢰성 높은 데이터를 보여주기 위해서 복잡한 로직을 작성하고 동기화 문제를 해결하기 위해 수많은 고민을 해야 해요. 'TanStack Query'는 query-key, stale-time, gc-time 등을 이용한 캐싱 전략과 낙관적 업데이트를 제공하여 엔드유저에게 데이터 일관성과 신뢰성을 보장해 줘요.

재사용성

세 번째, 'useQuery'를 사용해서 한 번이라도 서버 데이터를 불러왔다면 query-key 기반으로 해당 데이터를 Network 통신 없이 다시 가져올 수 있어요.

QueryClient에서 제공하는 메소드인 'getQueryData'를 사용한다면 'QueryClientProvider' 범위 안에 있는 컴포넌트 그 어디에서든 손쉽게 서버 데이터를 불러올 수 있어요. 클라이언트 상태 관리 라이브러리들처럼 'TanStack Query'도 'Props Drilling' 문제를 해결했어요.

편리한 재사용을 위해서는 유지보수 측면에서 query-key 관리에 신경 쓰면 좋다고 생각해요. 저는 Query Key Factory 패턴을 자주 사용하고 있어요. 'TanStack Query' 공식 문서에서 제공하는 커뮤니티 프로젝트인 'query-key-factory' 라이브러리를 사용해도 좋아요. 또는, 제가 많이 참고했던 'TanStack Query'의 메인테이너 TKDodo의 블로그를 참고하시는 것도 추천해요!

실제로 'TanStack Query'의 공식 문서에서 커뮤니티 리소스 중 하나로 TKDodo의 블로그를 추천하고 있어요.

다양한 커뮤니티 프로젝트

네 번째, 다양한 커뮤니티 프로젝트가 있어 지속적인 성장을 한다고 생각해요. 정말 많은 커뮤니티 프로젝트가 있어 'TanStack Query'가 정말 많은 분께 사랑받고 있다고 느꼈고, 그만큼 개발자들의 가려운 곳을 잘 긁어주는 정말 훌륭한 라이브러리라고 생각해요. 많은 커뮤니티 프로젝트가 'TanStack Query'에 의존하고 있는 만큼 지속적으로 업데이트되고 있어요. 이러한 생태계는 제가 라이브러리 사용을 위해 결정하는 중요한 요소 중 하나에요.

TanStack Query는 단점이 없나요?

제가 느낀 'TanStack Query'의 단점은 '초기 러닝 커브'라고 생각해요. 이 기술을 사용하기 위해서는 캐싱 전략을 필수적으로 알아야 하고 각종 용어의 의미를 알고 있어야 해요. 제대로 이해하지 못한다면 디버깅 과정에서 문제를 찾기 어려울 수 있어요. 그리고 'TanStack Query'는 정말 다양한 기능을 지원해요. 처음 사용하시는 개발자분들의 경우에는 적재적소에 어떤 기능을 사용할지 어려워할 수도 있어요.

발표자셨던 김민수님의 데모 프로젝트처럼 투두리스트를 만들어가면서 기술을 익히시는 게 큰 도움이 될 수 있다고 생각해요. 즉, CRUD 기능을 제공하는 사이드 프로젝트를 진행해보시는 걸 추천해요.

마무리

전 앞으로도 서버 상태 관리를 위해 'TanStack Query'를 자주 사용할 것 같아요. 만족도가 높은 라이브러리는 언제나 환영이죠!

혹시라도 'Redux, Mobx 등의 전역 상태 관리 라이브러리를 'TanStack Query'로 대체할 수는 없을까?'라는 의문을 가지신 분들께 공식 문서를 공유해요. 이러한 질문이 많았는지 공식 문서에서 답변해주고 있어요. 이와 관련된 카카오페이의 기술 블로그 한 편을 추천해요.

AWSKRUG 프론트엔드 소모임과 같은 커뮤니티 활동은 항상 이미 알고 있던 혹은 알고 싶었던 지식을 정리할 수 있게 되는 계기가 되는 것 같아요.

AWSKRUG에 관심이 있으시다면 Meetup에서 만나보실 수 있어요.

읽어주셔서 감사합니다!