Slider Revolution으로 만든 슬라이드의 배경이미지가 보이지 않는 문제를 해결하다가 여기까지 왔습니다. 웹하드 용량 부족으로 Slider Revolution으로 만든 슬라이드의 배경이미지가 로딩이 안되었던 것입니다.
문제가 된 호스팅 상품은 10G 광아우토반 FullSSD Plus 자이언트을 이용하고 있습니다. 전체 용량이 10,100Mbyte(10.1 GiGabyte)로 작지 않습니다. 그런데 용량이 거의 찾습니다. 가장 큰 문제는 워드프레스로 컨텐츠를 추가하지 않아도 계속 용량이 증가하여 찬다는 것입니다. 용량을 추가해도 같은 문제가 반복될 것이 뻔하다는 것입니다.
원인을 캐시와 백업 파일 문제라고 판단하였습니다.
캐시 플러그인을 일일히 찾고 이놈이 생성한 캐시 파일을 찾아서 수동으로 삭제하려 하니 시간이 많이 걸렸으며 이렇게 하여 줄어든 용량도 미비하였습니다.
FTP에서 해답을 쉽게 찾을 수 있었습니다. ‘back’으로 검색하니 문제를 야기한 원인 명확해젔습니다.
Tip : 다음에 웹하드 용량에 문제가 생기면 back(backp), cache 이렇게 2단어를 검색하면 원인을 쉽게 찾을 수 있습니다. 기억해주세요.
loco 번역 플로그인으로 생성된 비정상적으로 큰 po파일이 문제였습니다.

woocommerce-ko_KR-backup-20250227121816O.po- (1,803,935 KB = 약 1.8GB)
woocommerce-ko_KR-backup-20250227219500.po- (1,803,937 KB = 약 1.8GB)
woocommerce-ko_KR-backup-20250227218640.po- (1,798,439 KB = 약 1.8GB)
geodirectory-ko_KR-backup-202411020719190.po- (582,336 KB = 약 582MB)
geodirectory-ko_KR-backup-202411020774220.po- (582,100 KB = 약 582MB)
geodirectory-ko_KR-backup-202411020717130.po- (581,364 KB = 약 581MB)
geodirectory-ko_KR-backup-202411020763110.po- (581,851 KB = 약 582MB)
geodirectory-ko_KR-backup-202411020715210.po- (581,829 KB = 약 582MB)
위에 파일들을 FTP로 삭제했는데, 왜 12시간 정도 지났는데, 카페24의 웹용량은 즉시 늘어나지 않을까요?
확인 시점
다음 시간대에 재확인:
- 1시간 후
- 4시간 후
- 내일 오전 (24시간 후)
만약 24시간 후에도 갱신 안 되면:
1. 카페24 고객센터 직접 문의
2. 파일 삭제 증빙 스크린샷 제공
3. 수동 용량 갱신 요청
카페24 게시판 문의를 통해 알게된 원인은 debug.log였습니다. 카페24의 답변은 아래와 같습니다.
www폴안의 폴더별 용량을보면
32K ./.well-known
4.0K ./.quarantine
56M ./wp-includes
112K ./.tmb
9.5G ./wp-content
11M ./wp-admin
4.0K ./cgi-bin
wp-content 폴더에서 가장많은 용량을 차지하고있는걸로 확인되며 wp-content 폴더안의 폴더별용량을보면
12K ./.well-known
40M ./wp-includes
6.4G ./uploads
391M ./plugins
47M ./wp-content
39M ./themes
64K ./mu-plugins
24K ./ai1wm-backups
9.6M ./wp-admin
776K ./endurance-page-cache
4.0K ./upgrade-temp-backup
15M ./languages
4.0K ./cgi-bin
4.0K ./upgrade
uploads 폴더에서 용량을 많이 차지하는걸로 확인됩니다.
다만 현재 www/wp-content 폴더안에 보면 워드프레스 디버깅파일이 있는걸로 확인되며 디버깅 파일의 용량이 상당히 큰것으로 확인됩니다.
2.7G debug.log -> 이 놈을 삭제하니 실시간으로(바로 2.7Gbyte)가 늘어나서 문제를 해결할 수 있었습니다.
위처럼 디버깅 파일이 2.7GB정도되고 해당파일이 고객님이 wp-config.php파일에 디버깅설정을 해놓으셔서
지속적으로 debug.log 파일명으로 로그가 쌓이고있는걸로 확인됩니다.
디버깅 파일이 불필요하다면 FTP서버로 접속후 wp-config.php파일에서 디버깅 기능을 비활성화를해주시기 바랍니다.
define(‘WP_DEBUG’, true );
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
현재 위처럼 디버깅 기능 활성 및 로그파일 저장이되도록 하신부분을
define(‘WP_DEBUG’, false );
#define(‘WP_DEBUG_LOG’, true);
#define(‘WP_DEBUG_DISPLAY’, false);
위처럼 수정 및 주석처리를하면 더이상 디버깅 로그파일이 남지않게되고 이후에
www/wp-content 폴더에 접속후 debug.log 일을 삭제를해보시기 바랍니다.
이 파일들은 Loco Translate 플러그인이 생성한 번역 파일들의 백업입니다.
.po 파일 = 번역 파일일반적인 번역 파일은 수 MB 정도인데, 1.8GB는 비정상적입니다:
이 백업 파일들은 삭제해도 안전합니다!
→ 실제 번역 파일은 별도 위치에 있음
→ 백업이므로 웹사이트 기능에 영향 없음
WordPress 관리자 → Loco Translate → Settings
→ "File system permissions" 확인
→ "Backup directory" 설정 확인
/wp-content/languages/plugins/
/wp-content/languages/themes/
Loco Translate → Settings → Advanced
→ "Number of backups to keep" = 3개 정도로 제한
→ "Enable file backups" 체크 해제 (선택사항)
bash# FTP에서 파일명 확인
- 파일명에 "backup" 포함
- 확장자가 .po- (하이픈 포함)
- 타임스탬프 포함 (20250227121816)
1. 웹사이트 정상 작동 확인
2. 한국어 번역 정상 표시 확인
3. Loco Translate 플러그인 정상 작동 확인
→ 백업 개수 제한 (3-5개)
→ 자동 백업 주기 조정
→ 오래된 백업 자동 삭제 활성화
→ 정기적으로 백업 폴더 확인
→ 비정상적인 대용량 파일 감시
결론: 이 파일들은 Loco Translate의 백업 파일이므로 안전하게 삭제 하시면 됩니다.