Cache Response Rules란 무엇인가
Cloudflare가 기존 Cache Rules의 한계를 보완하는 Cache Response Rules를 새롭게 도입했다. 기존 Cache Rules는 요청(Request) 단계의 속성만을 평가할 수 있었다. 즉, URL 패턴, HTTP 메서드, 헤더 등 클라이언트가 보내는 정보를 기준으로만 캐시 여부를 판단했다. 이 방식은 오리진 서버가 실제로 어떤 응답을 내려보내는지와 무관하게 캐시 정책이 결정된다는 근본적인 한계가 있었다.
Cache Response Rules는 오리진 서버가 응답한 이후, 캐시에 저장되기 이전 시점에 동작하는 룰 엔진이다. 이 단계에서는 응답 상태 코드, 응답 헤더, Content-Type 등 실제 오리진 응답 내용을 평가 대상으로 삼을 수 있다. 결과적으로 응답 내용에 따라 캐시 저장 여부와 방식을 동적으로 제어하는 것이 가능해진다.
실무에서 왜 중요한가
백엔드 개발자 관점에서 이 기능이 중요한 이유는 오리진 응답의 다양성에 있다. 동일한 엔드포인트라도 오리진이 상황에 따라 다른 상태 코드나 헤더를 반환할 수 있다. 예를 들어 다음과 같은 시나리오를 생각해볼 수 있다.
- 오리진이
200 OK를 반환할 때만 캐시에 저장하고,500 Internal Server Error는 캐시하지 않도록 제어 - 응답 헤더에
X-Cache-Eligible: false가 포함된 경우 캐시 저장을 명시적으로 건너뜀 - 특정
Content-Type(예:application/json)에만 TTL을 다르게 적용
기존에는 이런 세밀한 제어를 위해 오리진 서버 코드 레벨에서 Cache-Control 헤더를 직접 조작하거나, CDN 설정을 우회하는 방식으로 처리해야 했다. Cache Response Rules는 이 복잡성을 인프라 레이어에서 흡수할 수 있게 해준다.
# 예시: 오리진이 5xx를 반환하면 캐시 저장 안 함
if (http.response.code ge 500 and http.response.code lt 600) {
cache: bypass
}
위와 같이 응답 코드 범위를 기준으로 캐시 우회 정책을 선언적으로 정의할 수 있어, 오리진 코드 변경 없이 운영 중 정책을 유연하게 조정할 수 있다.
기존 Cache Rules와의 비교
두 기능은 상호 보완적으로 동작한다. 요청 단계와 응답 단계를 각각 분리해서 이해하면 다음과 같다.
| 구분 | Cache Rules | Cache Response Rules |
|---|---|---|
| 평가 시점 | 요청 수신 직후 | 오리진 응답 수신 후 |
| 평가 대상 | URL, 메서드, 요청 헤더 | 응답 코드, 응답 헤더 |
| 주요 용도 | 캐시 대상 사전 필터링 | 응답 기반 캐시 저장 정책 결정 |
실무에서는 두 룰을 조합해 사용하는 것이 권장된다. 요청 단계에서 명백히 캐시가 불필요한 경우를 먼저 걸러내고, 응답 단계에서 오리진 응답 내용에 따라 최종 캐시 정책을 확정하는 방식이다. 이렇게 하면 불필요한 오리진 부하를 줄이면서도 캐시 적중률과 정확성을 동시에 높일 수 있다.
정리
- Cache Response Rules는 오리진 응답 이후, 캐시 저장 이전 단계에서 응답 코드·헤더 등을 기준으로 캐시 정책을 동적으로 제어하는 기능이다.
- 오리진 코드 변경 없이 인프라 레이어에서 세밀한 캐시 제어가 가능해져, 5xx 오류 캐싱 방지 등 실무 운영 이슈를 효과적으로 해결할 수 있다.
- 기존 Cache Rules(요청 단계)와 조합해 사용하면 캐시 적중률과 정확성을 모두 확보하는 이중 레이어 캐시 전략을 구성할 수 있다.