워드프레스 데이터베이스 용량 증가 원인 분석

1월 05, 2026

워드프레스를 운영하며 블로그 속도가 느려지는 경험, 다들 한 번쯤 겪으셨을 겁니다. 저 역시 그랬습니다. 눈에 보이지 않지만 서버 자원을 야금야금 잡아먹는 데이터베이스(DB) 용량 폭발 때문에 한때 블로그 로딩 속도가 2초를 넘어갔던 아픈 기억이 있습니다. 단순히 포스팅 몇 개 늘었다고 DB가 수백 MB까지 불어날 리 없죠. 제 경험을 바탕으로 워드프레스 DB를 비대하게 만드는 숨겨진 원인들을 분석하고, 2주 만에 DB 용량을 150MB에서 28MB까지 줄였던 실질적인 노하우를 공유합니다.

1. 원인 분석: 워드프레스 DB 용량을 키우는 3대 빌런.

제 블로그 DB를 분석했을 때, 용량 증가를 유발하는 핵심 요소는 크게 세 가지였습니다.

포스트 리비전(Post Revisions): 글을 작성하고 저장할 때마다 생성되는 자동 백업 데이터입니다. 포스팅이 100개이고 리비전이 각 10개라면, 사실상 1,000개의 게시물이 있는 것과 같습니다.
트랜지언트(Transient) 및 세션 데이터: 캐싱 플러그인이나 일부 테마가 저장해두는 임시 데이터입니다. 특히 수명이 만료된 데이터가 제대로 삭제되지 않고 wp_options 테이블에 쌓일 때 용량 폭발의 주범이 됩니다.
사용하지 않는 플러그인의 잔해: 플러그인을 비활성화하거나 삭제해도 DB에 로그, 설정 기록, 히스토리 테이블 등을 남기는 경우가 많습니다.

2. 응급 처치: 10분 만에 끝내는 DB 플러그인 정리.

가장 쉽고 빠르게 DB 용량을 정리하는 방법은 최적화 플러그인을 활용하는 것입니다. 저는 'WP-Optimize' 플러그인을 사용하여 초기 용량의 30% 정도를 즉시 줄일 수 있었습니다.

Step-by-step 정리 순서:

WP-Optimize를 설치하고 활성화합니다.
'데이터베이스' 메뉴로 이동합니다.
'포스트 리비전 정리', '스팸 및 휴지통 댓글 정리' 항목을 선택합니다.
'선택한 최적화를 실행합니다' 버튼을 눌러 작업을 수행합니다. (작업 전 반드시 DB 백업을 권장합니다.)

3. 설정 최적화: wp-config.php를 통한 리비전 통제.

응급 처치로 기존의 리비전은 정리되었지만, 앞으로 글을 쓸 때마다 리비전이 무한정 쌓이는 것을 막아야 합니다. 이는 워드프레스의 핵심 설정 파일인 wp-config.php에 한 줄을 추가하여 영구적으로 통제할 수 있습니다.

적용 방법:

FTP 또는 파일 관리자를 통해 워드프레스 설치 경로의 wp-config.php 파일을 열고, /* That's all, stop editing! Happy publishing. */ 주석 바로 위에 다음 코드를 추가합니다.

define('WP_POST_REVISIONS', 3); // 리비전 개수를 3개로 제한합니다.

이 코드를 적용한 후부터 포스트 리비전은 최대 3개만 저장됩니다.

4. 심화 진단: phpMyAdmin에서 'Transient' 테이블 직접 제거.

응급 처치 플러그인으로도 해결되지 않는 경우가 있는데, 바로 수명이 만료된 대량의 '트랜지언트' 데이터입니다. 이는 서버의 phpMyAdmin에 직접 접속하여 SQL 쿼리를 실행해야 합니다.

Step-by-step 쿼리 실행:

호스팅 계정에서 phpMyAdmin에 접속합니다.
해당 워드프레스 DB를 선택하고, 상단의 'SQL' 탭을 클릭합니다.
다음 쿼리문을 입력하고 실행합니다. (테이블 접두사 wp_가 다를 경우 수정해야 합니다.)

DELETE FROM wp_options WHERE option_name LIKE ('%_transient_%');

이 쿼리는 수명이 만료되었거나 임시로 저장된 트랜지언트 데이터를 삭제하여 wp_options 테이블 크기를 대폭 줄여줍니다.

5. 정리 기준: 최적화 후 '이상적인' DB 용량 기준.

포스팅 개수와 사용 플러그인에 따라 DB 용량은 달라지지만, 콘텐츠 중심의 일반적인 워드프레스 블로그라면 최적화 후 '이상적인' 용량 기준은 다음과 같습니다.

포스팅 200개 이하 블로그: 30MB 미만
포스팅 500개 이상 대형 블로그: 50MB ~ 70MB

제 경험상, DB 용량이 100MB를 넘어서기 시작하면 로딩 속도에 눈에 띄는 악영향을 미치기 시작했습니다. 이 기준을 넘어섰다면 즉시 정리 작업을 시작해야 합니다.

6. 경험 공유: 2주간 적용 후 얻은 최종 절감 효과.

저는 약 150개의 포스팅을 운영하는 블로그에 이 5가지 단계를 2주간 순차적으로 적용했습니다. 결과는 놀라웠습니다. 최초 150MB였던 DB 용량은 최종적으로 28MB까지 감소했습니다. 용량 절감뿐만 아니라, 가장 크게 체감된 효과는 블로그의 TTFB(Time To First Byte)가 평균 1.2초에서 500~700ms대로 개선된 점입니다. DB 최적화는 단순히 용량을 줄이는 것을 넘어, 블로그 속도와 사용자 경험을 근본적으로 개선하는 가장 중요한 작업임을 확신하게 되었습니다.

IT정보통신