아웃소싱 프로젝트 - 소프트 딜리트(SoftDelete) 트러블 슈팅

소프트 딜리트는 "진짜 삭제" 대신 "숨기기"를 해서, 복구성과 감사성, 데이터 안정성을 높이기 위한 기술이다.

 

유저나 리뷰, 댓들-facing 데이터는 삭제해도 복구 가능성과 운영 안정성을 위해 소프트 딜리트를 적용했다

하지만, 장바구니는 Hard Delete를 선택했다.

 

 

장바구니는 본질적으로 임시 저장소에 가까운 데이터다. 사용자가 상품을 담고, 주문을 완료하거나 장바구니를 비우는 흐름이 반복되기 때문에, 삭제된 장바구니 데이터를 복구해야 할 필요성이 거의 없다.

 

오히려 삭제된 데이터를 계속 남겨두면 데이터량이 불필요하게 쌓이기에, 장바구니(Cart)와 같은 경우에는 소프트 딜리트 대신 Hard Delete(완전 삭제) 방식을 선택해 관리 효율성과 성능을 높였다.

 

 

✅  문제 상황

• Store, Review 등 주요 엔티티에 소프트 딜리트(SoftDelete) 기능을 도입했다.
• 삭제 시 실제 DB 레코드를 제거하지 않고,
  deleted = true 로 상태만 변경하는 방식을 사용했다.

🚨 문제 발생

• findAll(), findById() 같은 기본 JPA 조회 메서드를 호출했을 때, 삭제된 데이터(deleted = true)도 함께 내려오는 문제가 발생했다.

 

💡 원인 분석

 

엔티티에는 deleted 플래그만 추가된 상태였고, 조회 시 별도로 "WHERE deleted = false" 조건을 걸어주지 않았다.
JPA 기본 동작은 모든 레코드를 다 조회하기 때문에, 별도 필터링이 없으면 삭제된 데이터도 같이 노출되는 문제가 있었다.

 

🔥 해결 방법

• 엔티티 클래스에 @Where 어노테이션을 추가한다.

@Entity
@Where(clause = "deleted = false")
public class Store { ... }

 

 

✅ 이 @Where 어노테이션을 사용하면 findAll(), findById() 등 모든 기본 조회 쿼리에 자동으로 "WHERE deleted = false" 조건이 붙는다.

 

해결 결과 

 

@Where 조건이 적용된 엔티티는 기본 조회 시 소프트 삭제된 데이터가 결과에서 자동으로 제외되는 것을 볼 수 있다.

 

 

엔티티에 @Where(clause = "deleted = false")와@SQLDelete 어노테이션을 추가하여 자동으로 삭제된 데이터를 걸러내도록 개선했다.
수정 결과, API 조회 시 삭제된 데이터는 내려오지 않게 되었고, 프론트엔드 화면에서도 삭제된 가게나 리뷰가 노출되지 않도록 하였다.