API 통합 — `tosslib` http + `isHttpError` + React Query 키 전략

Q6-1-a. isHttpError를 안 쓴 게 마이너스 평가는 아닐까요? → 그래서 README에 명시적으로 to-do로 남겨두고 인터뷰에서도 회피하지 않고 답하기로 했어요. 토스 가이드의 "사용자 경험 개선 지점은 README 등에 문서화" 원칙과도 맞고, 6시간 안에 골격(편도/왕복, 다시 선택 영속화, 검증) 안정성에 우선 시간을 썼다는 우선순위 결정이 더 중요하다고 봤습니다. 못 했다고 회피보다 "왜 우선순위에서 뺐는지" 설명이 더 신뢰감 있다고 생각해요.

Q6-1-b. mutation onError에서 isHttpError로 분기하면 구체적으로 어떤 코드가 되나요? → 대략 이런 형태입니다:

useMutation({
  mutationFn: postReservationApi,
  onError: (error) => {
    if (isHttpError(error)) {
      if (error.status === 409) toast('이미 예약된 좌석입니다');
      else if (error.status >= 500) toast('잠시 후 다시 시도해주세요');
      else toast(error.message);
    } else {
      toast('네트워크 오류가 발생했어요');
    }
  },
});

type guard로 분기해야 status code 기반의 친절한 메시지가 가능해집니다.

Q6-1-c. http.get의 searchParams에 undefined를 그대로 넘기는 패턴은 안전한가요? → useStationsQuery에서 searchParams: params?.keyword ? { keyword: params.keyword } : undefined로 처리한 부분 말씀이시죠. tosslib의 http는 ky 기반이라 searchParams가 undefined면 query string을 붙이지 않습니다. 빈 문자열을 넘기면 ?keyword=가 그대로 붙어서 서버가 빈 키워드로 검색하는 사고가 날 수 있어요. 그래서 keyword가 falsy일 때는 명시적으로 undefined를 넘겨 query string 자체를 빼는 패턴을 썼습니다.

Q6-2-a. invalidate가 일어나는 케이스가 있나요? 예약 후에 reservations를 invalidate해야 하는 상황 같은 건요? → 이번 과제는 그런 상황이 자연스럽게 안 생겼어요. 예약 mutation 성공 후 곧바로 /complete/:id로 navigate하기 때문에 CompletePage가 새로 마운트되면서 useReservationQuery(id)로 fetch가 일어나거든요. 같은 id의 reservation이 또 변할 가능성이 없으니 invalidate가 불필요합니다. 만약 "예약 목록" 화면이 추가되면 그때는 mutation onSuccess에서 queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.RESERVATIONS] })를 호출하는 게 표준이에요.

Q6-2-b. params를 객체 그대로 두 번째 요소로 두면 객체 참조가 매번 바뀌어서 캐시 미스가 나지 않나요? → react-query는 queryKey를 deep equal로 비교합니다 — 이게 핵심이에요. 참조가 달라도 안의 값이 같으면 같은 키로 인식해서 동일 캐시 슬롯을 씁니다. useStationsQuery({ keyword: '서울' })을 매 렌더에 새 객체로 호출해도 캐시 미스가 안 나는 이유입니다. 다만 객체 안에 함수나 클래스 인스턴스 같은 비직렬화 값이 들어가면 안 됩니다.

Q6-2-c. QUERY_KEYS.STATIONS가 단순 string인데, TypeScript 타입으로 더 강하게 만들 수 있지 않나요? → 가능합니다. as const + literal union으로 좁히거나, enum 또는 query factory로 가면 더 강해져요. 다만 string 상수로도 오타를 막는 1차 효과는 충분하고, 객체 자체를 한 곳에서만 import해서 쓰니까 사용처에서 키를 잘못 쓸 위험이 매우 낮았어요. 6시간 안에서는 이 정도가 적정선이라고 봤습니다.

Q6-3-a. staleTime이 1분이면 한 번 받은 응답이 너무 오래 살아남지 않나요? → 살아남는 게 정확히 의도예요. staleTime은 "이 시간 안에는 다시 fetch하지 않는다"는 의미고, 그 시간이 지나면 마운트 시 자동으로 fresh fetch가 일어납니다. SaaS처럼 실시간성이 중요하면 더 짧게 잡아야 하지만, 이번 과제 같이 한 번의 검색 흐름이 1~2분 안에 끝나는 시나리오에서는 1분이면 사용자가 같은 흐름을 한 번 오갔을 때 캐시가 살아있는 정도라 적정합니다.

Q6-3-b. retry: 1로 줄이면 일시적 네트워크 끊김에 약해지지 않나요? → 단발 끊김에는 1번이면 충분하고, 연속적 끊김이면 사용자가 직접 재시도하는 게 나아요. 자동 재시도가 누적되면 사용자는 "왜 응답이 안 올까" 답답해하는데, 명시적 에러로 빠르게 끝나면 "다시 시도하기" 같은 행동을 사용자가 직접 결정할 수 있습니다. 다만 retry 함수에 (failureCount, error) => isHttpError(error) && error.status >= 500 ? failureCount < 1 : false 같은 분기를 넣어서 "5xx만 한 번 재시도"로 정교하게 만들 수도 있어요. 6시간 안에서는 default 1로 두고 README에 to-do로 남겼습니다.

Q6-3-c. queries default와 mutations default가 다른데, mutations에는 retry를 안 주신 이유는요? → mutation은 side effect가 있는 요청이라 자동 재시도가 위험합니다. 예약 mutation을 자동으로 재시도하면 같은 예약이 두 번 만들어질 수 있어요. react-query default도 mutation은 retry 0이라 그대로 뒀습니다. 만약 idempotent한 mutation이라면 retry를 켤 수 있지만, 예약 같은 non-idempotent operation은 명시적으로 사용자가 "다시 시도하기"를 누르도록 두는 게 안전합니다.

Q6-4-a. keepPreviousData를 쓰면 직전 쿼리의 stale 상태와 새 쿼리의 fresh 상태를 구분해야 할 것 같은데, 그건 어떻게 처리하나요? → react-query v5에서 keepPreviousData를 쓰면 data는 직전 결과를 유지하면서 isPlaceholderData: true 또는 isFetching: true로 "지금 fetch 중"임을 알려줍니다. UI에서는 "부드럽게 직전 데이터를 보여주되 약하게 로딩 인디케이터(반투명 등)로 시각적 시그널"을 줄 수 있어요. 이번 과제에서는 simple하게 직전 데이터만 보여주는 정도로 마무리했습니다 — 검색 응답이 빠른 환경 가정 하에서요.

Q6-4-b. enabled: params !== null로 막아두면 처음 진입 시 isLoading이 어떻게 되나요? → enabled가 false인 동안 query는 'pending' 상태긴 하지만 fetch는 일어나지 않아요. isLoading은 enabled가 true가 되는 순간부터 의미를 가집니다. 그래서 "params가 null인 동안은 빈 리스트 또는 안내 UI를 보여주고, params가 set되면 그제야 isLoading 처리"라는 분기가 필요합니다. TicketList에서는 isReturnPhase에 따라 params를 조립해서 한 번 set되면 fetch가 자동으로 시작되도록 풀었어요.

Q6-4-c. useTicketsQuery의 queryFn에서 params!로 non-null assertion을 쓴 게 좀 거슬리는데요, 더 깔끔한 방법은 없을까요? → 맞아요, 거슬리는 부분이긴 합니다. enabled가 true일 때만 queryFn이 호출된다는 react-query의 invariant를 신뢰해서 !를 쓴 건데, 더 안전하게 가려면 useTicketsQuery(params) 자체의 시그니처를 (params: GetTicketApiParams)로 두고 호출자가 enabled 옵션을 직접 결정하게 분리하는 방식도 가능해요. 그러면 하나의 hook이 "params 받아서 fetch만" 책임지고, 호출 가능 시점은 호출자가 결정하는 분리가 됩니다. 6시간 안에서는 hook 안에 enabled까지 캡슐화한 게 호출자 입장에서 더 단순해서 그쪽으로 갔어요. trade-off가 있는 부분입니다.

Q6-5-a. CompletePage가 새로고침되면 reservation 캐시가 사라져서 다시 fetch가 일어날 텐데, 그건 사용자에게 보이나요? → 새로고침 시 query는 다시 isLoading 상태로 시작합니다. 다만 staleTime이 지나기 전이고 캐시가 살아있다면 즉시 cache hit이라 인지 가능한 로딩이 없어요. SPA 안에서 navigate로 이동했다면 캐시가 살아있지만, 새로고침은 메모리 리셋이라 fetch가 다시 일어납니다. 그래서 CompletePage에는 isLoading 시 스켈레톤이나 안내 UI가 필요한데, 이번 과제에서는 react-query의 isLoading boolean으로 분기하는 정도로 처리했습니다.

Q6-5-b. mutation 응답을 setQueryData로 미리 채우는 게 ROI가 어느 정도일까요? → 이 흐름에서는 ROI가 낮습니다. 사용자는 mutation 성공 → navigate 한 번을 거치는데, navigate가 인스턴트라 fetch가 즉시 시작돼요. fetch가 200ms 걸린다고 하면 그 동안 isLoading 스켈레톤이 보이는데, 이걸 setQueryData로 없애면 200ms 깜빡임이 사라집니다. 페이지 진입 즉시 데이터를 보고 싶은 critical path라면 의미가 있지만, 예약 완료 화면처럼 "끝났음"을 알리는 화면은 200ms 정도의 로딩이 오히려 자연스러울 수 있어요. UX 우선순위에 따라 달라집니다.

Q6-5-c. mutation 자체에 retry나 onError 핸들링이 더 들어가야 하지 않나요? → 네, 그게 README to-do의 미구현 영역입니다. 이상적으로는 mutation에 (1) onError에서 isHttpError로 분기해 토스트, (2) retry: false 명시(default가 false긴 하지만), (3) optimistic UI 같은 것까지 들어가는데, 6시간 안에서는 골격을 우선해서 mutate(body, { onSuccess }) 단순 흐름에서 멈췄어요. 인터뷰에서 솔직히 인정하고 우선순위 결정 근거를 답변할 준비가 돼 있습니다.