워드프레스 중복·미사용 이미지 삭제｜중복사진·미사용 이미지·옛날 썸네일 삭제

잡가이버 2026. 8. 11. 15:33

워드프레스 중복사진·미사용 이미지·오래된 미디어 파일 정리

워드프레스를 몇 년 이상 운영하다 보면 글이나 페이지보다 미디어 라이브러리와 wp-content/uploads 폴더가 더 빠르게 커지는 경우가 있습니다.

처음에는 사진을 많이 올렸으니 당연하다고 생각할 수 있지만 실제 서버를 확인하면 원본 JPG·PNG뿐 아니라 워드프레스가 자동 생성한 썸네일, 과거 테마가 만든 이미지 크기, WebP·AVIF 변환본, 더 이상 사용하지 않는 미디어까지 함께 남아 있는 경우가 많습니다.

워드프레스 미디어 라이브러리에서 미사용 이미지와 중복사진을 정리해 서버 저장공간을 확보하는 방법

먼저 알아둘 점
미사용 이미지와 중복 이미지, 자동 생성된 썸네일은 서로 다른 문제입니다.

Media Cleaner → 사용되지 않는 미디어·깨진 미디어 정리
Media Tracker → 실제 중복 이미지 + 사용 위치 + 미사용 미디어 확인
Unused Media Checker → 콘텐츠에서 실제 사용 중인지 세밀하게 검사
Regenerate Thumbnails → 테마 변경 후 썸네일 재생성 및 옛 사이즈 정리
SSH / WP-CLI → 이미지가 수만~수십만 개일 때 서버에서 직접 분석

Media Cleaner는 중복사진 전용 플러그인은 아니다

예전에 이 글을 작성할 당시에는 Media Cleaner를 중복사진 정리 플러그인처럼 소개했는데 현재 기준으로 보면 조금 구분해서 이해하는 것이 정확합니다.

Media Cleaner의 핵심 기능은 WordPress Media Library를 분석해 사용되지 않는 미디어와 깨진 항목을 찾아 정리하는 것입니다.

반대로 똑같은 사진을 여러 번 업로드한 다음과 같은 실제 중복파일까지 찾고 싶다면 Media Tracker 같은 중복 탐지 기능을 가진 플러그인을 같이 사용하는 편이 낫습니다.

photo.jpg
photo-copy.jpg
photo-1.jpg
photo-final.jpg

이 네 파일이 내용은 같지만 파일명이 다르다면 단순히 파일명만 보고는 중복 여부를 판단하기 어렵습니다.

Media Cleaner 설치 및 다운로드

워드프레스 관리자에서 플러그인 → 새 플러그인 추가로 이동한 뒤 Media Cleaner를 검색해 설치합니다.

Media Cleaner 공식 다운로드

설치 후 일반적으로 Meow Apps → Cleaner에서 설정을 확인하고 Media → Cleaner에서 실제 스캔 결과를 확인합니다.

Media Cleaner 무료버전으로 가능한 것

Media Library 미사용 미디어 검사
깨진 미디어 항목 확인
삭제 전 내부 Trash 활용
검사 결과에서 참조 위치 확인
삭제 후보 개별 검토

실제 wp-content/uploads 파일시스템을 직접 비교해 워드프레스 미디어 라이브러리에 등록조차 되지 않은 고아파일까지 찾는 기능은 더 고급 기능에 해당합니다.

Media Cleaner 추천 설정 - 처음부터 Skip Trash 켜지 말 것

이미지가 많은 사이트라면 처음부터 고급 옵션을 공격적으로 바꾸는 것보다 기본값으로 스캔을 시작하는 편이 좋았습니다.

설정	추천	이유
Clean Library	ON	기본 Media Library 미사용 검사
Skip Trash	OFF	실수 시 복구할 안전장치 유지
Expert Mode	처음에는 OFF	검사 결과를 이해한 뒤 사용
Medias Buffer	100 전후	대량 미디어에서도 비교적 보수적
Posts Buffer	5 → 오류 시 1~2	콘텐츠 분석은 서버 부담이 큼
Analysis Buffer	100 전후	처음에는 기본값 유지
Delay	100ms	Timeout 시 200~500ms로 증가

Skip Trash는 용량이 급하다고 바로 켜지 않는 편이 좋습니다.
삭제된 이미지가 글, 대표이미지, 테마 옵션, CSS 배경 등에 숨어 사용되는 경우가 있기 때문에 먼저 Trash로 보내고 사이트를 확인한 뒤 최종 삭제하는 것이 안전합니다.

Media Cleaner가 중간에 멈추거나 Timeout이 날 때

이미지와 글이 많은 사이트에서는 콘텐츠 분석 단계에서 다음과 같은 시간 초과 오류가 발생할 수 있습니다.

The server request exceeded the safe time limit.

이 경우 무조건 처음부터 다시 스캔하기보다 진행 상태를 이어갈 수 있다면 Resume을 사용하고, 반복해서 멈춘다면 Posts Buffer를 줄이고 Delay를 늘려봅니다.

Posts Buffer
5 → 2 → 그래도 실패하면 1

Delay
100ms → 200ms → 필요 시 500ms

웹호스팅에서는 PHP 실행시간과 메모리 제한도 확인합니다.

php -i | grep memory_limit
php -i | grep max_execution_time

단 SSH에서 보이는 PHP CLI 설정과 Apache·Nginx PHP-FPM이 사용하는 설정은 다를 수 있으므로 cPanel/WHM 환경이라면 MultiPHP INI Editor와 PHP-FPM 설정도 함께 확인하는 것이 좋습니다.

이미지 처리 중 Imagick 관련 경고까지 발생한다면 아래 노랗IT월드 글을 함께 참고할 수 있습니다.

노랗IT월드 - 워드프레스 Imagick 모듈 비활성화 오류 해결

실제 중복사진을 찾으려면 Media Tracker 같이 사용

Media Cleaner로 미사용 이미지를 정리한 뒤에도 같은 사진을 여러 번 올린 중복 파일이 남아 있다면 Media Tracker를 추가로 활용할 수 있습니다.

Media Tracker는 미디어 사용 위치를 추적하면서 Unused Media와 Duplicate Images를 따로 볼 수 있는 것이 장점입니다.

Gutenberg와 Classic Editor뿐 아니라 WooCommerce, ACF, Elementor, Divi 같은 환경도 지원 대상으로 안내하고 있어 페이지빌더나 쇼핑몰 사이트라면 Media Cleaner 결과와 교차 확인하는 용도로 활용하기 좋습니다.

Media Tracker 공식 다운로드

두 플러그인에서 모두 미사용이라고 나온다고 바로 전체 삭제하지는 않는 것이 좋습니다.
테마 CSS, 외부 CSS, JavaScript, 이메일 템플릿, 외부 사이트에서 직접 URL로 호출하는 이미지는 플러그인이 완벽하게 판단하기 어려울 수 있습니다.

삭제 안전성을 더 확인하고 싶다면 Unused Media Checker

사용하지 않는 것처럼 보이는 이미지를 실제로 어디에서 쓰는지 한번 더 확인하고 싶다면 Unused Media Checker도 괜찮은 보조 도구입니다.

현재 버전은 대표이미지, 포스트·페이지·Custom Post Type, 본문의 직접 uploads URL, Customizer의 로고·사이트 아이콘·배경 이미지, Rank Math FAQ 이미지 등을 검사하고 개별 항목을 Inspect할 수 있습니다.

특히 Quick Scan보다 Thorough Scan을 먼저 사용하는 편이 안전하며 대규모 사이트에서는 처음부터 삭제하기보다 Inspect 결과를 몇 장 확인한 뒤 범위를 늘리는 편이 좋습니다.

Unused Media Checker 공식 다운로드

플러그인별 추천 용도 비교

플러그인	잘하는 기능	추천 상황
Media Cleaner	미사용·깨진 미디어 + Trash	전체적인 미디어 정리
Media Tracker	미사용 + 실제 중복파일	중복사진까지 찾고 싶을 때
Unused Media Checker	사용 위치 Inspect	삭제 전 재확인
Regenerate Thumbnails	현재 이미지 사이즈 재생성	테마 변경 이후
Force Regenerate Thumbnails	기존 사이즈 삭제 후 강제 재생성	잘못 생성된 썸네일을 새로 만들 때

테마를 바꾼 뒤 옛날 썸네일이 남았다면 Regenerate Thumbnails

오랫동안 워드프레스를 운영하면 GeneratePress → OceanWP → Avada처럼 테마를 바꾸거나 테마가 업데이트되면서 필요한 이미지 사이즈가 달라질 수 있습니다.

문제는 예전 테마가 만들었던 다음과 같은 썸네일이 테마를 삭제했다고 함께 없어지는 것이 아니라는 점입니다.

photo-1200x700.jpg
photo-800x450.jpg
photo-600x600.jpg
photo-400x300.jpg

이때 현재 테마가 요구하는 썸네일을 다시 생성하려면 Regenerate Thumbnails 계열 플러그인을 사용할 수 있습니다.

Regenerate Thumbnails Force Regenerate Thumbnails reGenerate Thumbnails Advanced

특히 Force Regenerate Thumbnails는 기존 썸네일을 제거하고 현재 필요한 크기로 다시 생성하는 방식이므로 운영 중인 대형 사이트에서 버튼부터 누르기보다는 반드시 백업 후 일부 이미지로 시험하는 편이 좋습니다.

앞으로 쓸데없는 썸네일이 계속 만들어지는 것도 막아야 한다

기존 파일을 아무리 지워도 새 이미지를 올릴 때마다 다시 같은 파생 이미지가 10장씩 만들어진다면 오래 지나지 않아 똑같은 문제가 반복됩니다.

먼저 워드프레스 관리자에서 설정 → 미디어를 확인합니다.

그리고 현재 서버에 실제 등록되어 있는 이미지 사이즈는 SSH와 WP-CLI에서 다음처럼 볼 수 있습니다.

cd /home/USER/public_html

wp media image-size

root 계정이라면:

wp media image-size --allow-root

예:

thumbnail       150   150   hard
medium          300   300   soft
medium_large    768   0     soft
large           1024  1024  soft
theme-card      640   360   hard

여기서 테마나 플러그인이 추가한 이미지 사이즈가 너무 많다면 어느 코드가 등록했는지 찾아볼 수 있습니다.

grep -R --include="*.php" "add_image_size" \
wp-content/themes \
wp-content/plugins \
2>/dev/null

add_image_size 코드가 보인다고 바로 지우면 안 됩니다.
홈 화면, 카테고리, 관련글, WooCommerce 상품 카드처럼 실제로 필요한 사이즈일 수 있습니다. 차일드테마나 Code Snippets를 사용해 생성 중단 여부를 충분히 테스트한 뒤 적용하세요.

이미지 압축과 미사용 이미지 삭제는 별개 작업

Media Cleaner로 미사용 이미지를 지우는 것과 Imagify·Smush로 JPEG·PNG를 압축하거나 WebP로 변환하는 것은 목적이 다릅니다.

저장공간이 크다면 보통 다음 순서가 깔끔합니다.

미사용 원본 이미지 정리
오래된 테마 썸네일 정리
현재 필요한 파생 사이즈만 유지
남은 JPG·PNG 압축
WebP 또는 AVIF 서비스 여부 점검

잡가이버 관련글
워드프레스 WebP·AVIF 변환 및 원본 이미지 삭제 후기

Linux SSH로 wp-content/uploads 용량부터 직접 확인

이미지가 수만 장 이상이라 플러그인이 느리거나 Timeout을 반복한다면 SSH에서 직접 서버 상태를 분석하는 것이 훨씬 빠를 수 있습니다.

AlmaLinux, Rocky Linux, RHEL 계열과 Ubuntu·Debian에서 대부분 비슷하게 사용할 수 있습니다.

아래 예제의 USER와 경로는 자신의 서버 환경에 맞게 바꿉니다.

cd /home/USER/public_html

pwd

du -sh wp-content/uploads

uploads 전체 파일 개수

find wp-content/uploads -type f | wc -l

JPG JPEG 파일 개수

find wp-content/uploads -type f \
\( -iname "*.jpg" -o -iname "*.jpeg" \) \
| wc -l

PNG 파일 개수

find wp-content/uploads -type f \
-iname "*.png" | wc -l

WebP 파일 개수

find wp-content/uploads -type f \
-iname "*.webp" | wc -l

WebP 전체 용량

find wp-content/uploads \
-type f -iname "*.webp" \
-printf '%s\n' \
| awk '{s+=$1} END {printf "%.2f GB\n", s/1024/1024/1024}'

자동 생성된 썸네일만 몇 장인지 찾기

워드프레스 파생이미지는 일반적으로 파일명 뒤에 가로×세로 크기가 붙습니다.

photo-150x150.jpg
photo-300x169.jpg
photo-768x432.jpg
photo-1024x576.jpg

GNU find를 사용하는 Linux 서버라면 다음 명령으로 대략적인 개수를 확인할 수 있습니다.

find wp-content/uploads \
-regextype posix-extended \
-type f \
-iregex '.*-[0-9]+x[0-9]+\.(jpg|jpeg|png|webp|avif)$' \
| wc -l

파생 썸네일 전체 용량 계산

find wp-content/uploads \
-regextype posix-extended \
-type f \
-iregex '.*-[0-9]+x[0-9]+\.(jpg|jpeg|png|webp|avif)$' \
-printf '%s\n' \
| awk '{s+=$1} END {printf "%.2f GB\n", s/1024/1024/1024}'

이 명령들은 조회만 하고 아무것도 삭제하지 않습니다.

연도별로 어느 시기에 이미지가 폭증했는지 확인

du -sh wp-content/uploads/* \
2>/dev/null | sort -hr

예:

3.1G    wp-content/uploads/2022
2.6G    wp-content/uploads/2021
2.0G    wp-content/uploads/2020
650M    wp-content/uploads/2024
320M    wp-content/uploads/2025

특정 연도만 지나치게 크다면 당시 사용한 테마, 페이지빌더 또는 이미지 최적화 플러그인이 어떤 썸네일을 생성했는지 조사해보는 것이 좋습니다.

가장 큰 이미지 파일 50개 찾기

find wp-content/uploads \
-type f \
-printf '%s\t%p\n' \
| sort -nr \
| head -50 \
| numfmt --field=1 --to=iec

10MB 이상의 PNG나 GIF가 수백 장 발견된다면 자동 썸네일 정리보다 원본 이미지 자체를 최적화했을 때 더 큰 효과를 볼 수도 있습니다.

WP-CLI로 현재 필요 없는 옛날 썸네일 삭제

현재 WP-CLI에는 오래된 미등록 이미지 사이즈만 정리하는 --delete-unknown 옵션이 있습니다.

먼저 지원 여부부터 확인합니다.

wp media regenerate --help

지원되는 환경에서 일부 Attachment ID만 테스트하려면:

wp media regenerate 123 456 789 \
--delete-unknown \
--allow-root

테스트 후 이상이 없을 때 전체 적용:

wp media regenerate \
--delete-unknown \
--yes \
--allow-root

전체 실행 전에 반드시 확인
옛날 글의 HTML이나 외부 사이트가 특정 썸네일 URL을 직접 사용하고 있다면 현재 테마에 등록되지 않은 이미지라고 해도 삭제 시 이미지가 깨질 수 있습니다.
반드시 백업 후 소수 Attachment ID로 먼저 테스트하세요.

unknown --delete-unknown parameter 오류

서버의 WP-CLI 또는 media-command 버전이 오래됐다면 다음 오류가 발생할 수 있습니다.

Error: unknown --delete-unknown parameter

이 경우 먼저:

wp --info

wp media regenerate --help

를 확인합니다.

여러 워드프레스 사이트가 동일한 서버 WP-CLI를 공유한다면 단순한 이미지 정리를 위해 공용 WP-CLI를 무조건 업데이트하는 것도 조심하는 편이 좋습니다.

SSH에서 이미지를 바로 find -delete 하면 위험한 이유

다음처럼 파일명만 보고 삭제하는 것은 상당히 위험합니다.

# 실행하지 않는 것을 권장
find wp-content/uploads \
-name "*-800x450.jpg" \
-delete

현재 WordPress의 soft crop 결과가 우연히 같은 800×450일 수도 있고 본문의 HTML에서 해당 파일 URL을 직접 사용하고 있을 수도 있기 때문입니다.

서버에서 작업할 때도 가장 안전한 순서는:

find로 조회
현재 image size 확인
테마 add_image_size 확인
본문 직접참조 확인
DRY RUN
백업
5~10장 테스트
전체 적용

작업이 오래 걸리면 nohup으로 SSH 연결이 끊겨도 계속 실행

미디어가 수만 장이면 WP-CLI도 오래 걸릴 수 있습니다.

SSH 창이나 WHM Terminal을 닫아도 실행을 유지해야 한다면:

nohup wp media regenerate \
--delete-unknown \
--yes \
--allow-root \
> ~/wp-media-clean.log 2>&1 &

프로세스 확인:

ps aux \
| grep "wp media regenerate" \
| grep -v grep

로그 확인:

tail -30 ~/wp-media-clean.log

실시간으로 확인:

tail -f ~/wp-media-clean.log

tail -f에서 Ctrl+C를 눌러도 nohup으로 실행한 백그라운드 프로세스 자체가 종료되는 것은 아닙니다.

대규모 사이트라면 nice ionice로 서버 부하 낮추기

서비스 중인 VPS에서 수십만 개 파일을 find나 du로 검사하면 순간적인 디스크 I/O가 증가할 수 있습니다.

방문자가 있는 운영 서버라면 우선순위를 낮춰 검사할 수도 있습니다.

nice -n 19 ionice -c3 \
du -sh wp-content/uploads

대규모 분석은 새벽이나 트래픽이 낮은 시간에 하는 편이 좋습니다.

서버가 느린 문제까지 있다면
잡가이버 - AlmaLinux 워드프레스 서버 느림 및 SSH 점검방법

SSH가 없으면 cPanel Disk Usage부터 확인

공유호스팅처럼 SSH를 제공하지 않는 환경이라면 cPanel의 Files → Disk Usage에서 어떤 폴더가 용량을 많이 사용하는지 먼저 확인할 수 있습니다.

FTP에서는 파일 하나하나는 볼 수 있어도 폴더별 총용량이나 수십만 개 파일의 통계를 확인하는 데 시간이 많이 걸리므로 서버 관리 기능이 있다면 Disk Usage를 먼저 보는 편이 빠릅니다.

잡가이버 - 워드프레스 용량보다 서버 사용량이 훨씬 크게 나오는 원인

미사용 이미지 삭제했는데 서버 용량이 그대로라면

Media Cleaner로 수천 장을 삭제했는데 서버 전체 사용량이 크게 줄지 않는다면 이미지가 원인이 아닐 수도 있습니다.

대표적으로 확인할 항목은:

MySQL / MariaDB 데이터베이스
WP Rocket·LiteSpeed Cache 등의 캐시
백업 ZIP·TAR.GZ
SQL Dump 파일
Apache·Nginx·PHP 로그
cPanel 이메일
임시파일
보안·통계 플러그인 로그

100MB 이상 SQL 백업 찾기

find /home/USER \
-type f \
-name "*.sql" \
-size +100M \
-ls 2>/dev/null

500MB 이상 ZIP TAR.GZ 찾기

find /home/USER \
-type f \
\( -name "*.zip" -o -name "*.tar.gz" -o -name "*.tgz" \) \
-size +500M \
-ls 2>/dev/null

DB가 크다면 이미지보다 데이터베이스를 먼저 다이어트

예를 들어 uploads 전체가 10~15GB인데 MySQL DB가 30~40GB라면 이미지 1GB를 어렵게 줄이는 것보다 DB에서 어느 테이블이 큰지 찾는 것이 훨씬 효과적일 수 있습니다.

WP-CLI를 사용할 수 있다면:

wp db size --tables

wp db check

wp transient delete --expired

MySQL·MariaDB에서 용량 상위 테이블을 직접 확인하려면:

mysql -e "
SELECT
    table_schema,
    table_name,
    ROUND((data_length + index_length)/1024/1024,2) AS MB
FROM information_schema.tables
ORDER BY (data_length + index_length) DESC
LIMIT 30;
"

잡가이버 관련글
워드프레스 MySQL DB 최적화 - phpMyAdmin·SSH·WHM·cPanel

노랗IT월드 관련글
WP-Optimize 워드프레스 DB·캐시 최적화 설정

삭제 후 이미지가 엑박으로 보일 때

삭제 후 일부 이미지가 깨졌다면 우선 Media Cleaner Trash에서 복원이 가능한지 확인합니다.

그 다음:

Cloudflare Cache Purge
WP Rocket / LiteSpeed Cache 삭제
브라우저 캐시 삭제
해당 이미지 URL 직접 접속
CDN WebP Rewrite 여부 확인
본문 HTML에 예전 썸네일 URL이 직접 들어 있는지 확인

노랗IT월드 - 웹페이지 이미지 깨짐·엑박 원인 및 해결방법

캐시 최적화는 이미지 정리가 끝난 다음

이미지와 썸네일을 정리한 뒤에는 실제 페이지의 전송량과 캐시 효율도 같이 확인하는 것이 좋습니다.

이미지 용량을 줄여도 HTML·CSS·JavaScript와 광고 스크립트가 무겁다면 체감 속도는 생각보다 크게 좋아지지 않을 수 있습니다.

노랗IT월드 관련글
WP Rocket 워드프레스 속도 최적화 후기 및 추천설정

제가 이미지가 많은 사이트를 다시 정리한다면

1. 전체 사이트와 DB 백업
2. Media Cleaner Clean Library Scan
3. Skip Trash OFF 상태로 명확한 미사용 미디어만 정리
4. Media Tracker로 Duplicate Images 추가 확인
5. Unused Media Checker Thorough Scan으로 교차검사
6. SSH에서 uploads 전체 용량·파일 개수 조사
7. WP-CLI에서 현재 image size 확인
8. 과거 테마·플러그인의 OLD SIZE 조사
9. Attachment 몇 장만 테스트
10. 문제가 없을 때 전체 썸네일 정리
11. Imagify·Smush 등으로 남은 이미지 압축
12. DB와 서버 로그·백업파일까지 확인

이 방식의 장점은 원본부터 무작정 지우지 않고 다시 만들 수 있는 파생파일과 정말 사용하지 않는 미디어부터 단계적으로 줄일 수 있다는 점입니다.

워드프레스 중복·미사용 이미지 삭제 FAQ

Media Cleaner 무료버전도 미사용 이미지를 삭제할 수 있나요?

네. 기본 Media Library를 분석해 사용되지 않는 미디어를 찾고 정리하는 용도로 사용할 수 있습니다. 실제 uploads 파일시스템까지 깊게 비교해야 한다면 고급 기능 또는 SSH 분석을 함께 사용하는 편이 좋습니다.

Media Cleaner가 중복사진도 찾아주나요?

Media Cleaner의 핵심은 미사용 미디어 정리입니다. 내용이 같은 파일을 여러 번 업로드한 실제 중복 이미지를 전문적으로 확인하려면 Media Tracker의 Duplicate Images 같은 기능을 함께 사용하는 편이 목적에 더 맞습니다.

Unattached 이미지는 모두 삭제해도 되나요?

아닙니다. 워드프레스 Attachment 관계가 없어도 본문 HTML, 테마 옵션, CSS, 위젯, 페이지빌더 또는 외부 사이트가 직접 URL로 사용하고 있을 수 있습니다.

Media Cleaner와 Media Tracker를 같이 설치해도 되나요?

검사 목적으로 번갈아 사용하는 것은 가능하지만 대량 스캔을 동시에 실행하는 것은 추천하지 않습니다. DB와 PHP 사용량이 커질 수 있으므로 한 플러그인의 분석이 끝난 뒤 다른 플러그인을 실행하는 편이 좋습니다.

Force Regenerate Thumbnails는 언제 사용하나요?

테마를 변경했거나 기존 썸네일 크기가 잘못 만들어져 현재 테마에 맞춰 다시 생성해야 할 때 유용합니다. 기존 썸네일 삭제가 포함될 수 있으므로 백업 없이 대형 사이트 전체에 바로 실행하지 않는 편이 좋습니다.

WebP 파일이 있으니 JPG 원본을 삭제해도 될까요?

장기 운영 사이트라면 저는 원본을 별도로 보관하는 편을 추천합니다. 향후 압축률을 바꾸거나 AVIF 등 다른 포맷으로 다시 변환할 때 원본이 필요할 수 있습니다.

SSH가 플러그인보다 오류가 적나요?

수십만 개 파일의 개수와 용량을 조사하는 작업은 SSH가 브라우저 Timeout에 영향을 덜 받기 때문에 편합니다. 다만 삭제 명령을 잘못 사용하면 플러그인보다 훨씬 위험하므로 실제 삭제는 충분한 검증 후 진행해야 합니다.

WP-CLI --delete-unknown 옵션이 안 보입니다

서버에 설치된 WP-CLI media-command가 오래된 경우일 수 있습니다. wp media regenerate --help로 현재 지원 여부부터 확인한 뒤 업데이트 또는 다른 방법을 결정합니다.

이미지를 삭제했는데 서버 용량이 거의 안 줄었습니다

uploads보다 DB, 백업 ZIP, SQL dump, 캐시, 이메일, 로그가 더 큰 서버일 수 있습니다. 이 경우 이미지 정리보다 du, find, MySQL 테이블별 용량 분석부터 해보는 것이 좋습니다.

미디어 라이브러리는 한 번 지우는 것보다 생성 구조를 바꾸는 것이 중요하다

오래 운영한 워드프레스에서 저장공간을 줄이면서 느낀 점은 단순히 미사용 이미지 몇 천 장을 삭제하는 것보다 앞으로 불필요한 파일이 계속 생성되지 않게 만드는 것이 더 중요하다는 것입니다.

테마를 여러 번 변경했다면 오래된 썸네일을 정리하고, 현재 사용하지 않는 image size 생성도 중단하고, 이미지 압축 플러그인은 하나만 선택해 운영하는 편이 좋습니다.

특히 Imagify, Smush, ShortPixel, 테마 자체 WebP 기능을 여러 개 동시에 켜 놓으면 같은 원본에 여러 변환 파일이 생길 수 있기 때문에 이미지 압축과 WebP·AVIF 변환을 담당할 도구는 가능하면 하나로 정하는 것이 관리가 편했습니다.

그리고 이미지 정리 이후에도 서버가 여전히 크거나 관리자 화면이 느리다면 DB, PHP-FPM, MySQL, 캐시, 로그까지 함께 살펴봐야 합니다. 결국 워드프레스 최적화는 플러그인 하나로 끝나는 작업보다는 미디어 → DB → 캐시 → 서버 순서로 문제를 분리해서 보는 것이 가장 정확합니다.

그리드형

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