언어와 로그인 상태에 따라 응답이 다른데 CDN에서 다른 사용자의 화면이 보입니다. 캐시 키와 Vary는 어떻게 확인하나요?

캐시가 응답을 구분하는 키에 표현을 바꾸는 조건이 포함되어야 합니다. Vary는 요청 헤더에 따른 표현 선택을 캐시에 알리지만 개인정보를 캐시해도 된다는 허가나 사용자 인가를 제공하지 않습니다.

동작 원리와 전제

언어별 응답에 Accept-Language가 영향을 주는데 키에 반영되지 않으면 다른 언어가 반환될 수 있습니다. 로그인별 응답은 일반적으로 private·no-store 등 정책과 CDN 설정을 검토합니다. Vary: Cookie를 무작정 쓰면 키 수가 폭증하거나 잘못된 쿠키 처리로 누출될 수 있습니다.

선택과 실패 처리

Authorization·쿠키·query·host·압축 협상이 실제 CDN 키에서 어떻게 처리되는지 확인합니다. 응답의 Cache-Control만이 아니라 경계의 강제 캐시 규칙도 봅니다. 사용자별 데이터를 공통 HTML에 넣고 브라우저에서 숨기는 것은 이미 노출된 정보입니다.

구체적인 사례와 검증

캐시를 검증할 때 사용자 A의 요청으로 먼저 hit 가능한 값을 만든 뒤 B가 같은 URL을 요청하는 순서를 반드시 넣습니다. 각각 cold 상태에서만 테스트하면 공유 키 충돌을 놓칩니다. 언어·압축·인증 헤더를 바꾸고 response header와 실제 본문을 대조합니다. Vary를 너무 넓게 주면 hit ratio가 줄 수 있지만 이를 줄이기 위해 개인정보 구분을 생략할 수는 없습니다. 공개 shell과 사용자별 API를 분리하는 설계도 검토합니다. CDN purge가 모든 edge와 브라우저 캐시를 동시에 지우는지 가정하지 않고 민감 데이터의 저장 자체를 제한하는 편이 필요한 경우가 있습니다.

서로 다른 사용자·언어·압축·쿠키 조합을 순서대로 요청해 hit·miss와 응답을 검사합니다. 304 경로도 인증·인가가 먼저 적용되는지 확인합니다. 캐시 적중률 개선은 보안·정확성 조건을 유지한 상태에서 평가하겠습니다.