이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
둘을 저는 언제 새로 받느냐 대 언제 버리느냐로 가릅니다. staleTime은 받아 둔 데이터를 얼마 동안 신선하다고 믿고 다시 안 받을지이고, gcTime은 아무도 안 쓰는 데이터를 메모리에서 얼마 뒤 치울지입니다. 즉 하나는 재요청 시점, 하나는 메모리 정리 시점이라 보는 게 다릅니다. 설정은 데이터 성격에 맞춥니다.
자주 안 바뀌는 목록은 staleTime을 길게 줘 불필요한 재요청을 줄이고, 실시간성이 중요한 값은 짧게 줘 항상 최신을 보게 합니다. gcTime은 화면을 들락거릴 때 매번 다시 안 받게 staleTime보다 여유 있게 둡니다. 학부 프로젝트에서 staleTime을 0으로 둬 화면 이동마다 깜빡이며 다시 받던 문제를 겪고 이 기준을 세웠습니다. 다만 길게 잡으면 옛 데이터가 보이는 대가가 있어, 신선도가 중요한 데이터엔 짧게 둡니다.
저는 이 설정을 문제를 겪고 나서 기준을 잡았습니다. 처음엔 기본값을 그대로 뒀는데, 화면을 옮길 때마다 같은 데이터를 다시 받아 깜빡이고 요청이 잦았습니다. 원인은 staleTime이 0이라, 받자마자 바로 낡은 것으로 보고 다시 요청하던 것이었습니다. 그 데이터는 몇 분간 안 바뀌어도 되는 것이라, staleTime을 그 주기만큼 줘 재요청이 확 줄었습니다. 반대로 알림 개수처럼 자주 바뀌는 값은 0에 가깝게 둬 항상 최신을 보게 했습니다. gcTime은 잠깐 다른 화면 갔다 와도 다시 안 받게 staleTime보다 길게 뒀습니다. 다만 staleTime을 너무 길게 준 값에서 바뀐 게 한동안 안 보이는 문제가 나, 신선도가 중요한 건 다시 짧게 조정했습니다. 그래서 제 기준은 이 데이터가 옛것이어도 되는 시간만큼 staleTime입니다.
저는 캐시 전략을 데이터를 성격으로 나누는 데서 시작합니다. 크게 셋으로 봅니다. 거의 안 바뀌는 것(설정·코드표), 가끔 바뀌는 것(목록·프로필), 수시로 바뀌는 것(알림·실시간 수치). 첫째는 staleTime을 아주 길게 줘 사실상 다시 안 받고, 둘째는 수 분 단위로 줘 적당히 갱신하며, 셋째는 0에 가깝게 둬 항상 최신을 봅니다. gcTime은 따로 보는데, 화면을 자주 들락거리는 데이터는 길게 줘 그 사이 재요청을 막습니다. 핵심은 staleTime은 신선도, gcTime은 메모리 체류라 따로 정한다는 점입니다. 학부 때 둘을 같은 값으로 묶어 두고 왜 의도대로 안 되는지 헤맨 경험이 있어 이 분류를 세웠습니다. 다만 길게 잡을수록 낡은 데이터·메모리 점유 대가가 커, 성격이 애매하면 짧은 쪽으로 둡니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.