글·이미지·CSS를 바꿨는데 예전 내용이 보일 때: 캐시 갱신 순서

글의 문장만 고쳤다면 HTML 캐시부터 확인해야 한다. 직접 관리하는 이미지나 CSS는 수정할 때 새 파일명을 사용하는 편이 간단하다. 같은 주소를 유지해야 한다면 원본 파일부터 확인해야 한다. 그다음 파일을 가져오는 순서에 맞춰 캐시를 갱신한다.

FlyingPress·WAAS·Bunny·브라우저에는 각각 캐시가 남아 있을 수 있다. 이전 내용이 어느 캐시에서 나오는지 확인하면 불필요한 캐시 삭제를 줄일 수 있다.

무엇을 수정했는지 먼저 구분할 것

글의 문장·제목

우선 할 일저장한 내용과 공개 글 비교

확인할 캐시FlyingPress의 해당 글·관련 페이지

새 파일명으로 올린 이미지

우선 할 일새 파일 확인 후 본문 주소 변경

확인할 캐시HTML 캐시, 새 주소의 CDN 응답

같은 주소로 덮어쓴 이미지

우선 할 일원본·크기별 이미지 확인

확인할 캐시해당 경로의 WAAS·Bunny·브라우저

CSS·JS·폰트

우선 할 일새 파일명·버전 주소 확인

확인할 캐시파일 캐시와 이를 참조하는 HTML

원본 연결과 캐시 보관기간은 Bunny CDN 설정 가이드에서 설명했다. 여기서는 수정한 내용이 독자에게 전달되는 순서를 살펴보고자 한다.

CSS·JS 중 테마나 플러그인이 관리하는 파일은 이름을 직접 바꾸지 말아야 한다. 업데이트 때 연결이 끊길 수 있다. 해당 제품이 지원하는 버전 관리 방식을 먼저 확인해야 한다.

글만 고쳤다면 HTML부터 확인할 것

글을 발행하거나 수정하면 메인페이지의 최신 글 목록도 자동으로 갱신되어야 한다. 관리자가 홈을 따로 편집하거나 매번 캐시를 지우는 방식으로 운영해서는 안 된다.

Data In Hands는 공개 글을 언어와 주제별로 조회해 최신 글 목록을 만든다. 글 저장·발행·공개 상태 변경과 카테고리·언어 변경 시 목록 캐시를 무효화한다. 이어서 한국어 홈과 영문 홈의 FlyingPress 캐시 갱신을 요청한다. 따라서 새 글을 홈에 넣기 위해 목록을 수동으로 고칠 필요는 없다.

2026년 11월 9일에는 한영 검증용 글로 즉시 발행·제목 수정·예약 발행을 시험했다. 세 경우 모두 수동 캐시 갱신 없이 해당 언어의 공개 홈에 반영됐다. 예약 시각 전에는 목록에 나타나지 않았다. 시험 후 글을 초안으로 돌리자 홈에서도 자동으로 사라졌다. 고정 대표 글은 최신 글 목록과 별도로 유지된다. 최근 글은 발행일과 분류 조건에 따라 선택되므로, 예전 글을 수정했다고 항상 목록 맨 위로 올라오는 것은 아니다.

일반적인 FlyingPress 자동 갱신 범위에는 수정한 글과 관련 홈·목록이 포함된다. 별도로 만든 홈은 해당 주소가 자동 갱신 대상에 연결되어 있어야 한다. FlyingPress 자동 갱신 설명

저장한 문장이 보이지 않으면 비로그인 상태에서도 같은지 확인해야 한다. FlyingPress에 대기 중이거나 실패한 작업이 있는지도 살펴봐야 한다. 자동 갱신이 실패했다면 먼저 실패 원인을 고쳐야 한다. 장애 복구를 위해 캐시를 수동으로 갱신할 때는 수정한 페이지와 관련 목록으로 범위를 제한한다. 전체 사이트 캐시 비우기는 범위를 넓혀야 할 이유가 있을 때 선택한다. 글의 문장만 바뀌었는데 Bunny의 이미지 캐시를 모두 지울 필요는 없다.

FlyingPress 문서의 Purge & Preload Cache는 기존 페이지 캐시 전체를 지운 뒤 다시 만드는 동작이다. 단순 Preload는 기존 캐시를 먼저 지우지 않는다. 글 하나를 고쳤다고 전체 재생성을 기본 절차로 삼아서는 안 된다. 두 동작의 차이

이미지를 수정했다면 새 파일명으로 올릴 것

워드프레스의 이미지 블록에서 교체하면 HTML을 직접 고칠 필요가 없다. 다음 순서로 새 이미지를 선택하면 된다.

1. 새 파일명으로 준비할 것. 예를 들어 기존 diagram-v1.png 대신 diagram-v2.png를 준비한다.
2. 이미지 블록에서 교체할 것. 새 파일을 업로드하거나 미디어 라이브러리에서 선택한다.
3. 설명과 링크를 확인할 것. ALT·캡션을 새 이미지에 맞춘다. ‘원본 보기’ 링크도 새 파일을 여는지 확인한다.
4. 저장 후 PC·모바일에서 확인할 것. 편집 화면뿐 아니라 비로그인 공개 페이지에도 새 이미지가 보이는지 확인해야 한다.

WordPress 미디어 라이브러리에 새 이미지를 업로드하면 설정된 크기에 맞춰 작은 이미지와 썸네일이 만들어진다. 원본보다 큰 크기까지 모두 만드는 것은 아니다. 생성되는 크기는 사이트 설정과 테마 등에 따라 달라진다. 보통은 썸네일을 직접 만들거나 주소를 하나씩 입력할 필요가 없다. 이미지 블록의 교체 기능 · 크기별 이미지 생성 설명

새 이미지가 연결된 페이지를 받으면 브라우저는 새 파일 주소를 요청한다. 예전 이미지가 브라우저 캐시에 남아 있어도 주소가 다르므로 그 사본을 대신 보여주지 않는다. 저장 후에도 예전 이미지가 보인다면, 먼저 공개 페이지의 HTML 캐시가 갱신됐는지 확인해야 한다.

Object Storage에 파일을 직접 올리거나 공개 URL만 본문에 넣는 경우는 다르다. 이 작업만으로 WordPress의 썸네일 생성이 실행되지는 않는다. 오프로드 플러그인을 쓴다면 원본뿐 아니라 크기별 파일도 저장소로 옮겨지는지 확인해야 한다.

원본 파일만 덮어쓴 경우는 별도로 확인할 것

서버에서 원본 파일만 덮어써도 기존 썸네일이 자동으로 바뀌지는 않을 수 있다. 작은 크기의 파일은 별도로 확인해야 한다. 이때는 PC에서는 새 이미지가 보이는데 모바일에서는 예전 이미지가 보이는 문제가 생길 수 있다.

이런 문제가 있거나 직접 HTML로 이미지를 연결했다면, 개발자 도구에서 실제 표시 중인 이미지 주소(currentSrc)를 확인해야 한다. 화면 크기별 후보는 srcset에 들어 있다. 이미지 최적화 기능을 사용한다면 WebP·AVIF 파일도 새 내용으로 만들어졌는지 확인해야 한다.

Object Storage의 이미지를 같은 주소로 덮어썼다면, 그 파일을 제공하는 미디어용 Bunny Zone의 캐시를 갱신해야 한다. WordPress 서버 파일용 Zone만 비워서는 미디어용 Zone에 남은 예전 이미지가 지워지지 않는다.

새 이미지가 정상적으로 보이더라도 기존 파일은 바로 삭제하지 말아야 한다. 캐시에 남은 페이지가 기존 이미지를 불러올 수 있기 때문이다. 문제가 생겼을 때 되돌리는 데도 이전 파일이 필요하다.

같은 주소로 교체했다면 원본부터 확인할 것

확인·갱신 작업 순서
방문자의 요청·응답 경로가 아니다.

1. 원본 파일새 내용 확인
2. →
3. WAAS 캐시WAAS에 저장된 경우
4. →
5. Bunny 캐시이전 파일 캐시 삭제
6. →
7. HTML·화면 확인이미지 주소·새 내용 확인

예를 들어 WordPress 서버에 있는 공개 CSS를 같은 주소로 교체했다면 다음 순서로 확인해야 한다. 번호는 캐시를 무조건 모두 지우라는 뜻이 아니다. 그 파일을 보관하는 캐시만 골라 갱신하면 된다.

1. 원본 파일에 수정한 내용이 저장되어 있는지 확인해야 한다. 사이트 도메인 응답도 WAAS를 지날 수 있으므로 그 응답만으로 원 서버 파일까지 바뀌었다고 판단해서는 안 된다. 서버에서 원본 파일의 내용이나 변경 기록을 확인해야 한다.
2. 그 파일을 WAAS가 캐시한다면 해당 캐시의 갱신부터 처리해야 한다. 원본 파일이 아직 바뀌지 않았거나 WAAS에 예전 사본이 남은 상태에서 Bunny만 비우면 Bunny가 이전 파일을 다시 가져올 수 있다.
3. 실제 파일을 제공하는 Bunny Zone에서 필요한 URL 또는 미리 구성한 태그의 캐시를 비워야 한다. 캐시 비우기(purge)는 저장된 사본을 무효화하는 작업이다. 파일 교체 자체가 아니다.
4. 파일 참조나 이미지 정보도 바뀌었다면 FlyingPress의 관련 HTML 캐시를 갱신해야 한다. 파일 내용만 바뀌고 HTML은 같다면 HTML까지 바꿀 필요가 있는지 먼저 판단한다.
5. 공개 페이지를 열어 브라우저가 실제 받은 파일을 확인해야 한다. 새 주소를 쓰지 못한 경우에는 방문자 브라우저의 보관기간이 남아 있을 수 있다.

이 순서는 Bunny가 WordPress 파일을 가져올 때 사이트 도메인과 WAAS를 거치는 구성에 해당한다. Object Storage용 Zone의 MISS는 사이트 WAAS를 거치지 않으므로 2번의 WAAS 갱신은 필요하지 않다. 원본 확인을 위해 비공개 파일을 공개하거나 인증을 우회해서는 안 된다.

파일을 제공하는 Bunny Zone과 갱신 방법을 확인할 것

Bunny 대시보드에서는 Zone 전체 또는 같은 태그가 붙은 파일들의 캐시를 비울 수 있다. 파일 하나의 주소를 지정해서 비우려면 URL purge API를 사용해야 한다. 태그별로 비우려면 미리 응답에 CDN-Tag를 지정해 두어야 한다. 예를 들어 같은 글의 이미지에 동일한 태그를 붙여 두면 묶어서 갱신할 수 있다. 태그를 지정하지 않았다면 이 방법을 바로 사용할 수는 없다.

URL purge API에는 원본 서버 주소가 아니라 독자의 브라우저가 요청하는 CDN 파일 주소를 지정해야 한다. Zone의 Vary 설정에 따라 URL별 purge가 지원되는지도 확인해야 한다. API 키는 서버의 보호된 설정에 보관하고 브라우저·본문·캡처에 노출해서는 안 된다.

태그나 자동화가 준비되지 않아 전체 Zone을 비워야 한다면 영향 범위를 확인한 뒤 실행해야 한다. 슬래시로 끝나는 경로·와일드카드는 더 많은 파일을 포함할 수 있다. Zone 전체를 비우면 원본 서버의 요청량이 일시적으로 늘 수 있다. Perma-Cache를 사용한다면 태그별 purge가 지원되지 않는 점도 확인해야 한다. Bunny purge 문서

Bunny는 원본 파일이 바뀌었는지 자동으로 감시하지 않는다. FlyingPress에서 파일 주소를 CDN 주소로 바꾸도록 설정했더라도, Bunny 캐시 삭제까지 자동으로 처리된다고 가정해서는 안 된다. 현재 구성에서 이 자동 연동은 확인하지 못했다. FlyingCDN 전용 연동과 일반 Bunny 연동은 구분해서 확인해야 한다. 자동화를 만들려면 변경된 파일 주소·대상 Zone·처리 결과·실패 재시도부터 별도 검증해야 한다.

방문자 브라우저에 남은 캐시도 고려할 것

방문자 브라우저가 아직 유효한 파일을 갖고 있으면 서버에 요청하지 않고 그 파일을 쓸 수 있다. Bunny에서 비웠다고 이미 방문한 사람의 브라우저 사본까지 회수되는 것은 아니다. 따라서 같은 주소로 자주 교체하는 파일은 브라우저 보관기간을 너무 길게 잡지 않는 편이 좋다. 즉시 반영해야 할 변경이라면 새 파일 주소를 사용하는 편이 낫다. 브라우저 캐시 설명

강력 새로고침이나 개발자 도구의 Disable cache는 내 브라우저를 확인하는 방법이다. 모든 방문자에게 수정이 반영됐다는 증거가 아니다. ?ver=를 바꾸는 방법도 Bunny와 WAAS가 그 값을 구분할 때만 기대한 동작을 한다. 2026년 11월 9일 확인에서도 사이트 파일용 Bunny Zone의 URL Query String은 미선택 상태였다. WAAS가 쿼리별로 사본을 구분하는지는 추가 시험이 필요하다.

별도 CSS 시험에서는 새 파일명으로 바꿨을 때 새 내용이 전달됐다

11월 9일 시험에서는 사이트에서 사용하지 않는 CSS 파일을 교체했다. 같은 주소로 덮어쓰자 Bunny는 이전 내용을 반환했다. 주소의 버전 번호만 바꾼 경우에도 결과는 같았다. 새 파일명으로 요청했을 때는 새 내용을 받았다.

Chrome에서도 같은 주소의 예전 파일을 디스크 캐시에서 다시 사용했다. 새 파일명을 요청하자 새 내용이 적용됐다. 이 결과는 해당 테스트 파일과 한 브라우저 환경에서 확인한 것이다. WAAS의 HIT 응답은 관찰하지 못했으므로, WAAS에 예전 파일이 남아 있을 때의 갱신은 별도 시험이 필요하다.

변경 반영 여부는 실제 받은 내용으로 확인할 것

새 내용과 실제 요청 주소를 함께 확인해야 한다. HIT는 캐시에 사본이 있다는 뜻일 뿐 최신 파일이라는 증거가 아니다. 캐시를 비운 직후에는 저장된 사본이 없으므로 MISS가 나고 원본을 다시 받을 수 있다.

수정한 문장·제목

정상 판단 기준비로그인 화면에 새 내용 표시

결과가 다를 때 볼 곳WordPress 저장·FlyingPress 작업과 관련 홈

이미지·원본 열기

정상 판단 기준이미지·원본 링크 모두 새 파일

결과가 다를 때 볼 곳srcset·currentSrc·다른 미디어 Zone

CSS·JS·폰트

정상 판단 기준받은 파일에 수정 내용 포함

결과가 다를 때 볼 곳원본·WAAS·Bunny·브라우저

화면

정상 판단 기준한영 PC·모바일 표시 정상

결과가 다를 때 볼 곳파일 주소·캐시·CORS 오류

확인할 때는 독자가 평소 접속하는 주소를 그대로 사용해야 한다. 무작위 쿼리를 붙이면 평소와 다른 캐시 사본을 받을 수 있다. 반대로 쿼리를 무시하는 캐시에서는 같은 사본을 받는다. 로그인 여부·브라우저 캐시 사용 여부·확인 시각을 남겨 서로 다른 조건의 결과를 혼동하지 않도록 해야 한다.

PC 브라우저에서는 개발자 도구를 열고 Network(네트워크) 목록에서 확인할 CSS를 선택한다. Headers(헤더)의 Request URL이 기대한 파일 주소인지 확인한다. Response(응답)에서는 수정한 선언을 찾는다. 예를 들어 새 CSS에 넣은 --brand-color: #245640이 보이는지 확인하는 식이다.

이미지라면 Elements(요소)에서 해당 이미지의 src·srcset과 실제 선택 주소 currentSrc를 대조한다. PC에서 화면 너비를 모바일 크기로 줄여도 실제 휴대폰에 저장된 캐시까지 확인할 수는 없다. 휴대폰에서도 직접 열어 봐야 한다.

파일 내용이 같은지 더 정확히 확인해야 한다면 해시값을 비교할 수 있다. 해시값은 파일 내용으로 계산한 값이며, 내용이 달라졌는지 비교할 때 사용한다. 압축 여부가 다른 전송 데이터끼리 비교하지 않고 같은 방식으로 디코딩한 내용끼리 비교해야 한다.

문제가 생겼다면 이전 파일부터 복구할 것

복구할 때는 이전 페이지에서 불러올 파일부터 다시 준비해야 한다. 같은 주소의 파일을 복원했다면 그 경로의 WAAS·Bunny 사본도 갱신해야 할 수 있다. 그다음 본문과 파일 주소를 이전 상태로 되돌린다. 관련 HTML 캐시도 다시 만들어야 한다. 파일 준비 전에 HTML부터 되돌리면 없는 파일을 가리킬 수 있다.

복구 후에는 한영 페이지를 PC와 모바일에서 열어 이미지·원본 보기·링크가 정상인지 확인해야 한다. 변경 전 설정과 파일, 작업 기록은 이 확인이 끝날 때까지 보관해야 한다. 캐시를 비웠다는 성공 메시지만으로 화면까지 복구됐다고 판단해서는 안 된다.

별도 CSS 파일의 교체 동작은 확인했다. 다만 캐시 삭제부터 복구까지 이어지는 전체 절차는 아직 시험하지 않았다. 모든 방문자에게 반영되는 시간도 측정하지 않았다.