하나의 주소에 접속해도 브라우저와 API 프로그램이 반드시 같은 콘텐츠를 받는 것은 아니다. 서버는 요청 헤더에 따라 HTML 문서와 JSON 데이터를 각각 반환할 수 있다. 이 차이를 구분하지 못하는 캐시는 다른 요청을 위해 만들어진 응답을 재사용할 수 있다.

01 / THE PROBLEM같은 URL에서 서로 다른 응답이 나오는 이유

웹 서버는 요청에 포함된 선호 형식과 언어를 참고해 같은 URL에서도 다른 형태의 콘텐츠를 제공할 수 있다. 이를 콘텐츠 협상(Content Negotiation)이라고 한다. Cloudflare는 공식 발표에서 하나의 /catalog 경로가 브라우저에는 HTML을, API 클라이언트에는 JSON을 반환하는 예시를 제시했다.

응답을 URL만으로 구분하면 먼저 저장된 HTML이 JSON을 기대하는 요청에 전달되거나 그 반대 상황이 발생할 수 있다. 반면 요청 헤더의 사소한 차이를 전부 별도 항목으로 저장하면 실질적으로 같은 콘텐츠가 여러 캐시 항목으로 나뉜다. 전자는 응답 정확성의 문제이고, 후자는 캐시 재사용 효율의 문제다.

HTTP 표준의 Vary 응답 헤더는 원본 서버가 어떤 요청 필드에 따라 응답을 달리할 수 있는지 캐시에 알리는 역할을 한다. 다만 Vary 자체가 서로 다른 헤더 값 중 어떤 값이 실질적으로 같은 콘텐츠를 요구하는지까지 설명하지는 않는다.

02 / THE RELEASECloudflare의 지원 확대: 출시와 상세 발표는 다른 시점

Cloudflare의 공식 변경 이력에는 Vary를 이용해 같은 URL의 여러 응답을 캐시하는 기능이 7월 2일 공개된 것으로 기록돼 있다. 이후 9월 22일에는 공식 기술 블로그에서 설계 배경, 헤더별 처리 방식, 캐시 조회 과정과 설정 사례를 상세히 설명했다. 따라서 9월의 기술 발표를 기능의 최초 출시로 해석해서는 안 된다.

기존에도 Cloudflare 이용자는 캐시를 우회하거나 사용자 정의 캐시 키(Custom Cache Key), Workers, 이미지 형식별 캐시 기능 등을 사용해 일부 응답 차이를 처리할 수 있었다. 이번 기능은 원본 서버가 응답에서 지정한 Vary 필드를 기준으로 Cache Rules가 헤더별 처리 방식을 결정한다는 점에서 구분된다. 사용자 정의 캐시 키는 설정한 요청 속성을 규칙 적용 대상에 공통으로 반영하지만, Vary는 서버의 응답 선언을 반영한다.

03 / THREE ACTIONS정규화·원본 값 비교·캐시 우회

Cloudflare는 원본 서버가 Vary에 명시한 요청 헤더마다 세 가지 동작 중 하나를 지정할 수 있도록 했다. 개별 설정이 없는 헤더에는 해당 규칙의 기본 동작이 적용된다.

정규화는 Accept, Accept-Language, Accept-Encoding에 각각의 규칙을 적용한다. 일반 헤더에는 중복된 헤더 줄을 결합하거나 바깥쪽의 선택적 공백을 정리하는 등 제한적인 처리만 적용한다. 원본 값 비교는 값의 미세한 차이까지 보존한다. 캐시 우회는 해당 응답의 저장을 건너뛰지만 이미 저장된 항목을 자동 삭제하지는 않는다.

04 / NORMALIZATION서로 다른 언어 요청이 같은 응답을 요구할 때

Cloudflare가 제시한 사례에서 원본 서버는 영어·프랑스어·독일어를 제공한다. 두 요청의 Accept-Language 값은 다르지만 모두 영어를 우선한다. 원본 값을 그대로 비교하면 별도의 캐시 항목이 되지만, 허용 언어 목록에 따라 정규화하면 동일한 결과로 묶을 수 있다.

Cloudflare는 정규화한 Accept와 Accept-Language 값을 캐시 선택에 사용할 뿐 아니라 원본 서버에도 전달할 수 있다. 서로 다른 원본 요청을 하나의 캐시 항목으로 묶으면서 서버가 다른 응답을 생성하는 상황을 줄이기 위한 처리다. Accept-Encoding의 원본 서버 전달 방식은 Respect Strong ETags 설정에 따라 달라진다.

정규화 과정에서는 지역별 언어 태그가 기본 언어로 축약되거나 일부 매개변수가 제거될 수 있다. Cloudflare 기술문서는 허용하지 않는 값을 뜻하는 q=0을 구분하도록 설명하지만, 지역 태그 축약이나 허용 목록 필터링 과정에서는 해당 의미가 손실될 수 있다고 주의한다. 원본 서버가 이런 차이를 실제 응답에 반영한다면 정규화와 원본 값 비교의 결과도 달라진다.

05 / AVAILABILITY & LIMITS적용 범위와 확인된 기술적 제약

이 기능은 Cloudflare의 Free·Pro·Business·Enterprise 요금제에서 제공된다. 대시보드의 Caching → Cache Rules와 Rulesets API, Terraform으로 설정할 수 있다. 다만 Vary 설정만 추가한다고 모든 응답이 캐시 대상이 되는 것은 아니다. 캐시 적격성, 캐시 제어 헤더와 다른 규칙도 함께 적용된다.

출처: Cloudflare Cache Rules 설정 문서. 실제 트래픽 성능 측정치가 아닌 구성 제한 수치다.

Cloudflare는 일반적인 구성에서 예상하지 못한 헤더가 캐시되지 않도록 기본 동작을 bypass로 두고, 원본 서버가 사용하는 헤더를 명시적으로 설정하는 방식을 문서에 안내한다. 이는 모든 헤더를 일괄 정규화하는 것과는 구별되는 설정 예시다.

HTTP / RESPONSE HEADER EXAMPLEHTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: public, max-age=3600
Vary: Accept

위 헤더는 같은 URL의 응답이 Accept 요청 헤더에 따라 달라질 수 있다는 사실과 캐시 유효기간을 함께 표현한 예시다. 실제 캐시 저장 여부는 Cloudflare의 캐시 적격성 및 적용 규칙에 따라 달라진다.

06 / THE CHANGE IN CONTEXT이번 업데이트가 바꾼 것

이번 기능은 새로운 HTTP 표준을 만든 것이 아니다. 기존 표준인 Vary를 Cloudflare의 일반적인 Cache Rules에서 처리할 수 있도록 범위를 확장한 변화다. 원본 서버는 어떤 요청 헤더가 응답에 영향을 줄 수 있는지 선언하고, Cloudflare는 해당 헤더 값을 어떻게 구분할지 설정한다.

이를 통해 같은 URL에서 제공하는 서로 다른 콘텐츠를 요청에 맞춰 선택할 수 있고, 정규화가 적절한 경우에는 불필요하게 분리된 캐시 항목을 줄일 수 있다. 실제 효과는 원본 서버가 반환하는 Vary와 캐시 설정, 요청의 분포에 따라 달라진다. Cloudflare가 발표한 기능과 공개 문서만으로 개별 웹사이트의 응답 속도나 캐시 적중률 개선 수치를 일반화할 수는 없다.