알마리눅스 9.7 워드프레스 서버 느림 해결과 예약글 오류 정리

알마리눅스 9.7 워드프레스 서버가 갑자기 느려질 때 먼저 봐야 하는 것

워드프레스 사이트를 몇 년만 운영해도 이상하게 처음보다 점점 무거워지는 느낌이 생깁니다. 저도 처음에는 단순히 서버 사양이 부족한 줄 알았는데, 막상 하나씩 열어보면 예약 작업 누락, 플러그인 내부 작업 실패, 봇 요청 과다, 캐시 미적용처럼 서로 다른 원인이 한꺼번에 겹친 경우가 많았습니다.

특히 AlmaLinux 9.7에 cPanel과 WHM, 워드프레스를 같이 운영하는 환경에서는 WHM이 느려졌다고 해서 꼭 WHM 자체 문제라고 단정하면 안 됩니다.

실제로는 php-fpm이 특정 워드프레스 사이트 요청에 계속 묶여 있거나, MySQL이 쿼리를 오래 끌고 있거나, 외부에서 들어오는 불필요한 요청이 서버를 계속 두드리고 있는 경우가 더 많습니다.

블루호스트 VPS WHM & C-Panel 업데이트 설치

그럼 AlmaLinux 9.7 기반 워드프레스 서버를 운영하면 오래된 고어파일을 제거하여 최적화는 방법에 대해 알아보도록 하겠습니다.

서버 느림 증상 확인

가장 먼저 할 일은 막연하게 플러그인부터 지우는 것이 아니라, 지금 서버가 어디에서 시간을 쓰고 있는지 확인하는 것입니다.

Advanced DB Cleaner PRO 후기 워드프레스 테이블, Cron Jobs 삭제

같은 느림이라도 php-fpm이 문제인지, MySQL이 문제인지, swap을 쓰고 있는지부터 구분해야 뒤 작업이 헛돌지 않습니다.

확인 항목	왜 보는지	점검 명령어 예시
php-fpm 점유	특정 사이트 요청이 몰리는지 확인	top, ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -20
MySQL 사용량	DB 쿼리로 병목이 생기는지 확인	top, mysqladmin proc status
메모리와 swap	물리 메모리 부족 여부 확인	free -m, vmstat 1 5
Apache 로그	봇과 관리자 요청 구분	awk, grep, tail

여기서 php-fpm 프로세스 이름에 특정 사이트 풀이 반복해서 보이면 그 사이트를 먼저 잡아야 합니다. 제 경험상 이 단계만 잘 봐도 어디서부터 손대야 할지 금방 방향이 잡혔습니다.

wp-cron 누락 확인

워드프레스 예약글 실패나 플러그인 예약 작업 오류는 의외로 단순합니다.

wp-config.php에서 wp-cron을 꺼놓고, 실제 서버 cron 등록을 빼먹은 경우가 정말 많습니다.

워드프레스 최적화 글을 보다 보면 성능 때문에 아래 설정을 넣는 경우가 많습니다.

define('DISABLE_WP_CRON', true);

이 설정 자체는 괜찮습니다. 문제는 이걸 넣고 나서 서버 cron을 같이 등록하지 않으면 예약글, 사이트맵 갱신, 캐시 정리 같은 작업이 뒤에서 조용히 밀리기 시작한다는 점입니다.

예시는 아래처럼 잡으면 됩니다.

*/5 * * * * /usr/local/bin/php /home/USER/public_html/wp-cron.php > /dev/null 2>&1
*/5 * * * * /usr/local/bin/php /home/USER/public_html/site1/wp-cron.php > /dev/null 2>&1
*/5 * * * * /usr/local/bin/php /home/USER/public_html/site2/wp-cron.php > /dev/null 2>&1

등록 후에는 crontab -l 로 실제 줄이 들어갔는지 꼭 봐야 합니다.

저는 이 부분을 놓쳤다가 예약 이벤트가 계속 실패하는 현상을 겪었습니다. 겉보기에는 사이트가 멀쩡해 보여도, 뒤에서는 예약 작업이 밀리고 있을 수 있습니다.

WP CLI 점검

워드프레스 예약 오류를 볼 때는 관리자 화면 경고만 믿지 말고 WP-CLI로 직접 확인하는 편이 훨씬 정확합니다.

어떤 이벤트가 살아 있고 어떤 작업이 실패 중인지 바로 나옵니다.

wp cron event list --path=/home/USER/public_html/site1 --allow-root
wp cron event run --due-now --path=/home/USER/public_html/site1 --allow-root

특정 이벤트만 직접 돌려보는 것도 가능합니다.

wp cron event run rank_math/sitemap/hit_index --path=/home/USER/public_html/site1 --allow-root
wp cron event run rocket_preload_process_pending --path=/home/USER/public_html/site2 --allow-root

여기서 성공 메시지가 나오면 이벤트 자체는 실행된 것입니다.

반대로 이벤트 이름이 잘못됐거나 이미 사라졌다면 invalid cron event 비슷한 메시지가 나올 수 있는데, 이 경우는 무조건 큰 장애라고 보기보다 이미 1회성 이벤트가 실행 후 없어졌는지부터 확인하는 것이 맞습니다.

주의 cPanel 계정에 shell 접근이 비활성화된 경우에는 sudo -u USER -i -- wp ... 방식이 막힐 수 있습니다. 그럴 때는 root에서 --allow-root 옵션을 붙이는 방식으로 점검하는 편이 현실적입니다.

Rank Math 오류 정리

Rank Math를 쓰는 사이트에서는 rank_math/sitemap/hit_index 같은 이벤트가 실패하는 경우가 있습니다.

이건 보통 Rank Math 전체가 고장 난 것이 아니라 사이트맵 관련 1회성 작업이 꼬인 상태로 보는 편이 맞습니다.

wp cron event list --path=/home/USER/public_html/site1 --allow-root | grep rank_math
wp cron event run rank_math/sitemap/hit_index --path=/home/USER/public_html/site1 --allow-root
wp cron event delete rank_math/sitemap/hit_index --path=/home/USER/public_html/site1 --allow-root
wp transient delete --all --path=/home/USER/public_html/site1 --allow-root
wp cache flush --path=/home/USER/public_html/site1 --allow-root
wp cron event run --due-now --path=/home/USER/public_html/site1 --allow-root

그리고 관리자에서 Rank Math → Sitemap Settings 로 들어가 사이트맵 기능을 끔 → 저장 → 다시 켬 → 저장 순서로 한 번 정리해주면 풀리는 경우가 많습니다.

운영 경험상 태그 아카이브와 작성자 아카이브는 필요 없으면 정리하는 편이 훨씬 깔끔했습니다. 특히 태그가 많은 블로그는 태그 sitemap까지 열려 있으면 크롤링 낭비가 쌓이기 쉽습니다.

WP Rocket 오류 정리

WP Rocket은 캐시 자체보다도 preload 계열 작업 때문에 서버가 바빠지는 경우가 있습니다.

rocket_preload_process_pending, rocket_preload_clean_rows_time_event 같은 이름이 반복해서 보이면 사전 로드 작업 잔재를 먼저 의심하는 편이 좋습니다.

먼저 관리자에서 아래 항목을 확인합니다.

• Preload 끔
• Link preload 끔
• CSS 전달 최적화 계열 기능이 과하게 켜져 있지 않은지 확인
• Heartbeat 제어가 과도하게 느슨하지 않은지 확인

그다음 예약 이벤트를 정리합니다.

wp cron event list --path=/home/USER/public_html/site2 --allow-root | grep rocket
wp cron event run rocket_preload_process_pending --path=/home/USER/public_html/site2 --allow-root
wp cron event delete rocket_preload_process_pending --path=/home/USER/public_html/site2 --allow-root
wp transient delete --all --path=/home/USER/public_html/site2 --allow-root
wp cache flush --path=/home/USER/public_html/site2 --allow-root
wp cron event run --due-now --path=/home/USER/public_html/site2 --allow-root

이름이 다른 preload 이벤트가 또 튀더라도 너무 놀랄 필요는 없습니다. 대개는 같은 계열의 잔여 작업이 순서대로 소모되는 경우가 많았습니다.

DB 찌꺼기 정리

몇 년 넘게 운영한 워드프레스는 글보다 revision, 휴지통 글, 스팸 댓글, transient가 더 많이 쌓여 있을 때가 있습니다.

저는 무리하게 플러그인 설치로 정리하기보다 WP-CLI로 1차 정리를 해두는 편이 훨씬 깔끔했습니다.

먼저 백업을 잡습니다.

wp db export /root/site1-before-cleanup.sql --path=/home/USER/public_html/site1 --allow-root

그다음 안전한 범위부터 정리합니다.

wp post delete $(wp post list --post_type=revision --format=ids --path=/home/USER/public_html/site1 --allow-root) --force --path=/home/USER/public_html/site1 --allow-root
wp post delete $(wp post list --post_status=trash --format=ids --path=/home/USER/public_html/site1 --allow-root) --force --path=/home/USER/public_html/site1 --allow-root
wp comment delete $(wp comment list --status=spam --format=ids --path=/home/USER/public_html/site1 --allow-root) --force --path=/home/USER/public_html/site1 --allow-root
wp transient delete --all --path=/home/USER/public_html/site1 --allow-root
wp cache flush --path=/home/USER/public_html/site1 --allow-root
wp db optimize --path=/home/USER/public_html/site1 --allow-root

여기까지만 해도 오래된 사이트는 체감이 달라집니다.

특히 예약 작업이 많은 블로그는 transient만 정리해도 꽤 가벼워지는 경우가 있습니다.

autoload 옵션 확인

워드프레스가 느린 사이트를 보다 보면 DB 전체 용량보다 autoload 옵션 몇 개가 너무 큰 경우가 있습니다.

요청할 때마다 자동으로 불러오는 값이 커지면 페이지마다 부담이 누적됩니다.

wp option list --autoload=on --fields=option_name,size_bytes --format=table --orderby=size_bytes --order=DESC --path=/home/USER/public_html/site1 --allow-root | head -30

여기서 예전에 쓰던 SEO 플러그인이나 오래전에 바꾼 테마 옵션이 남아 있는 경우가 있습니다.

예를 들어 지금 Rank Math를 쓰는데 Yoast 설정이 남아 있다면 선택적으로 정리할 수 있습니다.

wp option delete wpseo_titles --path=/home/USER/public_html/site1 --allow-root
wp option delete wpseo --path=/home/USER/public_html/site1 --allow-root
wp option delete wpseo_taxonomy_meta --path=/home/USER/public_html/site1 --allow-root

주의 현재 사용하는 플러그인의 설정을 지우면 사이트가 깨질 수 있습니다. active_plugins, rewrite_rules, cron, widget_*, 현재 실제로 쓰는 Rank Math와 WP Rocket 설정은 함부로 지우지 않는 편이 안전합니다.

로그 분석 방법

서버가 바쁜데 실제 방문자는 많지 않다면, 거의 항상 Apache 로그를 먼저 보는 편이 좋습니다.

티스토리나 네이버 블로그처럼 단순 방문자 수만 보는 습관으로는 이 부분이 잘 안 보이는데, 워드프레스 서버는 요청 종류를 직접 봐야 합니다.

awk '{print $1,$7}' /usr/local/apache/domlogs/example.com-ssl_log | tail -5000 | sort | uniq -c | sort -nr | head -50
grep -Ei 'bot|crawl|spider|ahrefs|semrush|mj12|bingbot|yeti|applebot' /usr/local/apache/domlogs/example.com-ssl_log | tail -5000 | awk '{print $1,$7}' | sort | uniq -c | sort -nr | head -50
egrep 'wp-admin|admin-ajax|wp-login|wp-json' /usr/local/apache/domlogs/example.com-ssl_log | tail -5000 | awk '{print $1,$7}' | sort | uniq -c | sort -nr | head -50

이렇게 보면 봇이 많은지, 댓글 API가 공격받는지, 관리자 요청이 과도한지가 어느 정도 구분됩니다.

저는 이 단계에서 외부 대역 요청이 많이 몰린 것을 확인하고, 그제야 왜 php-fpm이 계속 바빴는지 감이 왔습니다.

.htaccess 차단 설정

악성 요청이 반복되면 robots.txt보다 .htaccess 차단이 더 직접적입니다.

예시는 개인정보를 뺀 형태로 정리하면 아래처럼 구성할 수 있습니다.

<RequireAll>
Require all granted
Require not ip 198.51.100.10
Require not ip 203.0.113.50
Require not ip 203.0.113.0/24
</RequireAll>

<Files "wp-comments-post.php">
Require all denied
</Files>

<Files "xmlrpc.php">
Require all denied
</Files>

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|MJ12bot|DotBot|Barkrowler|DataForSeoBot|PetalBot) [NC]
RewriteRule .* - [F,L]

RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/comments [NC]
RewriteRule .* - [F,L]

RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [NC]
RewriteRule .* - [F,L]

댓글을 실제로 안 쓰는 사이트라면 wp-comments-post.php 차단은 꽤 효과가 좋았습니다.

xmlrpc도 특별히 쓸 일이 없다면 막아두는 편이 안전합니다.

주의 본인 회사 IP나 집 IP처럼 관리에 필요한 주소를 실수로 차단하지 않도록 예외 목록부터 먼저 정리하는 것이 좋습니다. 저는 이 부분을 따로 적어두고 작업했습니다.

Cloudflare 캐시 적용

보안과 DB 정리까지 끝났는데도 서버가 바쁘다면 마지막 핵심은 Cloudflare 캐시 적중률입니다.

이 부분이 잡히면 사용자 요청이 매번 원서버까지 내려오지 않아 php-fpm과 MySQL 부담이 확 줄어듭니다.

일반적인 워드프레스 블로그는 아래처럼 분리하는 편이 무난합니다.

• 일반 글, 페이지, 카테고리 캐시 허용
• /wp-admin, /wp-login.php, /wp-json 캐시 제외
• 장바구니, 결제, 마이페이지 캐시 제외

규칙 개념 예시는 아래와 비슷하게 잡을 수 있습니다.

(http.host eq "example.com"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and http.request.uri.path ne "/wp-login.php"
 and not starts_with(http.request.uri.path, "/wp-json")
 and not starts_with(http.request.uri.path, "/cart")
 and not starts_with(http.request.uri.path, "/my-account")
 and not starts_with(http.request.uri.path, "/checkout"))

설정은 아래 조합이 무난했습니다.

• Cache eligibility → Eligible for cache
• Edge TTL → 2시간
• Browser TTL → 원본 존중 또는 1시간
• Ignore query string → ON
• Cache deception armor → ON
• Serve stale content while revalidating → ON

설정 후에는 Purge Everything 를 한 번 실행하고, curl -I https://example.com/ 같은 방식으로 cf-cache-status: HIT 가 뜨는지 보는 것이 좋습니다.

여기까지 뜨면 구조가 바뀐 것입니다. 예전에는 사용자 요청이 서버를 바로 때렸다면, 이제는 Cloudflare가 먼저 응답하는 구간이 늘어납니다.

자주 막히는 부분

상황	원인	확인할 것
예약글이 계속 실패함	서버 cron 누락	crontab -l, wp-cron.php
WP-CLI가 root 실행을 막음	기본 보안 제한	--allow-root 사용
sudo -u USER 가 안 먹음	shell 접근 비활성화	root에서 WP-CLI 실행
Cloudflare 경고창이 뜸	프록시 미확인 경고	DNS 주황 구름 여부 확인 후 Deploy
HIT가 안 뜸	캐시 규칙 미적용, Purge 미실행	규칙 저장, 전체 제거, curl 재확인
프런트 기능 일부 이상	admin-ajax 차단 과도함	해당 규칙만 제거 후 재테스트

처음 따라할 때 추천 순서

처음 하시는 분이라면 한 번에 다 넣기보다 아래 순서대로 진행하는 편이 훨씬 덜 꼬입니다.

먼저 서버 상태를 보고, 그다음 wp-cron 등록 여부를 확인하고, 예약 이벤트 종류를 나눈 뒤, DB 정리와 로그 분석으로 넘어가는 순서가 안정적이었습니다. 그 뒤에 .htaccess 차단과 Cloudflare 캐시를 적용하면 체감 차이가 분명해집니다.

저라면 서버 상태 확인 → cron 등록 → Rank Math와 WP Rocket 정리 → DB와 autoload 정리 → 로그 분석 → 봇 차단 → Cloudflare HIT 확인 순서로 진행하겠습니다. 이 순서가 결국 가장 덜 돌아갑니다.

마무리 정리

AlmaLinux 9.7 환경에서 워드프레스 서버가 느릴 때는 단순히 서버 성능만 의심하면 해결이 늦어집니다. 실제로는 wp-cron 누락, 플러그인 예약 작업 잔여 이벤트, 오래된 옵션과 DB 누적, 외부 봇 요청, 캐시 미적용이 겹쳐서 문제가 커지는 경우가 더 많았습니다.

워드프레스 cPanel 서버에서 PHP-FPM 활성화가 안될 때 확인할 설정

워드프레스 최적화 - WP Rocket 플러그인 사용후기

 

저는 이번 작업을 하면서 오히려 서버를 새로 바꾸기 전에 먼저 정리할 것이 훨씬 많다는 걸 다시 느꼈습니다. 예약글 실패와 WHM 느림이 꼭 운영체제 문제만은 아니었고, 워드프레스 쪽 설정과 외부 요청 구조를 같이 봐야 풀렸습니다.

무조건 한 번에 끝내려고 하기보다 백업 후 한 단계씩 적용하고, 결과를 보고 다음으로 넘어가는 방식이 결국 가장 안전했습니다. 저도 그렇게 했고, 그 편이 훨씬 덜 불안했습니다.

Q. 예약글 실패가 뜨면 바로 플러그인 문제로 봐야 하나요?

A. 먼저 wp-cron이 실제 서버 cron으로 등록되어 있는지부터 보는 편이 좋습니다. 이 부분 하나 빠져도 예약글과 플러그인 예약 작업이 같이 밀릴 수 있습니다.

Q. WP Rocket 이벤트 오류는 서버가 망가진 건가요?

A. 대부분은 preload 계열 잔여 작업이 남은 경우가 많습니다. preload를 끄고 이벤트를 정리하면 잠잠해지는 경우도 적지 않았습니다.

Q. DB 정리만 하면 빨라지나요?

A. 어느 정도는 빨라집니다. 다만 오래된 워드프레스는 DB보다 외부 요청과 캐시 구조가 더 큰 영향을 줄 때도 많습니다.

Q. Cloudflare에서 HIT가 뜨면 무엇이 달라지나요?

A. 일반 글과 페이지 요청이 매번 원서버까지 내려오지 않기 때문에 php-fpm과 MySQL 부담이 크게 줄어듭니다.

Q. .htaccess 차단에서 가장 조심할 점은 무엇인가요?

A. 관리에 필요한 회사 IP나 집 IP를 실수로 막지 않는 것입니다. 차단 전에 예외 IP부터 먼저 적어두는 것이 안전합니다.