워드프레스 속도 개선 사례: 캐시 계층을 정리 후 검색 노출 Recovery(2026-08)

워드프레스 속도 개선은 플러그인 설정만으로 끝나지 않습니다. 이미지가 무겁게 나가고, 파일 하나 받는 데 4초가 걸리고, 캐시에 옛 화면이 갇혀 있던 상태를 하나씩 고쳤습니다. 무엇을 건드렸고 얼마나 빨라졌는지, 그 뒤 검색 노출이 어떻게 되돌아왔는지 정리했습니다.

uknew 사이트가 느리다는 것은 알고 있었습니다. 100M 인터넷에서 크롬 개발자도구 DOMContentLoaded 속도가 평균 150 ms 정도 나왔습니다. 다만 워드프레스 속도 개선이라고 하면 대개 캐시 플러그인을 깔고 이미지를 압축하는 선에서 끝나는데, 이미 다 해 둔 상태였습니다. 그래서 한동안 손을 놓고 있었습니다. 실제로 열어 보니 문제는 플러그인 바깥에 있었습니다. 서버 설정 한 줄, 캐시 계층의 순서, 정규식 안의 점 하나 같은 것들이었고, 각각은 사소해 보였지만 합쳐 놓으니 사이트 전체를 눌러 놓고 있었습니다.

1️⃣ 무거운 이미지

uknew는 이미지를 WebP로 설정해 운영 중이었습니다. Imagify 플러그인으로 변환해 두어 서버에는 원본 PNG와 WebP가 나란히 있었고, 브라우저가 WebP를 지원하면 가벼운 쪽을 내보내도록 nginx에 조건을 걸어 둔 상태였습니다. 그런데 설정 값이 잘못돼 있어서 실제로는 반대로 나가고 있었습니다. WebP를 지원하는 브라우저에는 서버에 없는 이름의 파일을 찾게 만들어 놓았고, 없으니 원본 PNG로 되돌아갔습니다. 지원하지 않는 쪽만 정확한 WebP를 찾아가고 있었습니다.

고치는 것은 값 하나였지만 설정이 두 군데 나뉘어 있어서, 한쪽만 바꾸면 전원이 원본을 받게 됩니다. 실제로 한쪽만 먼저 바꿨다가 되돌린 적이 있습니다. 두 곳을 같이 고친 뒤 한 페이지를 다시 열어 보니 총 수신량이 9,298KB에서 1,368KB로 줄었습니다. 이미지를 새로 압축한 것도, 플러그인을 바꾼 것도 아닙니다. 이미 만들어 둔 파일이 제대로 나가게 했을 뿐입니다.

2️⃣ 서버를 거친 정적 파일

보안 플러그인으로 wp-content 같은 경로 이름을 다른 이름으로 바꿔 두고 있었습니다. 그런데 바뀐 주소를 안내하는 설정 파일이 nginx에 연결되어 있지 않아서, CSS와 JS 요청이 매번 워드프레스를 거쳐 나오고 있었습니다. 디스크에서 바로 꺼내 주면 되는 파일이 PHP를 통과하고 있었던 겁니다.

CSS 1장   2.60초 → 0.208초
JS 1장    4.00초 → 0.26초
낯선 값이 붙은 주소   최대 60.9초(시간 초과) → 1.5~1.9초

같은 파일을 원래 주소로 부르면 0.2~0.3초였습니다.
PHP를 거쳤는지 구분하는 방법: 응답 정보에 문자 인코딩 표시가 붙어 있으면 PHP,
없으면 nginx가 직접 내보낸 것입니다.

설정 파일을 nginx에 연결하고 재시작하자 열 배 이상 빨라졌습니다. 주소 뒤에 낯선 값이 붙어 들어올 때 60초 넘게 걸리다 끊기던 것도 같이 풀렸습니다. 광고나 SNS를 타고 들어오는 주소에는 대개 이런 값이 붙어 있으니, 그동안 유입 하나가 통째로 날아가고 있었던 셈입니다.

3️⃣ 미국으로 돌아간 한국 방문자

워드프레스 속도 개선을 위한 방안 중 해외 방문자를 위해 클라우드플레어를 쓰고 있었습니다. 전 세계에 서버를 깔아 두고 가까운 곳에서 내보내 주는 서비스라, 당연히 한국 방문자는 한국이나 그 근처에서 받고 있을 거라 생각했습니다. 확인해 보니 로스앤젤레스였습니다. 한국에서 접속하는데 태평양을 건넜다 오고 있었던 겁니다.

실수가 아니라 요금제 문제였습니다. 무료와 중간 요금제에서는 한국 서버를 거치는 것이 보장되지 않습니다. 그래서 버니(bunny.net)로 옮겼습니다. 서울에 서버가 있고, 요금제와 무관하게 가까운 곳에서 내보내 줍니다. 옮기고 나서 해외 쪽 응답이 눈에 띄게 안정됐습니다.

4️⃣ 캐시에 갇힌 옛 화면

CDN을 옮기면서 캐시 계층이 하나 늘었습니다. 자주 쓰는 화면을 저장해 두고 원본 서버까지 가지 않아도 되게 만드는 기능입니다. 해외 방문자에게는 확실히 도움이 되는데, 여기에 함정이 있었습니다. 이미지나 CSS뿐 아니라 페이지 화면까지 저장하고 있었고, 한 번 들어간 화면은 계속 그 상태로 나갔습니다.

그래서 설정을 아무리 고쳐도 밖에서 보면 그대로였습니다. 처음에는 설정이 잘못된 줄 알고 몇 번을 다시 확인했습니다. 실제로는 설정이 전부 정상이었고, 몇 달 전 화면이 남아 있었을 뿐입니다. 캐시를 비우는 버튼을 눌러도 이쪽은 안 비워집니다.

페이지 화면은 여기에 저장되지 않도록 설정을 바꿔 해결했습니다. 그리고 이 일을 겪고 나서 순서를 정했습니다. 사이트 전체에 영향을 주는 설정을 바꿨을 때는 아래 순서를 지켜야 합니다.

1. 워드프레스 캐시 플러그인 비우기 → 다시 만들기
2. CDN 저장소 확인
3. CDN 전체 비우기

5️⃣ 글을 죽인 점 하나

속도를 재다가 엉뚱한 것을 발견했습니다. 글 하나가 접속 자체가 안 되고 있었습니다. 워드프레스가 만든 오류 화면이 아니라 서버가 먼저 막아 세운 화면이었고, 검색엔진도 방문자도 그 글에 닿을 수 없는 상태였습니다.

grep -n "wp-config" /home/site/www/security.conf
39:location ~ ^/(wp-config.php|wp-config-sample.php|readme.html|readme.txt|install.php|license.txt|php.ini|security.conf|bb-config.php|error_log) { deny all; }

범인은 보안 플러그인이 만들어 둔 설정 파일 39행이었습니다. wp-config.php처럼 노출되면 안 되는 파일을 차단하는 줄인데, 여기서 점이 특별한 의미로 해석됩니다. 정규식에서 점은 아무 글자나 하나를 뜻하기 때문에 wp-config.php는 wp-config로 시작해서 php로 끝나는 아무 문자열이나 잡습니다. 제 글 주소가 /wp-config-php-기본-설정/이었으니 그대로 걸린 겁니다.

~]# cp /home/site/www/security.conf /home/site/backup/security.conf.bak-260826

sed -i '39s/wp-config\.php|wp-config-sample\.php|readme\.html|readme\.txt|install\.php|license\.txt|php\.ini|security\.conf|bb-config\.php|error_log/wp-config\\.php|wp-config-sample\\.php|readme\\.html|readme\\.txt|install\\.php|license\\.txt|php\\.ini|security\\.conf|bb-config\\.php|error_log/' /home/site/www/security.conf

grep -n "wp-config" /home/site/www/security.conf
39:location ~ ^/(wp-config\.php|wp-config-sample\.php|readme\.html|readme\.txt|install\.php|license\.txt|php\.ini|security\.conf|bb-config\.php|error_log) { deny all; }
~]#

고치는 방법은 점 앞에 백슬래시를 붙여 「진짜 점」이라고 알려 주는 것입니다. 원본은 백업해 두고 해당 줄만 바꿉니다.

~]# nginx -t && systemctl reload nginx
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
 ~]# 

설정 파일 문법을 먼저 검사하고 통과하면 적용합니다. 검사를 건너뛰고 적용했다가 문법 오류가 있으면 사이트 전체가 멈춥니다.

확인은 두 가지를 같이 봐야 합니다. 죽었던 글이 살아났는지, 그리고 원래 막아야 할 파일은 여전히 막혀 있는지입니다. 앞이 200, 뒤가 403이면 정상입니다. 글만 살리고 차단이 풀렸다면 고친 게 아니라 구멍을 낸 겁니다.

~]# curl -s -o /dev/null -w "%{http_code}\n" "http://127.0.0.1/wp-config-php-기본-설정/" -H "Host: uknew.co"
200
curl -s -o /dev/null -w "%{http_code}\n" "http://127.0.0.1/readme.html" -H "Host: uknew.co"
403

그리고 이 글을 쓰는 지금 다시 확인해 보니, 같은 자리가 또 403이었습니다. 보안 플러그인이 경로 설정을 바꿀 때마다 이 파일을 새로 만들어서 손으로 고친 것이 지워집니다. 앞으로도 플러그인 설정을 만진 뒤에는 이 줄을 다시 봐야 합니다. 한 번 고쳐 놓고 끝나는 문제가 아니었습니다.

6️⃣ 다시 연 판단

구조 자체는 1년쯤 전에 이미 한 번 갈아엎었습니다. 원래는 아파치가 HTTP/2로 직접 응답하는 구성이었는데, 앞에 nginx를 세워 HTTP/3를 켜고 아파치는 뒤로 물렸습니다. 그래서 속도를 재던 초반에도 앞단은 이미 최신 규격이었고, 남은 건 뒤에서 아파치를 거치는 비용뿐이었습니다.

속도 작업 초반에 이런 생각을 했습니다. 워드프레스 캐시 플러그인이 만들어 둔 파일을 nginx가 바로 내보내면 더 빠르지 않을까. 지금은 nginx가 받아서 아파치로 넘기고, 아파치가 다시 워드프레스를 거쳐 파일을 찾아오는 구조였습니다. 중간을 건너뛰면 이득이 클 것 같았습니다.

재 봤더니 아파치를 거치는 비용이 10ms 정도였습니다. 200ms쯤 줄 거라 기대했는데 실제로는 그 20분의 1이었습니다. 손이 많이 가는 작업인데 얻는 게 이 정도면 할 이유가 없었습니다. 오판이었다고 정리하고 접었습니다.

3주 뒤 속도 측정 도구를 만들면서 다시 열게 됐습니다. 이번에는 측정 대상이 페이지 전체가 아니라 서버가 응답을 만들어 내는 시간 하나였습니다. 그 항목만 떼어 놓고 보니 결과가 달랐습니다. 12.0ms가 5.6ms로 줄었습니다. 절반 이하입니다.

도구를 만들면서 측정 자체의 함정도 하나 발견했습니다. 어떤 사이트를 재도 전부 HTTP/1.1로 나오길래 이상해서 들여다보니, 측정하는 쪽에서 상위 규격을 쓰겠다고 알리지 않고 있었습니다. 서버는 HTTP/2를 지원하는데 물어보지 않으니 기본값으로 답한 것입니다. 측정 도구를 고치자 제대로 나왔습니다.

처음 측정이 틀린 것은 아니었습니다. 전체 응답 시간 안에서 10ms는 묻히는 값이 맞습니다. 다만 서버 처리 시간만 놓고 보면 그 10ms가 절반을 차지하고 있었던 겁니다. 무엇을 재느냐에 따라 같은 숫자가 무의미해지기도 하고 결정적이 되기도 합니다. 접었던 판단을 다시 열어 볼 만한 이유는 대개 여기에 있습니다.

7️⃣ 워드프레스 속도 개선으로 얻은 것: 되돌아온 검색 노출

워드프레스 속도 개선 후 대략 2주 후부터 실시간 유입을 보다가 낯선 제목들을 발견했습니다. 최근에 쓴 글이 아니라 몇 년 전에 써 두고 잊고 있던 글들이었습니다. 한동안 조용하던 페이지에 다시 사람이 들어오고 있었습니다.

짐작가는 이유는 이렇습니다. 사이트 응답이 빨라지면 검색엔진이 같은 시간에 더 많은 페이지를 훑고 갑니다. 한 번 와서 서너 개 보고 나가던 것이 훨씬 많이 보고 가게 되니, 색인은 돼 있지만 오랫동안 노출 후 묻힌 글과 노출 후 클릭이 되지 않던 글들이 다시 평가 대상에 들어옵니다. 새 글이 뜬 게 아니라 묻혀 있던 글이 다시 올라온 겁니다.

그리고 이렇게 돌아온 글 중 상당수가 시간이 지나도 내용이 상하지 않는 종류였습니다. 발행 직후에 트래픽이 몰리는 글은 기억에 남는데, 이런 글은 꾸준히 조금씩 들어오는 대신 눈에 띄는 순간이 없어서 잊고 있었습니다. 다시 자리를 잡으면 잘 빠지지 않는 쪽이기도 합니다.

워드프레스 속도 개선의 보상은 순위가 확 뛰는 형태로 오지 않았습니다. 이미 가지고 있던 것이 다시 보이게 되는 형태로 왔습니다. 몇 년치 글이 쌓여 있는 사이트일수록 이 차이가 큽니다. 훑을 것이 많이 있어야 훑는 속도가 빨라진 효과도 커지기 때문입니다.

🔗 추천 콘텐츠

유뉴 도구 워드프레스 테마 확인 · 플러그인 감지 주소만 넣으면 그 사이트가 쓰는 테마와 플러그인, 호스팅까지 나옵니다. 빠른 사이트를 만났을 때 무엇으로 만들었고 어디에 올려 뒀는지 확인해 보세요. 도구 열기 →

캐시 WP Rocket 설정 가이드 캐시 3단계의 첫 단계를 맡는 플러그인, 설정 항목별로 살펴봅니다. 이미지 IMAGIFY 설정: 이미지 최적화 WebP 변환을 맡는 쪽입니다. 만들어 두는 것과 내보내는 것은 별개입니다. 최적화 Perfmatters 리뷰 & 가이드 3년 동안 쓰면서 정리한 성능 최적화 설정 방법입니다.

ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액^{(이벤트 할인 시 금액이 내려갑니다↓)}은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.