워드프레스 속도 개선, DB 정리, 자바스크립트와 CSS 압축 때문에 저는 WP Rocket을 5년 넘게 꽤 만족하면서 써왔습니다. 체감도 나쁘지 않았고, 설정도 어렵지 않아서 사실상 기본 플러그인처럼 두고 있었는데요. 그런데 최근 파일질라로 error_log를 보다가 평소엔 그냥 지나쳤을 만한 로그가 계속 반복되는 걸 확인하면서 생각이 많이 달라졌습니다.
처음에는 단순한 경고 정도로 봤습니다. 그런데 SSH와 WHM 쪽에서 하나씩 확인해보니 단순한 알림이 아니라 WP Rocket의 배경 작업이 실제 서버 부하를 만들고 있을 수 있는 상태였습니다.
특히 제 서버는 4 CPU, 메모리 7.68GB, 스왑 4GB 구성인데, 이 정도 사양에서도 php-fpm과 mysqld가 계속 상단에 뜨고, preload와 SaaS 관련 요청까지 반복되는 걸 보니 무조건 빠르게만 만들어주는 플러그인은 아니라는 걸 체감했습니다.
처음 발견한 오류 로그
제가 처음 발견한 건 관리자 화면이 아니라 서버 로그였는데요 일단 error_log를 확인하다가 아래처럼 반복되는 항목들을 보게 됐습니다.
rocket_saas_pending_jobs
rocket_saas_on_submit_jobs
action_scheduler_run_queue_rucss
rocket_preload_process_pending
처음엔 이름만 보고 “배경 작업인가 보다” 하고 넘기기 쉽습니다. 저도 그랬습니다. 그런데 이게 계속 보인다는 건 그냥 설치만 되어 있는 게 아니라, 실제로 CSS 처리, preload, SaaS 요청, cron 작업이 계속 돌고 있다는 뜻이었습니다.
WHM과 SSH로 보니 더 분명했던 서버 상태
이후에는 단순히 워드프레스 관리자 화면만 보지 않고, WHM과 SSH에서 부하를 직접 확인했습니다.
uptime top -b -n 1 | head -30 free -m ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -25 iostat -x 1 3
이렇게 확인해보면 생각보다 금방 감이 오는데요 당시 제 서버에서는 mysqld가 계속 상단에 있었고, php-fpm: pool 도메인, php-fpm: pool 도메인, php-fpm: pool 도메인이 순서대로 CPU를 계속 쓰고 있었습니다.
저는 원래 한개의 사이트만 의심했는데, 실제로는 다른 사이트까지 같이 영향을 받고 있었습니다.
더 중요한 건 스왑이었습니다. 메모리는 당장 바닥은 아니었지만 스왑을 1.5GB 이상 이미 쓰고 있는 상태였고, 이건 예전에 메모리 압박이 있었다는 흔적이라 그냥 넘기기 어렵습니다.
제 기준에서는 이 시점부터 “속도 플러그인이 정말 이득만 주고 있는가”를 다시 봐야 했습니다.
access 로그에서 확인된 실제 원인
error_log만 봐서는 추측으로 끝날 수 있어서, access 로그도 직접 봤습니다. 이때 확실히 보인 게 아래 요청들이었습니다.
WP Rocket/Preload
WP-Rocket/SaaS
/wp-content/cache/background-css/
?nowprocket=1&no_optimize=1&wpr_imagedimensions=1
이건 정말 차이가 컸습니다. 단순히 외부 방문자나 크롤러만 오는 게 아니라, WP Rocket 자체가 캐시 예열, 배경 CSS 생성, SaaS 처리 요청을 계속 만들고 있었다는 뜻이었기 때문입니다.
그러니 php-fpm이 바쁠 수밖에 없고, 여기에 Bingbot이나 AhrefsBot 같은 크롤러까지 겹치면 서버는 더 바빠질 수밖에 없습니다.
WP Rocket이 무조건 나쁜 플러그인이라는 뜻은 아닙니다
여기서 오해하면 안 되는 부분이 있습니다.
저도 5년 넘게 잘 써왔고, 지금도 WP Rocket 자체가 나쁜 플러그인이라고 생각하진 않습니다. 문제는 모든 서버 환경에서 모든 기능을 켠 상태로 항상 이득만 주는 건 아니라는 점입니다.
특히 저처럼 여러 개의 워드프레스 사이트를 한 VPS에서 같이 운영하고 있고, 여기에 크롤러 유입이 섞여 있고, 서버에서 PHP 배경 작업까지 같이 돌면, preload나 SaaS 계열 기능은 점수보다 부하를 먼저 만들 수 있습니다. 저는 이번에 이걸 직접 확인한 셈입니다.
특히 주의해야 했던 WP Rocket 기능
CSS 전달 최적화
이 기능은 점수만 보면 켜고 싶어집니다. 저도 그랬습니다. 그런데 실제 서버에서는 RUCSS, background-css, SaaS 요청과 연결되면서 계속 작업을 만들 수 있었습니다. 점수는 조금 좋아질 수 있어도 서버가 민감하면 오히려 이 기능이 부담이 됩니다.
사전 로드 활성화
이 기능도 주의가 필요합니다. 글이 많거나 수정이 잦은 사이트에서는 preload가 계속 돌면서 access 로그에 WP Rocket/Preload 요청이 반복해서 찍힐 수 있습니다. 캐시를 미리 만들어두는 기능 자체는 좋지만, 서버가 감당하기 어려운 환경에서는 그 자체로 추가 요청이 됩니다.
링크 사전 로드 활성화
이건 없어도 사이트가 망가지지 않습니다. 그런데 내부 링크가 많고 페이지가 많은 블로그라면 체감보다 불필요한 요청 증가가 먼저 보일 수 있습니다. 저라면 서버가 조금이라도 바쁜 시간대가 있다면 이 기능은 가장 먼저 끄는 편입니다.
제가 실제로 바꾼 운영 방식
결국 사이트별로 다르게 갔습니다.
처음에는 세 사이트 다 같은 방식으로 최적화하면 된다고 생각했는데, 직접 확인해보니 그게 아니었습니다.
- CSS 전달 최적화
- 사전 로드 활성화
- 링크 사전 로드 활성화
그리고 캐시 수명도 길게 두지 않고 5시간 기준으로 맞췄습니다. 예전처럼 10시간 이상 길게 두는 것보다, 지금처럼 최근에 캐시와 크론 이슈가 있었던 시기에는 짧게 운용하는 쪽이 더 낫다고 봤습니다.
SSH에서 자주 쓴 확인 명령어
저처럼 관리자 화면보다 서버 쪽에서 직접 보고 싶은 분들은 아래 명령어가 꽤 도움이 됩니다.
현재 부하 확인
uptime top -b -n 1 | head -30 free -m ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -25
WP Rocket 관련 크론 확인
wp cron event list --path=/home/dhfimtmy/public_html --allow-root | egrep 'rocket|rank_math|action_scheduler' wp cron event list --path=/home/dhfimtmy/public_html/도메인 --allow-root | egrep 'rocket|rank_math|action_scheduler' wp cron event list --path=/home/dhfimtmy/public_html/도메인 --allow-root | egrep 'rocket|rank_math|action_scheduler'
tail -n 20 /home/dhfimtmy/access-logs/* 2>/dev/null | head -200
저는 이 명령어들로 preload 요청과 SaaS 요청이 실제로 찍히는 걸 보고 나서, 관리자 화면에서 “최적화 켜짐”만 보고 있으면 안 되겠다고 느꼈습니다.
WP Rocket과 비슷한 플러그인도 똑같이 조심해야 합니다
이 부분도 많이들 놓칩니다. WP Rocket만 주의하면 끝나는 게 아닙니다. 비슷한 캐시·최적화 플러그인도 결국 방향은 비슷합니다. 이름만 다를 뿐, 캐시 생성, 미사용 CSS 처리, preload, 이미지 최적화, background 작업으로 서버에 부담을 줄 수 있습니다.
LiteSpeed Cache
서버가 LiteSpeed라면 장점이 분명하지만, 아닌 환경에서는 생각보다 손이 많이 갑니다. 특히 CSS/JS 쪽 최적화는 점수는 예뻐 보여도 서버와 궁합이 안 맞으면 관리가 번거로워질 수 있습니다.
Autoptimize
가볍게 쓰면 괜찮지만, 여러 최적화 플러그인과 겹치게 설정하면 CSS와 자바스크립트 처리에서 엉키기 쉽습니다. 제 기준에서는 한 플러그인에 한 역할만 맡기는 쪽이 낫습니다.
FlyingPress
평가가 좋아도 preload, CSS 처리, 페이지 캐시 같은 무거운 기능이 들어가면 결국 서버 환경 따라 다릅니다. 플러그인 이름이 다르다고 서버 부담이 사라지는 건 아닙니다.
제가 실제로 느낀 핵심 정리
이번 일을 겪고 나서 든 생각은 단순했습니다. 워드프레스 속도 플러그인은 항상 서버를 가볍게 만들어주는 도구가 아니었습니다. 어떤 기능은 분명 도움되지만, 서버와 사이트 상황을 무시하고 전부 켜두면 오히려 느려짐과 부하를 만들 수 있습니다.
저라면 지금부터는 PageSpeed 점수보다 아래를 먼저 보겠습니다.
- error_log에 반복 오류가 없는지
- access 로그에 preload나 SaaS 요청이 과한지
- php-fpm이 특정 사이트에서 계속 상단에 뜨는지
- mysqld가 함께 올라오는지
- swap이 계속 늘어나는지
점수 2~3점보다 서버가 조용한 게 훨씬 중요했습니다. 저는 이번에 그걸 아주 제대로 느꼈습니다.
이런 분들은 특히 조심하는 게 좋았습니다
제가 보기엔 아래 조건에 해당하면 캐시 플러그인을 더 보수적으로 써야 합니다.
- VPS 한 대에 워드프레스 사이트를 여러 개 운영하는 경우
- 블로그 글 수가 많고 수정이 잦은 경우
- 외부 봇과 크롤러 유입이 많은 경우
- PHP 백그라운드 작업이 이미 자주 도는 경우
- 메모리는 버틸 만해도 스왑이 이미 쓰이고 있는 경우
저 역시 4 CPU, 7.68GB 메모리, 4GB 스왑 환경이면 충분할 거라고 생각했는데, 실제로는 preload와 SaaS 요청이 겹치면 이 사양에서도 부담이 생겼습니다. 이 부분은 정말 직접 봐야 체감됩니다.
Q. WP Rocket이 있으면 무조건 워드프레스가 빨라지나요?
아닙니다. 페이지 캐시만 가볍게 쓰면 도움이 되지만, CSS 전달 최적화나 사전 로드, SaaS 계열 작업이 서버 환경과 맞지 않으면 오히려 php-fpm과 MySQL 부하가 늘 수 있습니다.
Q. WP Rocket 관련 크론이 보인다고 바로 문제라고 봐야 하나요?
크론 생성 자체는 정상일 수 있습니다. 다만 해당 작업이 반복적으로 오류를 내거나 preload, SaaS, 유지보수 모드, cron 저장 실패까지 이어지면 그때는 실제 운영 문제로 봐야 합니다.
Q. WP Rocket 대신 다른 최적화 플러그인을 쓰면 해결되나요?
꼭 그렇지는 않습니다. LiteSpeed Cache, Autoptimize, FlyingPress도 캐시, CSS, preload, background 작업이 들어가면 서버에 비슷한 부담을 줄 수 있습니다. 결국 서버 환경과 어떤 기능을 켜느냐가 더 중요합니다.
Q. 서버 부하가 의심될 때 가장 먼저 꺼볼 기능은 무엇인가요?
저는 CSS 전달 최적화, 사전 로드, 링크 사전 로드부터 먼저 꺼보는 편입니다. 그 뒤에도 preload나 SaaS 요청이 계속 보이면 플러그인을 가볍게 쓰거나 사이트별로 다르게 운용하는 게 낫습니다.
