워드프레스 업로드 폴더가 유난히 큰 이유
워드프레스 업로드 폴더가 큰 이유는 이미지 하나당 파일 하나만 저장하는 법이 없기 때문입니다. 업로드할 때마다 원본과 함께 정해진 리사이즈 사본이 한 세트씩 생성됩니다.
게시됨
워드프레스 업로드 폴더가 큰 이유는 이미지 하나당 파일 하나만 저장하는 법이 없기 때문입니다. 업로드할 때마다 원본과 함께 정해진 리사이즈 사본이 한 세트씩 생성되는데, 일반적인 카메라 사이즈 사진이라면 테마나 플러그인이 더 추가하기도 전에 이미 일곱 개입니다. 손상된 것이 아니라, 업로드 하나하나마다 벌어지는 곱셈을 보고 있는 것뿐입니다. 해결책은 어차피 쓰지도 않는 사이즈의 생성을 멈춘 다음, 재생성해서 디스크에 남은 옛날 사본들을 지우는 것입니다.
계산을 해보자
4000×3000 JPEG 하나를 업로드하고 /wp-content/uploads/2026/07/ 안을 들여다보세요. 파일이 하나만 있지 않습니다. 다음 파일들이 있습니다.
photo.jpg— 손대지 않은 원본photo-scaled.jpg— 원본 대신 워드프레스가 제공하는 2560px 사본photo-150x150.jpg—thumbnailphoto-300x225.jpg—mediumphoto-768x576.jpg—medium_largephoto-1024x768.jpg—largephoto-1536x1152.jpg—medium_large의 2배 버전photo-2048x1536.jpg—large의 2배 버전
코어만으로도 원본 하나에 파생본 일곱 개입니다. 3 MB짜리 업로드가 플러그인이 하나라도 돌기 전에 디스크에서 5~6 MB로 불어날 수 있습니다. 여기에 자체 사이즈를 네 개 등록하는 테마와 우커머스(세 개 더)를 더하면, 업로드 하나가 열네다섯 개의 파일이 됩니다. 이걸 이미지 수천 개짜리 라이브러리에 곱하면 폴더 용량이 큰 이유는 더 이상 미스터리가 아닙니다.
본인의 이미지 사이즈와 등록된 사이즈에 대한 정확한 숫자를 알고 싶다면, 이미지 저장 용량 계산기가 대신 곱셈을 해줍니다.
왜 이런 일이 생기나
업로드하면 wp_generate_attachment_metadata()가 wp_create_image_subsizes()를 호출하고, 이 함수는 get_intermediate_image_sizes()가 반환하는 모든 사이즈를 순회하면서 원본이 만들어낼 수 있을 만큼 큰 경우마다 파일을 하나씩 씁니다. 코어는 thumbnail, medium, medium_large, large와 함께 WP 5.3에서 추가된 1536x1536, 2048x2048 레티나 사이즈를 등록합니다. add_image_size()를 호출하는 테마나 플러그인은 무엇이든 바로 그 순회 루프에 추가됩니다 — 그것도 앞으로의 모든 업로드에 대해 영구적으로 말이죠.
-scaled 파일은 별개의 메커니즘에서 나옵니다. 바로 기본값 2560px인 big_image_size_threshold 필터입니다. 이보다 넓은 이미지는 스케일된 사본이 생기고, 이 사본이 제공되는 “full” 이미지가 되는 한편 원본은 디스크에 그대로 남습니다. 그래서 큰 이미지를 업로드하면 거대한 원본과 2560px 버전을 둘 다 갖게 됩니다.
주어진 이미지에 대해 본인의 설정이 정확히 무엇을 생성하는지는 이미지 사이즈 인스펙터로 확인할 수 있습니다.
순서대로 고치는 법
1. 아무것도 건드리기 전에 먼저 측정하세요. 어림짐작은 시간 낭비입니다. 사이트 루트에서 실행합니다.
du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20
2. 제공하지 않는 사이즈는 등록을 해제하세요. 대부분의 테마는 1536과 2048 사이즈를 절대 출력하지 않고, 상당수는 medium_large도 전혀 쓰지 않습니다. 없애버리세요.
// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
remove_image_size( '1536x1536' );
remove_image_size( '2048x2048' );
} );
// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
unset( $sizes['medium_large'] );
return $sizes;
} );
3. 재생성해서 옛날 사본을 지우세요. 등록 해제는 앞으로의 생성만 멈출 뿐이며, 이미 디스크에 있는 파일은 재생성하기 전까지 그대로 남습니다.
wp media regenerate --yes
최근 WP-CLI 버전은 더 이상 등록되지 않은 사이즈의 파일을 진행하면서 삭제합니다. 대신 Regenerate Thumbnails 플러그인을 쓰고 있다면 “delete unregistered sizes” 옵션에 체크하세요 — 이 박스를 체크하지 않으면 옛날 파일이 그대로 남습니다.
4. 고아 파일을 찾아내세요. 테마를 바꿔도 예전 테마가 등록했던 사이즈는 절대 정리되지 않습니다. 글을 삭제해도 그 파생본이 항상 지워지는 것도 아닙니다. 3단계 이후에도 du -sh 값이 계산기가 예측한 것보다 여전히 훨씬 크다면, 고아 파일이 있는 것입니다 — 어떤 첨부물도 참조하지 않는, 디스크에 남은 파일들 말이죠.
하지 말아야 할 것
“용량을 아끼려고” 스케일 이미지를 끄지 마세요. -scaled 파일은 원본보다 작습니다. big_image_size_threshold를 끈다고 지워지는 것은 아무것도 없습니다 — 그저 워드프레스가 수 메가바이트짜리 full 원본을 모든 방문자에게 제공하게 만들 뿐입니다. 이건 대역폭과 화질에 관한 결정이지 저장 용량 정리가 아니며, 보통은 페이지 무게를 오히려 더 늘립니다. 스케일 이미지 비활성화 도구는 이 기능을 끄는 게 실제로 맞는 경우가 언제인지 설명합니다 — 업로드 폴더 줄이기는 그런 경우가 아닙니다.
SFTP로 uploads에서 파일을 직접 지우지 마세요. 각 첨부물의 서브사이즈 목록은 해당 첨부물의 _wp_attachment_metadata에 들어 있습니다. 손으로 파일을 지우면 깨진 참조가 남고, 파생본을 만들어낸 원본을 지워버렸다면 재생성으로도 그 사이즈를 다시 만들 수 없습니다. 원본을 지우면 그 이미지는 영영 사라집니다.
설정 → 미디어에서 thumbnail/medium/large를 0으로 놓고 폴더가 줄어들 것이라 기대하지 마세요. 사이즈를 0으로 두면 앞으로의 생성은 멈추지만 이미 디스크에 있는 것은 아무것도 건드리지 않으며, UI로는 medium_large, 1536, 2048나 테마/플러그인 사이즈에 접근할 수도 없습니다 — 거기엔 없으니까요.
데이터베이스를 탓하지 마세요. 무거운 uploads 폴더는 이미지 파일이지, DB인 경우는 사실상 없습니다. 테이블 최적화로는 그 숫자가 움직이지 않습니다.
그래도 안 되면?
재생성한 뒤에도 폴더가 예상보다 여전히 크다면, 본인의 실제 이미지 사이즈와 등록된 사이즈를 저장 용량 계산기에 넣어 나온 수치를 du -sh wp-content/uploads와 비교해 보세요. 차이가 크다면 예전 테마나 삭제된 글에서 남은 고아 파일이 있다는 뜻입니다 — 코어 탓도 아니고, 재생성을 더 한다고 해결될 문제도 아닙니다. 차이가 작다면 그저 계산이 원래 그런 것입니다. 업로드당 일곱 개 이상의 파일, 설계된 그대로 정확히 작동하고 있는 것이죠.