워드프레스 이미지 용량 줄이기｜AlmaLinux SSH 명령어·Media Cleaner 무료판으로 원본 보존 다이어트

워드프레스를 오래 운영하다 보면 데이터베이스보다 더 부담스러워지는 것이 wp-content/uploads 이미지 폴더입니다.

저도 처음에는 이미지가 많으니 서버 용량이 큰 게 당연하다고 생각했는데, 실제 AlmaLinux 서버에서 SSH로 하나씩 확인해보니 상황이 조금 달랐습니다.

원본 JPG나 PNG만 많이 쌓인 것이 아니라 하나의 이미지를 올릴 때 워드프레스와 테마가 만든 150×150, 300×200, 768px, 1024px 등의 썸네일, 이미지 최적화 플러그인이 만든 WebP 사본, 예전에 사용했던 테마의 이미지 크기까지 함께 남아 있었습니다.

제가 정한 원칙은 단순합니다.
원본 이미지는 최대한 보존하고, 먼저 서버에서 무엇이 용량을 차지하는지 확인한 뒤 미사용 미디어 → 불필요한 썸네일 → 중복 WebP → 오래된 이미지 사이즈 순서로 정리합니다.

특히 수익형 블로그처럼 방문자가 아주 많지 않은데 서버 용량 때문에 비싼 VPS를 계속 사용하고 있다면, 서버를 업그레이드하기 전에 uploads 폴더를 한번 제대로 분석해볼 가치가 있습니다.

워드프레스 이미지 1장이 실제로는 여러 장 저장되는 이유

워드프레스 미디어 라이브러리에 JPG 이미지 한 장을 업로드했다고 해보겠습니다.

photo.jpg
photo-150x150.jpg
photo-300x200.jpg
photo-768x512.jpg
photo-1024x683.jpg
photo-1536x1024.jpg
photo-2048x1365.jpg

여기에 Imagify 같은 이미지 최적화 플러그인까지 사용한다면 환경에 따라 다음처럼 WebP 파일도 추가될 수 있습니다.

photo.webp
photo-150x150.webp
photo-300x200.webp
photo-768x512.webp
photo-1024x683.webp

테마에서 별도 이미지 크기를 등록했다면 파일은 더 늘어납니다.

결국 관리자가 올린 것은 원본 한 장인데 서버에는 5장, 10장 또는 그 이상의 파일이 만들어질 수 있습니다.

Imagify와 WebP 변환 구조가 궁금하다면 아래 기존 글도 같이 보면 이해가 쉽습니다.

▶ 워드프레스 WebP 이미지 변환 및 압축 Imagify 설정방법

무조건 JPG·PNG 원본부터 삭제하면 안 되는 이유

서버 용량을 줄인다고 가장 큰 JPG나 PNG부터 삭제하는 것은 저는 추천하지 않습니다.

예를 들어 다음처럼 되어 있다고 가정해봅니다.

IMG_20260801.jpg          4.2MB  ← 원본
IMG_20260801-1024x683.jpg 420KB
IMG_20260801.webp         620KB
IMG_20260801-1024x683.webp 180KB

당장은 4.2MB짜리 JPG를 삭제하는 것이 가장 큰 절약처럼 보입니다.

하지만 나중에 WebP 변환을 다시 하거나 이미지 품질을 바꾸고 싶을 때 원본이 없으면 복원이 어렵습니다.

특히 오래 운영하는 블로그는 테마 변경, CDN 변경, WebP 플러그인 변경이 있을 수 있기 때문에 저는 원본 1장은 보험처럼 남겨두는 편이 낫다고 봅니다.

예전에 JPG·PNG를 WebP로 변환하면서 원본을 삭제했을 때의 장단점은 아래 글에서 별도로 정리했습니다.

▶ 워드프레스 WebP 변환 후 원본 이미지 삭제해본 후기

AlmaLinux SSH에서 서버 전체 용량부터 확인

아래 명령어들은 제가 워드프레스 서버를 확인할 때 자주 사용하는 형태입니다.

주의
아래 예제의 USER와 워드프레스 경로는 자신의 서버 환경에 맞게 바꿔야 합니다.
WHM/cPanel 환경이라면 일반적으로 /home/계정명/public_html 형태가 많습니다.

디스크 전체 사용량 확인

df -hT

예를 들어 다음과 같이 표시될 수 있습니다.

Filesystem     Type  Size  Used Avail Use%
/dev/sda1      xfs   240G  183G   57G  77%

여기서 중요한 것은 Used와 Use%입니다.

디스크가 80~90%에 가까워지고 있다면 이미지 정리뿐 아니라 백업, 로그, 캐시까지 함께 확인해야 합니다.

서버에서는 워드프레스가 30GB라고 나오는데 실제 VPS가 100GB 가까이 차는 경우도 있습니다. 이런 경우는 아래 글처럼 서버 전체를 먼저 추적하는 것이 좋습니다.

▶ 워드프레스 용량은 작은데 서버 사용량이 큰 원인 SSH로 찾는 방법

워드프레스 폴더별 용량 확인

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

조금 더 좁혀서 wp-content만 확인합니다.

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

예를 들어 결과가 다음과 같다면 원인이 명확합니다.

126G    wp-content/uploads
14G     wp-content/cache
3.8G    wp-content/plugins
850M    wp-content/themes

이 경우 플러그인 몇 개 삭제해서 해결될 문제가 아니라 uploads부터 확인해야 합니다.

uploads 폴더가 몇 GB인지 확인

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

예를 들어

126G    /home/USER/public_html/wp-content/uploads

처럼 나온다면 이제 이 126GB의 정체를 찾아봅니다.

연도별 이미지 용량 확인

du -sh /home/USER/public_html/wp-content/uploads/* | sort -hr

결과 예시는 다음과 같습니다.

31G  2025
26G  2024
21G  2023
16G  2022
12G  2021
8G   2020

오래 운영한 워드프레스라면 특정 연도부터 이미지가 갑자기 늘어난 시점도 확인할 수 있습니다.

특정 연도의 월별 용량 확인

du -sh /home/USER/public_html/wp-content/uploads/2025/* | sort -hr

예를 들어 특정 달만 유난히 크다면 그 시기에 테마나 이미지 최적화 플러그인을 바꿨는지 같이 확인해볼 필요가 있습니다.

전체 이미지 파일 개수를 확인해보니 더 놀라웠다

용량뿐 아니라 파일 개수도 중요합니다.

find /home/USER/public_html/wp-content/uploads -type f | wc -l

예를 들어 미디어 라이브러리에는 몇 만 장 정도 있다고 생각했는데 실제 결과가

428531

처럼 나온다면 원본보다 파생 이미지가 훨씬 많은 상태일 가능성이 높습니다.

JPG 파일 개수

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

PNG 파일 개수

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

WebP 파일 개수

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

AVIF 파일 개수

find /home/USER/public_html/wp-content/uploads -type f \
-iname "*.avif" | wc -l

이렇게 확장자별로 나눠보면 JPG가 문제인지 WebP 중복본이 문제인지 훨씬 쉽게 판단할 수 있습니다.

가장 큰 이미지 50개 찾기

다음 명령어는 파일을 삭제하지 않고 가장 큰 파일부터 보여줍니다.

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

결과는 이런 식입니다.

18M /home/USER/public_html/wp-content/uploads/2022/03/photo01.png
15M /home/USER/public_html/wp-content/uploads/2021/07/screenshot.png
12M /home/USER/public_html/wp-content/uploads/2020/11/design.png

여기서 10~20MB짜리 PNG가 수백 장 발견된다면 상당한 용량을 줄일 수 있습니다.

다만 이 명령어는 삭제 대상 선정용이 아니라 어디에 문제가 있는지 확인하는 명령어입니다.

실제로 가장 궁금했던 자동생성 썸네일 개수 확인

워드프레스 썸네일은 일반적으로 파일명 뒤에 해상도가 붙습니다.

image-150x150.jpg
image-300x200.jpg
image-768x512.jpg
image-1024x683.jpg

아래 명령어로 이런 형태의 파일 개수를 대략 확인할 수 있습니다.

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

파생 썸네일이 총 몇 GB인지 계산

find /home/USER/public_html/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 전체가 120GB인데 해상도가 붙은 파생이미지만 55GB라면, 원본 이미지를 삭제하지 않고도 손댈 수 있는 공간이 상당히 많다는 뜻입니다.

150x150 썸네일만 몇 장인지 확인

find /home/USER/public_html/wp-content/uploads \
-type f -iname "*-150x150.*" | wc -l

300px 계열도 확인할 수 있습니다.

find /home/USER/public_html/wp-content/uploads \
-type f -iname "*-300x300.*" | wc -l

다만 실제 이미지는 비율에 따라 300x200, 300x169처럼 다양하기 때문에 전체 파생파일 확인은 앞의 정규식 명령어가 더 정확합니다.

-scaled 이미지는 함부로 삭제하지 않는 것이 좋다

파일을 보다 보면 다음과 같은 파일도 많이 보입니다.

photo.jpg
photo-scaled.jpg

여기서 -scaled라는 이름만 보고 썸네일이라고 생각해 한꺼번에 삭제하면 안 됩니다.

워드프레스에서는 큰 이미지를 업로드했을 때 scaled 버전이 실제 Full Size 이미지로 사용되는 경우가 있기 때문입니다.

따라서 다음 명령어는 개수 확인 용도로만 사용합니다.

find /home/USER/public_html/wp-content/uploads \
-type f -iname "*-scaled.*" | wc -l

-scaled 파일은 단순 파생 썸네일과 별도로 생각하는 것이 안전합니다.

현재 워드프레스가 어떤 이미지 크기를 만드는지 WP-CLI로 확인

오래 운영한 사이트에서 가장 먼저 확인할 부분 중 하나입니다.

워드프레스 경로로 이동합니다.

cd /home/USER/public_html

WP-CLI가 설치되어 있다면 다음 명령어를 실행합니다.

wp media image-size --allow-root

예를 들어 다음처럼 표시됩니다.

+--------------+-------+--------+------+
| name         | width | height | crop |
+--------------+-------+--------+------+
| thumbnail    | 150   | 150    | hard |
| medium       | 300   | 300    | soft |
| medium_large | 768   | 0      | soft |
| large        | 1024  | 1024   | soft |
| theme-card   | 480   | 320    | hard |
| blog-list    | 720   | 480    | hard |
+--------------+-------+--------+------+

여기서 theme-card, blog-list처럼 워드프레스 기본값이 아닌 사이즈가 여러 개 보인다면 테마나 플러그인이 추가한 이미지 크기일 가능성이 높습니다.

테마·플러그인이 추가한 add_image_size 찾기

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

예를 들어 예전에 설치했던 테마 코드에서

add_image_size('blog-grid', 450, 300, true);
add_image_size('blog-list', 720, 480, true);
add_image_size('sidebar-thumb', 120, 120, true);

처럼 여러 이미지 사이즈가 발견될 수 있습니다.

현재 사용하지 않는 테마에서 과거에 생성했던 크기라면 기존 파일은 uploads에 그대로 남아 있을 수 있습니다.

앞으로 불필요한 이미지가 계속 생성되는 것부터 막아야 한다

기존 이미지만 정리하고 끝내면 새 글을 쓸 때마다 같은 이미지가 다시 만들어집니다.

그래서 현재 사용하지 않는 커스텀 이미지 사이즈가 확실하다면 차일드테마나 Code Snippets 등을 이용해 등록을 해제할 수 있습니다.

예를 들어 사용하지 않는 old-theme-card라는 사이즈가 있다고 가정하면 다음과 같은 형태입니다.

add_action('init', function () {
    remove_image_size('old-theme-card');
}, 100);

다만 thumbnail, medium, medium_large, large 등의 워드프레스 기본 크기는 무작정 없애지 않는 것이 좋습니다.

테마의 반응형 이미지와 srcset에서 실제로 사용될 수 있기 때문입니다.

Media Cleaner 무료버전으로 미사용 이미지부터 찾기

SSH로 파생 이미지 파일을 바로 삭제하기 전에 저는 먼저 워드프레스의 Media Cleaner 같은 도구로 미사용 미디어를 확인하는 편이 안전하다고 봅니다.

2026년 8월 기준 Media Cleaner 무료버전에서도 워드프레스 미디어 라이브러리에 등록된 미사용 미디어를 검사하고 삭제할 수 있습니다.

워드프레스 관리자에서 보통 다음 경로로 들어갑니다.

관리자
→ Media
→ Cleaner

또는 설정 화면은

Meow Apps
→ Cleaner

에서 확인할 수 있습니다.

공식 플러그인 페이지는 아래에서 확인할 수 있습니다.

▶ Media Cleaner 워드프레스 공식 플러그인

Media Cleaner 무료판과 Pro 차이

기능	무료	Pro
미디어 라이브러리 미사용 파일 검사	가능	가능
미사용 미디어 삭제	가능	가능
실제 파일 삭제	가능	가능
uploads 파일시스템 직접 검사	제한	가능
Elementor·ACF 등 복잡한 환경 추가 지원	제한적	강화
Live Site Scan	불가	가능
Media Cleaner WP-CLI	불가	가능

무료판이라고 미사용 이미지 삭제 자체가 막힌 것은 아닙니다.

헷갈리는 부분은 Filesystem Analysis가 Pro 기능이라는 점입니다.

즉 서버의 uploads 폴더 안에는 존재하지만 워드프레스 미디어 라이브러리에 등록조차 되지 않은 고아 파일까지 찾아내는 것은 Pro 영역이고, 워드프레스 미디어 라이브러리 기준으로 사용하지 않는 이미지를 찾는 기본 정리는 무료에서도 가능합니다.

Media Cleaner에서 바로 영구삭제하지 않은 이유

제가 오래 운영한 워드프레스에서는 HTML에 이미지 URL을 직접 넣은 글도 있고, 테마 옵션이나 CSS에서 이미지를 불러오는 경우도 있기 때문에 스캔 결과를 100% 믿고 즉시 영구삭제하는 방식은 피하는 편입니다.

먼저 Media Cleaner의 Trash로 이동한 뒤 사이트를 며칠 확인하고 문제가 없을 때 최종 정리하는 쪽이 안전합니다.

워드프레스 전체 찌꺼기와 사용하지 않는 이미지 정리를 함께 하고 싶다면 아래 글도 참고할 수 있습니다.

▶ 워드프레스 10년간 쌓인 캐시·Cron·미사용 이미지 찌꺼기 정리

WebP가 실제로 몇 GB를 사용하는지도 확인

Imagify나 다른 이미지 최적화 플러그인을 여러 번 바꿨다면 WebP 파일도 상당한 용량을 차지할 수 있습니다.

WebP 전체 개수

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

WebP 전체 용량 계산

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

예를 들어

JPG/PNG 원본 및 썸네일 : 78GB
WebP                    : 34GB
AVIF                    : 7GB

처럼 나온다면 이미지 최적화 포맷만 40GB 이상을 사용하고 있는 것입니다.

그렇다고 WebP를 몽땅 삭제하면 안 됩니다.

현재 서버가 WebP 파일을 직접 서비스하고 있는지, CDN이나 Imagify에서 WebP를 사용하고 있는지 먼저 확인해야 합니다.

원본 이미지와 파생이미지를 구분하는 것이 핵심

파일	권장 판단
photo.jpg	원본이라면 보존 권장
photo-150x150.jpg	파생 이미지
photo-300x200.jpg	파생 이미지
photo-1024x683.jpg	본문에서 실제 사용 가능성 높음
photo-scaled.jpg	자동삭제 금지
photo.webp	현재 WebP 서비스 여부 확인

WP-CLI로 오래된 미등록 이미지 사이즈 정리하는 방법

이 단계부터는 Media Cleaner보다 훨씬 조심해야 합니다.

WP-CLI에는 현재 워드프레스에 등록되어 있지 않은 예전 썸네일 사이즈를 제거하면서 이미지를 다시 생성하는 기능이 있습니다.

먼저 현재 사이즈를 확인합니다.

cd /home/USER/public_html
wp media image-size --allow-root

그리고 테스트할 이미지 몇 개의 Attachment ID를 확인한 뒤 일부만 먼저 실행하는 것이 좋습니다.

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

문제가 없는 것을 충분히 확인한 뒤 전체 이미지에 적용할 수 있습니다.

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

이 명령은 주의해야 합니다.
--delete-unknown은 현재 등록되지 않은 오래된 썸네일을 삭제할 수 있기 때문에, 예전 글 HTML에 해당 이미지 URL을 직접 입력해 두었다면 이미지가 깨질 가능성이 있습니다.
전체 사이트에 바로 실행하지 말고 반드시 백업 후 일부 Attachment ID로 먼저 테스트하는 것이 좋습니다.

백업은 같은 서버 안에만 만들지 않는 것이 좋다

이미지 원본 분실이 걱정된다면 이 부분이 가장 중요합니다.

서버 용량을 줄이면서 같은 서버 안에 uploads 전체 백업을 하나 더 만들면 오히려 디스크가 가득 찰 수 있습니다.

따라서 가능하다면 PC, NAS, 외장 저장장치 또는 별도의 백업 스토리지에 원본 백업 하나를 가지고 있는 것이 좋습니다.

별도 마운트된 백업 디스크가 있다는 전제라면 rsync도 사용할 수 있습니다.

rsync -aH --info=progress2 \
/home/USER/public_html/wp-content/uploads/ \
/backup/wordpress-uploads/

이렇게 하면 서버에서 파생이미지를 정리하더라도 원본을 복구할 마지막 수단을 확보할 수 있습니다.

이미지 정리 후 서버 용량 다시 비교

작업 전 값을 기록해 두었다면 정리 효과를 바로 비교할 수 있습니다.

df -hT

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

예를 들어 작업 전

uploads 126GB
디스크 사용량 183GB

에서 작업 후

uploads 82GB
디스크 사용량 139GB

가 됐다면 원본을 대량으로 삭제하지 않고도 약 44GB를 확보한 셈입니다.

이미지를 정리했는데 서버가 여전히 크다면 DB도 따로 확인

uploads를 정리했는데 서버 사용량이 생각보다 줄지 않는다면 이미지 문제와 DB 문제를 분리해서 봐야 합니다.

MySQL/MariaDB 데이터베이스가 수십 GB라면 이미지 다이어트와는 별개입니다.

DB 크기는 다음처럼 확인할 수 있습니다.

du -sh /var/lib/mysql/* 2>/dev/null | sort -hr | head -30

워드프레스 DB 내부에서는 wp_postmeta, wp_options, Action Scheduler, 통계 및 로그 테이블이 비정상적으로 큰지도 따로 확인해야 합니다.

이 부분은 아래 글에 phpMyAdmin, SSH, WHM 기준으로 따로 정리해두었습니다.

▶ 워드프레스 MySQL DB 용량 최적화 phpMyAdmin·SSH·WHM 사용방법

AlmaLinux 서버가 느리다면 이미지 용량만 볼 문제는 아니다

이미지가 많다고 해서 무조건 웹사이트가 느린 것은 아닙니다.

Cloudflare나 페이지 캐시가 제대로 적용되어 있다면 하루 방문자가 많지 않은 사이트는 이미지가 많아도 CPU 사용량 자체는 낮을 수 있습니다.

반대로 방문자는 많지 않은데 서버가 계속 느리다면 php-fpm, MySQL, WP-Cron, Action Scheduler 또는 봇 요청을 같이 확인하는 것이 좋습니다.

AlmaLinux + WHM/cPanel 환경에서 서버가 느려졌을 때 제가 확인했던 명령어와 해결 과정은 다음 글에 정리했습니다.

▶ AlmaLinux 워드프레스 서버 느림·예약글 오류 SSH 점검방법

제가 워드프레스 이미지 다이어트를 한다면 이 순서로 한다

이미지가 수십만 개 있는 오래된 워드프레스라면 한 번에 지우는 것보다는 아래 순서가 가장 안전했습니다.

1단계 - df, du로 서버와 uploads 용량 확인
2단계 - JPG·PNG·WebP·AVIF 개수와 용량 확인
3단계 - 해상도가 붙은 파생이미지가 몇 GB인지 계산
4단계 - WP-CLI로 현재 등록된 이미지 사이즈 확인
5단계 - 더 이상 사용하지 않는 테마·플러그인 이미지 사이즈 생성 중단
6단계 - Media Cleaner 무료판으로 실제 미사용 미디어부터 정리
7단계 - WebP·AVIF 중복파일 사용 여부 확인
8단계 - 오래된 미등록 썸네일은 백업 후 WP-CLI로 소량 테스트
9단계 - 사이트 이미지 깨짐 여부 확인
10단계 - 문제가 없을 때 최종 삭제 후 df -hT로 절감량 확인

Media Cleaner와 SSH 중 무엇을 먼저 사용해야 할까?

초보자라면 Media Cleaner부터 사용하는 것이 좋습니다.

미디어 라이브러리에 정상 등록된 이미지 기준으로 사용 여부를 분석하기 때문에 SSH에서 파일명을 보고 직접 삭제하는 것보다 실수를 줄일 수 있습니다.

반면 몇 년 동안 테마와 플러그인을 여러 번 교체한 오래된 워드프레스라면 Media Cleaner만으로는 부족할 수 있습니다.

서버에는 존재하지만 미디어 라이브러리에는 없는 파일, 과거 테마가 만든 썸네일, 최적화 플러그인이 남긴 WebP 등이 있을 수 있기 때문입니다.

그때부터 SSH와 WP-CLI가 필요합니다.

워드프레스 이미지 용량 줄이기 FAQ

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

가능합니다. 무료버전도 워드프레스 미디어 라이브러리를 검사해 미사용 미디어를 찾고 삭제할 수 있습니다. 다만 서버의 uploads 파일시스템을 직접 대조하는 Filesystem Analysis, Live Site Scan, 일부 복잡한 플러그인 지원 및 Media Cleaner용 WP-CLI 기능은 Pro에 포함됩니다.

미디어 라이브러리에서 Unattached면 무조건 삭제해도 되나요?

아닙니다. 게시물에 attachment 관계가 없더라도 본문 HTML, 대표이미지, 테마 옵션, CSS 또는 다른 위치에서 사용하고 있을 수 있습니다. Unattached 표시만 보고 일괄 삭제하는 것은 추천하지 않습니다.

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

당장 서버 용량은 줄어들지만 장기간 운영할 사이트라면 저는 원본 1장은 보관하는 편을 권합니다. 나중에 AVIF로 다시 변환하거나 압축률을 바꿀 때 원본이 필요할 수 있기 때문입니다.

150x150이나 300x300 이미지는 모두 삭제해도 되나요?

아닙니다. 테마 목록, 관련글, 검색결과, 사이드바 등에서 실제로 사용할 수 있습니다. 먼저 wp media image-size로 현재 등록된 사이즈를 확인해야 합니다.

삭제한 썸네일은 다시 만들 수 있나요?

원본 이미지와 워드프레스 Attachment 정보가 정상적으로 남아 있다면 WP-CLI의 wp media regenerate 등을 이용해 현재 등록된 이미지 사이즈를 다시 생성할 수 있습니다.

이미지 용량이 100GB가 넘으면 VPS를 바로 업그레이드해야 하나요?

방문자 수가 많지 않다면 무조건 서버를 올리는 것보다 먼저 이미지 구조를 분석해보는 것이 좋습니다. 원본보다 썸네일·WebP·캐시·백업이 훨씬 많은 환경이라면 서버 사양을 올리지 않고도 수십GB를 확보할 수 있습니다.

워드프레스 이미지 용량을 줄일 때 가장 중요한 것은 큰 파일부터 무작정 삭제하는 것이 아니라 원본과 다시 만들 수 있는 파일을 구분하는 것이라고 생각합니다.

원본 JPG·PNG는 한번 잃어버리면 복구하기 어렵지만, 워드프레스의 썸네일은 원본과 Attachment 정보만 정상이라면 다시 생성할 수 있습니다.

그래서 오래 운영한 AlmaLinux 워드프레스 서버라면 먼저 SSH에서 du와 find로 실제 용량을 확인하고, Media Cleaner로 명확한 미사용 미디어부터 정리한 다음, 오래된 테마 썸네일과 WebP 중복파일을 단계적으로 줄이는 방식이 가장 안전했습니다.

특히 서버 비용이 부담되는 수익형 블로그라면 비싼 VPS로 업그레이드하기 전에 이 작업부터 해보는 것이 좋습니다. 생각보다 원본 이미지가 아니라 수년 동안 자동으로 복제된 파생 이미지가 서버 용량의 상당 부분을 차지하고 있을 수도 있습니다.