항공 프론트엔드, 전역 상태 관리 라이브러리 없이 React Query와 URL 상태로 해결

항공 프론트엔드 구축 과정에서 Zustand나 Recoil 같은 전역 상태 관리 라이브러리 도입을 검토했으나 최종적으로 적용하지 않았다. 초기에는 화면 수가 많고 컴포넌트 깊이가 깊어 props drilling이 우려되었지만, 실제 구현에서는 상태의 소유권과 수명을 명확히 정의하여 불필요한 전역 저장소를 제거했다.

상태 분류와 관리 전략

상태를 네 가지 축으로 재정의하여 각각에 맞는 도구를 사용했다.

• 서버 데이터: React Query로 관리하며, 캐싱과 재요청을 제어한다.
• URL 상태: 검색 조건이나 필터는 nuqs 라이브러리를 통해 쿼리 스트링에 저장한다.
• 화면 공유 상태: UI 단계나 펼침 여부 등 서버와 무관한 상태는 Context로 관리한다.
• 로컬 상태: 토글이나 입력 중 값은 useState로 처리한다.

props drilling 회피 및 성능 최적화

서버 데이터는 각 컴포넌트가 React Query 훅으로 직접 호출한다. 동일한 키를 사용하는 경우 서버 요청은 1회만 발생하며 캐시를 활용하므로, 전역 저장소를 쓰지 않아도 효율적이다. 해외선 예약 상세 화면에서는 useSuspenseBookingDetail 훅을 80개 이상 파일에서 호출하지만 요청은 중복되지 않았다.

로딩과 에러 처리는 루트 레벨에서 한 번만 수행하고, 하위 컴포넌트(SuccessBody)에서는 데이터 존재를 전제로 동작하도록 설계했다. Context는 값 변경 시 하위 전체 리렌더링을 유발하므로, 자주 변하지 않는 값만 포함하고 스크롤 위치 등은 제외했다.

URL 상태 관리의 이점

필터나 정렬 상태를 URL에 저장하면 새로고침 시 상태가 유지되고 링크 공유가 가능하다. 또한 브라우저 뒤로가기 지원이 자동화되며, 웹뷰와 브라우저 환경에서 동일한 화면을 렌더링할 수 있는 유일한 통로 역할을 한다. 결과적으로 전역 저장소가 필요한 '주인이 애매하고 오래 살아야 하는 값'이 거의 없어, 라이브러리 도입 없이도 복잡한 화면을 안정적으로 관리할 수 있었다.