워드프레스 캐시 플러그인 오히려 느려질 수 있었던 이유로그로 직접 확인한 후기

워드프레스 속도 플러그인은 분명 편합니다. 저도 예전에는 캐시 플러그인만 잘 깔아두면 서버가 훨씬 가벼워질 거라고 생각했습니다. 그런데 직접 VPS 서버 로그를 확인해보니 이야기가 조금 달랐습니다.

일단 preload, background CSS 생성, Jetpack 관련 크론, Action Scheduler 실패 흔적, Redis 중복 로드, 그리고 memory_limit 값이 256MB가 아니라 256 bytes처럼 잘못 해석되는 PHP 경고까지 한꺼번에 얽혀 있었고 실제로 겪어보니 속도 플러그인이 항상 서버를 가볍게 만들어주는 것은 아니었습니다. 

워드프레스 서버 사양이 괜찮아도 안심하기 어려웠던 이유

이번에 확인한 환경은 워드프레스 사이트 하나만 올린 서버가 아니었습니다.

여러 사이트를 함께 운영하는 VPS였고, 대략 4 CPU, 메모리 7.68GB, 스왑 4GB 정도의 사양이었습니다. 숫자만 보면 충분해 보였지만 실제 운영 상태는 달랐습니다.

• [IT 리뷰/블로그 SEO] - 블루호스트 VPS 워드프레스 TTFB 줄이기(OPcache + Redis Object Cache 설치)
• [IT 리뷰/블로그 SEO] - 블루호스트 VPS 워드프레스 예약발행 자주 실패한다면 크론 루프백 서버확인

저는 이 정도 사양이면 캐시 플러그인 정도는 충분히 감당할 수 있을 거라고 봤습니다. 그런데 preload 요청과 SaaS 처리, background CSS 생성 작업이 한꺼번에 겹치면 php-fpm과 MySQL이 예상보다 훨씬 바빠졌습니다.

특히 스왑이 이미 1.5GB 이상 사용된 시점도 있었고, php-fpm 풀 역시 특정 사이트 하나만 쓰는 구조가 아니었습니다.

여러 사이트가 동시에 CPU를 점유하다 보니, 숫자만 보고 판단하면 놓치는 부분이 많았습니다. 버티기는 해도, 모든 기능을 마음 놓고 켜둘 정도는 아니었습니다. 

문제는 관리자 화면보다 서버 로그에서 먼저 보였습니다

처음 이상하다고 느낀 건 관리자 화면 체감 속도보다 error_log였습니다.

관리자 화면은 그냥 조금 느리다고 넘길 수도 있지만, 서버 로그는 실제로 어떤 작업이 반복되고 있는지 훨씬 솔직하게 보여줍니다.

실제로 반복적으로 눈에 들어온 작업 이름은 아래와 같았습니다.

• rocket_saas_pending_jobs
• rocket_saas_on_submit_jobs
• action_scheduler_run_queue_rucss
• rocket_preload_process_pending
• rank_math/analytics/workflow
• rank_math/analytics/email_report_event
• action_scheduler/migration_hook

이런 이름은 처음 보면 그냥 워드프레스 내부 작업처럼 보입니다. 저도 예전에는 크론 정도로만 생각하고 지나쳤습니다.

그런데 같은 항목이 계속 쌓이거나 실패 기록이 반복되면 얘기가 달라집니다. 그때부터는 단순 설치 상태가 아니라, 서버가 실제로 일을 계속 떠안고 있는 상태로 봐야 합니다. 

WP Rocket이 실제로 만들던 요청

error_log만 본 것이 아니라 access 로그도 같이 확인했습니다. 그때 눈에 들어온 건 일반 방문자 요청이 아니라, 플러그인이 직접 만들어내는 요청들이었습니다.

• WP Rocket/Preload
• WP-Rocket/SaaS
• /wp-content/cache/background-css/
• ?nowprocket=1&no_optimize=1&wpr_imagedimensions=1

이걸 보고 느낀 점이 컸습니다. 캐시 플러그인은 단순히 캐시 파일만 만드는 줄 알았는데, 실제로는 preload 요청과 background CSS 생성, SaaS 처리 요청까지 서버에서 계속 돌리고 있었습니다.

여기에 Bingbot, AhrefsBot 같은 외부 크롤러까지 겹치면 php-fpm이 바빠지는 건 자연스러운 결과였습니다. 

WP Rocket에서 특히 조심해야 했던 기능

CSS 전달 최적화

점수만 보면 가장 먼저 켜고 싶어지는 기능으로 저도 그랬습니다.

다만 실제 서버에서는 RUCSS, background CSS, SaaS 요청과 연결되면서 계속 추가 작업을 만들 수 있었습니다. 결과적으로 점수는 예뻐질 수 있어도, 서버 입장에서는 해야 할 일이 늘어날 수 있습니다.

사전 로드 활성화

사전 로드는 글이 새로 올라오거나 수정될 때 preload 요청을 계속 발생시킬 수 있습니다.

일단 글 수가 많고 수정이 잦은 블로그에서는 생각보다 부담이 큽니다. 저도 access 로그에 WP Rocket/Preload가 반복적으로 찍히는 걸 확인하고 나서야 체감이 아니라 실제 원인이라는 걸 알았습니다.

링크 사전 로드 활성화

이 기능은 꺼도 사이트가 망가지지 않습니다. 하지만 내부 링크가 많고 글 페이지 수가 많은 사이트에서는 체감보다 먼저 요청 수가 늘어날 수 있습니다.

그래서 저라면 서버가 예민한 시간대가 있거나, 여러 사이트를 함께 운영하는 VPS라면 이 기능부터 먼저 꺼두겠습니다. 

WP Rocket만 보면 안 되고 Jetpack과 Rank Math도 같이 봐야 했습니다

이번에 느낀 건 속도 플러그인 하나만 보고 판단하면 안 된다는 점이었습니다. 실

제 환경에서는 Jetpack, Rank Math, Action Scheduler까지 함께 얽혀 있었습니다.

rank_math/analytics/workflow
rank_math/analytics/email_report_event
action_scheduler/migration_hook

이런 작업이 있다고 해서 무조건 문제가 있다는 뜻은 아닙니다.

하지만 사이트가 커지고 플러그인이 늘어날수록, 각 플러그인의 배경 작업이 동시에 돌아가면서 서버 부담이 누적됩니다.

저도 결국 실패한 스케줄 액션을 정리하고, 실제로 쓰지 않는 작업은 지우는 방식으로 정리했습니다. 

제가 실제로 확인했던 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

워드프레스 크론과 Rocket 관련 작업 확인

wp cron event list --path=/home/계정/public_html --allow-root | egrep 'rocket|rank_math|action_scheduler'
wp cron event run --due-now --path=/home/계정/public_html --allow-root

실패한 Action Scheduler 흔적 정리

wp action-scheduler clean --status=failed --before="$(date '+%Y-%m-%d %H:%M:%S')" --path=/home/계정/public_html --allow-root
wp action-scheduler run --path=/home/계정/public_html --allow-root

에러 로그 확인

tail -n 100 /home/계정/public_html/error_log 2>/dev/null
tail -n 100 /home/계정/public_html/사이트경로/error_log 2>/dev/null

access 로그에서 preload와 SaaS 요청 확인

tail -n 20 /home/계정/access-logs/* 2>/dev/null | head -200

저는 이런 식으로 확인하다가 preload와 SaaS 요청이 계속 찍히는 걸 보고, 관리자 화면 체크박스만 보고 안심하면 안 되겠다고 느꼈습니다. 

제가 WP Rocket을 더 가볍게 쓰기로 한 이유

중요했던 건 사이트별 반응이 달랐다는 점입니다.

어떤 사이트는 WP Rocket을 켠 상태에서도 당장 큰 에러로그는 없었지만 preload와 SaaS 요청은 실제로 계속 돌고 있었습니다. 반대로 어떤 사이트는 충돌 이력이 있었고, 유지보수 모드까지 보였기 때문에 훨씬 보수적으로 접근해야 했습니다.

그래서 저는 이렇게 정리했습니다. 실제 문제가 있었던 사이트는 WP Rocket을 끄고, 다른 사이트는 완전히 끄지는 않더라도 CSS 전달 최적화, 사전 로드, 링크 사전 로드는 꺼두는 방향으로 운영했습니다.

캐시 수명도 무조건 길게 잡기보다 5시간 정도로 적당히 두는 편이 훨씬 무난했습니다. 

비슷한 플러그인도 같은 식으로 조심해야 했습니다

이번 경험이 WP Rocket만의 특별한 문제라고 보기는 어렵습니다.

LiteSpeed Cache, Autoptimize, FlyingPress 같은 플러그인도 결국 캐시 생성, CSS 처리, preload, background 작업을 합니다. 이름만 다를 뿐 서버가 해야 할 일이 늘어나면 php-fpm과 MySQL이 바빠지는 건 똑같습니다.

저는 이번에 이걸 겪고 나서부터는 무슨 플러그인이 더 좋으냐보다, 어떤 기능을 켜면 서버가 실제로 무거워지는지를 먼저 보게 됐습니다. 점수보다 로그가 훨씬 솔직했습니다. 

Redis 중복 로드와 memory_limit 경고도 함께 정리했습니다

속도 플러그인만의 문제로 끝난 게 아니었습니다. 로그를 보다 보니 Redis와 PHP 설정 문제도 같이 드러났습니다.

WHM(EasyApache 4) PHP 8.4 OPcache + Redis Object Cache 구성 장애 복구후기

error_log에서는 Module "redis" is already loaded 경고가 반복됐습니다.

이건 워드프레스 플러그인이 아니라 PHP 설정에서 Redis 확장이 중복 로드되고 있다는 뜻이었습니다.

Redis를 이미 비활성화하고 삭제했는데도 로그에 계속 남아 있었기 때문에 더 헷갈리기 쉬운 상태였습니다.

저는 실제로 PHP ini 경로를 확인하고 중복된 redis 로드 설정을 정리했습니다.

Redis 중복 로드 확인 명령어

php --ini
php -m | grep -i redis
grep -Rni "redis.so\|extension=redis" /opt/cpanel/ea-php*/root/etc 2>/dev/null

그리고 또 하나 눈에 띈 게 Failed to set memory limit to 256 bytes 경고였습니다.

원래는 256MB처럼 잡혀야 할 값이 256 bytes처럼 잘못 해석되는 흔적이 있었고, 이 역시 워드프레스 플러그인보다 PHP 설정 쪽 문제였습니다.

memory_limit 확인 명령어

php -i | grep -i '^memory_limit'
grep -Rni "memory_limit" /opt/cpanel/ea-php*/root/etc /home/계정/public_html 2>/dev/null

저는 결국 속도 플러그인을 점검하다가 Redis 중복 로드와 PHP memory_limit 설정 오류까지 같이 정리하게 됐습니다.

따로 보면 전혀 다른 문제 같지만, 로그를 계속 보다 보면 결국 한 번에 걸려 나오는 경우가 많았습니다. :{index=9}

제가 이번에 내린 결론

워드프레스 속도 플러그인은 분명 도움이 됩니다.

다만 항상 서버를 가볍게 만들어주는 건 아니었습니다. 어떤 환경에서는 preload, SaaS, background CSS, Jetpack과 Rank Math 배경 작업, PHP 설정 문제까지 겹치면서 오히려 느려짐과 부하를 만들 수 있습니다.

저라면 이제 무조건 기능을 많이 켜는 방식보다, error_log와 access 로그를 먼저 보고 필요한 기능만 남기겠습니다.

페이지 점수 몇 점보다 서버가 조용하게 버티는지가 훨씬 중요했고, 저는 이번에 그 차이를 직접 확인했습니다. 

이런 환경이라면 특히 더 조심하는 편이 좋았습니다

• VPS 한 대에 워드프레스 사이트를 여러 개 운영하는 경우
• 글 수가 많고 수정이 잦은 블로그를 운영하는 경우
• Bingbot, AhrefsBot 같은 외부 크롤러 유입이 많은 경우
• PHP 배경 작업이 이미 자주 도는 경우
• 메모리는 버틸 만해도 swap이 이미 사용 중인 경우
• Jetpack, Rank Math, Action Scheduler 관련 작업이 함께 있는 경우

저도 처음에는 4 CPU, 7.68GB 메모리, 4GB 스왑 정도면 충분하다고 생각했습니다.

그런데 실제 운영에서는 preload와 SaaS 요청, 다른 플러그인 배경 작업이 겹치면 이 사양에서도 부담이 생겼습니다. 숫자만 믿고 기능을 다 켜두는 방식은 이제 저도 추천하지 않습니다. 

자주 묻는 질문

Q. WP Rocket을 쓰면 무조건 사이트가 빨라지나요?

아닙니다. 페이지 캐시만 가볍게 쓰면 도움이 되지만, preload나 SaaS, CSS 배경 처리 기능이 서버 환경과 맞지 않으면 오히려 php-fpm과 MySQL 부하를 키울 수 있습니다.

Q. WP Rocket 관련 크론이 보이면 바로 문제라고 봐야 하나요?

크론 생성 자체는 정상일 수 있습니다. 다만 같은 작업이 반복적으로 실패하거나 preload, SaaS 요청, 유지보수 모드, cron 저장 실패로 이어진다면 실제 운영 문제로 봐야 합니다.

Q. Jetpack이나 Rank Math 같은 다른 플러그인도 영향을 주나요?

그렇습니다. Jetpack 크론, Rank Math 분석 작업, Action Scheduler 관련 훅이 동시에 돌면 WP Rocket과 겹쳐 서버 부담이 커질 수 있습니다.

Q. 서버 부하가 의심될 때 무엇부터 보면 좋을까요?

error_log, access 로그, php-fpm 상단 프로세스, mysqld 점유율, swap 사용량을 먼저 보는 편이 좋습니다. 그리고 preload, SaaS, CSS 전달 최적화 같은 무거운 기능은 먼저 꺼보고 비교하는 쪽이 더 안전합니다.