워드프레스 서버 용량 부족? 이미지가 여러 개 생성되는 이유
워드프레스 서버 용량이 너무 빨리 줄어든다면? 이미지 1장이 7~8개로 저장되는 이유
안녕하세요. 디탑입니다!
워드프레스 블로그를 시작한 지 얼마 되지 않았는데 서버 저장공간이 예상보다 훨씬 빠르게 줄어들고 있었어요. 제가 쓰는 카페24 호스팅의 저장공간은 700MB인데, 게시물이 늘어날수록 남은 용량이 눈에 띄게 줄어들더라고요.
처음엔 압축하지 않은 고해상도 PNG를 그대로 올린 게 원인이라고 생각했어요. 실제로 초반에는 이미지 용량을 거의 신경 쓰지 않았거든요. 그런데 서버의 이미지 폴더를 직접 열어보니 또 하나의 사실을 발견했습니다. 이미지 한 장을 업로드했는데, 같은 원본에서 파생된 파일이 7~8개씩 저장되어 있었어요.
예를 들어 image-30.png 한 장을 기준으로 서버에는 이런 파일들이 함께 있었습니다.
image-30-150x150.png
image-30-300x169.png
image-30-768x432.png
image-30-1024x576.png
image-30-1536x864.png
image-30-2048x1152.png
image-30-scaled.png
image-30.png
처음엔 단순한 중복 파일인 줄 알았어요. 하지만 확인해보니 워드프레스는 이미지 하나를 올리면 화면이나 용도에 맞는 여러 크기의 이미지를 자동으로 만들어두는 구조였고, 테마나 플러그인이 별도의 크기를 추가하는 경우도 있었습니다.
그러면 질문이 달라져요. “중복 이미지를 전부 삭제하면 되는 것 아닐까?”가 아니라 **”내 사이트에 실제로 필요한 이미지는 무엇이고, 제한된 워드프레스 서버 용량을 어떻게 관리해야 할까?”**를 먼저 확인해야 하더라고요.
이번 글에서는 제가 워드프레스 서버 용량 문제를 직접 겪으면서 확인한 원인과, 현재 선택한 해결 방향을 정리해봤습니다.
한눈에 보기
이번에 확인한 핵심은 세 가지예요.
- PNG 원본 자체가 컸다. 압축하지 않은 고해상도 PNG를 많이 쓰면서 원본 이미지가 상당한 저장공간을 차지하고 있었습니다.
- 워드프레스는 이미지 1장을 여러 크기로 저장한다. 반응형 이미지 등에 쓰기 위해 여러 크기의 파일을 자동 생성하기 때문에, 미디어 라이브러리에 보이는 이미지 수와 서버에 실제 저장된 파일 수는 다를 수 있습니다.
- 삭제보다 최적화가 먼저다. 자동 생성 이미지를 무작정 지우기보다, 기존 원본을 최적화하고 앞으로 올릴 이미지의 크기와 형식을 관리하는 게 우선이라고 판단했습니다.
제 경우에는 기존 PNG의 파일명과 확장자를 유지한 채 용량만 줄이고, 새로 올리는 이미지는 WebP 중심으로 관리하는 방법을 선택했어요. 최적화 후 실제 저장공간이 얼마나 줄었는지는 다음에 확인해서 공유할게요.
워드프레스 이미지 한 장이 왜 여러 파일로 저장될까?
워드프레스는 업로드한 원본 하나만 저장해서 쓰는 방식이 아니에요.
PC의 큰 화면과 스마트폰의 작은 화면에서 항상 같은 고해상도 원본을 불러오면 불필요하게 큰 데이터를 전송하게 되죠. 그래서 워드프레스는 원본을 바탕으로 여러 크기의 이미지를 미리 만들어둡니다.
제가 서버에서 발견한 파일들도 정확히 이 구조였어요.
| 파일명 접미사 | 크기 |
|---|---|
-150x150 | 썸네일 |
-300x169 | 중간(medium) |
-768x432 | 중간-대형(medium_large) |
-1024x576 | 대형(large) |
-1536x864 | 2배 해상도용 |
-2048x1152 | 2배 해상도용 |
-scaled | 원본이 너무 클 때 축소된 대체본 |
| (접미사 없음) | 업로드 원본 |
WordPress 공식 개발자 문서를 보면, 워드프레스 코어는 기본 크기 외에 1536과 2048 사이즈를 추가로 등록하고 있고, 원본의 가로 또는 세로가 2560px을 넘으면 축소된 -scaled 파일을 만들어 실제 사용 이미지로 삼는다고 설명하고 있어요. 브라우저는 srcset과 sizes 정보를 보고 상황에 맞는 크기를 골라 씁니다.
즉 서버에 여러 크기의 이미지가 존재한다는 사실 자체는 오류가 아니에요. 오히려 방문자가 불필요하게 큰 이미지를 내려받지 않도록 하는 정상적인 기능의 일부입니다.
이미지가 여러 개면 서버 용량도 그만큼 늘어날까?
여기서 제가 처음 했던 생각은 단순했어요. “이미지 하나가 7~8개씩 만들어지면, 이것 때문에 저장공간이 부족해진 것 아닐까?”
하지만 파일 개수만 보고 판단하면 안 되더라고요. 원본 이미지가 몇 MB인지, 자동 생성된 각 이미지가 어느 정도 용량인지, 사이트에 이미지가 얼마나 많이 올라가 있는지를 함께 봐야 합니다. 작은 썸네일 여러 개보다 압축하지 않은 고해상도 PNG 원본 하나가 더 많은 공간을 차지할 수도 있거든요.
그래서 워드프레스 이미지가 쓰는 저장공간은 파일 개수보다 이렇게 생각하는 게 더 정확했어요.
원본 이미지 용량 + 자동 생성 이미지 용량 + 업로드한 전체 이미지 수
제 경우에는 워드프레스가 여러 크기를 만든다는 사실뿐 아니라, 과거에 올려둔 PNG 원본의 크기도 같이 살펴봐야 했습니다.
제 경우엔 PNG 원본 용량도 문제였다
블로그를 처음 운영할 땐 파일 형식이나 압축률을 크게 신경 쓰지 않았어요. 그래서 상당수 이미지를 PNG로 저장했고, 일부는 별도 최적화 없이 그대로 업로드했습니다.
PNG가 나쁜 형식이라는 뜻은 아니에요. 그래픽 특성이나 투명 배경이 필요할 땐 PNG가 적합한 경우도 있죠. 문제는 블로그용 이미지까지 필요 이상으로 큰 해상도와 파일 크기로 계속 저장하고 있었다는 점이었습니다.
큰 PNG 원본을 올리고, 거기서 워드프레스가 여러 크기의 이미지를 추가로 만드는 과정이 반복되면 700MB처럼 제한된 서버 저장공간에서는 부담이 될 수밖에 없어요. 이미지 몇 장 올릴 땐 체감하지 못했지만, 게시물이 늘면서 이미지도 함께 누적됐고 예상보다 빠르게 저장공간을 쓰고 있었습니다.
자동 생성된 이미지를 모두 삭제해도 될까?
서버에서 여러 크기의 이미지를 처음 봤을 때 가장 먼저 떠오른 방법은 필요 없어 보이는 파일을 지우는 거였어요. 하지만 확인 없이 일괄 삭제하는 방법은 선택하지 않았습니다.
본문이나 썸네일뿐 아니라 현재 쓰는 테마와 플러그인이 특정 크기의 이미지를 불러오고 있을 가능성이 있기 때문이에요. 파일명에 150x150이나 768x432 같은 숫자가 붙어 있다고 해서 모두 불필요한 파일이라고 단정할 수는 없습니다.
그래서 두 가지를 구분할 필요가 있었어요.
- 현재 워드프레스가 어떤 크기의 이미지를 생성하고 있는가
- 실제 사이트에서 그중 어떤 크기를 사용하고 있는가
불필요한 크기의 생성을 줄이는 것과, 이미 만들어진 파일을 정리하는 것도 서로 다른 문제고요. 그래서 저는 파생 이미지를 먼저 삭제하기보다 원본 용량을 줄이고 앞으로 들어오는 이미지의 크기를 관리하는 쪽을 우선하기로 했습니다.
제가 선택한 방법: 기존 PNG 최적화 + 신규 WebP
문제를 확인한 뒤, 기존 이미지와 앞으로 올릴 이미지를 서로 다른 방식으로 관리하기로 했어요.
기존 이미지: 구조는 유지하고 용량만 줄이기
서버에서 기존 이미지 다운로드
PNG 이미지 압축
기존 파일명·확장자 유지
압축본으로 기존 파일 교체
기존 게시물에서 쓰고 있는 이미지 URL과 파일 구조를 최대한 유지하면서 파일 자체의 용량만 줄이기 위한 방법이에요. 이미 발행된 PNG의 확장자를 일괄 WebP로 바꾸면 기존 이미지 URL과 워드프레스 내부 참조 관계까지 확인해야 해서, 기존 이미지는 건드리지 않기로 했습니다.
신규 이미지: WebP를 기본으로
반면 앞으로 새로 만드는 블로그 이미지는 가능한 한 WebP를 기본 형식으로 쓰기로 했어요. 새로 올리는 이미지부터 WebP를 쓰면 기존 게시물을 건드리지 않으면서 앞으로 늘어나는 저장공간을 관리할 수 있거든요.
그래서 현재 제 원칙은 간단합니다.
기존 이미지는 파일 구조를 유지하면서 최적화하고, 신규 이미지는 WebP 중심으로 관리한다.
저장공간을 추가할까, 호스팅을 이전할까?
이미지 문제를 확인하기 전에는 호스팅 자체를 바꾸는 방법도 검토했어요. 카페24 기본 저장공간은 700MB이고, 추가하려면 별도 비용이 들죠. 그래서 카페24 추가 저장공간을 구매하는 것과 Cloudways처럼 기본 저장공간이 더 큰 호스팅으로 사이트 전체를 이전하는 방법을 비교해봤습니다.
하지만 서버를 확인하면서 생각이 조금 달라졌어요. 이미지 관리 방식에 문제가 있는 상태에서 저장공간만 늘리면, 당장의 부족은 해결돼도 이미지가 계속 쌓이는 구조 자체는 그대로거든요.
그래서 지금은 호스팅 이전보다 이미지 최적화를 먼저 진행하기로 했습니다. 기존 PNG를 압축하고 신규 이미지를 WebP로 관리하면서 저장공간 증가 속도가 실제로 얼마나 달라지는지 확인한 다음, 추가 용량이 필요한지 다시 판단할 생각이에요. 호스팅 이전은 그 이후에 검토해도 늦지 않다고 봤습니다.
- 카페24의 서버용량 추금은 타서비스 대비 비싸네요. 1gb 1년 결제 시 49,830원
디탑의 결론
처음엔 단순히 카페24의 700MB 저장공간이 너무 작은 게 문제라고 생각했어요. 하지만 서버 내부를 직접 확인해보니 그렇게 단순하게 볼 수는 없었습니다. 압축하지 않은 PNG 원본이 있었고, 하나의 원본에서 워드프레스가 여러 크기의 이미지를 만들고 있었죠.
중요한 건 워드프레스가 여러 크기의 이미지를 만드는 것 자체는 잘못이 아니라는 점이에요. 화면에 맞는 크기의 이미지를 제공하기 위한 정상적인 기능일 수 있습니다.
따라서 제가 풀어야 할 문제는 “자동 생성 이미지를 모두 없애는 것”이 아니라 **”내 사이트에 필요한 이미지 구조를 유지하면서 전체 이미지 용량을 어떻게 효율적으로 관리할 것인가”**였어요. 그래서 지금은 호스팅 용량을 바로 추가하거나 서버를 이전하기보다, 기존 PNG를 최적화하고 신규 이미지를 WebP로 관리하는 방법을 먼저 적용하고 있습니다.
다만 여기서 결론이 끝난 건 아니에요. 이미지를 실제로 압축한 뒤 워드프레스 서버 용량이 얼마나 줄었는지, 게시물이 늘어날 때 저장공간 증가 속도가 얼마나 달라지는지를 확인해야 합니다. 그 결과를 측정한 뒤 카페24를 그대로 유지할지, 추가 저장공간을 살지, 다른 호스팅으로 옮길지도 다시 비교해볼게요.
다음에 확인할 것
이번엔 워드프레스 서버 저장공간이 빠르게 줄어드는 문제에서 출발해 이미지 파일 구조를 확인했어요. 그 과정에서 새로운 질문이 생겼습니다.
150×150, 300×169, 768×432, 1024×576, 1536×864, 2048×1152 같은 이미지들은 정확히 누가 만들고 있는 걸까요?
워드프레스가 기본으로 생성하는 이미지와 테마 또는 플러그인이 추가하는 이미지를 구분할 수 있다면, 실제로 필요하지 않은 이미지가 계속 만들어지는 것도 줄일 수 있을지 몰라요. 다음 글에서는 워드프레스가 생성하는 이미지 크기의 구조와, 실제 사이트에서 어떤 이미지가 쓰이고 있는지를 확인해보겠습니다.
3줄 요약
- 워드프레스는 이미지 1장을 올리면 여러 크기의 파일을 자동 생성하며, 이는 오류가 아니라 정상 기능이다.
- 저장공간 부족의 실제 원인은 파일 개수보다 압축하지 않은 PNG 원본 용량과 누적된 이미지 수였다.
- 자동 생성 파일을 삭제하기보다 기존 PNG를 최적화하고 신규 이미지를 WebP로 관리한 뒤, 호스팅 변경은 이후에 판단한다.
