글을 자주 고치면 리비전이 쌓인다. 이때 데이터베이스를 가볍게 만들겠다는 이유로 리비전을 먼저 삭제하는 것은 좋은 출발점이 아니다. 리비전은 이전 글 상태를 확인하거나 실수로 지운 문장을 되돌릴 때 쓰이는 기록이기 때문이다. 정리의 첫 단계는 삭제가 아니라, 무엇을 되돌릴 수 있어야 하는지 확인하는 일이다.[1]
1. 리비전과 자동저장을 같은 것으로 보지 않는다
리비전은 글을 저장하거나 업데이트하면서 만들어지는 이전 버전이고, 자동저장은 편집 중 예기치 않은 종료에 대비하는 임시 복구 정보다. 둘 다 편집 화면의 되돌리기에 도움을 줄 수 있지만, 보관 방식과 활용 시점은 다르다. 글 하나에 리비전이 많다는 사실만으로 사이트 문제가 생겼다고 단정할 수는 없다.
| 확인 대상 | 먼저 볼 질문 | 정리 전 필요한 조치 |
|---|---|---|
| 공개 글 리비전 | 최근 수정 뒤 잘못 바뀐 문장이 없는가 | 현재 공개본과 직전 리비전 비교 |
| 예약 글 | 발행 전 수정 기록이 필요한가 | 예약 시각·본문·카테고리 확인 |
| 임시글 | 다시 사용할 초안인가 | 발행·삭제·보관 중 상태 결정 |
| 데이터베이스 | 실제 용량 문제가 확인됐는가 | 백업 파일과 복원 절차 확보 |
2. 이 사이트에서는 예약 글부터 확인한다
로니트윈스는 예약 발행을 사용한다. 리비전 정리 전에는 예약 글의 날짜·시간·본문·카테고리를 먼저 연다. 예약 글을 공개 글처럼 일괄 정리하면 나중에 어떤 버전으로 예약했는지 확인하기 어려워질 수 있다. 특히 플러그인·테마 업데이트 전후에는 편집기 동작이 달라질 수 있으므로, 정리와 업데이트를 같은 날 한꺼번에 하지 않는 편이 안전하다.
운영 기록 예시:
정리 전 데이터베이스 백업 완료 / 예약 4건 시간 확인 / 최근 공개 글 3건 리비전 비교 / 삭제 대상은 재사용하지 않는 임시글로 한정.
3. 백업은 복구 경로까지 확인한다
리비전·초안·첨부 파일이 포함된 백업인지, 문제가 생기면 어느 환경에서 복원할지 확인해야 한다. 단순히 플러그인에서 ‘완료’ 알림만 보는 방식은 충분하지 않다. 데이터베이스와 파일이 같은 시점의 백업인지 확인하고, 가능하다면 운영 사이트가 아닌 테스트 환경에서 열어 본다. 이 원칙은 워드프레스 백업은 복구 테스트까지 해야 하는 이유에서 다룬 것과 같다.
4. 삭제가 아니라 보관 기준을 먼저 만든다
정리 도구를 쓰기 전 다음 기준을 문서로 남긴다. 기준이 있어야 다음 달에도 같은 판단을 할 수 있다.
| 상태 | 권장 판단 | 이유 |
|---|---|---|
| 최근 공개 글의 리비전 | 당장 일괄 삭제하지 않음 | 오류 수정·원문 확인에 필요할 수 있음 |
| 다시 쓰지 않는 임시글 | 제목과 마지막 수정일 확인 후 정리 | 관리 목록 혼잡 감소 |
| 예약 글 | 발행 전까지 보존 | 본문·일정 검증 필요 |
| 매우 오래된 수정 기록 | 백업 검증 뒤 범위를 정해 정리 | 데이터베이스 관리 목적 |
리비전 개수 제한이나 데이터베이스 최적화는 사이트 환경에 따라 판단해야 한다. 호스팅 자원 부족, 백업 시간 증가, 관리자 지연 같은 실제 신호가 없다면 성급한 삭제보다 발행·수정 흐름을 기록하는 편이 먼저다.
마무리
리비전 정리는 ‘쌓인 것을 비우는 작업’이 아니라, 복구 가능성을 잃지 않고 운영 기록을 관리하는 일이다. 정리 전에는 사이트 건강 상태와 백업 상태를 확인하고, 변경 뒤에는 공개 글·이미지·관리자 편집 화면을 새로 점검하자.
참고 자료
리비전 삭제는 저장 공간 정리가 아니라 복구 선택지 축소다
리비전은 글을 수정한 기록이므로, 지우기 전에 “어느 시점으로 돌아갈 수 있어야 하는가”를 먼저 정해야 한다. 오탈자 수정처럼 작은 변경만 반복한 글과, 제목·주소·표·링크를 함께 바꾼 글은 위험도가 다르다. 후자는 편집 전의 상태를 별도 백업에 남기고, 수정한 날짜와 변경 이유를 간단히 기록해 두는 편이 복구에 유리하다.
백업 플러그인의 성공 알림만 믿지 말고 실제 복구 파일이 어디에 있는지, 데이터베이스와 업로드 파일이 함께 포함됐는지 확인한다. 글 본문은 데이터베이스에 있지만 첨부 이미지와 테마 설정은 별도 파일에 있을 수 있어, 복구 범위를 잘못 판단하면 글은 돌아와도 화면이 달라질 수 있다.
정리 전 복구 지점 확인표
| 확인 항목 | 왜 필요한가 | 확인 방법 |
|---|---|---|
| 최근 전체 백업 | 리비전 정리 실패 시 사이트 단위 복구 | 백업 날짜·용량·저장 위치 확인 |
| 데이터베이스 백업 | 글·댓글·설정 변경 이력 보호 | 복원 대상 DB가 분리돼 있는지 확인 |
| 대표 글의 이전 버전 | 의미가 바뀐 수정 되돌리기 | 편집기 리비전 비교 화면 캡처 또는 내보내기 |
| 복구 책임자와 절차 | 문제 발생 시 지연 방지 | 관리자 계정과 복구 순서를 문서화 |
정리 작업은 작은 단위로 끝낸다
데이터베이스 정리 도구를 사용한다면 먼저 삭제 대상 수를 확인하고, 가장 오래된 리비전만 소량 처리한 뒤 글 편집·미디어·검색 기능을 점검한다. 한 번에 모든 글의 리비전을 삭제하면 문제가 생겼을 때 원인 범위를 좁히기 어렵다. 특히 예약 글은 발행일과 본문이 바뀌지 않았는지 별도로 확인한다.
정리 후에는 관리자 화면에서 글 하나를 열어 이전 버전 비교가 필요한지, 공개 화면에서 표와 링크가 정상인지 살핀다. 문제를 발견하면 추가 정리를 멈추고 마지막 정상 백업의 복구 가능 여부부터 확인한다. 저장 공간을 조금 줄이는 것보다 독자가 읽는 정보와 복구 경로를 지키는 것이 우선이다.
월간 운영 메모
- 리비전 정리 전에는 전체 백업과 DB 백업 날짜를 기록한다.
- 중요한 수정이 있었던 글은 최소 하나의 이전 버전을 남긴다.
- 정리 후에는 예약 글, 대표 글, 문의 페이지를 각각 한 번씩 공개 화면에서 확인한다.
복구 테스트에서 확인할 실제 결과
백업을 한 번 복원해 본다는 것은 운영 중인 사이트를 무조건 덮어쓰라는 뜻이 아니다. 가능하면 스테이징이나 별도 테스트 환경에서 대표 글 하나, 이미지 하나, 메뉴 하나가 정상적으로 돌아오는지 확인한다. 테스트 환경이 없다면 백업 파일을 열어 데이터베이스와 업로드 파일이 모두 존재하는지, 복구 도구가 필요한 정보가 함께 저장됐는지부터 확인한다. 복구 가능 여부를 모르는 백업은 실제 문제가 생겼을 때 선택지가 되기 어렵다.