워드프레스 데이터베이스 최적화: 안전한 정리 방법

워드프레스 데이터베이스 최적화는 데이터베이스를 무조건 작게 만드는 작업이 아닙니다. 사이트가 실제로 느린 원인을 확인하고, 복원 가능한 백업을 만든 뒤, 출처가 분명한 불필요 데이터만 단계적으로 정리하는 유지보수입니다. 이 글은 초보 운영자가 위험한 SQL 삭제 없이 진단부터 검증까지 진행할 수 있도록 순서를 정리합니다.

먼저 알아둘 핵심: 데이터베이스 크기와 속도는 같은 말이 아니다

데이터베이스가 크다고 반드시 사이트가 느린 것은 아닙니다. 이미지 파일은 보통 데이터베이스가 아니라 업로드 폴더에 저장되며, 페이지 속도는 호스팅 자원, 캐시, 테마와 플러그인 코드, 외부 스크립트의 영향을 함께 받습니다. 반대로 데이터베이스 크기가 작아도 모든 요청에서 불필요한 자동 로드 옵션이 읽히거나 특정 쿼리가 반복되면 관리자 화면이 느려질 수 있습니다.

따라서 최적화 전에는 ‘몇 MB인가’만 적지 말고 어떤 화면이 언제 느린지 기록해야 합니다. 공개 페이지, 관리자 글 목록, 글 저장, 검색, 로그인처럼 기능별로 나누면 데이터베이스 문제인지 다른 문제인지 판단하기 쉽습니다.

최적화가 필요한 신호와 먼저 볼 곳

증상	확인할 항목	바로 삭제하면 안 되는 이유
글 저장과 관리자 화면만 느림	리비전 수, 플러그인 쿼리, 자동 로드 옵션	공개 페이지 캐시와는 원인이 다를 수 있음
백업 파일이 갑자기 커짐	큰 테이블, 로그·세션·통계 데이터	플러그인이 현재 사용하는 데이터일 수 있음
삭제한 플러그인의 흔적이 보임	옵션·테이블 이름과 플러그인 문서	비슷한 이름을 다른 기능이 공유할 수 있음
데이터베이스 오류 메시지	호스팅 오류 로그, 사이트 상태, 테이블 상태	단순 청소가 아니라 복구가 필요한 상황일 수 있음

한 번의 느린 요청만으로 결론 내리지 말고 같은 동작을 여러 번 확인하세요. 캐시가 있는 사이트는 첫 요청과 이후 요청의 조건이 다르므로 측정 조건도 기록해야 합니다.

1단계: 파일과 데이터베이스를 함께 백업한다

데이터베이스에는 글, 설정, 사용자, 댓글 같은 정보가 있지만 테마, 플러그인, 업로드 이미지는 파일 영역에 있습니다. 완전한 복구를 위해 둘 다 백업해야 합니다. WordPress 공식 백업 안내와 데이터베이스 백업 안내를 기준으로 호스팅 환경에 맞는 방식을 선택하세요.

• 백업 생성 시각과 파일 크기를 확인합니다.
• 백업 파일을 운영 서버와 다른 위치에도 보관합니다.
• 가능하면 스테이징 사이트에서 복원 테스트를 합니다.
• 복원 방법과 관리자 접근 방법을 작업 기록에 남깁니다.

‘백업 완료’ 알림만으로는 충분하지 않습니다. 복원할 수 있어야 백업입니다. 관련 절차는 워드프레스 백업·복원 가이드와 함께 확인할 수 있습니다.

2단계: 변경 전 기준값을 기록한다

효과를 확인하려면 정리 전 상태가 필요합니다. 데이터베이스 전체 크기, 큰 테이블 상위 목록, 관리자 주요 화면의 체감 시간, 오류 로그 유무, 백업 소요 시간을 기록하세요. 전문 도구가 없다면 호스팅 패널의 데이터베이스 화면과 WordPress 사이트 건강 정보만으로도 시작할 수 있습니다.

기록 항목	변경 전	변경 후
데이터베이스 전체 크기	호스팅 패널에서 기록	같은 화면에서 비교
글 편집 화면 열기	같은 계정·브라우저에서 확인	캐시 조건을 맞춰 확인
백업 생성 시간	시작·완료 시각 기록	다음 백업과 비교
오류 로그	작업 직전 확인	작업 직후 다시 확인

목표도 구체적으로 정합니다. 예를 들어 ‘오래된 리비전을 줄여 백업 용량을 관리한다’는 목표는 검증할 수 있지만 ‘사이트를 무조건 빠르게 만든다’는 목표는 원인과 측정 기준이 불분명합니다.

3단계: 비교적 안전한 항목부터 정리한다

휴지통과 스팸 댓글처럼 관리자 화면에서 내용을 확인할 수 있는 항목부터 시작합니다. 필요한 항목이 섞여 있지 않은지 검토한 다음 한 종류씩 삭제하세요. 작업 직후 공개 페이지와 관리자 화면을 확인하면 문제가 생겼을 때 원인을 좁히기 쉽습니다.

• 스팸 댓글: 정상 댓글이 잘못 분류되지 않았는지 먼저 확인합니다.
• 휴지통 글·페이지: 복원할 콘텐츠와 첨부파일 관계를 확인합니다.
• 만료된 임시 데이터: 재생성 가능한 데이터인지 확인하고 캐시 플러그인 문서를 따릅니다.
• 오래된 세션·로그: 해당 데이터를 만든 플러그인의 보관 정책과 삭제 기능을 우선 사용합니다.

직접 SQL 문을 실행하는 방식은 빠르지만 대상 범위를 잘못 지정하면 복구가 어렵습니다. 초보 운영자는 WordPress 관리자 또는 해당 플러그인의 공식 정리 기능을 우선 사용하는 편이 안전합니다.

리비전은 ‘전부 삭제’보다 보관 기준을 정한다

리비전은 글을 이전 상태로 되돌릴 수 있게 해 주는 편집 이력입니다. 수정이 잦은 글은 리비전이 늘 수 있지만, 문제 해결과 실수 복구에 중요한 역할을 합니다. 최근 리비전을 충분히 남긴 뒤 오래된 이력만 줄이세요.

앞으로 저장할 리비전 수를 제한하려면 wp-config.php 설정을 사용할 수 있습니다. WordPress 공식 wp-config.php 문서는 WP_POST_REVISIONS와 휴지통 보관 기간을 설명합니다. 이 파일은 사이트의 핵심 설정 파일이므로 변경 전 원본을 별도로 보관하고 문법 오류가 없는지 확인해야 합니다. 호스팅 파일 접근과 복원 방법을 모르면 먼저 호스팅 지원팀에 문의하세요.

자동 로드 옵션은 이름만 보고 삭제하지 않는다

일부 옵션은 WordPress가 시작될 때 자동으로 읽힙니다. 자동 로드 데이터가 지나치게 크면 여러 요청에 부담을 줄 수 있지만, 옵션 행 수가 많다는 이유만으로 문제가 되는 것은 아닙니다. 어떤 플러그인이나 테마가 만들었는지, 현재 기능에서 사용하는지, 값의 크기가 어느 정도인지 함께 봐야 합니다.

WordPress 공식 성능 최적화 문서도 자동 로드 옵션이 wp_options 테이블에 저장된다고 설명합니다. 옵션 이름을 검색해 출처를 확인하고, 활성 플러그인의 설정 화면이나 제거 절차를 우선 사용하세요. 출처가 불명확하면 삭제 대신 백업과 기록만 남기고 보류하는 것이 낫습니다.

삭제한 플러그인의 고아 데이터 판단법

플러그인을 비활성화하거나 삭제해도 설정을 보존하기 위해 테이블과 옵션을 남기는 경우가 있습니다. 이것이 곧 오류나 불필요 데이터라는 뜻은 아닙니다. 재설치할 가능성이 있거나 다른 플러그인이 같은 테이블을 이용하면 삭제가 손실로 이어질 수 있습니다.

1. 테이블 접두사 뒤의 이름과 옵션 이름을 기록합니다.
2. 해당 플러그인의 공식 문서와 제거 안내를 확인합니다.
3. 현재 활성 플러그인과 테마에서 같은 이름을 사용하는지 확인합니다.
4. 스테이징에서 삭제 후 로그인, 글 편집, 검색, 폼, 예약 작업을 시험합니다.
5. 문제가 없을 때만 운영 사이트에서 동일한 변경을 수행합니다.

출처를 확인할 수 없는 데이터는 ‘고아 데이터 후보’일 뿐, 삭제 대상으로 확정된 것이 아닙니다.

테이블 최적화와 복구 기능을 구분한다

테이블 최적화는 저장 구조의 여유 공간을 정리하는 작업이고, 손상된 테이블을 복구하는 작업과는 목적이 다릅니다. 오류가 없는 사이트에서 복구 기능을 상시 켤 이유는 없습니다. WordPress 공식 wp-config.php 문서에는 WP_ALLOW_REPAIR를 이용한 복구 방식과 함께, 복구 페이지가 로그인 없이 접근될 수 있으므로 문제 해결 뒤 설정을 제거해야 한다는 보안 주의가 나와 있습니다.

데이터베이스 연결 오류나 테이블 손상이 의심되면 임의 삭제보다 호스팅 지원팀과 백업 상태를 먼저 확인하세요. 복구를 시도하기 전에도 가능한 범위에서 현재 데이터베이스 사본을 보관해야 합니다.

플러그인으로 정리할 때 확인할 기준

정리 플러그인을 하나 더 설치하면 편리하지만, 자동 삭제 설정이 오히려 위험을 키울 수 있습니다. 설치 수보다 기능의 출처와 동작 범위를 확인하세요.

• 최근 업데이트와 현재 WordPress 버전 호환 여부
• 삭제 전 미리보기 또는 대상 목록 제공 여부
• 리비전 보관 개수와 기간을 세밀하게 설정할 수 있는지
• 자동 작업의 주기와 로그를 확인할 수 있는지
• 삭제한 플러그인 옵션까지 무차별 제거하지 않는지
• 문제가 생겼을 때 되돌리는 방법을 문서로 제공하는지

최적화 플러그인을 여러 개 동시에 실행하지 마세요. 서로 같은 데이터를 처리하거나 예약 작업이 겹치면 결과를 추적하기 어려워집니다. 플러그인 충돌이 의심되면 플러그인 충돌 진단 순서를 따라 한 번에 한 요소씩 확인하세요.

작업 후 반드시 검증할 기능

데이터베이스 크기가 줄었다고 작업이 끝난 것은 아닙니다. 다음 기능을 관리자와 로그아웃 상태에서 확인하세요.

• 홈, 카테고리, 주요 글이 정상적으로 열리는지
• 관리자 로그인, 글 편집, 저장, 미리보기가 되는지
• 사이트 검색과 댓글 또는 문의 폼이 동작하는지
• 예약 글과 백업 같은 예약 작업이 실행되는지
• 모바일 화면과 캐시 삭제 후 화면이 정상인지
• 브라우저 콘솔, WordPress 디버그 로그, 호스팅 오류 로그에 새 오류가 없는지

변경 전 기록과 같은 조건에서 다시 측정하고, 효과가 불분명하면 추가 삭제를 멈추세요. 데이터베이스 정리만으로 프런트 화면 속도가 달라지지 않을 수도 있습니다. 이 경우 캐시, 이미지, 외부 스크립트, 호스팅 자원을 별도로 점검해야 합니다.

권장 유지보수 주기

작은 블로그는 매일 자동 삭제할 필요가 없습니다. 월 1회 정도 데이터 증가 추세와 백업 상태를 확인하고, 큰 플러그인 변경이나 대량 콘텐츠 수정 전후에 별도 점검하는 방식이 현실적입니다. 방문이 적은 시간에 작업하고, 한 번에 한 종류만 변경하며, 작업 날짜·대상·결과·복원 위치를 기록하세요.

WordPress 공식 사이트 유지관리 문서도 백업, 업데이트, 스팸 정리와 정기 점검을 함께 다룹니다. 데이터베이스만 떼어 놓기보다 사이트 전체 유지관리 일정 안에 포함하는 편이 좋습니다.

최종 체크리스트

• 느린 화면과 재현 조건을 기록했는가?
• 파일과 데이터베이스를 모두 백업했는가?
• 백업 생성 시각·크기와 복원 방법을 확인했는가?
• 한 번에 한 종류의 데이터만 정리했는가?
• 옵션과 테이블의 생성 주체를 확인했는가?
• 직접 SQL 삭제 대신 공식 관리 기능을 우선했는가?
• 작업 후 공개 화면, 관리자 기능, 예약 작업, 오류 로그를 확인했는가?
• 효과가 없을 때 추가 삭제를 멈추고 다른 원인을 점검했는가?

안전한 워드프레스 데이터베이스 최적화의 핵심은 많이 지우는 것이 아니라, 지워도 되는 이유를 확인하고 문제가 생기면 복원할 수 있게 준비하는 것입니다. 기준값과 작업 기록을 남기면 다음 유지보수 때 데이터 증가 원인을 더 빠르게 찾을 수 있습니다.