상태관리 의사결정 — Jotai + React Query 역할 분담

시작점에서 가장 먼저 본 신호는 package.json에 jotai도 react-query도 없다는 점이었습니다. 마크업·스타일은 거의 다 깔려 있는데 라이브러리만 비어 있다는 건, 토스가 상태 관리 도구를 직접 골라서 그 선택을 설명할 수 있는가를 본다는 의도라고 읽었습니다.

저는 client state는 jotai, server state는 react-query로 가르고 시작했습니다. 두 가지가 풀어야 할 문제 자체가 다르니까요. 사용자가 입력한 출발역·가는날·인원 같은 값은 클라이언트가 주인이고 페이지를 옮겨다녀도 유지돼야 하는 데이터고, /api/stations나 /api/tickets 응답은 서버가 주인인 캐시 같은 데이터입니다. 한 도구로 둘 다 다루면 staleTime이나 invalidate 같은 개념이 client state까지 침범해서 모델이 흐려진다고 봤습니다.

jotai를 고른 이유는 세 가지입니다. 첫째, atom 단위로 selective subscription이 자연스럽게 됩니다 — passengerCountAtom을 구독한 컴포넌트는 다른 atom이 바뀌어도 리렌더되지 않습니다. 둘째, 보일러플레이트가 거의 없습니다. atom 한 줄로 끝나니 6시간 제약 안에서 행정 비용이 작습니다. 셋째, atom이 모듈 스코프 변수라 "다시 선택" 같은 페이지 간 영속화 요구가 자연스럽게 풀립니다.

다른 후보를 배제한 이유도 명확합니다. Context API는 provider value가 바뀌면 모든 consumer가 리렌더되기 때문에 검색 필드 4~5개를 별도로 끊어서 다루기에는 적합하지 않습니다. 별도 provider를 5개 만들면 트리가 지저분해지고요. redux는 action·reducer·dispatcher 보일러플레이트가 본 과제 규모에 과합니다. 토스 가이드라인의 "화려한 방법보다 익숙한 방법"과도 충돌합니다. zustand는 좋은 후보였지만, selective subscription을 위해서 selector 함수와 equality 비교를 직접 신경 써야 하는 반면 jotai는 atom을 따로 만드는 것만으로 그게 자연스럽게 됩니다. 본 과제처럼 필드 4~5개를 작게 쪼개는 패턴엔 jotai가 더 잘 맞는다고 봤습니다.

react-query는 server state 표준이라 별 고민 없이 골랐습니다. 캐싱, 중복 요청 제거, mutation 후 invalidate, isPending/isError 같은 상태 관리를 직접 짜면 6시간이 다 갑니다.

atom을 필드별로 쪼갠 가장 큰 이유는 selective re-render입니다. 만약 searchConditionAtom이라는 큰 객체 atom 하나를 두고 그 안에 { departureStation, arrivalStation, tripType, ... }을 다 넣으면, 인원 한 번 바꾸는 것만으로도 객체 참조가 새로 생기니 그 atom을 구독하는 모든 컴포넌트가 다 리렌더됩니다. 출발역 ListRow가 인원 변경 때마다 리렌더되는 건 명백한 낭비고요.

필드별로 atom을 두면 passengerCountAtom을 구독한 CountField만 리렌더되고, 출발역을 구독한 StationSection은 그대로 있습니다. 이건 jotai의 atom 모델이 자연스럽게 만들어주는 효과라 별도 메모이제이션 코드 없이 무료로 따라옵니다.

다만 필드를 분리한다고 일관성을 잃으면 안 되는 케이스가 있습니다. 예를 들어 출발역과 도착역이 같으면 안 되고, 가는날을 변경해서 오는날이 그것보다 이전이 되면 안 되고, 가는날·편도왕복이 바뀌면 이미 선택한 티켓은 더 이상 의미가 없어서 reset돼야 합니다. 이런 종속성은 writable atom의 부수효과로 묶어서 처리했습니다 — setDepartureDateAtom은 가는날을 setting하면서 (1) 다른 날짜면 티켓 reset, (2) returnDate가 더 이전이면 undefined로 정리합니다. atom을 쪼갰지만 변경 흐름은 한 곳에 모인 셈입니다.

useMemo와 derived atom 둘 다 같은 결과를 낼 수 있는 자리지만, 이번 케이스는 atom으로 둔 게 더 자연스럽다고 봤습니다. 이유는 두 가지입니다.

첫째, 검증 규칙이 한 곳에 모이는 효과입니다. 출발역·도착역이 둘 다 있어야 하고, 둘이 같으면 안 되고, 가는날이 있어야 하고, 왕복이면 오는날도 있어야 하고, 인원이 0명이면 안 되고, 유아 동반 시 어른이 1명 이상이어야 한다 — 이 룰들이 isSearchValidAtom 한 군데에 모입니다. 룰이 늘어나면 atom만 고치면 되고 호출처는 그대로입니다. useMemo로 페이지 안에 박아두면 이 검증 코드가 여러 페이지에 흩어질 위험이 있는데, atom으로 두면 그런 분산이 원천 차단됩니다.

둘째, 재사용성입니다. 지금은 SearchPage의 "기차 보기" 버튼 비활성화에만 쓰이지만, TicketsPage나 ConfirmPage에서 직접 URL로 진입했을 때 검색 조건이 valid한지 검사해서 잘못된 진입을 막는 가드로도 자연스럽게 활용할 수 있습니다 — useAtomValue(isSearchValidAtom) 한 줄로요. useMemo였으면 그 페이지마다 같은 계산을 다시 짜야 합니다.

물론 비용도 있습니다. derived atom은 그 atom이 의존하는 atom들이 바뀔 때마다 재계산되니, 검색 조건이 자주 바뀌는 SearchPage에서 매 입력마다 7~8개 atom을 다 읽고 boolean 하나를 내놓습니다. 다만 이건 실측해도 무시할 수준의 계산량이고, jotai가 의존성 추적을 alquantitatively 잘 해주니 의도와 다른 재계산이 일어날 가능성은 거의 없습니다.

이건 PDF의 한 문장에서 출발한 결정이었습니다. ConfirmPage 명세에 "기차표를 제외하고, 사용자가 입력한 출발역, 도착역, 여행 방식, 인원수는 유지되어야 해요"라고 명시돼 있어서, 이걸 atom 구조에 직접 반영하기로 했습니다.

검색 조건(출발역·도착역·tripType·날짜·인원)은 사용자가 직접 만드는 상위 도메인이고, 선택한 티켓(가는편·오는편)은 그 검색 조건에 종속된 하위 도메인입니다. 두 도메인의 라이프사이클이 다르니 파일도 따로 둔 게 자연스럽습니다.

이 분리가 빛나는 곳이 두 군데 있습니다. 첫째, ConfirmPage의 "다시 선택하기" 버튼 — resetSelectedTicketsAtom만 호출하고 navigate(SEARCH) 하면 검색 조건은 그대로, 티켓만 비워진 상태로 SearchPage로 돌아갑니다. 이게 atom 한 줄로 끝납니다. 둘째, 가는날을 바꾸거나 편도/왕복을 바꿀 때 — setDepartureDateAtom과 setTripTypeAtom이 부수효과로 resetSelectedTicketsAtom을 호출합니다. 검색 조건이 바뀌면 이미 선택해둔 티켓은 더 이상 의미가 없으니까요. 이 부수효과를 위해서 searchConditionAtom이 ticketConditionAtom에서 export한 reset atom을 import하는 구조입니다.

만약 두 파일을 합쳤으면 같은 동작은 가능했겠지만, "다시 선택" 시 어떤 필드는 유지하고 어떤 건 reset할지 호출처에서 일일이 처리해야 했을 겁니다. 그러면 한 군데서만 빼먹어도 일관성이 깨집니다. 파일 분리 + reset atom 패턴이 그 위험을 구조적으로 막아줍니다.

React Query의 옵션은 두 군데에서 정했습니다. 글로벌 기본값(queryClient.ts)과 각 query 훅에서의 override.

글로벌 기본값에서 staleTime: 60s를 줬습니다. 본 과제의 데이터는 역 목록·티켓 목록·예약 정보인데, 이것들이 1분 안에 자주 바뀔 가능성이 낮습니다. staleTime을 0으로 두면 컴포넌트가 마운트될 때마다 백그라운드 refetch가 일어나 불필요한 요청이 늘어나니, 60초 정도면 합리적인 기본값이라고 봤습니다. retry: 1은 일시적 네트워크 오류에 한 번은 재시도하고 그 이상은 사용자에게 에러로 노출하는 균형점이고요. refetchOnWindowFocus: false는 본 과제가 모바일 흐름 중심이라 탭 포커스 변경이 거의 없고, BottomSheet가 열렸다 닫힐 때마다 윈도우 포커스 이벤트가 트리거될 수 있어서 끄는 쪽이 안전했습니다.

훅 레벨 override는 두 가지가 의미 있는데요.

첫째 useStationsQuery의 placeholderData: keepPreviousData. 사용자가 역명을 한 글자씩 입력할 때마다 디바운스된 keyword가 바뀌고 query key가 바뀝니다. 기본 동작이면 키 변경 시 데이터가 잠깐 undefined가 됐다가 새로 채워지는 깜빡임이 생기는데, keepPreviousData를 주면 이전 결과를 그대로 보여주면서 새 결과를 백그라운드에서 받아옵니다. 검색 UX의 표준 처리고요.

둘째 useTicketsQuery의 enabled: params !== null. 티켓을 검색하려면 출발역·도착역·날짜가 다 있어야 하는데, 그게 갖춰지기 전에 호출이 나가면 안 됩니다. enabled 플래그로 호출 자체를 막아두는 게 깔끔합니다. 같은 패턴이 useReservationQuery에도 들어 있습니다 — id가 null이면 호출 안 함.