Data In Hands

워드프레스에 CDN이 필요할까: 속도·방문 지역·비용으로 판단하기

원본에서 파일을 받는 경로와 CDN에 저장된 사본을 받는 경로를 비교한 그림

이미지가 늦게 뜬다고 CDN부터 추가할 필요는 없다. 파일을 받는 데 시간이 걸리는지 먼저 확인해야 한다. 그 지연이 주요 방문 지역에서 반복된다면 CDN을 시험해 볼 만하다.

글은 열렸는데 대표 이미지가 한참 뒤에 나타난다. CDN을 쓰면 빨라진다는 이야기를 듣고 설정 화면을 열어 본다. 그런데 원본 주소와 캐시 항목을 채우기 전에 막히는 질문이 있다.

“지금 느린 이유가 CDN이 없어서일까?”

이 질문부터 풀어 보고자 한다. 공개 이미지 하나를 골라 늦는 구간을 확인하는 것부터 시작하면 된다. 비용 비교와 도입 판단은 그다음이다.

CDN은 여러 지역의 서버를 이용해 콘텐츠를 전달하는 서비스다. 이번 글은 도입 여부를 판단하는 데 집중한다. 실제 연결 절차는 Bunny CDN 설정 가이드에서 이어서 볼 수 있다.

1. CDN으로 줄일 수 있는 지연부터 찾을 것

글을 열면 브라우저는 먼저 페이지의 HTML을 받는다. 그 안에 적힌 주소를 보고 이미지와 스타일 파일을 요청한다. 파일을 받은 뒤에는 내용을 화면에 그린다. 어느 단계가 늦는지에 따라 해결 방법이 달라진다.

예를 들어 이미지 다운로드는 끝났는데 화면이 계속 비어 있다면 표시 작업을 살펴봐야 한다. 같은 파일을 더 빨리 전달하는 것만으로는 이 문제가 해결되지 않는다. 반대로 이미지 요청이 일찍 시작됐는데 다운로드가 오래 걸린다면 전송 경로를 비교할 이유가 있다. 먼저 이미지 용량이 불필요하게 크지는 않은지도 확인해야 한다.

느린 구간에 따라 먼저 할 일
관찰한 현상 먼저 확인할 것
HTML 응답을 오래 기다린다 서버 처리와 페이지 캐시. 파일용 CDN만 연결해도 HTML 생성이 빨라지는 것은 아니다.
공개 이미지·폰트 전송이 오래 걸린다 파일 크기와 방문 지역별 전송 시간. CDN 비교 시험의 후보가 된다.
파일을 받았는데 화면 표시가 늦다 CSS·JavaScript와 이미지 표시 시점. 성능 시리즈 3편의 순서로 점검한다.

CDN으로 HTML까지 제공하는 구성도 있다. 개인별 화면과 캐시 갱신을 함께 설계해야 하므로 공개 파일부터 비교하는 이번 시험과는 범위를 나누는 편이 좋다.

2. 방문자가 많은 지역에서 비교할 것

접속 통계에서 최근 방문자의 국가·지역을 확인해 보자. 국내 방문이 대부분이라면 국내 접속 성능을 우선 확인하면 된다. 해외 독자가 꾸준히 방문한다면 해당 지역도 비교 대상에 넣어야 한다. 국가별 방문 수만으로 속도가 느리다고 판단할 수는 없다.

지역별 측정 기능이 있는 도구나 해당 지역의 협조자를 통해 같은 글을 열어 보면 된다. 측정 위치와 기기 조건을 고정해야 비교할 수 있다. 한국의 데스크톱 결과와 미국의 느린 모바일 회선 결과를 바로 비교하면 지역 차이와 기기 차이가 섞인다.

우선 자주 읽는 글 하나와 이미지가 많은 글 하나를 골라보자. 각각 여러 번 측정하고 중앙값을 비교하는 방법이 실용적이다. 중앙값은 결과를 크기순으로 놓았을 때 가운데 값이다. 유난히 빠르거나 느렸던 한 번의 결과에 덜 끌려갈 수 있다.

3. 느린 이미지 하나로 확인을 시작할 것

페이지 전체를 한꺼번에 분석하려 하면 어디서부터 봐야 할지 막막하다. 먼저 늦게 나타나는 대표 이미지 하나를 골라보자.

확인 순서

  1. Chrome에서 해당 글을 열고 F12로 개발자 도구를 연다.
  2. Network 탭을 선택한 뒤 페이지를 새로고침한다.
  3. Img 필터를 선택한다. 목록에서 대표 이미지를 찾는다. 이름이 낯설다면 Preview에서 그림을 확인하면 된다.
  4. 이미지 요청의 Timing을 연다. 응답 대기와 다운로드 중 어느 쪽이 오래 걸렸는지 확인한다.
Chrome Network에서 대표 이미지 요청을 필터링한 실제 화면. Size 24.2 kB, Time 751 ms가 표시되어 있다.
선택한 이미지 요청의 Size·Time 부분을 확대한 화면. 크게 보기

위 화면은 이 사이트의 공개 이미지 요청을 Chrome에서 확인한 것이다. Size에는 24.2 kB가 표시됐다. Time은 751 ms였다. 작은 파일도 응답을 기다리느라 늦을 수 있으므로 Timing을 열어 시간을 나눠 봐야 한다.

결과는 이렇게 읽으면 된다

Waiting for server response가 길다면 응답을 받기 전의 대기가 큰 것이다. 여기에는 네트워크 왕복과 서버 처리 시간이 함께 들어간다. 이 숫자만으로 서버 성능 문제라고 판단할 수는 없다.

Content Download가 길다면 파일을 내려받는 데 시간이 걸린 것이다. 파일 용량부터 확인해야 한다. 용량을 줄인 뒤에도 주요 방문 지역에서 지연이 반복되면 CDN 경로와 비교해 볼 수 있다.

작은 화면에서는 캡처를 좌우로 밀어 볼 수 있다. 크게 보기를 누르면 원본이 열린다.

실제 Timing 화면. Waiting for server response 624.50 ms, Content download 111.85 ms.
같은 요청의 Timing. 초록색 응답 대기가 파란색 다운로드보다 길다. 크게 보기

이 요청에서는 응답 대기가 624.50 ms였다. 다운로드는 111.85 ms가 걸렸다. 다음에는 같은 조건으로 여러 번 확인해야 한다. 대기가 계속 길다면 응답 경로와 서버 처리를 살펴볼 차례다. 이 한 번의 결과만으로 CDN을 추가할 필요가 있다고 결론 낼 수는 없다.

2026-11-13 Chrome 영문 UI 캡처. 로그인한 브라우저에서 공개 이미지 파일을 확인했다. Disable cache가 켜져 있고 속도 제한은 없는 상태였다. 일반 방문자의 페이지 로딩 속도를 측정한 결과는 아니다.

비교할 때는 파일 주소·크기·응답 상태를 함께 기록해야 한다. CDN에서 더 작은 이미지로 변환했다면 경로 변경과 용량 감소의 효과가 섞인다. 먼저 같은 파일끼리 비교하는 편이 원인을 찾기 쉽다.

개발자 도구의 Disable cache는 브라우저 캐시를 끄는 기능이다. CDN에 저장된 파일을 지우는 버튼은 아니다. 비교 시험에서는 이 조건을 같게 유지해야 한다. 평소 재방문 속도를 확인할 때는 브라우저 캐시를 켠 결과도 따로 보면 된다. Chrome Network 사용 안내

4. 첫 요청과 반복 요청을 나눠 확인할 것

원 서버는 파일 원본을 제공하는 서버다. CDN에 쓸 수 있는 사본이 있으면 그 파일을 전달한다. 이를 캐시 적중(HIT)이라고 한다. 사본이 없어 원본을 가져와야 하면 캐시 미적중(MISS)이다.

HIT 한 번만 보고 모든 방문이 빨라졌다고 판단해서는 안 된다. 다른 지역의 CDN 서버에는 아직 사본이 없을 수 있다. 드물게 요청되는 파일은 캐시에서 제거될 수도 있다. 처음 받은 결과와 반복해서 받은 결과를 나눠 기록해야 한다. CDN 응답 헤더나 관리 화면의 통계로 적중 여부를 확인하면 된다. 헤더 이름과 값은 서비스마다 다르다. CDN의 원본 요청과 캐시 동작

예를 들어 반복 요청만 빨라지고 첫 요청은 차이가 없을 수 있다. 이런 경우에는 실제 방문에서 HIT가 얼마나 발생하는지 더 살펴봐야 한다. 테스트 중 같은 파일을 연속으로 열어 만든 높은 적중률을 전체 방문의 결과로 취급해서는 안 된다.

같은 이미지의 실제 응답 헤더. Cache-Control public, Server ZENEDGE, X-Cache-Status MISS가 보인다.
Headers의 Response headers. 캐시 정책과 이번 요청의 결과를 구분해서 읽는다. 크게 보기

Cache-Control은 저장 조건을 알려준다. 위의 public은 공유 캐시에 저장할 수 있다는 뜻이다. 이것만으로 이번 응답이 캐시에서 왔다고 판단할 수는 없다.

이번 응답에는 X-Cache-Status: MISS가 표시됐다. Server: ZENEDGE와 X-Cdn: Served-By-Zenedge도 함께 보인다. 따라서 이 값을 Bunny 캐시의 결과로 기록하면 안 된다. 먼저 요청 주소와 응답한 서비스를 확인해야 한다.

5. 공개 파일을 함께 저장해도 되는지 확인할 것

블로그의 공개 이미지처럼 누구에게나 같은 내용을 보내는 파일이 첫 시험에 적합하다. 로그인 화면의 사용자 정보나 장바구니는 다른 사람과 같은 사본을 쓰면 안 된다. 공개 파일 설정을 사이트 전체에 그대로 적용해서는 안 된다.

HTTP 응답의 Cache-Control: private는 공유 캐시에 저장하지 말라는 뜻이다. no-store는 응답을 저장하지 말라는 지시다. 이런 설정을 지워 적중률을 높이려 해서는 안 된다. 브라우저 캐시와 공유 캐시의 차이

이미 호스팅이나 최적화 서비스에 CDN이 포함되어 있는지도 확인해야 한다. 같은 역할의 서비스를 추가하기 전에 현재 어떤 주소로 파일을 받는지 살펴보자. 기존 CDN에서 원하는 지역의 성능이 충분하다면 새 서비스를 더할 이유는 적다.

6. 전송료와 운영 부담을 함께 비교할 것

CDN 사용료가 늘어도 원 서버의 전송료는 줄어들 수 있다. 다만 원본을 다시 가져오는 요청은 계속 발생한다. CDN에서 방문자에게 보낸 용량 전체가 원 서버의 절감량과 같지는 않다.

비용을 비교할 때는 현재 월 청구서에서 전송료부터 확인해야 한다. 호스팅 요금에 전송량이 포함되어 있다면 당장 줄일 비용이 없을 수도 있다. 그다음 예상 CDN 요금과 남을 원 서버 요금을 더해 보자. 지역별 단가·최소 요금·추가 기능 비용도 확인해야 한다. Bunny의 현재 요금표는 실제 도입 시 다시 확인할 것.

도입 후 비교할 비용
CDN 전송료 + 남는 원 서버 전송료 + 추가 기능 요금

별도로 볼 부담
파일 갱신 확인 · 장애 대응 · 설정 관리에 쓰는 시간

속도 차이가 작더라도 원 서버 부하나 비용이 충분히 줄면 유지할 이유가 있다. 반대로 비용이 조금 줄어도 파일 교체 때마다 확인할 일이 크게 늘면 작은 블로그에서는 이득이 적을 수 있다.

7. 같은 증상이라도 다음 조치는 달라진다

대표 이미지가 늦게 보이는 두 상황을 가정해 보자. 아래는 판단 방법을 설명하기 위한 예다.

이미지 다운로드는 이미 끝난 경우

Network에서는 이미지 요청이 완료됐는데 화면에는 빈칸이 남아 있다. 이때는 CDN 계약보다 표시 시점 확인이 먼저다. 지연 로딩이나 JavaScript 때문에 이미지가 뒤늦게 나타나는지 살펴봐야 한다. 3편의 이미지 표시 점검으로 돌아가면 된다.

해외에서 파일 다운로드가 계속 늦는 경우

같은 이미지가 국내에서는 빨리 내려받아진다. 해외의 같은 시험 환경에서는 여러 번 확인해도 오래 걸린다. 파일 용량을 줄일 여지도 크지 않다. 이 경우에는 공개 이미지 일부를 CDN으로 제공하는 시험을 진행할 이유가 있다.

시험 후에도 차이가 없다면 적용 범위를 넓힐 필요는 없다. 접속 회선이나 다른 병목을 다시 확인해야 한다.

8. 일부 공개 파일로 시험한 뒤 결정할 것

  1. 도입 전 기록을 남긴다. 비교할 글·파일·지역·기기 조건을 정한다. HTML과 파일 전송 시간을 따로 기록한다.
  2. 공개 파일 일부로 시험한다. 테스트 페이지에서 CDN 주소를 사용한다. 기존 주소로 되돌릴 수 있게 원본을 유지한다.
  3. 같은 조건으로 다시 측정한다. 처음 요청과 반복 요청을 구분한다. PC와 모바일에서 이미지·폰트가 제대로 나오는지도 확인한다.
  4. 파일을 수정해 본다. 새 내용이 전달되는지 확인해야 한다. 구체적인 방법은 글·미디어 캐시 갱신 가이드를 따르면 된다.
  5. 속도와 비용을 함께 보고 결정한다. 주요 지역에서 개선이 반복되면 적용 범위를 넓힐 수 있다. 차이가 없거나 오류가 생기면 기존 주소로 되돌린 뒤 원인을 확인한다.

이번 글에서는 CDN 도입 여부를 판단할 기준을 정리했다. 연결을 시험하기로 했다면 Bunny CDN 설정 가이드에서 파일 원본을 구분하는 단계부터 진행하면 된다.

위로 스크롤