개인정보가 포함된 HTTP 응답을 캐시하면서 최신 여부도 확인하려면 Cache-Control, ETag, 304를 어떻게 조합하나요?

HTTP 캐시는 저장할 수 있는지, 저장된 표현을 검증 없이 재사용할 수 있는지, 공유 캐시가 다른 사용자의 응답으로 재사용할 수 있는지를 나눠 정해야 합니다. 개인정보 응답이라면 기본값은 Cache-Control: private이고, 브라우저에도 남기면 안 되는 민감한 응답은 no-store를 선택하겠습니다. 단, private만으로 같은 브라우저에서 계정을 전환한 뒤 이전 계정의 화면이 보이지 않는다고 보장할 수 없습니다. 사용자 인증·인가와 캐시 재사용 조건을 함께 검증해야 합니다.

인증·인가를 먼저 확인한다

캐시된 인증 응답을 재사용하기 전에 현재 요청의 세션·토큰이 유효한지, 요청한 리소스에 대한 인가가 있는지 확인해야 합니다. 캐시가 사용자별 표현을 제공할 수 있는 구조라면 캐시 키가 사용자·권한 경계를 빠뜨리지 않아야 하며, 가장 민감한 응답은 애초에 no-store로 저장을 막겠습니다. private는 공유 캐시 저장을 제한할 뿐 브라우저 개인 캐시를 지우거나 계정 전환을 감지하지 않습니다. 따라서 로그아웃·계정 전환·권한 변경 뒤 뒤로 가기, 서비스 워커, 브라우저 캐시가 이전 응답을 제공하는지 별도로 시험합니다. 이를 인증 경계와 캐시 경계의 분리라고 부르겠습니다.

지시자와 조건부 검증

max-age=60은 캐시가 60초 동안 신선하다고 판단할 수 있다는 뜻입니다. no-cache는 저장 금지가 아니라 재사용 전에 원본 검증을 요구하며, no-store는 요청·응답을 저장하지 말라는 지시입니다. 공개 데이터라도 최신성이 필요하면 no-cache와 ETag를 조합할 수 있고, 개인정보는 최신 검증을 하더라도 인증·인가 검사가 먼저입니다.

캐시가 가진 ETag를 If-None-Match로 보내고 현재 표현의 태그와 같으면 서버는 본문 없이 304 Not Modified를 반환할 수 있습니다. 캐시는 검증된 같은 표현의 본문을 재사용하면서 304의 허용된 헤더를 갱신합니다. 태그가 다르면 200과 새 본문을 보내야 합니다. 강한 ETag는 바이트 표현 동일성, 약한 ETag는 의미상 동일성에 가까운 검증에 쓰므로 요구에 맞춥니다. ETag에 이메일이나 계정 ID를 직접 넣지 않고 불투명한 값을 사용하겠습니다.

공유 캐시와 실제 검증

사용자·권한에 따라 응답이 달라지면 공유 캐시를 허용하지 않는 것을 기본으로 하겠습니다. 공유를 의도적으로 허용하는 특수 설계에서는 인증 응답의 캐시 허용 조건과 주체별 키·인가를 먼저 보장하고 Vary로 표현 선택에 쓰는 요청 헤더도 지정해야 합니다. Vary 자체는 인가 장치가 아닙니다. 그렇다고 Vary: Cookie를 무작정 넣으면 캐시 키와 메모리 비용이 커질 수 있습니다. HTTPS는 전송 중 도청을 줄이지만 저장·재사용 정책을 대신하지 않습니다. 304가 돌아와도 현재 인증·인가를 통과한 요청에 대한 검증 결과인지 확인하며, 오래된 개인 응답을 단지 원본에 접근할 수 없다는 이유로 재사용하지 않겠습니다. 공개 데이터는 긴 freshness와 ETag로 본문을 줄이고, 즉시 최신성이 필요한 데이터는 짧은 수명·재검증·must-revalidate 같은 계약을 요구에 맞춰 선택합니다.

추가 조건과 판단

예를 들어 같은 브라우저에서 사용자 A가 로그아웃하고 B가 로그인했는데 프로필 URL은 같다고 하겠습니다. private이고 fresh인 응답은 서버에 재검증하러 가지 않을 수 있으므로 B의 로그인만으로 A의 캐시가 지워지지는 않습니다. 민감 응답에는 no-store를 사용하고 애플리케이션 메모리·서비스 워커 캐시와 화면 상태도 전환 시 정리해야 합니다. no-store도 이미 저장된 과거 사본이나 화면 캡처를 삭제해 주는 명령은 아닙니다. 서버로 온 조건부 요청은 인증·인가를 먼저 수행하고 그 사용자의 표현을 선택한 뒤 ETag를 비교해야 다른 사용자의 태그가 304 판단을 우회하지 않습니다.