그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Network
Network

stale-while-revalidate는 무엇이고 언제 적합한가요?

실무4/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

디렉티브 의미를 외우는 수준인지, 적용해도 되는 화면과 절대 안 되는 화면을 구분하는 판단까지 가는지를 가른다. SWR 구간 길이를 어떻게 정하느냐에서 깊이가 한 번 더 드러난다.

큐레이션 답변

학습 자료

stale-while-revalidate(SWR)는 Cache-Control 디렉티브로, max-age가 끝난 뒤 일정 기간 동안 오래된 응답을 그대로 클라이언트에 돌려주고 그 사이 백그라운드에서 재검증을 돈다. 사용자는 만료 직후에도 즉시 응답을 받고, 다음 요청부터 갱신된 데이터를 본다. 체감 지연을 깎는 대신 _한 박자 늦은 데이터_를 허용하는 거래라, 가격·재고처럼 즉시 정확성이 필요한 도메인엔 맞지 않는다.

좋은 답변 구조

  1. 01캐시 만료 직후 발생하는 미스 지연을 병목으로 짚는다
  2. 02max-age 이후 stale 응답을 즉시 돌리고 백그라운드 재검증으로 갱신하는 동작 흐름을 설명한다
  3. 03적용해도 되는 화면(피드·프로필)과 안 되는 화면(가격·재고)을 기준으로 답한다
  4. 04stale 구간 길이와 재검증 실패 시 노출 정책까지 트레이드오프로 짚는다

자주 실수하는 포인트

가격·재고처럼 실시간성이 핵심인 화면에도 같은 정책을 그대로 박는다
max-age와 SWR 구간의 합을 보지 않고 둘을 개별 옵션처럼 따로 잡는다
백그라운드 재검증이 실패했을 때 stale 응답이 얼마나 더 노출되는지 따지지 않는다
측정 없이 SWR을 켜고 효과를 체감만으로 판단한다

실무 맥락

  • 사용자가 자주 새로고침하는 피드·목록 화면에서 첫 응답 지연을 깎아야 하는 환경
  • 데이터가 분 단위로만 갱신되는 대시보드를 캐시로 받쳐 백엔드 부하를 줄여야 하는 환경
  • CDN과 브라우저 캐시 TTL을 함께 맞춰 응답 정책을 일관되게 가져가야 하는 환경

본인 경험에 녹이는 힌트

목록 화면 첫 로딩이 느리다는 피드백을 캐시 정책 변경으로 해결한 경험과 연결할 수 있다

같은 API라도 화면별로 캐시 정책을 다르게 가져갔던 결정 과정을 설명할 수 있다

DevTools 네트워크 탭이나 응답 헤더를 직접 까서 캐시 동작을 검증한 경험을 엮을 수 있다

CDN과 브라우저 캐시 TTL을 맞추다 부딪힌 충돌을 풀어본 경험이 있다면 이 질문과 연결된다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1stale-if-error와 함께 쓰면 무엇이 달라지나요
Q2SWR 구간 길이는 어떤 기준으로 정하나요
Q3브라우저 캐시와 CDN 캐시 정책이 충돌할 때 어떻게 조정하나요
Q4must-revalidate나 no-cache와 SWR은 어떻게 함께 쓸 수 있나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문