Cloudflare Vary 캐시: normalize·passthrough·bypass 선택 기준

Cloudflare Vary 캐시 규칙은 응답 의미를 안전하게 묶을 수 있으면 normalize, 원시 헤더 값의 작은 차이까지 실제 응답을 바꾸면 passthrough, 값의 범위가 예측하기 어렵거나 잘못 캐시했을 때 위험이 크면 bypass를 고르는 것이 핵심입니다. Cloudflare의 현재 action 이름은 exact가 아니라 passthrough이며, 원시 값을 그대로 구분하는 동작을 뜻합니다. 세 모드 중 하나를 먼저 찍는 대신, 원본의 Vary 헤더와 대표 요청 조합의 응답 차이를 확인한 뒤 캐시 키의 정확성과 재사용성을 함께 판단해야 합니다.

확인된 사실: Cloudflare는 2026년 9월 22일 Vary 지원을 모든 요금제의 Cache Rules에 제공한다고 발표했습니다. 공식 문서는 Vary를 같은 URL의 응답이 요청 헤더에 따라 달라질 수 있음을 CDN에 알리는 응답 헤더로 설명합니다. RFC 9111도 저장된 응답의 Vary에 지정된 필드 값과 새 요청의 값을 대조해 사용할 응답을 고르도록 규정합니다.

POEMORA의 해석: 기능을 켰다는 사실은 안전한 캐시 설계의 완료 증거가 아닙니다. 응답이 실제로 달라지는 헤더만 분기하고, 분기 수를 줄여도 의미가 보존되는지 확인해야 오배달과 캐시 조각화를 동시에 줄일 수 있습니다. 이 글은 특정 Cloudflare zone을 직접 검증한 결과가 아니라, 승인된 공식 근거를 운영 선택표로 바꾼 가이드입니다.

비교 기준: 응답 차이와 변형 수를 먼저 본다

세 선택지를 같은 기준으로 비교하려면 헤더 이름보다 아래 네 가지를 먼저 기록합니다.

1. 응답 차이: 대표 헤더 값을 바꿨을 때 상태 코드, Content-Type, Content-Language, 본문 바이트가 실제로 달라지는가?
2. 의미의 묶음: 서로 다른 원시 값 여러 개를 같은 언어·포맷·기기 범주로 정규화해도 사용자가 받아야 할 표현이 유지되는가?
3. 변형의 경계: 허용 값이 작고 관리 가능한가, 아니면 사용자·실험·세션마다 값이 계속 늘어날 수 있는가?
4. 실패 영향: 잘못된 변형이 전달됐을 때 단순 품질 저하에 그치는가, 아니면 민감하거나 권한별인 응답이 섞일 수 있는가?

직접 확인할 항목: 원본 응답에 기대한 Vary가 실제로 있는지 먼저 봅니다. Cloudflare 공식 문서에 따르면 Cache Rule만 구성했다고 모든 응답이 자동으로 분기되는 것은 아니며, 원본 응답의 Vary와 그 안에 나열된 헤더별 action이 함께 캐시 키에 반영됩니다.

세 방식의 장단점: normalize, passthrough, bypass

normalize — 의미는 같고 표기만 다양한 경우

Accept-Language나 Accept처럼 표준 협상 헤더는 원시 문자열 조합이 많아도 실제 서비스가 제공하는 결과는 몇 개 범주로 줄어들 수 있습니다. Cloudflare 발표는 알려진 협상 헤더를 normalize하는 방향을 제시합니다.

• 장점: 의미가 같은 요청을 한 변형으로 모아 캐시 재사용성을 높일 수 있습니다.
• 단점: 정규화 규칙이 원본의 실제 협상 로직보다 거칠면 다른 응답이 같은 키에 들어갈 수 있습니다.
• 선택 조건: 지원 언어·포맷 목록이 명시돼 있고, 정규화 전후 대표 요청의 응답 바이트가 같은 범주에서 일치할 때 적합합니다.

passthrough — 값 하나하나가 결과를 바꾸는 경우

헤더 값의 작은 차이가 실제 응답 내용이나 형식을 바꾼다면 원시 값을 그대로 구분해야 합니다. Cloudflare는 이런 차이가 중요할 때 passthrough로 전달하는 방향을 설명합니다.

• 장점: 서로 다른 요청 값을 별도 변형으로 보존하므로 오배달 위험을 줄일 수 있습니다.
• 단점: 값의 조합이 많아질수록 캐시 항목이 조각나고 재사용 기회가 줄 수 있습니다.
• 선택 조건: 값의 집합이 제한돼 있고, 각 값에 대응하는 응답 차이가 테스트로 확인되며, 그 차이를 합칠 수 없을 때 적합합니다.

bypass — 변형을 안전하게 열거할 수 없는 경우

값이 예측 불가능하거나 민감한 변형을 캐시 키로 안전하게 모델링하기 어렵다면 캐시하지 않는 쪽이 낫습니다. Cloudflare 발표는 이런 경우 cache bypass를 선택하는 방향을 제시하며, 공식 문서는 Vary: * 응답이 설정과 관계없이 항상 캐시를 우회한다고 설명합니다.

• 장점: 잘못된 변형을 재사용하는 위험을 피합니다.
• 단점: 캐시 적중의 성능·원본 부하 이점을 포기합니다.
• 선택 조건: 사용자별·권한별 결과처럼 값의 경계를 통제할 수 없거나, 대표 조합만으로 안전성을 입증하기 어려울 때 적합합니다.

적합 대상: 헤더별 선택표

이 표는 “항상 normalize가 빠르다”거나 “passthrough가 가장 정확하다”는 순위를 만들지 않습니다. 독자 조건이 달라지면 추천도 달라집니다. 안전하게 묶을 근거가 있으면 normalize, 차이를 보존할 이유가 있으면 passthrough, 두 조건을 검증할 수 없으면 bypass가 맞습니다.

선택 순서: 원본 Vary부터 배포 후 read-back까지

1. 원본 응답을 캡처합니다. 캐시를 거치지 않은 대표 요청에서 Vary, 콘텐츠 유형·언어, 상태 코드와 본문 해시를 기록합니다.
2. 헤더별 변형 수를 셉니다. 실제 서비스가 내는 언어·포맷·응답 종류와 관측되는 원시 헤더 값의 수를 분리합니다.
3. 정규화 가능성을 시험합니다. 여러 원시 값이 같은 의미의 응답으로 모이면 normalize 후보로 두고, 하나라도 응답이 달라지면 passthrough 후보로 되돌립니다.
4. 안전한 열거 가능성을 봅니다. passthrough 후보의 허용 값이 작고 고정됐는지 확인합니다. 값의 경계가 없거나 민감한 분기라면 bypass로 둡니다.
5. 작은 범위에 규칙을 적용합니다. 전체 경로를 한 번에 바꾸지 말고 대표 URL과 헤더 조합으로 먼저 확인합니다.
6. 두 번째 요청까지 read-back합니다. 각 조합의 응답 바이트와 핵심 헤더가 기대한 변형인지 확인하고, Age와 CF-Cache-Status를 함께 기록해 재사용 여부를 봅니다.

예시: 한국어·영어 두 페이지만 제공하면서 다양한 Accept-Language 문자열을 두 언어로 안정적으로 매핑할 수 있다면 normalize 후보입니다. 반대로 API 버전 헤더의 값마다 JSON 스키마가 달라지고 허용 버전이 제한돼 있다면 passthrough 후보입니다. 사용자별 권한이나 예측할 수 없는 실험 값이 응답을 바꾼다면 bypass에서 시작하는 편이 안전합니다. 이는 선택 방법을 설명하기 위한 예시이며 특정 서비스의 검증 결과가 아닙니다.

실패 조건과 한계: 켰다는 사실만으로는 부족하다

다음 중 하나라도 남으면 완료로 보지 않습니다.

• 원본 응답에 기대한 Vary가 없거나 프록시 구간에서 사라집니다.
• normalize 범주 안에서 상태 코드, 콘텐츠 유형·언어 또는 본문 바이트가 달라집니다.
• passthrough에 넣은 값의 종류가 계속 늘어 캐시 항목 수를 통제할 수 없습니다.
• bypass가 필요한 민감한 변형을 성능 때문에 캐시하려 하지만 안전한 분리 근거가 없습니다.
• 한 번의 요청만 보고 성공이라 판단해, 재사용된 두 번째 요청의 응답과 캐시 상태를 확인하지 않았습니다.

RFC 9111의 선택 규칙은 Vary 필드 값이 맞는 저장 응답을 고르는 기준을 제공합니다. 그러나 어떤 헤더를 정규화할지, 값 집합이 운영상 감당 가능한지, 우회로 인한 원본 부하를 수용할지는 서비스가 직접 측정해야 합니다. Cloudflare 기능 지원 여부만으로 이 판단을 대신할 수 없습니다.

최종 선택: 의미를 묶고, 중요한 차이는 남기고, 모르면 우회한다

최종 기준은 단순합니다. 같은 응답 의미를 증명할 수 있으면 normalize, 다른 응답 의미를 보존해야 하면 passthrough, 둘 중 어느 쪽도 안전하게 증명할 수 없으면 bypass를 선택합니다. 그 뒤 대표 요청 조합마다 응답 바이트와 Age·CF-Cache-Status를 read-back해 오배달과 캐시 재사용을 함께 확인합니다.

현재 웹사이트가 다국어·이미지 포맷·HTML/JSON 변형을 같은 URL에서 제공하지만 캐시 키가 불명확하다면, 헤더별 선택표를 채운 뒤 웹사이트 구축·성능 운영 점검으로 다음 조치를 연결할 수 있습니다.