리액트 쿼리를 사용하는 방식에 대해 궁금증이 있어요.

저도 비슷한 고민 많았어요. MVP · 실험 단계라면 컴포넌트에서 바로 useSuspenseQuery 쓰는 편이 속도 면에서 좋았어요. 규칙 정하기 전에 빠르게 수정하기 쉬워서요. 반대로 같은 쿼리 옵션이 세 번쯤 복붙되기 시작하거나 팀원이 늘면 useTodos() 같은 도메인 훅으로 감싸두는 게 마음이 편하더라고요. 한 곳만 고치면 캐시 정책·오류 처리 모두 반영돼서 리스크가 줄어드는 것 같아서요. 또한, 캐시 새로고침 타이밍이 매출·비용에 직접 영향 주는 데이터(재고, 결제 금액 등)라면 중앙 제어할 수 있는 훅 패턴이 오히려 안전할 수 있는 것 같아요. 아래 2가지 • 쿼리 옵션 파일만 따로 entities/todo/todosQuery.ts처럼 빼두고, 재사용 필요해지면 그때 훅을 만들면 코드 변경 비용이 상대적으로 적은 것 같아요. • ESLint + TS Path Alias로 레이어 경계를 체크해두면 “어디 둬야 하지?” 고민을 자동으로 막을 수 있었어요. 결국 “팀 규모·재사용 빈도·비즈니스 리스크” 세 가지로 판단할 수 있는 것 같아요. 처음부터 한쪽으로 고정하기보다는, 상황에 따라 변경할 수 있게 고민해서 결정하는 것도 방법이 될것 같아요 :)

저도 같은 고민을 한 적 있었는데요. 단순히 한두 번 사용하는 쿼리라면, 경찬님 말씀처럼 빠른 MVP 개발 관점에서는 useSuspenseQuery를 직접 사용하는 게 더 직관적일 수 있다고 생각해요. 하지만 useTodos처럼 래퍼 훅으로 추상화해두면 도메인 레벨에서 의미를 분명히 드러낼 수 있어서, 팀원 간 커뮤니케이션이나 유지보수 측면에서는 훨씬 유리하더라고요. 실제로 코드 리딩 관점에서도 도메인별로 훅이 잘 분리돼 있으면 구조를 이해하기 훨씬 쉬웠던 경험이 많았어요.

여러 사례들을 찾아보니 간단한 조회 같은 쿼리는 UI와 함께 작성해도 무방하고, 규모가 커지거나 재사용이 필요하면 별도로 분리하는 것을 고려하라는 내용이 많은 것 같아요. 첫번째 케이스는 컴포넌트 레벨에서 쿼리를 관리하면 UI와 로직의 결합 가능성이 있을 것 같고 특히, mutation의 콜백 함수를 다뤄야한다면 코드가 복잡해질 가능성도 있을 것 같아요. 두번째 케이스는 컴포넌트 레벨에서는 정의된 커스텀훅 쿼리만 호출하면돼서 관심사의 분리가 용이한 장점이 있고, 반면 단점으로는 추상화 계층이 하나 더 생기고 타입 추론이 어려워질 수도 있겠어요. 저는 주로 커스텀훅으로 분리해서 계층을 하나 더 두는편인데요. 케이스에 따라 어떤건 컴포넌트 계층에 정의하고 어떤건 별도로 분리하고 하는게 유지보수 차원에서 혼란을 줄 수 있다고 생각해서요, 간단한 쿼리여도 커스텀 훅으로 분리해서 일관된 API 정의 패턴을 지키려고 해요!