문제와 판단 기준

IXC Insights Editorial · 기술 확인 기준: 2026년 9월 26일

상품 화면을 빠르게 만들려고 CDN 캐시를 켰는데, 로그인한 고객에게 다른 고객의 계약 가격이 보인다고 가정해 보겠습니다. 같은 상품 주소라는 이유로 응답을 함께 재사용했지만 실제 가격은 고객마다 달랐던 설계 예시입니다. 이때 먼저 살펴볼 것은 캐시 적중률이 아니라 어떤 요청끼리 같은 응답을 받아도 되는지입니다.

이 글에서 제안하는 출발점은 다음과 같습니다. 공개 정적 자산과 누구에게나 같은 공개 콘텐츠는 공유 캐시 후보로 두고, 개인 정보·고객사별 데이터·인증 상태를 담은 응답은 우선 제외합니다. 공개 가격·재고·검색 결과는 허용할 정보 지연과 응답이 달라지는 조건을 정한 뒤 판단합니다. 동적으로 생성했다는 이유만으로 캐시가 불가능한 것은 아닙니다. HTTP 캐시는 응답의 저장·재사용 조건을 다루며, 정적 파일인지 여부만으로 안전성을 결정하지 않습니다.[1]

운영 기준으로는 같은 캐시 키에 들어오는 요청들이 권한·본문·응답 헤더·허용 신선도 측면에서 서로 대체 가능한가를 묻는 것이 유용합니다. 이를 설명하기 어렵다면 TTL부터 늘리지 말고, 응답을 분리하거나 공유 캐시를 끄는 쪽에서 시작합니다.

브라우저에 남기는 것과 다른 사용자에게 나누는 것은 다르다

브라우저의 개인 캐시와 CDN의 공유 캐시는 사용 범위가 다릅니다. Cache-Control을 읽을 때도 “저장할 수 있는가”와 “저장한 것을 언제 다시 쓸 수 있는가”를 나눠야 합니다. 아래는 필드 이름을 붙이지 않은 일반적인 응답 지시자의 의미입니다.[1]

응답 지시자저장·재사용 의미혼동하기 쉬운 점
private공유 캐시에는 저장하지 않습니다. 개인 캐시는 저장할 수 있습니다.브라우저에도 남기지 말라는 뜻이 아닙니다.
no-store개인·공유 HTTP 캐시에 이 요청·응답을 저장하지 않도록 지시합니다.이미 존재하는 모든 복사본을 원격 삭제하는 명령은 아닙니다.
no-cache저장은 가능하지만 재사용 전에 원본의 성공적인 재검증이 필요합니다.이름과 달리 저장 금지가 아닙니다.

max-age는 신선하게 취급할 기간을 나타냅니다. s-maxage는 공유 캐시에 적용되며 그곳에서는 max-age보다 우선합니다. 신선도 만료는 물리적인 즉시 삭제와 다릅니다. 만료된 객체를 재검증하거나 특정 조건에서 다시 사용할 수 있으므로, TTL이 0이라는 설명만으로 저장 금지를 뜻한다고 해석하면 안 됩니다.[3]

이 구분도 HTTP 캐시의 범위입니다. 서버 안의 데이터 캐시, 애플리케이션이 보관한 화면 상태, 브라우저의 방문 기록은 별도로 점검해야 합니다. HTTP 표준 역시 방문 기록과 캐시를 구분합니다. 따라서 로그아웃 후 화면을 비우는 요구사항을 헤더 하나로 끝냈다고 판단하지 않습니다.[1]

서비스 작동 방식

콘텐츠에 맞춰 전송 경로를 설계 — 파일의 갱신 방식에 맞춰 캐시를 나누고 엣지 전송 결과와 원본 부하를 함께 관측합니다.

응답별 정책표부터 만든다

다음 표는 편집자가 만든 설계 예시입니다. 고객 사례나 실행 결과가 아니며, 숫자는 비교를 위한 가정이지 권장 최적값이 아닙니다. 기본 범위는 조회용 GET 응답입니다. 주문 생성·수정 같은 상태 변경 요청에 이 표를 그대로 적용하지 않습니다.

표의 공통 키 출발점은 요청 메서드와 대상 URL입니다. 실제 CDN의 키 구성과 정규화는 별도로 확인합니다. “CDN 30초”는 신선도 정책의 목표이며 그 시간 동안 반드시 객체를 보관한다는 보장은 아닙니다.[1]

응답 종류공유 여부·브라우저 정책응답을 나누는 조건·키TTL·신선도 가정무효화·전환 계기원본 장애 때의 설계
버전이 붙은 공개 JS·CSS·이미지공유 허용, 브라우저 저장 허용콘텐츠 버전이 포함된 URL, 필요한 표현 형식CDN·브라우저 30일변경 시 새 URL. 보안상 철회할 파일은 별도 차단·무효화철회되지 않은 동일 버전에 한해 만료 후 추가 24시간 허용을 검토
익명 사용자에게 같은 공개 글·목록조건부 공유, 브라우저는 재사용 전 재검증언어, 페이지, 공개 필터 등 실제 변형 조건CDN 60초수정·삭제·비공개 전환 시 관련 목록까지 무효화만료 후 추가 제공은 허용하지 않음
로그인 처리·토큰 발급·계정별 리다이렉트공유 제외, 브라우저 no-store세션·인증 상태에 의존. 공통 객체로 합치지 않음저장하지 않음세션 생성·교체·종료. 과거 캐시가 있었다면 제거성공 응답이나 다른 세션 응답으로 대체하지 않음
개인 주문·프로필·결제 수단 조회공유 제외, 브라우저 no-store인증된 사용자와 객체 접근 권한저장하지 않음로그아웃·권한 변경·데이터 수정오래된 개인 응답 대신 오류 또는 재시도 안내
고객사별 대시보드·계약 가격기본적으로 공유 제외, 브라우저 no-store검증된 tenant·사용자·역할·객체 범위저장하지 않음고객사 이동·역할 변경·계약 변경이전 권한의 응답으로 우회하지 않음
누구나 볼 수 있는 표시용 가격조건부 공유, 브라우저는 재사용 전 재검증상품·통화·판매 시장·가격 표시 조건CDN 30초가격 게시·프로모션 변경만료 후 추가 제공 금지. 주문 확정 시 권위 있는 가격 재확인
공개 재고 안내조건부 공유, 브라우저는 재사용 전 재검증상품·공개 지역·재고 조회 단위CDN 5초입출고·품절·판매 중단만료 후에는 확인 불가로 표시. 예약·차감 판단에는 사용하지 않음
익명 공개 검색 결과조건부 공유, 브라우저는 재사용 전 재검증검색어·필터·정렬·페이지·언어CDN 10초색인 변경·공개 범위 변경만료 후 추가 제공 금지. 개인화·민감 검색은 별도 제외

로그인 화면도 구분이 필요합니다. 세션 정보가 전혀 없는 공통 화면 틀과 공개 이미지는 앞의 공개 콘텐츠 정책의 적용 대상입니다. 반면 같은 화면 안에 일회성 토큰, 사용자 이름, 계정별 이동 주소가 들어간다면 “로그인 페이지”라는 이름만으로 한 정책에 묶지 않습니다.

가격과 재고는 화면에 보여도 되는 지연과 거래 판단에 허용하는 지연을 따로 합의하는 편이 안전합니다. 위 예시는 표시용 조회만 공유하는 설계입니다. 주문 확정·재고 차감까지 캐시된 조회 결과에 맡기는 설계가 아닙니다. 고객별 할인이 섞이는 순간 공개 가격 행이 아니라 개인·고객사별 행으로 옮깁니다.

또한 CDN에 막 저장한 응답이라도 애플리케이션이 오래된 데이터 스냅샷으로 만들었다면 업무상 최신 정보는 아닙니다. 정책 검토에서는 CDN TTL 외에 원본 데이터 갱신, 비동기 반영, 무효화 지연까지 함께 적습니다. 짧은 TTL을 지원하지 않거나 변경 전파가 요구사항을 만족하지 못하면 해당 응답의 캐시를 제외하는 선택도 남겨 둡니다.

키에 무엇을 넣을지는 응답이 달라지는 이유에서 찾는다

캐시 키로 저장된 응답을 찾습니다. Vary는 응답 선택에 영향을 주는 요청 헤더를 알리는 표준 장치입니다.[2] 설계할 때는 URL만 보지 말고 쿼리, 언어, 통화, 쿠키, 인증 상태, 고객사 식별 정보 중 무엇이 실제 응답을 바꾸는지 추적합니다.

예를 들어 통화 쿠키를 읽어 가격을 바꾸면서 캐시는 URL만으로 구분한다면, 같은 주소에서 서로 다른 가격이 필요하다는 사실이 키에 반영되지 않습니다. 반대로 응답에 영향을 주지 않는 추적용 값을 모두 키에 넣는 것도 먼저 선택할 이유는 없습니다. 원본과 CDN이 동일한 요청을 동일하게 해석하는지 검증한 뒤 필요한 변형만 남기는 방식이 적절합니다.

여기서 원본으로 전달하는 값과 캐시 키에 포함하는 값은 같지 않을 수 있습니다. CloudFront는 캐시 정책에 포함한 값을 원본에도 전달하지만 별도 원본 요청 정책으로 키에 넣지 않는 값을 전달할 수도 있습니다.[4] 따라서 “서버까지 고객사 헤더가 도착한다”는 확인만으로 고객사별 캐시가 분리됐다고 결론내리면 안 됩니다.

고객사 식별자를 키에 넣는 일은 권한 검사도 대신하지 않습니다. 이 글의 기본안이 고객사 응답을 공유 캐시에서 제외한 이유입니다. 별도의 인증된 공유 캐시를 설계하려면 적어도 캐시 HIT 응답을 내보내기 전에 검증된 접근 맥락을 적용하고 같은 고객사 안의 역할 차이와 권한 철회까지 처리해야 합니다. 요청자가 보낸 고객사 문자열만 믿거나 토큰을 키에 추가한 것으로 검토를 끝내지 않습니다.

Vary는 제품의 현재 지원 방식까지 확인한다

Cloudflare는 2026년 7월 2일 Cache Rules의 Vary 지원을 발표했습니다. 현재 문서는 캐시 규칙에서 이를 활성화하고 원본이 Vary를 반환하는 조건을 설명합니다. 따라서 과거 자료의 “Cloudflare는 Vary를 무시한다”는 설명을 무조건 적용하는 것도, 헤더만 추가하면 모든 설정에서 자동으로 분리된다고 보는 것도 맞지 않습니다.[5][6]

선택한 헤더를 그대로 구분할지, 정규화할지, 해당 응답을 캐시에서 제외할지는 원본의 응답 생성 방식과 맞춰야 합니다. 특히 언어·형식 값을 정규화할 때는 합쳐진 요청들이 실제로 같은 표현을 받아도 되는지 확인합니다. 지원되는 기능이라는 사실과 현재 배포에 올바르게 적용됐다는 사실은 별개입니다.

원본 헤더보다 강한 CDN 설정이 있는지 본다

브라우저에서 Cache-Control: private를 확인했다고 해서 CDN 안의 저장 정책까지 확인한 것은 아닙니다. 다음은 2026년 9월 26일 공식 문서에서 확인한 서로 다른 구성 요소의 예시입니다. 두 제품의 성능 비교나 동일 설정끼리의 비교가 아닙니다.

확인할 구성공식 문서상 주의점변경 전에 확인할 것
Cloudflare Cache Rules의 Edge TTL원본 Cache-Control을 무시하고 지정한 TTL을 사용하는 선택지가 있습니다.[7]실제 매칭 범위, 원본 헤더 존중 여부, 이후 적용되는 규칙과 엣지 코드
CloudFront 캐시 정책Minimum TTL이 0보다 크면 원본의 no-cache·no-store·private에도 그 기간 캐시할 수 있습니다.[4]해당 경로에 연결된 정책의 세 TTL 값과 캐시 키
CloudFront 관리형 CachingOptimizedMinimum TTL은 1초이고 쿠키와 쿼리 문자열은 키에 포함하지 않습니다.[8]이 정책을 개인화 HTML·API에 넓게 연결하지 않았는지

CloudFront는 Minimum·Default·Maximum TTL을 모두 0으로 하면 캐싱을 비활성화한다고 설명합니다. 관리형 CachingDisabled도 이 세 값을 0으로 둡니다.[4][8] 다만 캐시를 끈 뒤에도 인증 등 필요한 요청 정보가 원본에 전달되는지는 별도 정책에서 확인해야 합니다.

Cloudflare를 사용한다면 요청 단계뿐 아니라 응답 단계의 변경도 살핍니다. Cache Response Rules는 캐시에 들어가기 전 Cache-Control이나 Set-Cookie 같은 헤더를 바꿀 수 있습니다.[5] 클라이언트에 보이는 헤더, 캐시가 판단할 때 사용한 헤더, 최종 매칭 규칙을 함께 확인하는 이유입니다.

이 표는 운영용 복사·붙여넣기 설정이 아닙니다. 계정의 플랜, 규칙 순서, 경로별 연결 상태, 다른 캐시 계층을 확인하지 않은 상태에서 전역 규칙으로 옮겨서는 안 됩니다.

인증 헤더와 쿠키를 안전장치로만 생각하지 않는다

RFC 9111은 Authorization 요청의 공유 캐시 재사용을 제한하지만 public·s-maxage·must-revalidate 등 명시된 응답 지시자의 조건에 따른 예외도 둡니다. “인증 헤더가 있으니 어떤 설정에서도 공유되지 않는다”는 전제는 성립하지 않습니다.[1]

쿠키는 별도로 봐야 합니다. CloudFront는 구성에 따라 쿠키를 무시하거나 선택한 쿠키를 키에 반영합니다. 쿠키를 원본에 전달하도록 구성하면 원본의 Set-Cookie를 객체와 함께 캐시하고 이후 응답에 반환할 수 있다고 설명합니다.[9] 세션을 발급하는 응답을 캐시에 넣지 않는지, 다른 사용자에게 같은 세션 설정이 재생되는지까지 확인해야 합니다.

Cloudflare도 Origin Cache Control 설정과 캐시 규칙에 따라 인증·쿠키 처리가 달라집니다.[3] 제품명을 근거로 안전하다고 단정하기보다는 로그인 전 첫 요청, 로그인 직후, 로그아웃 직후의 요청과 응답을 따로 검사하는 편이 낫습니다.

응답 본문만 비교해서도 부족합니다. 본문이 같은 화면이어도 Set-Cookie, 계정별 Location, 접근 범위를 담은 메타데이터가 달라질 수 있습니다. 정책표와 테스트의 비교 대상을 본문·상태 코드·보안 관련 헤더까지 넓힙니다.

서비스 작동 방식

서비스 앞단에서 요청을 분류하고 방어 — 요청과 차단 기록을 살펴 방어 규칙을 조정하고 인증서와 접근 통제를 함께 관리합니다.

재검증과 장애 대응에도 접근 경계가 남아 있어야 한다

ETag를 이용한 재검증은 같은 표현이 바뀌었는지 확인하는 데 쓰입니다. 접근 권한을 대신 판정하는 수단은 아닙니다. RFC 9110은 조건부 요청을 평가하기 전에 정상적인 요청 검사를 수행하도록 규정합니다.[2] 이를 테스트 설계에 적용하면, 권한이 철회된 사용자의 요청을 예전 ETag만 보고 304 Not Modified로 처리하지 않는지 확인해야 합니다.

오래된 응답을 허용하는 정책도 따로 적습니다. stale-while-revalidate는 새 응답을 확인하는 동안, stale-if-error는 원본 오류 상황에서 만료된 응답을 제공하는 데 사용됩니다.[10] 공개 글에서는 가용성을 위해 일정 지연을 받아들일 수 있지만 철회된 접근 권한이나 이전 계약 가격까지 오래 유지해도 된다는 뜻은 아닙니다.

위 정책표에서 “추가 제공 금지”라고 정했다면 그 요구가 실제 CDN의 오류·재검증 정책으로 구현됐는지 확인해야 합니다. CloudFront의 만료 문서는 원본 연결 실패 시 설정에 따라 오래된 객체가 반환될 수 있는 경우도 설명합니다.[10] 정상 상태의 TTL 검사만으로 장애 시 동작까지 통과시켜서는 안 됩니다.

재검증을 강제하는 지시자와 오래된 응답을 허용하는 지시자를 한꺼번에 나열하는 것도 피합니다. 공유 캐시의 s-maxage에는 proxy-revalidate 의미도 포함되므로, 오래된 응답 허용 설정과의 관계를 확인해야 합니다. 충돌·우선순위를 선택한 제품의 문서에서 확인하고 실제로 기대하는 결과를 장애 테스트의 합격 조건으로 적습니다.[3]

잘못 저장한 응답은 헤더 수정만으로 정리하지 않는다

캐시에 저장하면 안 되는 응답이 들어갔다면, 앞으로 적용할 정책과 이미 저장된 객체를 나눠 처리합니다. 다음은 소유하거나 명시적으로 허가받은 환경에서 적용 범위를 정한 뒤 실행할 방어적 복구 절차 제안입니다.

  1. 잘못된 재사용과 재유입부터 막습니다. 영향 경로의 공유 캐시를 제외하고 원본 응답 정책을 고칩니다. 규칙이 실제로 적용됐는지 확인합니다. 원본이 계속 잘못된 객체를 공급한다면 purge 이후에도 다시 저장될 수 있습니다.
  2. 기존 키와 변형을 포함해 무효화합니다. 현재 키뿐 아니라 변경 전 키, 언어·쿼리·쿠키별 변형, 사용 중인 캐시 계층의 처리 범위를 확인합니다. Cloudflare의 단일 URL purge는 헤더·쿠키 기반 사용자 지정 키에서 제약이 있으므로, 실제 키에 맞는 API 요청이나 적절한 범위의 다른 purge 방식을 검토합니다.[11]
  3. CDN 밖의 복사본과 노출 영향을 따로 처리합니다. CloudFront의 invalidation으로 브라우저나 기업 프록시의 복사본까지 지울 수는 없습니다.[12] 애플리케이션 캐시·화면 상태·이미 전달된 정보의 영향 범위를 확인하고 필요한 사고 대응으로 연결합니다.
  4. 내용과 접근 결과로 복구를 확인합니다. Cloudflare purge의 HTTP 200은 요청 접수를 뜻하며 객체가 실제로 존재했거나 제거됐다는 증거는 아닙니다.[13] 최신 본문 버전과 사용자 격리를 다시 확인합니다. 정상 객체가 다른 요청으로 먼저 채워졌다면 HIT가 나올 수도 있으므로, MISS만을 복구 성공 조건으로 삼지 않습니다.

버전 URL로 바꾸는 방법은 공개 정적 자산의 배포에 유용합니다. 다만 이전 URL에 이미 노출된 민감 응답을 없애거나, 접근을 철회하는 절차를 대신하지는 않습니다. 파일 버전 관리와 CDN 무효화의 역할을 나눠 둡니다.[12]

두 사용자로 캐시의 정상 경로와 실패 경로를 함께 확인한다

다음은 실행하지 않은 테스트 설계 예시입니다. 허가된 테스트 환경에서 가상 사용자 A와 B, 서로 다른 가상 고객사, 합성 주문 데이터를 준비합니다. 같은 고객사 안에서도 권한 차이를 시험할 수 있도록 별도의 역할 조건을 둡니다. 데이터에는 실제 개인정보 대신 구분용 표식을 넣고, 브라우저 프로필과 쿠키 저장소도 분리합니다.

검사요청 순서·조건합격 조건
공개 캐시의 정상 재사용같은 공개 자산을 반복 조회하고 캐시가 채워진 상태도 만듭니다.허용된 경로에서 정상 재사용이 관측되고 내용·버전이 일치합니다. 전부 차단한 것을 성공으로 보지 않습니다.
사용자·고객사 격리같은 API 주소를 A → B, B → A 순서로 요청합니다. 동시 요청도 별도로 확인합니다.각자 허용된 데이터만 받으며 본문·헤더에 상대 표식이 없습니다. 민감 경로는 공유 캐시로 재사용되지 않습니다.
로그인 전후·세션 발급익명 조회 후 로그인하고 새로운 B 세션에서도 반복합니다.다른 세션의 Set-Cookie나 계정별 이동 주소가 재생되지 않습니다.
같은 고객사 안의 역할 차이같은 객체를 관리자 조건과 제한된 역할 조건으로 조회합니다.고객사가 같아도 허용 범위 밖 필드·객체가 전달되지 않습니다.
권한 철회·고객사 이동이전 응답이 유효할 법한 시간 안에 권한을 변경하고 다시 요청합니다. 조건부 요청도 포함합니다.과거 본문이나 부적절한 304로 이전 권한을 유지하지 않습니다. 정상적으로 허용되는 작업은 계속 가능합니다.
로그아웃·계정 전환로그아웃 후 직접 재요청, 뒤로 가기, B 로그인 후 같은 화면 접근을 구분합니다.HTTP 응답과 애플리케이션 화면 상태 모두에서 이전 계정의 정보가 노출되지 않습니다.
쿼리·언어·통화실제 응답을 바꾸는 조건을 하나씩 변경하고 정규화되는 값도 비교합니다.달라야 하는 응답은 분리되고 합쳐도 되는 요청만 같은 표현을 받습니다.
만료·재검증만료 전후를 비교하고 원본의 변경·미변경 조건을 각각 만듭니다.승인한 신선도·재검증 정책대로 동작하며 표현과 검증자가 뒤섞이지 않습니다.
가격·재고 변경과 purge원본 값을 변경하고 관련 상세·목록·검색을 검사합니다. 변경 전 키의 객체도 준비합니다.변경 전 값이 허용 범위를 넘어 남지 않고, 주문 확정·재고 차감은 권위 있는 상태로 판단합니다.
원본 오류·시간 초과통제된 원본에서 오류·연결 실패를 만들고 캐시 유무와 만료를 조합합니다.민감 응답은 오래된 객체로 대체되지 않습니다. 공개 응답도 사전 합의한 만료 후 허용 범위를 넘지 않습니다.
오류·리다이렉트 응답성공 응답 외에 계정별 리다이렉트, 401·403·404 경로를 검사합니다.다른 사용자의 상태가 재사용되지 않고, 오류 페이지나 헤더에도 민감 정보가 없습니다.

캐시 상태, 응답 코드, Cache-Control, Vary, Age, ETag, 본문 버전·합성 표식, 적용 정책 버전을 함께 기록합니다. 실제 토큰이나 세션 쿠키를 증거 파일에 그대로 남길 필요는 없습니다. 사용자별 결과와 원본·CDN 기록을 연결하되 비밀 값은 제외합니다.

캐시 상태 이름은 제품과 요청 경로에 따라 다를 수 있습니다. 한 번의 MISS는 “저장하지 않음”을 증명하지 않고, 한 번의 200은 “올바른 사용자 데이터”를 증명하지 않습니다. 서로 다른 사용자, 이미 채워진 캐시, 만료, 무효화, 원본 장애까지 기대 결과가 유지되는지 확인해야 합니다.

전송·원본·전환 항목을 함께 살펴볼 때는 CDN·WAF 구성 점검표를 참고하고 사용자 격리 검증 결과는 별도로 덧붙일 수 있습니다.

캐시를 켜는 범위보다 책임질 수 있는 범위가 먼저다

공개 정적 자산만 캐시하고 응답·배포·무효화 담당자가 명확하다면, 작은 정책표와 회귀 검사부터 직접 운영할 수 있습니다. 반면 고객사별 응답, 여러 CDN·프록시·애플리케이션 캐시, 잦은 권한 변경이 함께 있으면 각 계층의 담당자가 같은 접근·신선도 기준을 합의해야 합니다. 이 경우 초기 적중률을 낮추더라도 불명확한 경로를 제외하는 선택이 합리적입니다.

캐시 검토의 결과물은 “캐시를 켰다”가 아니라 공유할 응답, 나눌 키, 허용할 지연, 지울 계기, 장애 때의 행동, 이를 입증할 검사가 연결된 정책입니다.

공유 캐시의 데이터 경계와 별개로 원본 접속 경로를 보호하는 문제는 CDN과 WAF를 붙였는데도 원본 서버가 노출되는 이유와 막는 법에서 다룹니다.

외부 지원을 검토한다면 IXC CDN 서비스의 지원 범위를 확인하고 캐시 정책·무효화·검증 중 필요한 검토 범위를 구체적으로 협의할 수 있습니다.