Data In Hands의 글을 열면 HTML과 이미지·폰트를 서로 다른 경로로 받는다. 글의 구조와 내용을 담은 HTML은 WordPress 서버가 제공한다. CSS·JavaScript·이미지·폰트는 주로 Bunny CDN이 전달한다. OCI Object Storage에 보관한 미디어는 별도의 Bunny CDN 연결을 통해 제공한다.
화면이 늦게 뜨거나 수정한 이미지가 보이지 않는다면, 먼저 문제가 된 요청의 주소를 확인해야 한다. HTML과 파일을 제공하는 곳이 다르기 때문이다. 이 글에서는 Data In Hands의 구성을 따라 각 서비스의 역할을 살펴보고자 한다. 요청 주소를 확인한 뒤 어느 캐시를 점검해야 하는지도 정리했다.
요청 경로는 2026년 10월 24일 확인 기록을 바탕으로 설명한다. WAAS 설정은 11월 9일 확인한 기록을 함께 반영했다. 각 설정과 응답은 당시 확인한 결과다. 같은 구성을 적용하더라도 실제 응답은 따로 확인해야 한다.
원본 글이 있는데, 왜 HTML을 따로 저장할까?
WordPress에 저장된 글과 독자에게 보내는 완성된 페이지는 다르다. 글의 본문·제목 같은 내용은 보통 데이터베이스(DB)에 들어 있다. WordPress는 페이지를 만들 때 DB에서 글 내용을 조회한다. 테마와 플러그인은 메뉴와 본문 등을 조합해 HTML을 만든다. 브라우저는 이 HTML을 받아 화면을 표시한다.
캐시를 사용하지 않으면 방문 요청을 처리하면서 HTML을 만들어야 한다. 같은 글을 여러 사람이 열 때도 이 작업이 반복될 수 있다.
같은 서버에 저장하는데, 왜 더 빠를까?
이미 만들어 둔 HTML을 보내면 페이지를 다시 만드는 작업을 줄일 수 있기 때문이다. FlyingPress의 페이지 캐시(page cache)는 완성된 HTML을 파일로 저장해 두었다가 재사용한다.
여기서는 여러 방문자에게 같은 내용을 보여주는 공개 페이지를 기준으로 설명한다. 로그인 상태나 사용자별 정보가 담긴 페이지는 HTML을 공용 캐시로 재사용해도 되는지 별도로 확인해야 한다.
| 응답 전 작업 | HTML 캐시 없음 | 사용 가능한 캐시 있음 |
|---|---|---|
| 본문·설정 조회 | 수행 | 상당 부분 생략 |
| 페이지 HTML 생성 | 수행 | 저장본 재사용 |
| HTML 전송 | 새로 만든 결과 | 저장한 파일 |
완성된 HTML을 재사용하면 응답 전에 처리할 일이 줄어든다. 다만 캐시를 제공하는 방식에 따라 일부 처리는 남는다. 서버 응답이 이미 빠른 사이트라면 체감 차이는 작을 수 있다. 도입 효과는 캐시 적용 전후의 응답시간을 비교해 판단해야 한다.
HTML 응답이 빨라졌다면 다음으로 이미지·CSS·JavaScript의 로딩 시간을 확인해야 한다. 브라우저가 화면을 완성하려면 이미지·CSS·JavaScript도 받아 처리해야 한다. HTML 캐시가 있어도 큰 이미지나 무거운 스크립트 때문에 화면이 늦게 뜰 수 있다.
HTML과 이미지·폰트의 요청 주소부터 구분할 것
브라우저가 글을 열면 먼저 HTML 문서를 받는다. 그 안에서 화면에 필요한 파일 주소를 찾아 CSS·JavaScript(JS)·이미지·폰트도 요청한다. 하나의 페이지가 보여도, 각 요청을 처리하는 곳은 다를 수 있다.
여기서 원 서버(origin server)는 WordPress와 원본 파일이 있는 서버를 뜻한다. CDN은 방문자와 가까운 여러 거점에서 파일 사본을 제공하는 서비스다. 이 사이트에서는 Bunny가 그 역할을 맡고 있다.
| 요청하는 것 | 브라우저가 사용하는 주소 | 요청을 먼저 받는 서비스 |
|---|---|---|
| 글·홈 HTML | datainhands.com | OCI WAAS |
| 공개 정적 파일 | cdn.datainhands.com | Bunny CDN |
| 별도 보관 미디어 | datainhandsoci.b-cdn.net | Bunny CDN |
예를 들어 cdn.datainhands.com은 Bunny CDN에 연결한 파일용 주소다. 브라우저가 이 주소로 파일을 요청하면 Bunny가 응답한다.
HTML은 WordPress 서버의 페이지 캐시로 제공
OCI WAAS는 사이트 앞에서 요청을 검사하고 전달하는 보안 서비스다. 글 주소로 들어온 요청은 이 서비스를 거쳐 원 서버로 전달된다. 당시 HTML 응답에서는 WAAS가 페이지를 캐시하지 않았다. 원 서버가 FlyingPress로 만들어 둔 HTML을 제공했다.
요청에 응답할 수 있는 캐시 사본이 있으면 캐시 적중(cache hit, HIT), 없다면 캐시 미적중(cache miss, MISS)이라고 한다. HIT일 때는 요청마다 WordPress와 데이터베이스(DB)가 같은 HTML을 다시 만들 필요가 줄어든다.
FlyingPress 공식 문서에 따르면 최종 HTML 캐시는 원 서버의 wp-content/cache/flying-press/ 아래에 저장된다. 사용할 캐시가 없는 요청에는 우선 최적화되지 않은 페이지를 제공한다. 그 URL은 최적화 대기열에 들어간다. 따라서 캐시가 없는 첫 응답과 최적화를 마친 뒤의 응답은 구분해서 확인해야 한다. FlyingPress 캐시 생성·저장 설명
FlyingPress 클라우드는 페이지 분석·최적화를 담당
FlyingPress 클라우드는 페이지 분석을 맡는다. 최적화한 HTML은 WordPress 서버에 저장된다. FlyingPress는 HTML 저장뿐 아니라 파일을 불러오는 방식도 최적화한다. 이를 위해 클라우드에서 페이지를 브라우저로 열어 분석한다. 처음 화면에 필요한 이미지·폰트나 사용하지 않는 CSS 등을 파악하는 작업이다.
페이지를 준비할 때와 독자가 방문했을 때의 흐름은 다음과 같다.
저장된 HTML을 사용할 수 있으면 원 서버가 바로 제공한다. 독자는 클라우드 분석이 다시 끝나기를 기다릴 필요가 없다. FlyingPress 클라우드 분석 설명
HTML 캐시가 있는데, Bunny CDN은 왜 필요할까?
HTML 캐시는 페이지 생성 작업을 줄인다. 이 구성에서 Bunny CDN은 이미지·CSS 같은 파일 전달을 맡는다. CDN 도입 여부는 파일 전송에 걸리는 시간을 측정한 뒤 결정하는 것이 좋다. 특히 주요 방문자와 원 서버가 멀리 떨어져 있다면 파일 전달 구간을 확인해야 한다.
브라우저가 HTML을 받아도 화면을 완성하려면 CSS·이미지·폰트 등의 파일이 더 필요하다. cdn.datainhands.com 주소의 정적 파일(static files)은 브라우저가 Bunny CDN에 요청한다. Bunny에 사용할 수 있는 사본이 있으면 원 서버까지 가지 않고 응답한다.
사본이 없으면 Bunny가 원본을 가져와야 한다. 이를 위해 설정하는 원본 주소(Origin URL)가 이 사이트에서는 https://datainhands.com이었다. 따라서 Bunny가 원본 파일을 가져올 때도 WAAS를 거친다.
WAAS에 해당 파일을 제공할 수 있는 캐시가 있으면 거기서 응답한다. 그렇지 않으면 원 서버에서 파일을 받는다. WAAS는 캐시 규칙에 맞는 요청을 선택적으로 저장한다. 11월 9일 확인한 규칙은 CSS·이미지·폰트 등의 확장자를 대상으로 했고, 보관 기간은 1일이었다. 실제로 캐시를 사용했는지는 해당 요청의 응답 헤더에서 확인해야 한다. Oracle WAAS 캐시 규칙
회색 상자는 해당 요청이 도달하지 않은 곳이다. 초록은 요청, 파랑은 브라우저로 돌아오는 응답이다.
Object Storage 미디어는 별도 CDN 경로로 제공
일부 미디어는 WordPress 서버 대신 OCI Object Storage에 보관하고 있다. 파일을 서버 밖으로 옮겨 보관하는 것을 미디어 오프로드(media offloading)라고 한다. 이 파일들도 방문자에게는 Bunny CDN으로 전달한다.
이 미디어를 요청할 주소는 datainhandsoci.b-cdn.net이다. Bunny에서는 원본 주소와 캐시 설정을 묶어 관리하는 단위를 Pull Zone이라고 한다. 이 미디어용 Zone에는 Object Storage가 원본으로 지정되어 있다. Bunny에 사본이 없으면 Object Storage에서 파일을 가져온다. 이 원본 연결은 사이트의 WAAS와 WordPress 서버를 거치지 않는다.
같은 이미지라도 원 서버에 남아 있는 파일과 Object Storage로 옮긴 파일은 경로가 다르다. 어느 경로인지 알아보려면 이미지의 요청 주소부터 확인해야 한다.
원본과 캐시 사본의 저장 위치
| 보관 위치 | 보관하는 것 |
|---|---|
| 방문자의 브라우저 | 캐시 정책에 따른 파일 사본 |
| Bunny 거점 | CDN으로 전달한 파일 사본 |
| WAAS 거점 | 규칙에 맞는 응답 사본 |
| 원 서버 디스크 | FlyingPress HTML 캐시·원본 파일 |
| Object Storage | 옮겨 보관한 미디어 원본 |
브라우저에 아직 유효한 사본이 있으면 서버에 다시 요청하지 않고 그 파일을 보여줄 수 있다. Object Storage에는 미디어 원본이 있다. Bunny에는 전달용 사본이 저장될 수 있다. 캐시 갱신이 목적이라면 CDN에 저장된 사본을 비워야 한다. Object Storage의 원본 파일을 삭제해서는 안 된다. MDN의 HTTP 캐시 설명
문제가 생기면 요청 주소와 실제 응답부터 확인할 것
페이지가 느리거나 수정 내용이 보이지 않을 때는 문제가 된 요청 하나부터 확인해야 한다. 그 요청을 어느 서비스가 처리했는지 알아야 갱신할 캐시를 정할 수 있다. Chrome이나 Edge에서 개발자 도구를 열고 Network 탭을 선택한 뒤 페이지를 새로고침한다.
- 문제가 되는 요청을 찾을 것. HTML은 Document, 그림은 Img, 스타일은 CSS에서 찾을 수 있다.
- Headers에서 Request URL을 확인할 것. 사이트 주소인지, 일반 파일용 CDN인지, 미디어용 CDN인지 구분한다.
- 응답 헤더와 파일 내용을 함께 확인할 것. 먼저 응답 헤더에서 캐시 상태를 확인한다. 이어서 응답 내용에 수정한 문장이나 이미지가 들어 있는지 확인한다.
앞서 수집한 HTML 응답에는 x-flying-press-cache: HIT와 x-flying-press-source: Web Server가 있었다. FlyingPress가 준비한 캐시를 웹 서버가 제공했다는 뜻이다. 같은 응답의 WAAS 상태는 x-cache-status: NOTCACHED였다. WAAS가 저장한 페이지는 아니지만 원 서버에는 저장된 HTML이 있었으므로 두 값이 함께 나올 수 있다.
Bunny 주소의 응답에서는 Bunny의 CDN-Cache도 따로 봐야 한다. Bunny가 원 서버의 파일을 저장할 때 응답 헤더도 함께 저장했다가 전달할 수 있기 때문이다. HIT가 표시돼도 수정한 내용이 보이지 않으면 예전 사본이 남아 있는지 점검해야 한다. 속도 개선 효과는 응답시간을 따로 측정해 판단해야 한다.
Network에 항목이 있다고 모두 서버에서 새로 내려받은 것도 아니다. 브라우저 캐시에서 제공했는지 표시를 확인해야 한다. 개발자 도구의 Disable cache는 브라우저 캐시를 비교할 때 쓰는 옵션이다. Bunny나 WAAS 캐시를 비우지는 않는다.
글 수정 후 HTML 캐시와 목록 갱신도 확인할 것
DB의 글을 수정했더라도 예전 HTML 캐시가 계속 제공되면 독자에게는 수정 전 내용이 보인다. 글을 수정할 때 관련 HTML 캐시도 함께 갱신되어야 하는 이유다. FlyingPress는 글이 바뀌면 홈·카테고리 등 관련 URL의 캐시도 자동으로 갱신하도록 동작한다. 글을 수정한 뒤에는 홈과 카테고리 목록에도 변경 내용이 반영됐는지 확인해야 한다. 플러그인이 별도로 만든 목록도 점검 대상이다. 매번 수동으로 캐시를 지워야 반영된다면 자동 갱신이 빠진 원인을 찾아 수정해야 한다.
이미지를 같은 주소로 덮어썼다면 HTML과는 별도로 Bunny·WAAS·브라우저에 파일 사본이 남을 수 있다. 갱신 순서는 3편: 글·이미지·CSS 변경 후 캐시 갱신에서 확인할 수 있다.
HTML과 파일 중 문제가 생긴 쪽부터 점검할 것
문장 수정이 보이지 않는다면 HTML 캐시부터 확인해야 한다. 이미지 하나만 예전 모습이라면 그 이미지의 요청 주소부터 확인해야 한다. 이미지가 Object Storage에서 제공된다면 미디어용 Bunny Zone을 확인해야 한다. WordPress 서버의 캐시만 지워서는 그 Zone에 남은 사본이 갱신되지 않는다.
Bunny를 사용한다는 이유로 WAAS 캐시를 바로 꺼서는 안 된다. 당시에는 본 도메인으로 요청되는 파일이 남아 있었고, 실제 WAAS HIT 표본도 확인됐다. WAAS 캐시를 끄거나 규칙을 바꾸려면 어떤 파일에 영향을 주는지와 응답시간이 어떻게 달라지는지 먼저 확인해야 한다.
원본 연결을 설정할 때는 2편: Bunny CDN 설정 가이드의 실제 설정 화면을 따라 확인하면 된다. 파일을 저장한 위치에 맞는 Pull Zone을 선택하는 과정부터 설명했다.
HTML 캐시를 처음 검토한다면 페이지 캐시가 필요한 경우와 확인 방법을, 성능 측정부터 시작하려면 CDN 도입 전 병목 찾기를 먼저 읽어보는 것이 좋다.
