워드프레스 wp-content/uploads 용량 줄이기｜SSH·WP-CLI로 미사용 썸네일 3만개 정리

잡가이버 2026. 8. 11.

워드프레스를 오래 운영하다 보면 어느 날 서버에 접속해 보고 생각보다 많은 이미지 파일 수에 놀랄 때가 있습니다. 미디어 라이브러리에 등록된 이미지는 몇 만 장인데 실제 wp-content/uploads에는 20만 개, 30만 개가 넘는 파일이 존재하기도 합니다.

저도 처음에는 원본 JPG나 PNG가 너무 많아서 그런 줄 알았습니다. 그런데 AlmaLinux 기반 리눅스 서버에서 SSH로 하나씩 분석해보니 서버 용량을 차지하는 상당수가 원본이 아니라 예전에 사용했던 테마와 플러그인이 생성한 파생 썸네일이었습니다.

특히 테마를 여러 번 바꾼 워드프레스는 현재 사용하지 않는 1200x700, 800x450, 600x600 같은 이미지가 수천 장씩 그대로 남아 있을 수 있습니다. 여기에 JPG와 WebP가 동시에 존재하면 파일 개수는 훨씬 더 많아집니다.

이번 작업에서 확인한 핵심
한 오래된 워드프레스 사이트를 검사했더니 이미지 Attachment는 약 2만8천 개였지만 실제 uploads 파일은 수십만 개였습니다.
현재 사용하지 않는 과거 이미지 사이즈를 다시 분석한 뒤 원본 이미지는 유지하면서 오래된 파생 썸네일 약 3만3천 개를 정리할 수 있었습니다.
삭제 전 백업까지 포함해 실제 삭제 오류는 발생하지 않았습니다.

이 글에서는 특정 호스팅이나 워드프레스 플러그인에만 한정하지 않고 AlmaLinux, Rocky Linux, CentOS 계열과 Ubuntu·Debian, cPanel·WHM, 일반 VPS 및 전용 서버에서 응용할 수 있도록 과정을 정리합니다.

아래 서버 경로와 사용자 이름은 모두 공개용 예시입니다. 실제 운영 서버의 IP, SSH 계정, 호스트명, 도메인 및 데이터베이스 이름은 블로그나 커뮤니티에 그대로 공개하지 않는 것이 좋습니다.

워드프레스 이미지 한 장이 서버에서는 여러 장이 되는 이유

워드프레스에서 photo.jpg 한 장을 업로드했다고 해서 서버에도 파일 한 장만 저장되는 것은 아닙니다.

photo.jpg
photo-150x150.jpg
photo-300x169.jpg
photo-768x432.jpg
photo-1024x576.jpg
photo-1536x864.jpg
photo-2048x1152.jpg

기본 워드프레스 이미지 사이즈 외에도 테마와 플러그인이 자체 이미지 크기를 등록할 수 있습니다.

WordPress는 현재 등록된 이미지 sub-size 목록을 별도로 가지고 있으며 각 Attachment의 metadata에는 실제 생성된 파생 이미지의 파일명과 크기가 저장됩니다.

WordPress 공식 문서 - wp_get_registered_image_subsizes()

여기에 WebP 최적화를 사용하면 환경에 따라 아래 파일도 함께 존재할 수 있습니다.

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

따라서 미디어 라이브러리에는 2만 장이 있어도 실제 디스크에는 10만~30만 개 이상의 파일이 생기는 것이 이상한 현상은 아닙니다. 문제는 테마를 변경한 뒤에도 옛 테마가 만든 썸네일 파일은 자동으로 없어지지 않는 경우가 많다는 것입니다.

WebP 변환 후 원본 파일까지 삭제할지 고민된다면 아래 글도 함께 참고할 수 있습니다.

▶ 워드프레스 WebP 변환 후기 Plus WebP or AVIF로 원본 이미지 삭제

Media Cleaner가 자꾸 멈춰 SSH로 바꾼 이유

처음에는 워드프레스 Media Cleaner 계열 플러그인으로 미사용 이미지를 검사했습니다.

이미지가 적은 사이트라면 관리자 화면에서 처리하는 것이 훨씬 편합니다.

하지만 이미지와 글이 많이 쌓인 사이트에서는 글 내용을 계속 읽어 이미지 참조를 분석해야 하기 때문에 웹 요청 시간이 길어지고 서버 설정에 따라 timeout이 발생할 수 있습니다.

The server request exceeded the safe time limit.

반면 SSH의 du, find, awk 같은 명령은 브라우저의 AJAX 요청을 계속 유지할 필요가 없기 때문에 대량 파일 분석에서는 훨씬 다루기 편했습니다.

다만 SSH가 무조건 더 안전하다는 의미는 아닙니다.
파일 개수와 용량을 조사하는 작업은 SSH가 안정적이지만, rm이나 find -delete를 잘못 사용하면 플러그인보다 훨씬 큰 사고가 날 수 있습니다.
따라서 조회 → DRY RUN → 일부 테스트 → 백업 → 실제 삭제 순서가 중요합니다.

AlmaLinux 서버가 전체적으로 느리거나 PHP-FPM, MySQL, WP-Cron까지 문제가 있다면 이미지 정리와 별개로 서버 프로세스를 함께 확인하는 것이 좋습니다.

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

어떤 리눅스 서버에서 사용할 수 있을까?

서버 환경	사용 여부	비고
AlmaLinux / Rocky Linux	가능	cPanel·WHM VPS에서 많이 사용
CentOS / RHEL 계열	가능	GNU find·coreutils 기준
Ubuntu / Debian	가능	명령 대부분 동일
cPanel / WHM	가능	WHM Terminal 또는 SSH 사용
일반 VPS / 전용 서버	가능	SSH 권한 필요
공유 웹호스팅	조건부 가능	SSH·WP-CLI 제공 여부 확인
Docker WordPress	가능	컨테이너와 uploads 볼륨 위치 확인 필요
Windows Server / IIS	명령 변경 필요	PowerShell 명령 사용

SSH 화면을 블로그에 올릴 때 개인정보부터 가리기

서버 작업 후기를 블로그나 커뮤니티에 올릴 때는 명령어보다 터미널 프롬프트에 개인정보가 더 많이 들어가는 경우가 있습니다.

root@my-server.example.com
/home/myaccount/public_html/mysite
203.0.113.10
DB_NAME
DB_USER

공개 글에서는 다음처럼 변경해서 설명하는 편이 좋습니다.

root@SERVER
/home/USER/public_html/site
example.com
DBNAME
DBUSER

특히 서버 IP와 실제 cPanel 계정명, 데이터베이스 사용자명, 백업파일 경로는 스크린샷에서도 가리는 편이 안전합니다.

1단계 서버 전체 디스크 용량부터 확인

이미지 삭제부터 시작하지 말고 먼저 서버 전체 디스크 상태를 확인합니다.

df -hT

예시는 다음과 같습니다.

Filesystem     Type  Size  Used  Avail  Use%
/dev/sda1      xfs   240G  180G    60G   75%

그 다음 워드프레스 설치 위치로 이동합니다.

cd /home/USER/public_html/site
pwd

워드프레스가 맞는지 확인합니다.

ls -ld wp-content wp-config.php

wp-content에서 어떤 폴더가 큰지 확인

du -h --max-depth=1 wp-content 2>/dev/null | sort -hr

예를 들어 다음과 같이 나온다면 uploads부터 보면 됩니다.

13G     wp-content/uploads
4.5G    wp-content/cache
1.8G    wp-content/plugins
250M    wp-content/themes

워드프레스 관리자에서 보이는 용량과 실제 서버 사용량이 크게 다르다면 uploads 외에 백업, 로그, 메일, 캐시, 숨김 디렉토리도 같이 봐야 합니다.

▶ 워드프레스 용량은 22GB인데 서버 사용량이 90GB? 어디서 차지하는 걸까?

2단계 wp-content/uploads 실제 용량과 파일 개수 확인

uploads 총 용량

du -sh wp-content/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}'

WebP 용량이 크다고 WebP 전체를 삭제하면 안 됩니다.
현재 서버 Rewrite, CDN 또는 이미지 최적화 플러그인이 WebP를 실제 서비스 중일 수 있습니다. JPG·PNG와 WebP가 동시에 있다고 해서 곧바로 중복파일이라고 판단하면 안 됩니다.

3단계 연도별로 어느 시기에 이미지가 많이 쌓였는지 확인

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

예를 들어 다음과 같은 결과가 나왔다고 가정해보겠습니다.

3.0G    wp-content/uploads/2022
2.5G    wp-content/uploads/2021
2.2G    wp-content/uploads/2020
1.6G    wp-content/uploads/2023
600M    wp-content/uploads/2024
300M    wp-content/uploads/2025

2020~2022년만 유난히 크다면 당시 사용하던 테마나 이미지 플러그인이 더 많은 썸네일을 만들었을 가능성을 의심해볼 수 있습니다.

서버 전체 찌꺼기와 오래된 Cron, 캐시까지 함께 정리하려면 아래 글도 참고할 수 있습니다.

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

4단계 자동 생성된 썸네일이 몇 개인지 확인

대부분의 워드프레스 파생 이미지는 파일명 뒤에 -가로x세로 형식이 붙습니다.

image-150x150.jpg
image-300x169.jpg
image-768x432.jpg
image-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

파생 이미지가 몇 GB인지 계산

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}'

실제 확인했던 사이트에서는 uploads 용량의 절반가량이 이런 해상도 이름이 붙은 파생 이미지였습니다.

5단계 현재 워드프레스가 사용하는 이미지 사이즈 확인

여기서부터가 중요합니다. 1200x700 파일이 많다고 해서 1200x700을 전부 지우면 안 됩니다.

먼저 현재 WordPress에 어떤 이미지 크기가 등록돼 있는지 확인합니다.

wp media image-size --allow-root

일반 사용자 계정이라면 --allow-root는 빼도 됩니다.

예시는 다음과 같습니다.

name               width   height   crop
full
2048x2048          2048    2048     soft
1536x1536          1536    1536     soft
large              1024    1024     soft
medium_large       768     0        soft
medium             300     300      soft
thumbnail          150     150      hard
theme-card         640     360      hard

특히 soft crop은 원본 이미지 비율에 따라 실제 파일 크기가 달라집니다.

예를 들어 large = 1024×1024 soft라고 등록되어 있어도 16:9 이미지라면 실제 파일은 1024x576.jpg가 될 수 있습니다.

따라서 파일 해상도만 보고 삭제하는 방식은 위험합니다.

WordPress 공식 WP-CLI - wp media image-size

6단계 현재 사용하지 않는 OLD SIZE 이름 찾기

워드프레스는 각 이미지 Attachment의 _wp_attachment_metadata 안에 생성된 썸네일의 size slug와 실제 파일명을 저장합니다.

예전에 Ocean 계열 테마, Avada/Fusion, 포트폴리오 테마, 관련글 플러그인 등을 사용했다면 다음과 비슷한 이름이 남아 있을 수 있습니다.

old-theme-large
old-theme-medium
portfolio-full
portfolio-one
fusion-1200
fusion-800
recent-posts
related-thumbnail

반드시 자신의 사이트에서 직접 확인해야 하며 위 이름을 그대로 삭제 목록으로 사용하면 안 됩니다.

7단계 해상도가 아니라 Attachment Metadata 기준으로 검사

이 과정이 이번 작업에서 가장 중요했습니다.

단순히 *-1200x700.jpg를 찾는 것이 아니라 현재 등록된 이미지 size 이름과 각 Attachment의 과거 metadata를 비교합니다.

WordPress 공식 wp_get_attachment_metadata() 결과에는 상대 파일 경로와 각 파생 이미지의 file, width, height, mime-type 등이 포함됩니다.

WordPress 공식 문서 - wp_get_attachment_metadata()

8단계 본문에서 직접 사용하는 옛 썸네일은 보호해야 한다

현재 등록되지 않은 오래된 썸네일이라고 해서 모두 삭제 가능한 것도 아닙니다.

아주 오래된 워드프레스 글은 본문 HTML에 파생 이미지 URL 자체가 직접 들어 있을 수 있습니다.

https://example.com/wp-content/uploads/2020/01/photo-800x450.jpg

따라서 삭제 후보의 실제 파일명이 글 본문에 존재하는지 한번 더 검사해야 합니다.

특정 해상도가 몇 개 글에서 사용되는지 간단히 확인하려면 다음처럼 검사할 수 있습니다.

PREFIX=$(wp db prefix --allow-root)

wp db query "SELECT COUNT(*)
FROM ${PREFIX}posts
WHERE post_content LIKE '%-800x450.%';" --allow-root

다만 이것은 해상도 문자열만 보는 1차 검사입니다. 최종 삭제 스크립트에서는 실제 Attachment의 파일명을 기준으로 다시 확인하는 것이 더 안전합니다.

9단계 현재 이미지와 같은 파일을 공유하는 OLD SIZE도 보호

과거 size slug와 현재 size slug가 이름은 달라도 실제 생성된 파일명이 동일한 경우가 있을 수 있습니다.

old-theme-medium → photo-300x200.jpg
현재 custom-size → photo-300x200.jpg

이 경우 OLD SIZE라는 이유만으로 물리 파일을 삭제하면 현재 사용하는 이미지까지 사라질 수 있습니다.

따라서 최종 검사에서는 최소한 다음 조건을 모두 통과해야 삭제 후보로 보는 편이 좋습니다.

① 현재 WordPress 등록 size가 아님
② 실제 파일이 uploads 안에 존재함
③ 원본 이미지가 아님
④ 현재 등록 size와 같은 실제 파일을 공유하지 않음
⑤ 글 본문에서 해당 파일명을 직접 사용하지 않음
⑥ 삭제 전 별도 백업이 정상적으로 생성됨

10단계 처음에는 5장 정도만 실제 삭제 테스트

전체 2만~3만 Attachment를 바로 건드리는 것보다 OLD SIZE가 남아 있는 Attachment ID 몇 개만 골라 테스트하는 편이 좋습니다.

예를 들어 Attachment ID가 아래처럼 나왔다고 가정합니다.

원본 파일이 실제 존재하는지도 확인합니다.

for id in 10001 10002 10008 10015 10021; do
  FILE=$(wp post meta get $id _wp_attached_file --allow-root)

  test -f "wp-content/uploads/$FILE" \
    && echo "OK 원본존재: $FILE" \
    || echo "주의 원본없음: $FILE"
done

테스트 결과에서 원본은 그대로 있고 과거 파생 파일만 사라지는 것을 확인한 뒤 전체 작업으로 넘어갑니다.

WP-CLI --delete-unknown 옵션이 안 먹는 경우

현재 WP-CLI 공식 문서에는 다음 옵션이 있습니다.

wp media regenerate --delete-unknown

공식 설명상 --delete-unknown은 현재 등록되지 않은 과거 이미지 사이즈의 썸네일을 삭제하는 옵션입니다.

WP-CLI 공식 문서 - wp media regenerate

하지만 서버에 설치된 WP-CLI 또는 media-command가 오래된 경우 다음 오류가 발생할 수 있습니다.

Error: unknown --delete-unknown parameter

이 경우 운영 중인 서버에서 WP-CLI 자체를 무조건 업데이트하기보다 먼저 버전과 지원 옵션을 확인합니다.

wp --info

wp media regenerate --help

여러 워드프레스가 하나의 서버 WP-CLI를 함께 사용한다면 단순한 썸네일 정리 때문에 공용 WP-CLI를 갑자기 바꾸는 것도 조심하는 편이 좋습니다.

대량 작업은 nohup으로 터미널이 닫혀도 계속 실행

Attachment가 몇 만 개라면 작업 중 브라우저의 WHM Terminal을 실수로 닫을 수도 있습니다.

이럴 때는 nohup으로 백그라운드 실행하면 편합니다.

nohup wp eval-file \
/tmp/old-thumbnail-clean.php \
--allow-root \
> /root/old-thumbnail-run.log 2>&1 &

실행 중인지 확인합니다.

ps aux | grep old-thumbnail-clean.php | grep -v grep

로그 마지막 부분을 확인합니다.

tail -30 /root/old-thumbnail-run.log

실시간으로 보려면 다음을 사용합니다.

tail -f /root/old-thumbnail-run.log

tail -f에서 Ctrl+C를 누르는 것은 로그 화면만 빠져나오는 것이며 nohup으로 실행한 실제 백그라운드 작업은 계속됩니다.

Exit 255 오류가 뜰 때 확인할 것

WP-CLI 스크립트가 바로 종료되면서 다음처럼 보일 수 있습니다.

[1]+ Exit 255

이 경우 반복 실행부터 하지 말고 먼저 로그를 확인합니다.

tail -50 /root/old-thumbnail-run.log

PHP 파일 자체 문법검사는 다음과 같습니다.

php -l /tmp/old-thumbnail-clean.php

오류가 특정 줄에서 발생했다면 해당 주변만 확인합니다.

nl -ba /tmp/old-thumbnail-clean.php | sed -n '65,85p'

몇 만 개를 삭제하는 작업에서는 오류 메시지를 무시하고 다시 실행하는 것보다 어느 단계에서 멈췄는지를 확인하는 습관이 훨씬 중요합니다.

터미널에서 명령 입력 상태에 갇혔을 때

긴 PHP heredoc이나 여러 줄 명령을 붙여넣다가 프롬프트가 돌아오지 않는 경우가 있습니다.

예를 들어 마지막 PHP 문자열이 잘못 들어가면 터미널이 계속 다음 입력을 기다릴 수 있습니다.

이럴 때는 보통:

Ctrl + C

를 눌러 현재 입력을 취소하고

root@SERVER [site]#

프롬프트가 다시 나타나는지 확인합니다.

이미 nohup으로 실행된 별도의 프로세스가 있다면 Ctrl+C로 현재 셸 입력을 취소해도 그 백그라운드 프로세스까지 자동 종료되는 것은 아닙니다.

실제 작업 결과 - 원본을 지우지 않고 3만 개 이상 정리

제가 실제 운영 사이트에서 최종적으로 검사한 결과를 개인정보를 제외하고 정리하면 다음과 비슷했습니다.

항목	결과
이미지 Attachment 검사	약 2만8천 개
삭제된 과거 파생파일	약 3만3천 개
정리된 파일 용량	약 0.9GB
삭제 오류	0건
원본 이미지	보존

용량만 보면 0.9GB가 그렇게 커 보이지 않을 수도 있습니다. 하지만 파일이 3만 개 이상 줄었다는 것도 꽤 중요합니다.

파일 개수가 지나치게 많으면 백업, FTP/SFTP 파일 목록 조회, rsync, 파일 검사, 압축 작업에도 부담이 커질 수 있기 때문입니다.

백업했는데 서버 전체 용량이 안 줄어드는 이유

이 부분은 처음 작업하면 헷갈리기 쉽습니다.

예를 들어 uploads에서 0.9GB를 삭제하기 전에 동일한 파일을 /root/backup에 0.9GB 백업했다면:

uploads     -0.9GB
backup      +0.9GB
-------------------
서버 전체   거의 동일

따라서 삭제 작업 직후에는 서버 전체 여유공간이 거의 늘지 않는 것이 정상입니다.

사이트를 며칠 확인한 뒤 이상이 없다고 판단되면 그때 백업을 삭제해야 실제 디스크 공간이 확보됩니다.

주의
백업 경로를 rm -rf로 삭제하기 전에는 반드시 pwd와 ls, du -sh로 경로를 재확인하세요.
rm -rf는 휴지통을 거치지 않습니다.

정리 후 파일 수와 용량 다시 확인

du -sh wp-content/uploads

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

df -hT

작업 전 숫자를 메모해 두면 효과를 비교하기 쉽습니다.

작업 전
uploads       약 13GB
전체 파일     약 34만개

작업 후
uploads       약 12GB
전체 파일     약 31만개

실제 결과는 사이트마다 크게 다릅니다. 테마를 자주 변경했던 사이트라면 훨씬 많이 줄어들 수도 있고 처음부터 이미지 사이즈 관리가 잘 돼 있던 사이트라면 거의 줄지 않을 수도 있습니다.

이미지보다 데이터베이스가 더 크다면 DB부터 봐야 한다

이미지를 열심히 정리했는데 uploads가 10GB 정도이고 MySQL·MariaDB 데이터베이스가 30~40GB라면 실제 서버 다이어트의 핵심은 이미지가 아닐 수 있습니다.

워드프레스 DB가 지나치게 크다면 다음 테이블을 먼저 확인합니다.

wp_postmeta
wp_options
Action Scheduler 관련 테이블
통계·보안 로그 테이블
SEO 플러그인 데이터
리비전 및 자동저장
만료된 transient

DB가 큰 사이트는 phpMyAdmin에서 무작정 Optimize부터 누르기보다 어떤 테이블이 몇 GB인지 먼저 확인하는 편이 좋습니다.

▶ 워드프레스 MySQL DB 최적화 방법 phpMyAdmin SSH WHM cPanel 호스팅별 정리

플러그인과 SSH 중 어떤 방법이 더 좋을까?

항목	워드프레스 플러그인	SSH / WP-CLI
초보자 사용	편함	어려움
대량 파일 검사	시간 오래 걸릴 수 있음	유리
브라우저 timeout	발생 가능	영향 적음
파일별 용량 분석	제한적	매우 편함
실제 콘텐츠 참조 분석	플러그인 장점	별도 로직 필요
잘못된 명령 위험	상대적으로 낮음	높음
자동화	플러그인 기능에 의존	자유로움

제 기준에서는 몇 천 장 정도라면 플러그인, 몇 만 장 이상이면서 SSH 사용이 가능하다면 SSH로 먼저 분석하는 방법이 효율적이었습니다.

다만 실제 삭제 단계는 WordPress metadata까지 함께 확인해야 하므로 단순 Linux 파일 정리와 워드프레스 미디어 정리를 같은 것으로 생각하면 안 됩니다.

워드프레스 오래된 썸네일 삭제 FAQ

플러그인 없이 SSH만으로 워드프레스 이미지를 정리할 수 있나요?

가능합니다. du, find, awk, WP-CLI를 이용하면 이미지 개수와 용량, 등록된 이미지 size, 오래된 Attachment metadata까지 확인할 수 있습니다. 다만 실제 사용 여부 확인 없이 파일명만 보고 삭제하는 것은 권장하지 않습니다.

SSH가 Media Cleaner보다 오류가 적나요?

대규모 파일을 단순 분석하는 작업은 SSH가 편한 경우가 많습니다. 브라우저 AJAX 요청이나 페이지 세션에 의존하지 않기 때문입니다. 다만 SSH도 메모리 부족, OOM, 파일 권한, PHP Fatal Error, 잘못된 명령 등의 문제는 발생할 수 있습니다.

1200x700이나 800x450 이미지는 전부 삭제해도 되나요?

안 됩니다. 현재 WordPress의 soft crop 결과이거나 과거 글에서 해당 파일을 직접 사용하고 있을 수도 있습니다. 해상도가 아니라 Attachment metadata의 size slug와 실제 파일명을 기준으로 확인해야 합니다.

원본 이미지는 어떻게 구분하나요?

WordPress Attachment의 _wp_attached_file, get_attached_file(), wp_get_original_image_path() 등을 이용해 확인할 수 있습니다. 삭제 스크립트에는 원본 경로와 같은 파일이면 무조건 건너뛰는 안전장치를 넣는 것이 좋습니다.

-scaled.jpg는 삭제해도 되나요?

무조건 삭제하면 안 됩니다. 고해상도 이미지를 업로드했을 때 WordPress가 생성한 scaled 파일을 실제 Full 이미지처럼 사용하는 환경이 있을 수 있습니다. 일반 -300x200 썸네일과 별도로 판단해야 합니다.

WebP가 있으니 JPG 원본을 삭제해도 되나요?

장기간 운영할 사이트라면 저는 원본을 별도로 보관하는 쪽을 선호합니다. WebP나 AVIF 정책을 나중에 바꿀 때 고품질 원본이 있으면 다시 변환하기 쉽기 때문입니다.

wp media regenerate --delete-unknown이 안 됩니다

현재 공식 WP-CLI에는 해당 옵션이 있지만 서버에 설치된 media-command 버전이 오래되었다면 지원하지 않을 수 있습니다. wp media regenerate --help로 현재 서버 지원 옵션부터 확인하세요.

터미널을 닫으면 작업도 중단되나요?

일반 foreground 명령은 SSH 연결 종료와 함께 영향을 받을 수 있습니다. 긴 작업은 nohup, screen, tmux 등을 사용하면 관리하기 편합니다.

삭제한 뒤 사이트가 정상인지 무엇을 확인해야 하나요?

메인화면, 카테고리 목록, 검색결과, 오래된 게시글, 대표이미지, 관련글, 모바일 화면을 먼저 확인합니다. Cloudflare나 캐시 플러그인을 사용한다면 캐시 때문에 삭제 전 이미지가 계속 보일 수도 있으므로 원본 URL도 함께 확인하는 것이 좋습니다.

서버 다이어트는 삭제보다 먼저 구조를 이해하는 게 중요했다

처음에는 사용하지 않는 이미지를 찾아 한꺼번에 삭제하면 금방 끝날 줄 알았습니다. 하지만 오래 운영한 워드프레스는 생각보다 구조가 단순하지 않았습니다.

원본 한 장에서 WordPress 기본 썸네일이 만들어지고, 테마가 자체 이미지 사이즈를 추가하고, 관련글 플러그인이나 포트폴리오가 또 다른 크기를 생성하고, 나중에는 WebP까지 추가됩니다. 테마를 바꾼 뒤에도 과거 파일은 그대로 남는 경우가 많습니다.

그래서 저라면 다음에도 같은 순서로 작업할 것 같습니다.

서버 전체 용량 확인
↓
uploads 실제 파일 수와 확장자별 용량 확인
↓
현재 WordPress 등록 이미지 size 확인
↓
과거 Attachment metadata와 비교
↓
본문 직접 참조 및 공유파일 보호
↓
5장 정도만 실제 테스트
↓
삭제 전 백업
↓
nohup으로 대량 처리
↓
사이트 이상 여부 확인 후 백업 제거

이 방식의 장점은 원본을 최대한 그대로 보존하면서 다시 만들 수 있는 오래된 파생 파일부터 줄일 수 있다는 것입니다.

그리고 이미지 정리가 끝났는데도 서버가 여전히 수십 GB 이상 크다면 그 다음에는 DB, 로그, 백업, 캐시, 메일 디렉토리를 확인하는 것이 맞습니다. 특히 오래 운영한 WordPress는 이미지보다 MySQL·MariaDB가 훨씬 큰 경우도 있기 때문에 서버 용량은 한 폴더만 보고 판단하지 않는 것이 좋습니다.

그리드형

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

'블로그 수익화 > 블로그 SEO' 카테고리의 다른 글

워드프레스 중복·미사용 이미지 삭제｜중복사진·미사용 이미지·옛날 썸네일 삭제 (0)	2026.08.11
H1 태그 1개만 써야 할까? 2개 중복 시 SEO 영향 티스토리·워드프레스 해결방법 (0)	2026.08.07
네이버 블로그 72시간 저품질 사실일까? 검색 누락 원인과 해결방법 (0)	2026.08.07