워드프레스 서버 10년 간 쌓인 찌꺼기 데이터 정리 - 고어크론 예약 및 안쓰는 이미지 제거

잡가이버 2026. 7. 2. 04:20

728x90

워드프레스를 오래 운영하다 보면 글 수보다 더 무섭게 늘어나는 것이 있습니다. 캐시 파일, 예전 플러그인 옵션, 사용하지 않는 썸네일, 실패한 예약작업 기록, 휴지통 글, 스팸 댓글, 비활성 플러그인 파일이 대표적입니다.

겉으로는 사이트가 잘 열려도 서버 안에서는 이런 찌꺼기 데이터가 계속 쌓이면서 관리 화면이 느려지고, 디스크 용량이 줄고, 백그라운드 작업이 무거워집니다.

특히 5년 이상 운영한 워드프레스는 단순히 플러그인 몇 개 끄는 것으로 끝나지 않습니다. 무엇을 먼저 보고, 무엇을 지우고, 무엇은 절대 건드리면 안 되는지 순서를 잡아야 합니다.

그럼 서버관리등을 모르는 초보자도 따라 할 수 있게 아주 기초적인 부분부터 SSH와 WP-CLI를 쓸 줄 아는 분들이 바로 적용할 수 있는 명령어까지 함께 정리했습니다.

정리 전에 먼저 알아둘 원칙

워드프레스 최적화에서 가장 중요한 것은 무조건 삭제하지 않는 것입니다.

오래된 사이트일수록 이미지, 옵션, 캐시, 예약작업이 서로 연결되어 있기 때문인데요 일단 이름이 낯설다고 지우면 사이트가 깨질 수 있기 때문에 저는 항상 먼저 백업을 만들고, 캐시를 비우고, 옵션은 현재 활성 플러그인과 연결된 것인지 확인한 뒤에만 삭제합니다.

가장 안전한 순서는 이렇습니다.

먼저 서버에서 어디가 가장 큰 용량을 차지하는지 확인하고, 그다음 백업을 만든 뒤 캐시와 트랜지언트를 비웁니다.

그 후 예약작업과 액션 스케줄러를 확인하고, 그다음에 autoload 옵션과 미사용 플러그인 흔적을 정리합니다. 이미지는 항상 맨 마지막입니다. 원본 이미지보다 먼저 오래된 썸네일부터 보는 것이 훨씬 안전합니다.

가장 먼저 볼 것

워드프레스가 느릴 때 처음부터 DB 최적화나 이미지 삭제부터 시작하면 오히려 꼬일 수 있습니다.

먼저 어떤 폴더가 가장 큰지부터 확인해야 합니다. 실제로 오래 운영한 사이트는 백업 파일보다 uploads와 cache 폴더가 더 큰 경우가 많습니다.

워드프레스 플러그인등을 사용하느거보다 서버의 WHM으로 접속하여 SSH로 진행하느것이 깔끔하고 빠릅니다.

du -h --max-depth=2 /home/USER/public_html 2>/dev/null | sort -hr | head -50

du -h --max-depth=2 /home/USER/public_html/site1/wp-content 2>/dev/null | sort -hr | head -50
du -h --max-depth=2 /home/USER/public_html/site2/wp-content 2>/dev/null | sort -hr | head -50
du -h --max-depth=2 /home/USER/public_html/site3/wp-content 2>/dev/null | sort -hr | head -50

이 명령을 실행하면 어떤 사이트의 uploads, cache, plugins, themes가 큰지 한눈에 볼 수 있습니다. 제 경험상 10년 운영한 블로그는 업로드 폴더가 가장 크고, 그다음이 캐시인 경우가 많았습니다.

백업부터 먼저 만들기

오래된 사이트는 작은 옵션 하나만 잘못 지워도 예전 설정이 날아갈 수 있습니다.

그래서 저는 옵션 정리나 썸네일 정리 전에 무조건 백업부터 만듭니다.

글 수가 많지 않아 보여도 이미지와 옵션이 복잡하게 얽혀 있기 때문에 백업은 선택이 아니라 기본입니다.

mkdir -p /root/wp-fix-backup

cd /home/USER/public_html/site1
wp db export /root/wp-fix-backup/site1-before-clean-$(date +%F-%H%M).sql --allow-root

cd /home/USER/public_html/site2
wp db export /root/wp-fix-backup/site2-before-clean-$(date +%F-%H%M).sql --allow-root

cd /home/USER/public_html/site3
wp db export /root/wp-fix-backup/site3-before-clean-$(date +%F-%H%M).sql --allow-root

파일 백업까지 같이 하려면 아래처럼 사이트 폴더를 압축해 두는 것이 안전합니다.

tar -czf /root/wp-fix-backup/site1-files-$(date +%F-%H%M).tar.gz /home/USER/public_html/site1

wp-config.php에서 먼저 확인할 설정

오래된 워드프레스는 파일 삭제나 업데이트를 할 때 FTP 방식으로 꼬이는 경우가 있습니다.

이럴 때 FS_METHOD를 direct로 잡아두면 불필요하게 FTP 경로를 거치지 않아 오류가 줄어드는 경우가 많습니다. 특히 캐시 파일 삭제, 이미지 재생성, 일부 플러그인 업데이트에서 체감되는 경우가 많습니다.

grep -q "FS_METHOD" /home/USER/public_html/site1/wp-config.php || \
sed -i "/That's all, stop editing/i define('FS_METHOD', 'direct');" /home/USER/public_html/site1/wp-config.php

여러 사이트를 함께 운영 중이라면 각 사이트마다 같은 방식으로 적용하면 됩니다.

파일 권한 정리는 어디까지 해야 하나

이미지 생성이 실패하거나 캐시 폴더가 비워지지 않거나 플러그인 업데이트가 꼬이는 사이트는 파일 소유권과 권한이 어긋난 경우가 있습니다.

다만 오래된 워드프레스는 파일 수가 많아서 전체 루트에 권한을 한 번에 걸면 시간이 굉장히 오래 걸릴 수 있습니다. 특히 이미지가 수십만 개 수준이면 더 오래 걸립니다.

그래서 초보자라면 전체 루트보다 먼저 wp-content만 정리하는 것이 안전합니다.

chown -R USER:USER /home/USER/public_html/site1/wp-content
find /home/USER/public_html/site1/wp-content -type d -exec chmod 755 {} \;
find /home/USER/public_html/site1/wp-content -type f -exec chmod 644 {} \;

이 작업은 속도를 올리는 작업이라기보다, 파일 쓰기와 캐시 생성이 꼬이지 않게 만드는 안정화 작업에 가깝습니다.

캐시와 트랜지언트부터 먼저 비우기

최대한 원본 콘텐츠를 건드리지 않으면서 가장 먼저 효과를 보기 좋은 부분은 캐시와 트랜지언트입니다. 오래 운영한 사이트는 예전 캐시 파일, 오래된 transient, rewrite 규칙 찌꺼기가 누적되어 관리 화면이 느려지는 경우가 있습니다.

cd /home/USER/public_html/site1
wp transient delete --all --allow-root
wp cache flush --allow-root
wp rewrite flush --hard --allow-root

WP Rocket을 사용 중이라면 캐시 폴더를 직접 비우는 것도 가능합니다.

rm -rf /home/USER/public_html/site1/wp-content/cache/*
wp cache flush --allow-root --path=/home/USER/public_html/site1

이 단계는 비교적 부담이 적고, 지워도 다시 생성되는 데이터이기 때문에 오래된 사이트를 정리할 때 가장 먼저 하기 좋습니다.

예약작업과 액션 스케줄러 확인

워드프레스는 겉으로는 멀쩡해 보여도 안쪽에서 예약작업이 실패한 상태로 쌓여 있을 수 있습니다.

특히 캐시 플러그인, SEO 플러그인, 통계 플러그인, Jetpack 계열이 액션 스케줄러를 많이 씁니다.

여기서 failed 작업이 과도하게 쌓이면 관리 화면이 무거워질 수 있습니다.

cd /home/USER/public_html/site1
wp db check --allow-root
wp db optimize --allow-root
wp cron event run --due-now --allow-root

액션 스케줄러 누적도 같이 확인할 수 있습니다.

cd /home/USER/public_html/site1
PREFIX=$(wp db prefix --allow-root)
wp db query "SELECT status, COUNT(*) cnt FROM ${PREFIX}actionscheduler_actions GROUP BY status;" --allow-root

예를 들어 complete가 몇백 개 수준이고 pending이 소수인 정도라면 대체로 정상 범위로 볼 수 있습니다.

failed가 수천 개씩 쌓여 있으면 그때는 해당 플러그인을 따로 점검하는 편이 좋습니다.

autoload 옵션이 왜 중요할까

워드프레스는 페이지 요청 시 autoload='yes'로 저장된 옵션을 함께 읽습니다.

사이트가 오래될수록 예전 플러그인 흔적이 여기에 남아 관리 화면과 첫 요청 응답을 무겁게 만드는 경우가 있습니다. 무조건 지우면 안 되지만, 오래전에 지운 플러그인의 흔적이라면 정리할 가치가 있습니다.

cd /home/USER/public_html/site1
PREFIX=$(wp db prefix --allow-root)
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM ${PREFIX}options WHERE autoload='yes' ORDER BY size DESC LIMIT 30;" --allow-root

오래된 사이트에서 자주 보이는 흔적은 이런 식입니다.

jetpack_*, googlesitekit_*, elementor_*, wpforms_*, widget_ocean_*, wpseo_*, redux_*

반대로 아래는 이름이 낯설어도 건드리면 안 됩니다.

active_plugins, rewrite_rules, *_user_roles, 현재 활성 플러그인의 핵심 설정값

실제로 미사용 흔적을 삭제할 때는 현재 플러그인 목록과 비교한 뒤 진행합니다.

cd /home/USER/public_html/site1
wp plugin list --allow-root | egrep "jetpack|google-site-kit|site-kit|elementor|wpforms|wordpress-seo|rank-math|seo-by-rank-math|ocean|redux"

현재 사용하지 않는 것으로 확인됐다면 아래처럼 삭제할 수 있습니다.

cd /home/USER/public_html/site1

wp option delete jetpack_active_plan --allow-root
wp option delete jetpack_options --allow-root
wp option delete jetpack_available_modules --allow-root
wp option delete googlesitekit_credentials --allow-root
wp option delete googlesitekit_active_modules --allow-root
wp option delete _elementor_assets_data --allow-root
wp option delete elementor_install_history --allow-root
wp option delete wpforms_admin_notices --allow-root
wp option delete widget_ocean_about_me --allow-root
wp option delete wpseo_social --allow-root

삭제 명령에서 warning이 떠도 너무 걱정할 필요는 없습니다. 이미 없는 옵션이라서 못 지운 경우가 많습니다.

inactive 플러그인과 테마도 정리해야 하는 이유

워드프레스 속도 얘기만 나오면 DB만 떠올리기 쉬운데, 오래된 사이트는 inactive 플러그인과 테마도 무시하면 안 됩니다.

폴더 수가 늘어나면 파일 탐색 시간이 늘고, 보안 면에서도 좋지 않습니다. 복구용 기본 테마 하나 정도만 남기고 실제로 쓰지 않는 것들은 줄이는 편이 낫습니다.

cd /home/USER/public_html/site1
wp plugin list --status=inactive --allow-root
wp theme list --allow-root

리비전과 휴지통 글, 스팸 댓글 정리

글이 많은 블로그는 리비전과 휴지통 데이터도 은근히 큽니다. 특히 자주 수정하는 블로그는 리비전이 계속 누적됩니다.

이 부분은 비교적 안전하게 정리할 수 있는 편입니다.

cd /home/USER/public_html/site1

wp post delete $(wp post list --post_type='revision' --format=ids --allow-root) --force --allow-root
wp post delete $(wp post list --post_status=trash --format=ids --allow-root) --force --allow-root
wp comment delete $(wp comment list --status=spam --format=ids --allow-root) --force --allow-root
wp comment delete $(wp comment list --status=trash --format=ids --allow-root) --force --allow-root

가장 큰 찌꺼기는 원본보다 썸네일이다

10년 운영 블로그를 점검하면 가장 큰 용량은 원본 이미지보다 자동 생성된 썸네일인 경우가 많습니다.

업로드 폴더는 몇 GB 수준인데, 잘못 만들어진 커스텀 사이즈나 예전 테마 썸네일이 수만 개씩 남아 있는 일이 흔합니다.

find /home/USER/public_html/site1/wp-content/uploads -type f | \
grep -E -- '-[0-9]+x[0-9]+\.(jpg|jpeg|png|webp|avif)$' | wc -l

du -sh /home/USER/public_html/site1/wp-content/uploads

그리고 어떤 규격이 많이 생성됐는지 먼저 확인합니다.

find /home/USER/public_html/site1/wp-content/uploads -type f | \
sed -nE 's/.*-([0-9]+x[0-9]+)\.(jpg|jpeg|png|webp|avif)$/\1/p' | \
sort | uniq -c | sort -nr | head -50

예를 들면 이런 결과가 나올 수 있습니다.

18770 150x150
4332 300x169
3875 768x432
3814 1200x675
3735 1024x576
3246 300x214
3225 66x66

여기서 중요한 점은 150x150처럼 현재 워드프레스가 기본으로 쓰는 크기까지 지우면 안 된다는 것입니다.

먼저 현재 등록된 이미지 크기를 확인해야 합니다.

cd /home/USER/public_html/site1
wp eval '
$sizes = [];
foreach (get_intermediate_image_sizes() as $size) {
  $sizes[$size] = [
    "w" => get_option("{$size}_size_w"),
    "h" => get_option("{$size}_size_h"),
    "crop" => get_option("{$size}_crop")
  ];
}
global $_wp_additional_image_sizes;
foreach ($_wp_additional_image_sizes as $name => $data) {
  $sizes[$name] = ["w"=>$data["width"],"h"=>$data["height"],"crop"=>$data["crop"]];
}
print_r($sizes);
' --allow-root

이 결과와 비교해서 현재 등록되지 않은 구형 커스텀 썸네일만 후보로 잡아야 합니다. 예를 들어 현재 등록된 사이즈가 150x150, 300x300, 768, 1024x1024, 1536x1536, 2048x2048이라면, 66x66, 177x142, 300x169, 320x202, 460x295 같은 오래된 규격은 삭제 후보가 될 수 있습니다.

안 쓰는 썸네일을 가장 안전하게 지우는 방법

원본 이미지 전체를 자동 삭제하는 방식은 위험합니다.

가장 안전한 방법은 현재 사용하지 않는 구형 썸네일 규격만 골라서 목록 생성 → 백업 압축 → 삭제 순서로 진행하는 것입니다.

mkdir -p /root/thumb-backup

find /home/USER/public_html/site1/wp-content/uploads -type f | \
grep -E -- '-(66x66|177x142|300x169|320x202|460x295|540x272|669x272)\.(jpg|jpeg|png|webp|avif)$' \
> /root/thumb-backup/site1-old-thumbs.txt

tar -czf /root/thumb-backup/site1-old-thumbs-$(date +%F-%H%M).tar.gz \
-T /root/thumb-backup/site1-old-thumbs.txt

cat /root/thumb-backup/site1-old-thumbs.txt | xargs -d '\n' rm -f

이 방식의 장점은 문제가 생겨도 tar.gz 백업에서 바로 복원할 수 있다는 점입니다. 저는 원본 이미지 전체 정리보다 이런 방식이 훨씬 안전하다고 봅니다.

Regenerate Thumbnails Advanced는 어떻게 써야 하나

이 플러그인은 현재 필요한 썸네일을 다시 생성하는 용도로는 괜찮지만, 무료 버전에서는 체크하지 않은 크기를 자동 삭제하는 기능이 제한될 수 있습니다.

그래서 처음부터 전체 삭제 느낌으로 쓰기보다는 재생성 도구로 생각하는 편이 맞습니다.

실제로는 최근 이미지 몇 개만 먼저 테스트하고, 현재 사이트가 실제로 쓰는 썸네일 크기만 체크해서 돌려본 뒤, 깨짐이 없는 것을 확인하고 전체 재생성으로 넘어가는 것이 안전합니다. 구형 썸네일 삭제는 플러그인보다 SSH에서 백업 후 삭제가 더 안정적입니다.

안 쓰는 이미지 자동 삭제가 왜 위험한가

초보자가 가장 많이 궁금해하는 것이 “안 쓰는 이미지만 자동으로 지우는 방법”인데, 완전히 안전한 자동 삭제는 없습니다.

워드프레스 이미지는 본문에 직접 삽입되기도 하고, 대표이미지로 쓰이기도 하고, 위젯이나 슬라이더, SEO 공유이미지, 테마 함수에서 불러오기도 합니다. 그래서 플러그인이 안 쓴다고 판단해도 실제로는 쓰는 경우가 있습니다.

그래서 가장 안전한 방향은 원본 이미지 자동 삭제가 아니라 현재 등록되지 않은 구형 썸네일만 정리하는 방식입니다. 이게 체감 용량 감소와 안전성의 균형이 가장 좋습니다.

어떤 옵션은 절대 지우면 안 된다

옵션 테이블을 정리하다 보면 이름이 낯설어서 지우고 싶어지는 항목이 많습니다. 하지만 아래는 지우면 안 됩니다.

active_plugins는 현재 활성 플러그인 목록이고, rewrite_rules는 퍼머링크 규칙입니다. 그리고 *_user_roles는 사용자 권한 정보라서 지우면 사이트 권한이 꼬일 수 있습니다. 현재 활성 플러그인의 핵심 설정값도 유지하는 것이 맞습니다.

초보자 기준으로 추천하는 정리 순서

처음 하는 분이라면 아래 순서대로 가는 것이 가장 안전합니다.

첫째, 용량 큰 폴더 확인. 둘째, DB와 파일 백업. 셋째, 캐시와 트랜지언트 정리. 넷째, 예약작업 확인. 다섯째, inactive 플러그인과 테마 점검. 여섯째, autoload 옵션 찌꺼기 정리. 일곱째, 리비전과 휴지통 정리. 여덟째, 현재 등록되지 않은 구형 썸네일만 백업 후 삭제.

워드프레스 10년 운영 사이트 최적화는 플러그인 하나 깔아서 끝나는 일이 아닙니다. 진짜 효과가 큰 것은 캐시 누적, 옵션 찌꺼기, 리비전, 예약작업 누적, 과다 썸네일을 순서대로 정리하는 것입니다. 특히 원본 이미지보다 구형 썸네일부터 정리하는 접근이 훨씬 안전합니다.

사이트가 느려졌다고 무조건 서버 스펙부터 올릴 필요는 없습니다. 오래 운영하면서 쌓인 내부 찌꺼기만 정리해도 관리 화면 응답, 캐시 생성, 예약작업 안정성, 디스크 사용량이 확실히 달라질 수 있습니다.

그리드형

저작자표시 비영리 변경금지 (새창열림)