소프트 삭제와 아카이브 전략 설계
많은 서비스가 처음에는 deleted_at 하나로 삭제 문제를 해결합니다. 시작은 빠르지만, 시간이 지나면 인덱스가 비대해지고 쿼리 누락이 생기고 복구/보존 규칙도 얽히기 시작합니다. 결국 삭제는 단순 CRUD가 아니라 데이터 수명 주기 설계라는 사실이 드러납니다.
soft delete는 복구 편의성의 대가가 있다
soft delete의 장점은 분명합니다.
- 복구가 쉽습니다
- 감사 추적이 남습니다
- 관계 데이터 정리가 단순해 보입니다
하지만 비용도 있습니다.
- 모든 조회에서 삭제 조건을 누락할 수 있습니다
- 유니크 인덱스 설계가 복잡해집니다
- 실제로는 죽은 데이터가 계속 운영 테이블에 남습니다
즉, soft delete는 무료 안전장치가 아니라 읽기 복잡성을 사는 방식입니다.
아카이브는 보관과 운영을 분리하는 전략이다
자주 조회하지 않는 삭제 데이터를 운영 테이블에 계속 붙잡아 두면, 운영 쿼리와 저장 공간이 함께 무거워집니다. 이때 아카이브 테이블이나 별도 저장소로 옮기는 전략이 필요합니다.
좋은 분리는 보통 다음 질문에서 시작합니다.
- 이 데이터는 복구가 자주 필요한가
- 운영 화면에서 계속 보여야 하는가
- 법적 보관 의무가 있는가
- 분석용으로 남겨야 하는가
복구 가능성, 보관 의무, 조회 빈도가 서로 다르면 삭제 정책도 하나로 통일할 수 없습니다.
삭제 정책은 세 단계로 나누면 운영이 편하다
실무에서는 보통 다음 3단계가 안정적입니다.
- soft delete
- archive 이동
- 최종 purge
예를 들어 사용자 실수 복구가 필요한 기간에는 soft delete 상태를 유지하고, 일정 시간이 지나면 archive로 옮긴 뒤, 규정 보관 기간이 끝나면 purge하는 방식입니다.
쿼리와 인덱스를 같이 다시 설계해야 한다
soft delete를 도입하면 조회 조건뿐 아니라 인덱스도 달라져야 합니다.
- 활성 데이터만 대상으로 하는 partial index
deleted_at is null조건을 고려한 실행 계획- archive 테이블의 조회 패턴 분리
정책만 바꾸고 인덱스를 그대로 두면 운영 성능은 계속 나빠집니다.
결론
삭제 전략은 “데이터를 지울지 말지”의 문제가 아니라, 어떤 데이터를 어떤 단계에서 어떤 비용으로 유지할지 결정하는 운영 설계입니다. soft delete와 archive를 분리해서 생각해야 장기 운영에서 쿼리, 저장소, 복구 정책이 함께 정리됩니다.
Continue Reading
다음으로 읽기 좋은 글
쿼리 플랜 회귀를 막는 데이터베이스 가드
인덱스 변경, 통계 갱신, 배포 이후 쿼리 실행 계획이 나빠지는 문제를 사전에 감지하는 방법을 정리합니다.
🗄️ DatabaseIdempotent Backfill 체크포인트 설계
백필은 한 번에 끝나지 않는 경우가 많습니다. 중단과 재시작을 견디는 체크포인트 설계가 데이터 작업의 안정성을 좌우합니다.
📈 최신 동향PostgreSQL 18 최신 동향: 실무에서 진짜 중요한 변화
PostgreSQL 18은 단순 업그레이드 뉴스가 아닙니다. AIO, skip scan, 업그레이드 후 성능 회복, OAuth, generated columns까지 운영팀과 개발팀 모두에게 영향이 큰 변화가 들어왔습니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
다음 탐색