워드프레스 Bunny CDN 설정: 원본 연결과 캐시 갱신

워드프레스에 Bunny CDN을 연결할 때는 공개 파일부터 CDN으로 제공하는 편이 좋다. HTML은 기존 페이지 캐시로 제공한다. CSS·JavaScript(JS)·이미지·폰트는 CDN으로 전달한다. 파일을 수정했을 때 독자가 새 파일을 받을 수 있는지도 확인해야 한다.

Data In Hands의 구성도 이와 같다. 2026년 11월 9일 확인한 Bunny 설정에서 사이트 파일용 Zone의 URL Query String 항목은 선택되지 않은 상태였다. 예를 들어 style.css?ver=1을 style.css?ver=2로 바꿔도 같은 캐시를 사용할 수 있다는 뜻이다. 연결을 새로 만드는 것보다, 수정한 파일이 제대로 전달되는지 확인하는 일이 먼저다.

HTML담당

원 서버·FlyingPress페이지 제공·HTML 캐시

공개 정적 파일담당

Bunny CDNCSS·JS·이미지·폰트 전달

별도 보관 미디어담당

미디어용 Bunny CDN원본: OCI Object Storage

오래 보관할 파일의 변경 원칙내용을 바꿀 때 파일명도 바꿀 것이전: image-v1.png / 변경 후: image-v2.png

WordPress 파일과 Object Storage 미디어의 원본을 나눌 것

파일의 저장 위치를 알아야 Bunny에 원본 주소를 올바르게 입력할 수 있다. 파일을 수정한 뒤 갱신할 캐시도 저장 위치에 따라 달라진다. 아래는 Data In Hands에서 파일을 나눠 제공하는 방식이다. 원 서버에는 WordPress와 파일 원본이 있다. OCI WAAS는 이 서버 앞에서 요청을 검사한다. 검사를 통과한 요청은 서버로 전달한다.

예를 들어 브라우저는 cdn.datainhands.com으로 파일을 요청한다. 이 주소의 요청은 Bunny CDN이 처리한다.

한번 가져온 파일을 다음 요청에도 쓸 수 있도록 저장해 두는 것이 캐시(cache)다. 저장해 둔 파일로 응답하면 캐시 적중(HIT)이라고 한다. 사용할 사본이 없어 원본에서 가져와야 하면 캐시 미적중(MISS)이다.

글·홈 HTML

현재 제공 방식WordPress 서버 · FlyingPress 캐시

권장 조치기존 경로 유지

서버의 공개 파일

현재 제공 방식Bunny CDN · 원본은 WordPress 서버

권장 조치연결은 유지. 수정한 파일이 전달되는지 확인

Object Storage 미디어

현재 제공 방식별도 Bunny CDN · 원본은 Object Storage

권장 조치별도 Zone 유지. 직접 제공할 때와 속도·비용 비교

로그인·비공개 콘텐츠

현재 제공 방식사용자별 접근 권한 필요

권장 조치공개 파일용 설정에서 제외

HTML 요청은 WAAS를 거쳐 WordPress 서버로 전달된다. 서버에 사용할 수 있는 FlyingPress HTML 캐시가 있으면 그 파일을 보내 준다. HTML 캐시를 더 추가할지는 실제 응답 지연을 측정한 뒤 판단해야 한다.

공개 CSS·JS·이미지·폰트는 Bunny가 제공한다. Bunny 캐시에 파일이 없으면 해당 Zone의 원본에서 가져온다. WordPress 파일용 Zone은 WAAS를 거쳐 서버에 요청한다. 미디어용 Zone은 Object Storage에 직접 요청한다. 로그인·비공개 콘텐츠는 인증과 접근 제한을 별도로 확인해야 한다.

이미지도 저장 위치에 따라 경로가 다르다. WordPress 서버에 저장된 이미지는 cdn.datainhands.com으로, OCI Object Storage에 저장된 미디어는 datainhandsoci.b-cdn.net으로 제공하고 있다. 후자는 사이트의 WAAS나 WordPress 서버를 거치지 않는다.

이제 이 구성을 Bunny에 등록할 차례다. 먼저 같은 원본에서 가져올 파일을 한데 묶어야 한다. WordPress 서버와 Object Storage 양쪽에 파일이 있다면, Bunny에 각각의 원본 주소를 알려 줘야 한다.

이때 사용하는 설정 단위가 Pull Zone이다. 파일을 가져올 원본 주소와 캐시 정책을 여기서 정한다. 원본 주소와 캐시 설정이 같은 파일은 한 Zone으로 묶으면 된다. 이 때문에 WordPress 파일용 Zone과 Object Storage 미디어용 Zone을 따로 구성했다. 글의 카테고리가 달라도 원본과 캐시 설정이 같다면 Zone을 나눌 필요는 없다.

Object Storage에 CDN이 필요한지 비용과 속도로 판단할 것

현재 Object Storage에 저장한 미디어는 별도의 Bunny Zone을 통해 제공하고 있다. Object Storage로 파일을 옮기면 WordPress 서버가 미디어까지 직접 보내지 않아도 된다. 여기에 CDN을 추가하면 독자와 가까운 곳에 저장된 사본으로 응답할 수 있다.

파일을 Object Storage로 옮겨도 저장소에서 멀리 떨어진 독자는 파일을 받는 데 시간이 걸릴 수 있다. OCI Object Storage는 선택한 지역, 즉 리전(region)에 파일을 보관하는 서비스다. 인터넷으로 직접 파일을 제공할 수 있지만, 방문자 가까운 여러 지역에 사본을 두려면 CDN이 필요하다. Bunny는 캐시에 파일이 있으면(HIT) 가까운 전송 거점에서 응답한다. 파일이 없으면(MISS) Object Storage에서 가져온다. 이 미디어 경로는 사이트의 WAAS나 WordPress 서버를 거치지 않는다. OCI Object Storage 설명 · Bunny의 원본 가져오기

다만 CDN을 유지하는 편이 유리한지는 실제 이용 상황을 보고 판단해야 한다. 방문 지역과 파일 이용 패턴을 확인한 뒤 다음 기준으로 판단하면 된다.

여러 국가에서 같은 파일 반복 조회

판단CDN 유지 검토

확인할 항목지역별 응답시간 · HIT 비율

방문자가 저장소 인근에 집중

판단직접 제공과 비교

확인할 항목동일 파일 응답시간 · 총비용

적은 방문량 · 낮은 파일 재사용

판단비용 대비 효과 확인

확인할 항목MISS 비율 · 전송량 · 요금

같은 주소의 파일을 자주 교체

판단갱신 방식 개선 우선

확인할 항목새 파일명 사용 가능 여부

파일명을 바꿀 수 없다면 해당 Zone의 캐시를 비우는 방법과 브라우저 보관기간을 확인해야 한다. CDN을 연결했다고 해서 항상 더 빨라지는 것은 아니다.

비용도 따로 계산해야 한다. OCI는 인터넷 반출 트래픽에 월 최초 10TB 무료 구간을 제공한다. Bunny는 CDN 전달량에 요금을 부과한다. OCI 사용량이 무료 구간 안에 있다면 저장소 요청이 줄더라도 총비용은 늘 수 있다. 저장소 용량·요청 비용과 CDN 요금을 합쳐 비교해야 한다. OCI 네트워크 요금 · Bunny CDN 요금

여기서는 기존 미디어용 Bunny 연결을 우선 유지하는 쪽으로 검토하고 있다. 저장소에서 직접 제공할 때와의 성능 차이는 아직 측정하지 않았다. 유지할 실익이 있는지는 지역별 응답시간·HIT 비율·비용을 비교해 판단해야 한다.

기존 설정에서 버전 구분과 캐시 기간을 확인할 것

Zone을 나눴다면 먼저 각 Zone의 원본 주소가 맞는지 확인해야 한다. 캐시 설정도 파일의 사용 방식에 맞춰 검토해야 한다. Origin URL은 Bunny가 파일을 가져올 주소다. Host header는 원본 서버에 어느 사이트의 파일을 요청하는지 알려 주는 값이다. 파일마다 캐시 동작을 다르게 정할 때는 조건별 규칙인 Edge Rules를 사용한다.

주소 끝의 버전 번호가 다를 때 파일을 따로 저장할지는 Vary Cache에서 설정한다. 11월 9일 확인한 값과 시험할 항목을 나눠 정리했다.

Origin URL

확인된 설정https://cdn.datainhands.com

권장 조치유지

Host header

확인된 설정datainhands.com

권장 조치유지

Edge Rules

확인된 설정등록된 규칙 없음

권장 조치공개 CSS 일부에서 규칙 시험

Smart Cache

확인된 설정ON

권장 조치유지. 공개 파일에만 적용되는지 확인

Bunny 캐시 만료

확인된 설정Override: 1 year

권장 조치파일 갱신 방식별로 기간 검토

브라우저 캐시 만료

확인된 설정Match server cache expiration

권장 조치실제 보관기간 확인

Vary Cache · URL Query String

확인된 설정미선택

권장 조치Bunny·WAAS의 버전 구분 시험

WAAS 정적 파일 캐시

확인된 설정대상 확장자 11종에 1일 (11월 9일 확인)

권장 조치우선 유지. 실제 요청 경로 확인

Origin URL과 Host header는 기존 WAAS 경로를 유지하도록 설정되어 있다. WAAS 캐시를 바꿀지는 본 도메인으로 직접 요청하는 파일과 Bunny의 MISS 요청을 확인한 뒤 판단해야 한다. Edge Rules는 전체 파일에 적용하기 전에 공개 CSS의 시험 경로로 범위를 제한할 계획이다.

먼저 확인할 것은 버전 번호를 바꿨을 때 새 파일을 받는지다. style.css?ver=1과 style.css?ver=2를 다르게 요청해도 Bunny가 쿼리 문자열(query string)을 구분하지 않으면 같은 사본을 줄 수 있다. 별도 CSS 테스트에서 버전 숫자만 바꿔도 Bunny가 이전 내용을 반환하는 상황을 재현했다. 아래 파일 갱신 시험 결과에서 확인할 수 있다.

원본·CDN 주소·HTTPS를 연결한 뒤 파일 주소를 바꿀 것

원본을 지정한 다음에는 브라우저가 파일을 요청할 CDN 주소를 연결해야 한다. CDN 주소로 파일이 열리고 HTTPS 인증서에도 문제가 없는지 확인한 뒤 WordPress의 파일 주소를 바꾸는 순서다. 아래는 새로 구성할 때의 절차다. 이미 연결을 마쳤다면 Zone이나 DNS 레코드를 다시 만들 필요 없이 기존 값을 확인하면 된다.

1. 변경 전 값 보관. Origin URL·Host header·만료·규칙·CDN 전환 값을 기록한다. 문제가 생겼을 때 이전 설정과 파일로 되돌릴 수 있어야 한다.
2. Bunny 대시보드에서 Add → Add Pull Zone을 연다. WordPress 파일은 Origin URL 방식으로 사이트의 HTTPS 주소를 넣는다. 현재 설정된 주소는 https://datainhands.com이다. Origin URL에 자기 CDN 주소를 넣으면 Bunny가 자신에게 다시 파일을 요청할 수 있으므로 넣지 말아야 한다.
3. 같은 서버에서 여러 사이트를 운영할 수 있다. 따라서 Bunny가 요청하는 사이트 이름도 정확해야 한다. Host header가 그 사이트 이름을 전달한다. Bunny는 비워 두면 Origin URL의 호스트를 사용한다. 현재 Host header에 지정된 값은 datainhands.com이다. Bunny 시작 문서
4. 독자가 사용할 주소를 Bunny에 연결한다. General → Hostnames에서 CDN용 하위 주소(서브도메인)를 추가한다. 예를 들면 cdn.datainhands.com이다. 주소를 연결하는 DNS 설정에서는 이 이름이 Bunny의 Zone 호스트를 가리키도록 별칭 레코드인 CNAME을 만든다. 대상 값은 Bunny 화면에 표시된 Zone 호스트를 사용한다. 다른 계정의 예시 Zone 이름을 그대로 복사하지 않는다.
5. 주소를 연결했다면 HTTPS로 파일이 열리는지 확인해야 한다. HTTPS는 브라우저와 CDN 사이의 통신을 암호화한다. DNS가 연결되면 Verify & Activate SSL 또는 Enable에서 인증서를 활성화한다. 그다음 실제 파일 주소를 열어 인증서 오류가 없는지 확인해야 한다. 이 확인을 마치기 전에는 사이트의 파일 주소를 바꾸지 말아야 한다. 호스트 연결 · HTTPS 설정
6. FlyingPress의 CDN 항목에 CDN 주소를 연결한다. 2026년 11월 9일 확인한 FlyingPress 5.6.7 설정은 CDN ON, cdn.datainhands.com, 파일 유형 all이었다. 이 구성은 유지한다. 다만 실제 요청 목록에서 로그인·비공개 경로가 CDN 주소로 바뀌지 않았는지 확인해야 한다.

① Origin URL·Host header: 파일을 가져올 서버 지정

② Hostnames: CDN 주소 연결과 HTTPS 활성화

③ FlyingPress CDN: 페이지의 파일 주소를 CDN 주소로 변경

Object Storage의 파일 주소는 WordPress 파일 주소와 구조가 다를 수 있다. 현재 미디어용 Zone은 Origin URL로 저장소를 지정하고, Origin Override 규칙으로 파일이 보관된 버킷 안의 경로를 지정하고 있다. Bunny의 별도 상품인 Bunny Storage를 선택하는 것과는 다르다. 버킷(bucket)은 파일을 담는 저장 공간이다. 먼저 버킷의 경로와 접근 권한을 확인해야 한다. CDN에는 공개해도 되는 파일만 연결해야 한다.

WordPress 파일용 Zone의 원본 주소는 기존 사이트 도메인을 유지할 계획이다. 이 값을 IP로 바꾸면 WAAS를 거치지 않을 수 있다. 따라서 변경 전 인증서·Host header·원본 접근 제한을 함께 검토해야 한다.

파일을 수정했다면 새 주소로 전달되는지 확인할 것

CDN을 연결했다면 파일을 수정했을 때 새 내용이 보이는지도 확인해야 한다. 같은 주소의 사본이 캐시에 남아 있으면 파일을 고쳐도 이전 내용이 보일 수 있다. 파일을 수정할 때 파일명도 바꾸는 방법을 권한다. 예를 들어 site.a81f.css를 수정했다면 site.c92b.css로 올린다. 웹페이지의 파일 주소도 새 이름으로 바꿔야 한다. 파일 내용으로 계산한 해시(hash)를 이름에 넣는 방법도 있다. 내용이 달라지면 파일명도 달라져 새 파일을 요청하게 된다. 예전 주소를 요청하는 페이지도 있을 수 있으므로 이전 파일은 바로 삭제하지 말아야 한다.

플러그인이나 테마가 관리하는 CSS·JS 파일은 임의로 이름을 바꾸지 말아야 한다. 업데이트 과정에서 파일이 다시 생성되거나 연결이 끊길 수 있기 때문이다. 이런 파일은 제품이 제공하는 버전 관리 방식을 먼저 확인해야 한다.

파일명을 바꾸는 대신 주소 끝의 버전 번호를 쓰는 경우도 있다. ?ver=처럼 물음표 뒤에 붙는 값은 쿼리 문자열(query string)이다. CDN이 이 값을 구분해야 새 버전 주소를 별개의 파일로 처리할 수 있다. WordPress가 ?ver=을 사용한다면 먼저 버전 번호별로 다른 파일을 받는지 시험해야 한다. 관련 설정은 Bunny의 Caching → General → Vary Cache에 있다. 시험 결과에 따라 URL Query String을 선택한 뒤 Save Vary Cache로 저장한다. 기본적으로 쿼리를 무시한다는 공식 설명도 확인했다. 다만 파일 내용과 관계없는 매개변수까지 구분하면 같은 파일을 여러 사본으로 저장할 수 있다. 쿼리 구분 문서

④ Vary Cache: 버전 번호별 캐시 구분 설정

?ver=2는 파일 내용을 바꾸는 명령이 아니다. 원본에 새 파일이 있어야 한다. 페이지에도 새 버전 주소가 반영되어야 한다. 같은 파일에 숫자만 바꿔 붙여 요청하는 시험으로는 새 내용 전달 여부를 입증할 수 없다.

WAAS가 버전 번호를 구분하지 않으면 Bunny도 예전 파일을 받을 수 있다. 시험할 때는 두 버전 주소로 각각 요청해 WAAS와 Bunny 모두 올바른 파일을 보내는지 확인해야 한다. WAAS의 쿼리별 구분은 아직 검증하지 않았으므로 Bunny 설정만 바꾸면 해결된다고 단정할 수는 없다.

공개 파일의 교체 방식에 맞춰 캐시 보관기간을 정할 것

새 파일을 구분할 수 있어도, 무엇을 캐시할지와 얼마나 오래 보관할지는 따로 정해야 한다. 로그인 정보나 사용자별 응답까지 공개 파일처럼 저장하지 않도록 캐시 대상을 먼저 살펴야 한다. Bunny의 Smart Cache는 확장자와 응답 유형을 보고 정적 파일의 캐시 가능 여부를 판단하는 기능이다. 현재 WordPress 파일용 Zone에서는 이 기능이 켜져 있다. 이 설정은 유지할 계획이다. 규칙을 추가할 때는 공개 파일에만 적용되는지 확인해야 한다. HTML·JSON 등을 무조건 캐시하는 광범위한 규칙도 추가하지 않는다.

개별 규칙에서 보관기간을 강제로 지정하는 Override Cache Time은 Smart Cache의 판단보다 우선할 수 있으므로, 기존 규칙도 함께 살펴야 한다. Smart Cache 설명

⑤ Cache expiration: CDN·브라우저 보관기간 설정

브라우저의 Match server cache expiration은 Bunny가 사용하는 캐시 기간을 브라우저에도 전달한다는 뜻이다. 원본 WordPress 서버의 값을 반드시 그대로 따르는 설정으로 이해하면 안 된다. 이 화면에서는 CDN 기간이 1년으로 지정돼 있으므로 브라우저가 실제 받은 Cache-Control 값도 확인해야 한다.

저장한 사본을 언제까지 재사용할지도 정해야 한다. 이 유효기간을 TTL(time to live)이라고 부른다. Bunny와 방문자의 브라우저는 파일을 따로 저장하므로 보관기간도 각각 확인해야 한다. CDN 캐시를 비워도 방문자의 브라우저에 남은 파일까지 삭제되지는 않는다. TTL이 1년이어도 파일이 모든 전송 거점에 1년 내내 보관된다는 보장은 아니다. 아래 기간은 시험을 시작할 때 사용할 제안값이다. 실제 반영 속도와 요청량을 보고 조정해야 한다.

같은 주소로 덮어쓰기

보관기간 권장안Bunny 3600초 / 브라우저 300초부터 시험

적용 전 확인새 내용 반영 · 요청량 변화

수정할 때 파일명 변경

보관기간 권장안새 주소 구분 확인 후 1년 등 장기 보관 검토

적용 전 확인새 파일 연결 · 표시 · 복구

비공개·인증 필요

보관기간 권장안공개 파일용 정책에서 제외

적용 전 확인접근 권한 · 캐시 제외 여부

같은 주소로 파일을 바꾼다면 현재의 1년 보관보다 짧은 기간부터 시험하는 편이 좋다. 새 파일명을 사용한다면 페이지에서도 그 주소를 불러오는지 확인해야 한다. 문제가 생겼을 때 되돌릴 수 있도록 이전 파일은 남겨 둬야 한다.

⑥ Edge Rules: 특정 파일에 적용할 캐시 규칙 설정

이 제안은 전체 Zone에 바로 적용하지 않고 공개 CSS의 시험 경로에만 적용해 본다. Bunny의 Edge Rules → Add Edge Rule → Override Cache Time에 3600을 입력한다. File Extension 조건에는 점 없이 css를 입력한다. 확장자 조건만 두면 다른 CSS에도 적용될 수 있다. 적용할 파일을 좁히려면 주소의 경로(path)를 조건으로 지정한다. Path 조건에는 시험 경로를 넣는다. 확장자와 경로를 모두 만족하도록 Match All을 선택한다. Match Any는 둘 중 하나만 맞아도 적용돼 범위가 넓어질 수 있다.

브라우저는 별도의 Override Browser Cache Time을 300으로 검토한다. 첫 번째 값은 Bunny가 사본을 재사용할 기간이다. 두 번째 값은 브라우저가 파일을 보관하도록 지정하는 기간이다. 기간 설정

Path 조건은 쿼리 문자열을 비교하는 기능이 아니다. ?ver= 구분은 앞의 Vary Cache에서 다룬다. 여러 규칙이 겹치면 실제 응답 헤더와 내용으로 결과를 확인한다. Path 조건 설명

새 파일과 메뉴·검색 동작을 확인할 것

설정을 바꾼 뒤에는 브라우저가 기대한 주소에서 올바른 파일을 받는지 확인해야 한다. 한영 홈과 대표 글에서 CSS·JS·이미지·폰트의 실제 요청 주소를 확인해야 한다. 응답 코드가 200이어도 원하는 파일인지 확인해야 한다. 파일 내용과 Content-Type에 표시된 파일 유형을 함께 보면 된다. 폰트를 CDN 주소에서 불러오면 페이지와 폰트의 도메인이 달라진다. 이때 브라우저가 폰트 사용을 차단하지 않도록 CORS 허용 설정도 확인해야 한다. HTTPS 오류와 한글·영문·코드 표시도 함께 살핀다. 모바일 브라우저는 작은 크기의 이미지 파일을 선택할 수 있으므로 실제로 표시 중인 이미지 주소도 확인해야 한다.

확인할 때는 PC 브라우저의 개발자 도구에서 Network(네트워크)를 열고 페이지를 다시 불러온다. CSS 파일 하나를 선택해 Headers(헤더)의 Request URL이 기대한 CDN 주소인지, Content-Type이 CSS인지 확인한다. Response(응답)에서는 수정한 선언이 실제로 들어왔는지 본다. 예를 들어 site.c92b.css에 넣은 내용을 이 응답과 대조하는 식이다. HIT 헤더만으로 새 파일이라고 판단하지 않는다.

로그인·검색·앱 인증·캘린더 요청까지 공개 파일용 CDN 주소로 바뀌어서는 안 된다. PC와 모바일에서 메뉴·검색·앱 링크를 직접 열어 봐야 한다. 비로그인 화면과 로그인 화면의 결과는 따로 기록한다.

문제가 생기면 CDN 주소 전환 설정부터 이전 상태로 되돌린다. 그다음 원래 파일을 참조하도록 HTML을 다시 생성한다. 실제 페이지에서도 원래 파일을 불러오는지 확인해야 한다. 기존 HTML이나 브라우저가 CDN 주소를 기억할 수 있으므로 Zone·DNS·이전 파일을 먼저 삭제해서는 안 된다. 글이나 파일을 수정한 뒤 캐시를 갱신하는 순서는 후속 글에서 다룰 예정이다.

운영 적용 전 파일 교체·캐시 갱신·복구를 시험할 것

기존 HTML·파일·미디어 제공 경로는 우선 유지한다. 그 상태에서 수정한 파일이 제때 전달되는지 확인해야 한다. 직접 관리하는 파일은 수정할 때 새 파일명을 사용하는 편이 좋다. ?ver=가 필요한 파일은 Bunny와 WAAS가 버전별로 구분하는지 시험해야 한다. 그 결과를 본 뒤 같은 주소로 교체하는 파일의 CDN·브라우저 보관기간을 조정한다.

제안한 설정은 아직 적용하지 않았다. 운영에 반영하기 전에 파일 교체·캐시 갱신·이전 파일 복구를 시험해야 한다. 변경 전후의 응답시간과 요청량도 비교해야 한다. HIT 여부와 함께 새 내용이 제대로 보이는지, 실제 응답시간이 달라졌는지도 확인해야 한다.

같은 주소의 파일을 바꿨다면 확인할 순서

1. 테스트 파일에 눈으로 구분할 수 있는 변경을 넣고 원본 주소에서 새 내용이 나오는지 확인해야 한다.
2. CDN 주소에서도 같은 내용을 확인해야 한다. 원본은 새 내용인데 CDN만 예전 내용이면 해당 Zone의 캐시와 원본 경로를 살펴야 한다.
3. CDN 응답은 새 내용인데 기존 브라우저만 예전 내용이면 브라우저 캐시를 의심할 수 있다. 개발자 도구에서 캐시를 끈 결과와 일반 방문 결과를 따로 비교해야 한다.
4. 페이지가 예전 파일 주소를 요청한다면 파일 캐시보다 HTML의 연결 주소와 페이지 캐시를 먼저 확인해야 한다.

WAAS의 현재 캐시 규칙을 확인할 것

2026년 11월 9일 OCI 콘솔에서 사이트의 WAAS 정책을 확인했다. 정책은 Active 상태였다. 캐시 규칙은 nv-static-1d 한 개였다. 동작은 Cache, 캐시 기간은 1일로 표시됐다. 미게시 변경 목록은 비어 있었다.

규칙은 URL 끝이 .css, .js, .png, .jpg, .jpeg, .gif, .webp, .svg, .ico, .woff, .woff2인 경우를 나열하고 있다. 예를 들어 Bunny에 CSS 사본이 없어서 사이트 주소로 요청하더라도, WAAS가 보관한 사본을 받을 수 있다. 따라서 Bunny 캐시만 확인해서는 파일이 갱신됐는지 판단하기 어렵다.

Client caching duration 칸은 비어 있었다. 이를 0초나 캐시 사용 안 함으로 해석해서는 안 된다. 브라우저에 전달되는 기간은 실제 응답 헤더와 함께 확인해야 한다. 또한 이 조건 목록만으로 ?ver=가 다른 요청을 각각의 사본으로 구분한다고 판단할 수는 없다. 이번 파일 시험에서도 WAAS의 HIT는 관찰하지 못했으므로, WAAS가 저장한 사본의 버전 구분은 미검증으로 남았다.

실제 파일 응답에서 확인한 내용

2026년 11월 9일, 홈에서 사용 중인 CSS 한 개와 JavaScript 한 개를 사이트 주소와 Bunny 주소로 각각 요청했다. 두 경로 모두 정상 응답(200)이었다. 압축을 푼 파일의 SHA-256 해시도 경로별로 같았다. 해시는 파일 내용이 같은지 대조하는 값이다. 다만 사이트 주소도 WAAS를 거치므로, 이 비교만으로 WordPress 서버에 저장된 원본까지 직접 확인했다고 볼 수는 없다.

Bunny 주소를 다시 요청하자 두 파일 모두 CDN-Cache: MISS에서 HIT로 바뀌었다. 확인한 두 파일을 Bunny가 제공하고 캐시를 재사용하는 동작은 확인됐다. 파일 자체는 수정하지 않았으므로, 교체한 파일이 얼마나 빨리 반영되는지는 아직 알 수 없다.

응답 헤더도 구간을 나눠 읽어야 한다. Bunny 응답에는 CDN-Cache: HIT와 x-cache-status: EXPIRED가 함께 있었다. 뒤의 값만 보고 Bunny 캐시가 만료됐다고 판단해서는 안 된다. 상류 응답의 헤더가 캐시된 사본에 남았을 가능성이 있지만, 이번 조회만으로 그 생성 지점까지 확정하지는 못했다.

브라우저에 전달된 Cache-Control도 확인했다. 사이트 주소는 max-age=31536000, Bunny 주소는 max-age=31919000이었다. 단위는 초다. 화면의 ‘1년’이라는 설정명만으로 실제 응답값을 대신하면 안 된다. 두 값이 달라진 정확한 이유는 추가 확인이 필요하다.

테스트 파일을 바꿔 보니 새 파일명만 새 내용을 받았다

11월 9일, 사이트에서 사용하지 않는 별도 폴더에 작은 CSS 파일을 만들었다. 먼저 v1 내용으로 Bunny의 HIT를 확인했다. 그다음 서버 파일을 v2로 바꿨다. 서버에 저장된 파일의 해시도 다시 읽어 실제 변경을 확인했다. 여기서 v1은 변경 전 내용, v2는 변경 후 내용이다. 기존 사이트 파일과 캐시 설정은 유지했다. 캐시도 비우지 않았다.

• 같은 주소로 덮어쓰기: 사이트 주소에서는 v2가 나왔지만 Bunny 주소에서는 이전 v1이 HIT로 두 번 반환됐다.
• 주소 끝의 버전만 변경: query.css?ver=1을 먼저 받은 뒤 원본을 바꾸고 ?ver=2로 요청했다. 사이트 주소는 v2였지만 Bunny는 v1을 HIT로 두 번 반환했다.
• 새 파일명 사용: new-v2.css에서는 두 경로 모두 v2가 나왔다. Bunny는 첫 요청에서 MISS, 다음 요청에서 HIT였고 내용은 모두 v2였다.

현재 Bunny 설정에서는 쿼리의 버전 숫자만 바꾸는 것으로 새 내용을 받지 못하는 상황을 재현했다. 직접 관리하는 파일은 새 파일명으로 올리는 방법부터 검토하면 된다. 이때 본문의 연결 주소도 바꿔야 한다. 테마·플러그인 파일은 이름을 임의로 바꾸지 말아야 한다. 해당 제품이 지원하는 갱신 방식을 따라야 한다.

이 결과는 이번 테스트 파일과 요청 지점에서 관찰한 내용이다. 사이트 주소의 응답은 계속 X-Cache-Status: MISS였으므로, WAAS에 예전 사본이 저장된 상태의 갱신이나 쿼리 구분까지 입증하지는 못했다.

브라우저도 같은 주소의 예전 파일을 다시 사용했다

Chrome에서 별도 테스트 페이지를 열어 v1 파일을 받았다. 그다음 서버의 파일을 v2로 바꿨다. 같은 주소를 사용하는 다음 페이지로 이동하자 브라우저에는 여전히 v1이 적용됐다. 개발자 도구의 네트워크 기록에서도 디스크 캐시에서 받은 응답임을 확인했다.

다음에는 페이지에서 새 파일명인 browser-v2.css를 요청하도록 했다. 이번에는 디스크 캐시를 사용하지 않았다. 새 파일을 내려받아 v2가 적용됐다. 원본 파일만 바꿔서는 이미 파일을 받은 방문자에게 새 내용이 바로 보이지 않을 수 있다. 직접 관리하는 파일은 새 파일명으로 올린 뒤 페이지의 연결 주소까지 바꿔야 한다.

이번 결과는 Chrome 한 환경에서 확인했다. 개발자 도구에서 캐시를 강제로 끄거나 Bunny 캐시를 비우지는 않았다.

운영 변경 전에 추가로 확인할 항목

• WAAS에 저장된 사본: 이번에는 사이트 주소가 계속 MISS를 반환했다. WAAS가 예전 파일을 보관한 상태에서도 새 버전이 전달되는지 시험해야 한다.
• 실제 페이지와 다른 방문 환경: 운영 HTML에 새 파일 주소가 반영되는지 확인해야 한다. 다른 지역·브라우저·실제 휴대폰에서도 새 내용이 보이는지 확인할 필요가 있다.
• 보관기간과 복구: 캐시 만료 시점, 제안한 기간 변경의 효과, 캐시 갱신과 이전 파일 복구는 아직 시험하지 않았다. 제안값을 운영에 적용하기 전에 별도 시험이 필요하다.