워드프레스 리비전 정리｜자동 저장 구분과 안전한 삭제

워드프레스 글을 자주 수정하면 이전 내용이 리비전으로 남습니다. 리비전은 실수로 지운 문장이나 이전 레이아웃을 되돌리는 안전장치이므로 숫자가 많다는 이유만으로 전부 삭제할 대상은 아닙니다. 먼저 어떤 글에서 얼마나 늘었는지 확인하고, 백업과 복원 테스트를 마친 뒤 오래된 수정본만 정리해야 합니다.

이 글에서는 리비전과 자동 저장, 임시글, 휴지통을 구분하고 데이터베이스 정리가 실제로 필요한지 판단하는 20분 점검 순서를 설명합니다. 현재 글이 느린 원인이 리비전이라고 단정하지 않고 관리자 화면, 쿼리와 서버 자원을 함께 비교하는 방식입니다.

리비전·자동 저장·휴지통 차이

워드프레스 공식 문서에 따르면 리비전은 wp_posts 테이블에 원본 글의 자식 항목으로 저장됩니다. 제목, 작성자, 본문과 요약의 변경 이력을 남기며 일반 리비전은 post_type이 revision입니다. 실제 테이블 접두사는 설치 환경마다 다를 수 있습니다.

자동 저장이 1분마다 새 행을 끝없이 만든다는 설명은 정확하지 않습니다. 기본적으로 글 하나에 사용자별 자동 저장은 최대 한 개이며 새 자동 저장이 이전 것을 덮어씁니다. 여러 사용자가 같은 글을 편집하면 사용자별 자동 저장이 존재할 수 있지만, 매분 무한히 늘어나는 구조는 아닙니다.

정리가 필요한지 판단하는 20분 점검

1. 데이터베이스 크기보다 개수부터 확인

호스팅 관리 화면이나 신뢰할 수 있는 데이터베이스 관리 도구에서 리비전 개수와 글별 분포를 확인합니다. 글 수는 적은데 리비전이 유난히 많다면 페이지 빌더 작업, 반복 저장 또는 콘텐츠 이전 과정에서 늘었는지 살펴보세요. 테이블 크기가 크다는 사실만으로 리비전이 성능 원인이라고 결론 내리면 안 됩니다.

2. 느린 증상과 같은 시간대를 비교

리비전 정리 전 관리자 글 목록, 편집기 열기와 저장 시간을 각각 기록합니다. 공개 페이지 TTFB도 함께 측정하세요. 리비전을 지운 뒤 데이터베이스 용량만 줄고 응답 시간은 같다면 병목은 다른 곳에 있을 가능성이 큽니다. 워드프레스 내부 요청은 Query Monitor로 느린 플러그인과 쿼리 찾기, 서버 단위 지연은 MySQL 슬로우 쿼리 로그 점검으로 구분할 수 있습니다.

3. 복원할 수정본을 먼저 표시

최근 수정한 핵심 글, 랜딩 페이지, 상품·신청 페이지는 리비전 화면에서 실제 차이를 확인합니다. 필요한 버전의 날짜와 작성자를 기록하고 페이지 빌더 전용 이력이 별도로 관리되는지도 확인하세요. 데이터베이스 백업 파일은 내려받기만 하지 말고 복원 가능한 형식인지 점검합니다.

안전한 정리 순서

1. 사이트 파일과 데이터베이스를 함께 백업합니다.
2. 스테이징 사이트가 있다면 백업 복원을 먼저 시험합니다.
3. 중요 글의 최근 리비전은 남기고 오래된 항목부터 소량 정리합니다.
4. 글 편집, 미리보기, 저장, 예약 발행과 페이지 빌더를 확인합니다.
5. 휴지통과 임시글은 리비전과 별도로 검토합니다.
6. 정리 전후 행 수, 데이터베이스 크기와 응답 시간을 같은 조건에서 비교합니다.

초보자는 데이터베이스에서 DELETE 문을 직접 실행하지 않는 편이 안전합니다. 리비전 삭제에는 연결된 메타데이터를 함께 처리하는 워드프레스 함수가 있으므로, 유지 관리가 되는 플러그인이나 호스팅 도구를 사용하세요. WP-CLI나 코드로 대량 정리한다면 스테이징에서 대상을 출력해 확인한 후 운영 서버에 적용합니다.

리비전 보관 개수 제한하기

정리만 하면 이후 편집 과정에서 다시 늘어납니다. 사이트별 설정을 관리할 수 있다면 wp-config.php의 WP_POST_REVISIONS에 양의 정수를 지정해 글마다 보관할 리비전 수를 제한할 수 있습니다. 예를 들어 아래 설정은 최근 리비전 5개를 보관합니다.

define( 'WP_POST_REVISIONS', 5 );

true 또는 -1은 제한 없이 보관하고, false 또는 0은 일반 리비전을 저장하지 않습니다. 다만 사용자별 자동 저장은 별도로 남을 수 있습니다. 양의 정수를 설정해도 기존 리비전이 즉시 모두 정리되는 것은 아니며, 해당 글이 다시 업데이트될 때 초과한 과거 리비전이 삭제됩니다.

모든 사이트에 5개가 정답은 아닙니다. 여러 명이 편집하거나 페이지 빌더로 큰 변경을 하는 사이트는 더 많은 복원 지점이 필요합니다. 개인 블로그처럼 작성자가 한 명이고 백업이 안정적인 사이트는 비교적 적게 보관할 수 있습니다.

정리 전후 기록표

행을 삭제해도 테이블 파일 크기가 바로 줄지 않을 수 있습니다. 테이블 최적화는 백업 후 트래픽이 적은 시간에 수행하고, 자동 최적화를 지나치게 자주 예약하지 마세요. 공개 페이지가 느리다면 TTFB와 캐시·서버 원인을 구분하는 방법도 함께 확인합니다.

TIP

정리 작업의 성공 기준을 “몇 MB 줄었는가” 하나로 잡지 마세요. 필요한 복원 지점이 남아 있고 편집·저장 기능이 정상이며, 정리 전후 측정값이 개선됐을 때 의미가 있습니다. 속도 차이가 없다면 추가 삭제를 멈추고 느린 쿼리나 플러그인으로 진단 범위를 옮기는 편이 안전합니다.

자주 묻는 질문

리비전을 삭제하면 현재 글도 없어지나요?

삭제 대상을 리비전으로 정확히 제한하면 현재 공개 글은 남습니다. 하지만 이전 버전 비교와 복원은 할 수 없으므로 백업이 필요합니다.

리비전을 완전히 끄는 것이 좋은가요?

편집 실수나 레이아웃 오류를 되돌리기 어려워집니다. 완전 비활성화보다 사이트의 편집 방식에 맞는 수를 남기는 것이 일반적으로 안전합니다.

정리하면 사이트가 바로 빨라지나요?

리비전이 비정상적으로 많고 관련 쿼리가 병목일 때는 도움이 될 수 있습니다. 그러나 테이블 크기만 큰 경우에는 체감 차이가 없을 수 있으므로 전후 시간을 측정해야 합니다.

공식 참고 자료

• 워드프레스 리비전과 자동 저장 안내
• 리비전 보관 개수 함수
• 리비전 삭제 함수

리비전 정리는 데이터베이스를 무조건 작게 만드는 작업이 아니라 복구 가능성과 운영 안전성을 유지하며 불필요한 기록을 줄이는 과정입니다. 백업, 대상 확인, 소량 정리, 기능 테스트, 보관 개수 제한 순서를 지키세요.