워드프레스 WebP 변환 후기 Plus WebP or AVIF로 원본 이미지 삭제까지 해본 진짜 기록
오랜만에 워드프레스 후기를 남깁니다.
워드프레스를 오래 굴리다 보니 어느 순간부터 사이트가 묵직해지더라고요. 글이 쌓이는 건 좋은데, 그만큼 미디어 라이브러리 용량이 눈덩이처럼 커지고, 백업 파일은 커지고, 속도는 조금씩 떨어지는 게 체감됐습니다. 특히 예전에 업로드해둔 JPG/PNG 이미지들이 계속 쌓여 있는 게 마음에 걸렸어요.

예전에는 이미지 변환과 압축 때문에 Smush Image랑 Imagify 같은 걸 써봤는데, 스머시는 옛날에 쓰다가 이미지가 좀 날아가서 트라우마가 생겼고, Imagify는 WP Rocket 덕에 같이 쓰긴 했지만 무료 용량 제한이 걸리다 보니 결제까지 했다가 결국 다시 원복했던 경험이 있습니다. 그래서 이번에는 방향을 확실히 잡았습니다.
- [IT 리뷰/블로그 SEO] - 워드프레스 이미지 최적화 · Gzip 압축 PageSpeed 점수후기 (Smush · Hummingbird · WP Rocket)
- [IT 리뷰/블로그 SEO] - 워드프레스 최적화 - WP Rocket 플러그인 사용후기
목표는 하나로 워드프레스 webp 변환을 해놓고 끝내는 게 아니라, 원본 이미지까지 정리해서 서버 용량을 줄이고, 페이지 전송량도 줄이고, 결과적으로 체감 속도까지 끌어올리는 것. 그리고 남는 김에 DB도 군살이 있으면 같이 정리하느것입니다.
왜 Plus WebP or AVIF를 골랐나
이미지 최적화 플러그인은 정말 많습니다. 그런데 막상 써보면 “WebP를 만들어두긴 하는데 원본(JPG/PNG)은 그대로 둔다” 쪽이 많더라고요. 그 방식도 나쁘진 않지만, 내 목표가 디스크 용량 자체를 줄이는 것이어서 아쉬웠습니다. 트래픽은 줄어도 서버는 계속 비대해질 수 있으니까요.
Plus WebP or AVIF는 WebP로 변환한 뒤에 원본을 교체하는 개념으로 가져갈 수 있다는 점이 마음에 들었습니다. 변환만 하고 끝나는 느낌이 아니라, 실제로 “이미지 관리가 가벼워지는 방향”으로 정리되는 쪽이었어요.

변환 전, 내가 먼저 정리한 것
이건 진짜 중요합니다. 이미지 관련 플러그인을 여러 개 동시에 만지면, 그때부터 사이트가 삐걱거리기 시작하더라고요. 한쪽은 리사이즈 만들고, 한쪽은 WebP 만들고, 또 한쪽은 CDN 규칙으로 바꿔치기하고… 그러다 보면 같은 파일이 여러 번 손을 타면서 중복 파일, 깨진 링크, 캐시 꼬임 같은 게 슬금슬금 올라옵니다.
그래서 나는 딱 한 가지로 정했습니다. 이미지 변환은 한 플러그인만 맡긴다. 기존에 Smush/Imagify/EWWW/ShortPixel 같은 걸 쓰고 있던 분이라면, 최소한 WebP 관련 기능은 꺼두고 한쪽만 맡기는 게 마음이 편합니다.

그리고 백업은 무조건 했습니다. uploads 폴더랑 DB를 같이 묶어서 잡아두면 심리적으로 훨씬 편해요. 원본 이미지 삭제까지 갈 생각이면, 이건 선택이 아니라 보험입니다.
원본 삭제는 “마지막”에 해야 속이 편하다
처음부터 전체 이미지를 한 번에 몰아치지 않고, 자주 들어오는 글 몇 개를 골라 먼저 확인했습니다.

특히 이미지가 많은 글, 썸네일이 여러 크기로 쓰이는 글, 갤러리나 슬라이더가 들어간 글은 꼭 확인했어요. 여기만 통과하면 웬만한 페이지는 안정적으로 따라옵니다.
그리고 원본 이미지 삭제는 변환과 교체가 끝난 다음에 했습니다.

변환만 해놓고 원본을 먼저 지우면, 글 본문이나 일부 메타가 아직 JPG/PNG를 가리키고 있어서 이미지가 안 뜨는 경우가 생길 수 있어요. 반대로 교체까지 끝난 상태에서 정리하면, 사이트가 이미 WebP 기준으로 굴러가니까 훨씬 안정적입니다.
캐시는 반드시 비웠다
여기서 한 번 낚일 뻔했는데, 변환이 끝났는데도 “뭔가 이미지가 이상한데?” 싶을 때가 있었습니다. 대부분은 실제 문제가 아니라 브라우저 캐시나 사이트 캐시가 예전 파일을 붙잡고 있던 상황이었어요. WP Rocket이나 Cloudflare를 쓰고 있다면 변환 후에는 캐시를 한 번 비워주는 게 정신 건강에 좋습니다.
변환 전후로 달라진 것
가장 먼저 눈에 들어온 건 uploads 용량이었습니다. 예전엔 이미지 하나 올리면 크기별 파일이 여러 장씩 생기고, 그게 글 개수만큼 누적되니까 서버가 차오르는 속도가 진짜 빠르더라고요. WebP로 바꾸고 원본까지 정리하니까 미디어 라이브러리가 한결 가벼워진 느낌이 확 왔습니다. 백업 파일도 덩달아 가벼워지고요.
속도는 사이트 구조에 따라 차이가 있겠지만, 사진 많은 글에서 확실히 체감이 났습니다. 페이지 전송량이 줄면 모바일에서 특히 티가 나더라고요. 이미지가 빨리 뜨니까 페이지가 “먼저 완성되는 느낌”이 생깁니다.
DB는 솔직히 말하면 이미지 변환만으로 크게 줄어드는 영역은 아닙니다. 이미지 파일은 기본적으로 디스크가 주 무대고, DB는 리비전이나 임시 캐시 데이터가 훨씬 많이 먹는 편이더라고요. 그래서 나는 이미지 정리 후에 DB 군살도 같이 덜어주는 쪽으로 마무리했습니다.
| 항목 | 변환 전 | 변환 후 | 메모 |
| wp-content/uploads 용량 | 예: ( )GB | 예: ( )GB | 서버 전체 백업 크기에도 같이 영향 |
| 대표 글 1개 전송량 | 예: ( )MB | 예: ( )MB | 이미지 많은 글을 기준으로 보면 차이가 잘 보임 |
| 모바일 체감 로딩 | 예: 느림 | 예: 개선 | 이미지 로딩 안정감이 좋아지는 편 |
| 미디어 백업 파일 크기 | 예: ( )GB | 예: ( )GB | 백업/복구 시간을 줄이는 데 도움 |
겪었던 이슈와 해결 경험
간혹 특정 글에서만 이미지가 안 뜨는 경우가 있었는데 우선 내가 겪은 케이스는 대부분 두 가지였어요. 하나는 그 글이 예전 편집기에서 저장된 스타일이라 이미지 참조가 묘하게 남아 있던 경우, 다른 하나는 캐시가 예전 파일을 잡고 있던 경우였습니다.
캐시를 비우고, 문제가 생긴 글은 한 번 저장만 다시 해도 풀리는 경우가 꽤 많았습니다.

정말 드물게는 특정 이미지 하나가 문제를 일으키기도 해서, 그때는 해당 이미지를 다시 업로드해서 정리했습니다. 다행히 “전체가 와장창” 같은 일은 없었어요. 초반에 대표 글들만 먼저 확인해둔 덕이 컸습니다.
또 하나는 투명 PNG였습니다. 로고나 아이콘처럼 투명 배경이 들어간 이미지는 WebP로 바뀌면서 가장자리 느낌이 달라 보일 때가 있더라고요. 이런 이미지는 품질 값을 조금 더 보수적으로 잡으니까 깔끔하게 해결됐습니다. 사진은 조금 더 과감하게 눌러도 티가 덜 나고, 텍스트/로고는 조금만 뭉개져도 바로 티가 납니다.
Plus WebP or AVIF를 추천하는 사람
워드프레스 webp 변환을 “해봤다”에서 끝내지 않고, 서버 저장공간까지 확실히 줄이고 싶은 분에게는 이 방향이 꽤 시원합니다. 특히 글이 계속 쌓이는 블로그라면, 미디어 라이브러리부터 가볍게 만들어두는 게 장기적으로 마음이 편해요.
그리고 변환이 끝난 뒤에 플러그인을 계속 둘지 말지는 스타일 차이입니다. 나는 앞으로 업로드되는 이미지까지 자동으로 관리되는 게 편해서 남겨뒀고, 반대로 “한 번만 싹 정리하고 가볍게 운영”하는 타입이면 변환이 끝난 뒤 정리해도 크게 문제는 없었습니다.
추가로 같이 해두면 체감이 더 커지는 정리
WebP로 바꾸고 원본 이미지 삭제까지 끝냈는데도 “속도가 크게 안 변한 것 같다”는 느낌이 들 수도 있어요. 이건 이미지가 아니라 다른 곳이 발목을 잡고 있는 경우가 많습니다. 내가 같이 손 본 포인트는 이쪽이었습니다.
업로드 이미지 크기부터 줄이면 결과가 더 깔끔하다
예전에 스마트폰으로 찍은 고해상도 원본을 그대로 올려둔 글이 많았습니다. WebP로 바꿔도 파일이 줄긴 하지만, 애초에 필요 이상으로 큰 이미지가 많으면 낭비가 남아요. 본문에서 실제로 보여주는 폭이 정해져 있다면, 그 폭에 맞는 크기로 만들어두는 게 가장 효율이 좋았습니다.
리비전과 임시 캐시 데이터는 한 번쯤 청소해볼 만하다
DB를 갉아먹는 건 의외로 이미지보다 리비전, 임시 캐시 데이터, 자동 로드 옵션 같은 게 크더라고요. 이미지 정리 후에 이런 군살을 조금 덜어주면 관리자 화면도 가벼워지고, 백업도 더 쾌적해집니다. 과하게 지우기보다는 보수적으로 손보는 편이 안전했습니다.
CDN을 쓰면 이미지도 “보이는 대로”만 믿으면 안 된다
Cloudflare 같은 걸 쓰면 변환이 끝났는데도 한동안 예전 이미지가 보일 수 있습니다. 이건 변환 실패가 아니라 캐시 때문인 경우가 많았어요. 변환이 끝난 날은 캐시를 한 번 비워주는 쪽이 속이 편했습니다.
결국 내가 원했던 건 딱 이것이었습니다. 미디어 라이브러리 용량을 줄이고, 백업을 가볍게 만들고, 페이지 전송량도 덜어내서 사이트가 오래 버틸 체질로 바꾸는 것. WebP 변환은 “속도” 얘기로만 끝나는 줄 알았는데, 실제로 해보니 운영 스트레스를 줄여주는 쪽이 더 컸습니다.
FAQ
Plus WebP or AVIF로 변환하고 나서 플러그인을 지워도 되나
변환이 끝난 뒤 이미지가 실제로 WebP로 교체되어 있고, 글에서도 WebP가 정상 표시되는 걸 확인했다면 크게 문제 없이 운영되는 경우가 많았습니다. 다만 이후에 새로 올리는 이미지까지 계속 자동 변환하고 싶다면 남겨두는 편이 편합니다.
원본 이미지 삭제를 해도 이미지가 깨지지 않나
원본을 지우기 전에 “교체가 끝났는지”가 핵심이었습니다. 나는 대표 글 몇 개를 먼저 확인한 뒤 원본을 정리했더니 큰 문제는 없었습니다. 캐시가 예전 파일을 보여줘서 깨진 것처럼 보일 때가 있으니 캐시 비우기도 같이 해주는 게 좋았습니다.
WebP로 바꾸면 무조건 속도가 빨라지나
사진이 많은 글에서는 체감이 나는 경우가 많았지만, 사이트 전체 속도는 테마, 플러그인, 서버 반응 속도, 캐시 구성 같은 요소의 영향도 큽니다. 내 경우엔 전송량이 줄면서 모바일에서 특히 안정감이 좋아졌습니다.
투명 PNG(로고, 아이콘)는 WebP로 바꿔도 괜찮나
가능은 한데, 로고나 텍스트가 들어간 이미지는 압축에 더 민감했습니다. 이런 이미지는 품질 설정을 조금 더 보수적으로 잡는 편이 결과가 깔끔했습니다.
이미지 플러그인을 여러 개 같이 써도 되나
가능은 하지만 충돌 확률이 올라갑니다. 나는 이미지 변환은 한 플러그인만 맡기고, 나머지는 캐시나 기타 기능만 쓰는 식으로 역할을 나눴더니 덜 흔들렸습니다.
예전에 올린 이미지가 너무 많으면 처리 시간이 오래 걸리나
이미지 개수가 많을수록 시간이 늘어나는 건 당연했습니다. 그래서 나는 자주 보는 글 몇 개로 먼저 확인해두고, 그 다음 전체를 돌리는 쪽이 마음이 편했습니다.
변환 후에도 용량이 크게 안 줄어든 것 같은데 왜 그런가
원본이 남아 있거나, 크기별로 생성된 썸네일 이미지가 많이 남아 있는 경우가 많습니다. 예전 설정으로 생성된 사이즈가 많으면 체감이 덜할 수 있어서, 미디어 라이브러리를 한 번 점검해보는 게 도움이 됩니다.
워드프레스 DB는 어떤 걸 정리하면 체감이 있나
이미지 자체보다는 리비전, 임시 캐시 데이터, 자동 로드 옵션이 비대해진 경우가 더 체감이 컸습니다. 다만 DB 정리는 무리해서 한 번에 크게 지우기보다, 안전한 범위부터 천천히 손보는 편이 낫습니다.
'IT 리뷰 > 블로그 SEO' 카테고리의 다른 글
| Cloudflare + WHM(cPanel) + ModSecurity + cPHulk 해외 로그인 공격(Brute Force) 차단 (0) | 2026.02.12 |
|---|---|
| 워드프레스 & WHM 보안 서치콘솔 오류부터 외부 유입 차단까지 (0) | 2026.02.12 |
| 구글 페이지스피드 Robots.txt AI봇 차단 해결후기 (0) | 2026.02.12 |