데이터베이스에서 데이터를 삭제하는 방법은 크게 두가지로 나뉩니다.

• Hard Delete: 우리가 잘 아는 Delete 문을 사용하여 실제 row를 삭제하는 방법

• Soft Delete: 삭제 표시(`deleted_at` 필드에 현재 시간으로 넣어주는 방법 등)를 해줌으로써 삭제된 필드다 < 라는 의미를 부여하는 방법

데이터간 관계있는 경우, join을 계속해서 해야하는 경우 soft delete을 이용하는 경우가 종종 있는데요.

블로그 글은 이벤트 티케팅 서비스에서 soft delete로 인하여 장애를 겪었던 이야기입니다.

좌석이 결제/예약이 되면 deleted_at으로 예약됨을 표시하고 있는 서비스에서 예약된 좌석을 뽑아내어 다시 재저장하는 DB 마이그레이션 작업이 필요하게 되었는데, 작성자가 사용한 ORM 라이브러리에서는 해당 soft delete를 제대로 filter 하지 못하여, 예약된 좌석도 마치 다 예약 가능한것 처럼 살아나게 되며 같은 자리가 무한으로 다시 예약이 되기 시작했다고 합니다. 다중 예약으로 인해 많은 고객들에게 불편을 끼치게 되면서 Soft delete에 대해서 다시 고민하기 시작했다는 경험 이야기인데요.

물론 위 이야기는 Soft Delete만의 이슈만은 아니지만., 너무 당연하게 쓰고 있었다면, 내가 쓰고 있는 방법에는 혹시 취약점이 없을까?! 한번 더 고민해보는 습관은 중요할 것 같습니다.

# Soft Delete의 문제점

• 복잡성 증가 : delete에 대한 표시가 로직을 이해해야 하고, 잘 이해하지 못하면 민감 데이터 노출이나 부정확한 데이터를 만들어 낼 수 있다.

• 인덱스, unique 등 제약조건 생성시 계속 "delete" 표시에 대한 것을 고려해야 되며 유지 관리를 복잡하게 할 수 있다.

# Soft delete의 대안

• 삭제 데이터 따로 보관 : 과거 데이터에 대한 유지를 해야하는 경우 별도 삭제 데이터 스토리지에 저장하고, 본래 테이블에서는 Hard Delete

• Audit log(감사로그)를 이용하여 데이터 변경 기록 저장하기

https://blog.bemi.io/soft-deleting-chaos/