느린 워드프레스 홈을 조사하며: OCI WAAS 캐시 적용과 요청 경로 확인

내 블로그의 랜딩 페이지가 느리게 열리는 것이 문제였다. 관리자 화면에서 메뉴를 누를 때 반응이 늦는 현상도 있었지만, 개선하려던 대상은 방문자가 처음 접하는 공개 페이지였다.

느린 블로그를 개선하려면 파일이 어느 경로로 전달되고, 어느 캐시가 실제로 응답하는지부터 확인해야 했다. WAAS 캐시를 추가한 뒤 일부 정적 파일의 응답은 빨라졌지만, 그 기록만으로 랜딩 페이지 전체가 빨라졌다고 결론 내릴 수는 없었다.

먼저 확인한 결과: 일부 파일의 응답은 빨라졌다

파일 전달을 맡는 CDN 서비스인 Bunny가 저장된 파일을 바로 제공하면 WAAS까지 요청하지 않는다는 점도 확인했다. 그래서 아래 수치는 WAAS를 거친 당시의 파일 요청과 관리자 화면 측정으로 범위를 나눠 읽어야 한다.

같은 PC에서 정적 파일을 적용 전 8회, 적용 후 10회 요청했다. 브라우저 가로 너비를 1920px로 두고 관리자 미디어 화면을 적용 전후 각 3회 열었다. 아래는 당시 기록을 크기순으로 놓았을 때 가운데에 해당하는 값, 즉 중앙값(median)이다. TTFB(Time to First Byte)는 요청을 보낸 뒤 첫 데이터를 받기까지 걸린 시간이다. HIT는 캐시에 저장된 응답을 사용했다는 표시이고, NOTCACHED는 캐시로 제공하지 않았다는 표시다. 이번 CDN 경로 확인 과정에서 성능을 다시 측정한 결과는 아니다.

DOMContentLoaded는 브라우저가 HTML을 읽고 페이지의 기본 구조를 만든 시점이다. 이미지 등 모든 파일을 다 받았거나 화면 조작 준비까지 끝났다는 뜻은 아니다. load는 페이지와 이미지·스타일 등 관련 파일의 로딩이 끝났을 때 발생하는 이벤트다. 나중에 필요할 때 불러오도록 한 파일은 제외된다. 이것도 버튼을 눌렀을 때의 반응 속도를 재는 값은 아니다. 이 수치로 사이트 전체가 두 배 빨라졌다고 말할 수는 없다. MDN DOMContentLoaded, MDN load

같은 시간대에 OttoKit도 비활성화했다. 서버에서 명령줄로 WordPress가 실행 준비를 마치는 데 걸린 시간은 2.46초에서 2.00초로 줄었다. 하지만 웹 서버의 응답 시간에서는 뚜렷한 차이를 확인하지 못했다. 플러그인 비활성화와 캐시 변경이 같은 시기에 이뤄졌으므로 관리자 화면 수치가 좋아진 이유를 WAAS 하나로 설명할 수는 없다. 이 글에는 요청별 상세 측정값 대신 당시의 요약 기록을 남겼다.

글을 정리하며 다시 보낸 공개 요청에서는 HIT와 MISS가 섞였다. 처음의 9/10은 당시 10회 요청에서 나온 결과다. 이후에도 같은 비율로 캐시가 사용된다는 뜻은 아니다. 또 Bunny 응답에 있는 x-cache-status는 원본 서버에서 받은 표시를 그대로 전달한 것일 수 있다. Bunny 자체의 캐시 사용 여부를 나타내는 CDN-Cache와 혼동하면 안 된다.

내부 요청 약 0.015초와 공개 요청 약 0.26초의 차이도 모두 WAAS 처리 시간으로 볼 수 없다. 요청과 응답이 인터넷을 오가는 시간, 서버에 연결하는 시간, HTTPS 암호화 연결을 맺는 과정(TLS) 등이 함께 포함돼 있기 때문이다. 이 차이는 어디를 더 살펴볼지 정하는 단서로만 사용했다.

먼저 정적 파일에 WAAS 캐시를 적용했다

먼저 CSS·이미지·폰트처럼 파일로 저장해 제공하는 정적 파일(static files)을 살펴봤다. 같은 파일을 WordPress가 설치된 원 서버(origin server) 안에서 직접 요청할 때와 인터넷의 공개 주소로 요청할 때를 비교했다. 이후 원 서버 앞에서 방화벽·중계 역할을 하는 OCI WAAS에 정적 파일을 저장해 두고 재사용하는 캐시(cache) 규칙을 추가했다. 앞의 표에 적은 정적 파일 TTFB는 이 적용 당시 기록이다.

초기 작업에서는 nv-static-1d라는 정적 파일 규칙을 추가했다. 원 서버는 Cache-Control: max-age=31536000, public이라는 헤더를 보냈다. 여러 사용자의 요청에 재사용하는 공유 캐시(shared cache)가 저장할 수 있고, 응답의 나이가 31536000초 이내면 원본에 다시 확인하지 않고 사용할 수 있다는 안내다. 그래도 WAAS가 실제로 파일을 저장해 다시 제공하는지는 별도로 확인해야 했다.

Client caching은 이 WAAS 규칙이 브라우저의 캐시 보관 안내를 바꿀지 정하는 옵션이다. OFF라고 해서 브라우저 캐시 자체가 꺼지는 것은 아니다. 원 서버가 이미 보내는 캐시 헤더는 별개다. Oracle CachingRule 옵션

규칙의 세부 조건과 적용 당시 캡처 보기

사용한 조건은 ‘이 중 하나라도 맞으면 적용’하는 OR 방식이다. ‘지정한 경로에 있고, 확장자도 맞아야 적용’하는 AND 방식으로 좁히지 못해 확장자를 기준으로 정했다. 그래서 /wp-admin/ 안에 있는 공개 CSS·JS도 적용 대상에 포함된다.

일반적인 HTML·로그인·REST API·admin-ajax 주소는 이 확장자 조건에 맞지 않는다. REST API와 admin-ajax는 화면이나 기능에서 데이터를 주고받을 때 쓰는 주소다. 다만 이 주소들을 캐시에서 무조건 제외하는 별도 규칙(BYPASS)을 만든 것은 아니다. 내용이 요청마다 달라지는 응답을 .css나 .js처럼 정적 파일 확장자가 붙은 주소로 제공하는 경우가 없는지도 확인해야 한다. Oracle 문서는 위에서부터 처음 일치하는 규칙을 사용한다고 설명하므로, 예외 규칙을 어디에 놓는지도 중요하다. Oracle Caching Rules

규칙 게시 시각은 2026년 10월 24일 13시 58분 KST, 효과를 확인한 시각은 14시 42분이었다. 내 요청에서 약 44분 뒤 변화를 관찰했다. 모든 지역의 엣지 서버에 규칙이 반영된 시각까지 확인한 것은 아니다.

이미 쓰던 CDN과 캐시의 역할을 다시 확인했다

내 사이트는 이미 CDN 서비스인 Bunny를 사용하고 있었다. CDN(Content Delivery Network)은 여러 지역의 서버에서 파일을 전달하는 콘텐츠 전송 네트워크다. WAAS 캐시가 도움을 줄 수 있는 구간을 파악하려고 Bunny의 원본 주소와 실제 요청 경로를 확인했다.

HTML, 즉 페이지의 내용과 구조는 WAAS를 거쳐 원 서버로 요청한다. 로그인·이용 상태 등에 쓰이는 쿠키(cookie)를 보내지 않고 확인한 공개 페이지에서는 WAAS가 HTML을 캐시로 제공하지 않았고(NOTCACHED), FlyingPress가 원 서버에 저장해 둔 HTML을 제공했다(HIT).

CSS·JS·이미지·폰트는 cdn.datainhands.com을 통해 CDN 서비스인 Bunny에 먼저 요청한다. 캐시에 저장된 파일로 응답하는 캐시 적중(cache hit, HIT)이면 WAAS까지 가지 않는다. 캐시로 처리하지 못하는 경우(cache miss, MISS)에는 원본 주소인 https://datainhands.com으로 요청하므로 WAAS를 거친다. 일부 미디어는 별도 Bunny 주소에서 파일 저장 서비스인 OCI Object Storage로 직접 연결된다.

이 구성에서는 WAAS가 실제로 처리한 요청을 따로 세어야 캐시의 효과를 판단할 수 있었다. 상세 구성도와 원본 주소·응답 헤더는 아래에서 각각 펼쳐 볼 수 있다.

아래는 2026년 10월 24일 설정을 바꾸지 않고 확인한 구성을 세 가지 요청 경로로 줄여 표시한 그림이다. 요청(request)은 왼쪽에서 오른쪽으로 진행하고, 응답(response)은 같은 경로를 되돌아온다. 저장 위치와 별도 최적화 경로까지 담은 기존 상세 그림은 아래에서 펼쳐 볼 수 있다.

상세 구성도 원본 보기

CDN 주소로 바뀌지 않은 파일도 확인했다

페이지나 CSS 코드에 파일 주소가 적혀 있어도 브라우저가 그 파일을 모두 내려받는 것은 아니다. 예를 들어 특정 글꼴을 쓰지 않으면 해당 글꼴 파일은 불러오지 않을 수 있다. 그래서 코드에 적힌 주소 목록과 브라우저의 실제 요청 기록을 따로 확인했다.

브라우저의 요청 기록에는 PC에 저장해 둔 파일을 다시 쓴 경우, 즉 브라우저 캐시(browser cache)에서 불러온 파일도 포함된다. 따라서 99건 모두 인터넷을 통해 WAAS나 원 서버에 요청했다는 뜻은 아니다. 관리 화면 기록도 이미 열려 있던 화면에서 가져왔다. 새로 실시한 성능 전후 시험과는 구분해서 봐야 한다.

현재 브라우저로 열었을 때와 쿠키 없이 HTTP 요청을 보냈을 때는 HTML 응답이 달랐다. 브라우저에서는 응답을 저장하지 말라는 no-store 표시와 PHP/MISS가 나왔다. 쿠키 없이 요청했을 때는 Web Server/HIT였다. 로그인 상태나 요청 조건 중 무엇이 이 차이를 만들었는지는 이번 조사에서 확정하지 못했다. 따라서 모든 방문자가 사이트 도메인으로 파일을 받는다고도, 모든 방문자가 CDN만 사용한다고도 쓰지 않았다.

CDN 주소로 바뀌지 않고 사이트 도메인에 남은 파일에는 Astra CSS, Polylang CSS, 공통 메뉴 파일, 관리자 플러그인 CSS가 있었다. 로그인 없이 이 주소들에 다시 요청했을 때 대부분 MISS였다. 다만 관리자 플러그인의 공개 CSS 한 개는 처음에 MISS, 다음에는 HIT였다. 일부 파일은 WAAS 캐시에서 제공할 수 있다는 뜻이다. 이 몇 건만으로 전체 요청 중 캐시가 처리한 비율이나 줄어든 시간을 계산할 수는 없다.

그래서 WAAS 캐시를 계속 써야 할까

일반 방문자에게 정적 파일을 전달하는 데 WAAS 캐시가 꼭 필요한 것은 아니라고 본다. 그렇다고 지금 전부 불필요하다고 결론 내리기도 어렵다.

WAAS의 추가 효과를 볼 대상은 Bunny의 원본 조회와 CDN 주소로 바뀌지 않은 파일 요청이다. FlyingPress의 HTML 캐시와 CSS·JS 파일 캐시는 저장 대상과 응답 위치가 달라 따로 봐야 한다.

반면 파일 주소가 CDN 주소로 바뀌지 않은 페이지나 관리 화면에서는 사이트 도메인으로 파일을 요청하기도 한다. 이곳에서는 WAAS가 직접 응답할 여지가 있다. 관리자 화면의 효과와 공개 랜딩 페이지의 효과도 별도로 측정해야 한다.

당장은 캐시를 확대하거나 끄기보다, 공개 랜딩 페이지의 반복 측정과 CDN 주소로 바뀌지 않은 파일 점검을 먼저 하는 편이 낫다고 본다. 관리자 정적 파일의 개선 효과는 별도로 측정할 항목이다. 실제로 유지할 이득이 확인되면 로그인 없이 제공해도 되는 정적 파일 주소에만 규칙을 적용하고, 그렇지 않으면 WAAS 캐시를 줄이는 안을 검토할 수 있다. 이번 조사에서는 설정을 바꾸지 않았다.

캐시를 늘리기 전에 갱신 방식부터 확인해야 했다

Bunny 관리 화면에서 사이트 자원용 Pull Zone의 캐시 보관기간(Cache expiration time)은 Override: 1 year였다. 원본 서버의 보관기간 대신 1년을 적용하는 설정이다. 브라우저 보관기간은 Match server cache expiration으로, 서버 캐시의 보관기간을 따르도록 돼 있었다.

주소 차이에 따라 캐시를 나눠 저장하는 Vary Cache 설정에서는 URL Query String이 선택되지 않았다. 쿼리 문자열(query string)은 주소 뒤의 ?ver= 같은 부분이다. 지금 설정에서는 이 부분만 바꿔도 Bunny가 다른 파일로 구분해 저장할 것이라고 기대해서는 안 된다.

같은 CSS 주소에서 쿼리 값을 A에서 B로 바꿔 요청했다. B로 처음 요청했는데도 HIT였고, CDN에 저장된 시점을 나타내는 CDN-CachedAt 값도 같았다. 관리 화면의 설정과 맞는 결과였다. 다만 원본 파일 내용은 바꾸지 않았다. 파일을 수정했는데도 예전 내용이 나오는 상황까지 시험한 것은 아니다.

Bunny 캐시만 비우면(purge) Bunny는 다음 요청 때 WAAS에서 파일을 다시 가져올 수 있다. 이때 WAAS에 예전 파일이 남아 있다면 Bunny도 그 파일을 다시 저장할 가능성이 있다.

그래서 두 서비스가 파일을 어떤 주소와 조건으로 구분해 저장하는지, 즉 캐시 키(cache key)를 확인해야 한다. 저장된 캐시를 더 이상 쓰지 않게 만드는 캐시 무효화(cache invalidation)를 어느 순서로 할지도 정해야 한다. 원본을 바꾼 뒤에는 전달된 파일 내용이 실제로 바뀌었는지 해시(hash)로 비교할 필요가 있다. 해시는 파일 내용을 비교하는 데 쓰는 식별값이다.

방문자와 가까운 CDN·중계 서버에 저장한 캐시를 엣지 캐시(edge cache)라고 한다. 여러 곳에 같은 파일을 저장하면 갱신할 때 챙길 곳도 늘어난다. WAAS 캐시를 줄일지 판단할 때는 이 관리 부담도 고려하려 한다. 파일명에 버전이나 내용에 따른 해시를 넣어, 내용이 바뀌면 주소도 달라지게 하는 방법을 검토할 수 있다. Bunny의 Vary Cache 설명

이 부분은 WAAS 캐시를 켜느냐보다 먼저 확인할 운영 과제다. 이번에는 Bunny의 보관기간·쿼리 설정이나 WAAS 규칙을 변경하지 않았다.

랜딩 페이지 개선을 판단하려면 남은 확인이 필요하다

다음에는 공개 랜딩 페이지를 같은 조건에서 반복 측정해, 어떤 파일과 요청 구간이 로딩을 늦추는지 확인해야 한다. 이번 정적 파일·관리자 화면 수치만으로는 그 답을 내릴 수 없다.

먼저 사이트 자원용 Bunny가 파일 버전을 어떻게 구분하는지, 캐시를 비운 뒤 최신 파일을 가져오는지 시험할 필요가 있다. 그다음 관리자 화면에서 쓰는 공개 정적 파일을 WAAS가 대신 제공하면서 원 서버 요청과 대기 시간이 얼마나 줄어드는지 따로 재려고 한다. 실제 요청 기록과 반복 측정 없이 사이트 전체의 개선 효과를 계산하지는 않았다.

WAAS 규칙을 되돌려야 한다면 정책에서 nv-static-1d를 제거하고 전체 게시(Publish all)를 실행한다. 이후 필요하면 남은 캐시를 비우고, 로그인과 관리 화면이 정상적으로 열리는지 확인한다. 이는 되돌리는 방법을 적은 것이며 이번 조사에서 실행하지 않았다.

이 확인 단계에서는 캐시 설정과 기존 운영 구성을 유지했다. 실제 광고 표시와 휴대폰 수동 검증도 완료로 바꾸지 않았다.

앞서 진행한 폰트 최적화와 중복 선로딩 수정 기록에서는 내려받는 파일과 초기 로딩을 살펴봤다. 이번에는 그 파일을 누가 저장하고 어느 경로로 내주는지까지 확인해 기록을 보완했다.