소프트 딜리트란?

소프트 딜리트(Soft Delete)란?

소프트 딜리트는 데이터베이스에서 레코드를 물리적으로 삭제하지 않고, 삭제된 것처럼 처리하는 방법입니다. 데이터를 실제로는 삭제하지 않고, 상태를 비활성화하여 다른 사용자들이 보지 못하게 하지만, 데이터는 여전히 데이터베이스에 남아 있습니다. 보통 삭제 플래그나 상태 값을 변경하는 방식으로 구현합니다.

 

소프트 딜리트 구현 방법

제가 구현한 소프트 딜리트는 데이터베이스 테이블에 Status 필드를 추가하여 처리했습니다. 상태 값으로 데이터의 활성, 비활성, 비공개 여부를 관리할 수 있습니다.

 

소프트 딜리트 코드

소프트 딜리트는 상태 값 INACTIVE를 사용해 게시글이 삭제된 것처럼 보이도록 설정할 수 있습니다.

public enum ArticleStatus {
    ACTIVE,     // 게시글이 활성화된 상태
    INACTIVE,   // 게시글이 비활성화된 상태 (삭제된 상태처럼 보이지만 데이터는 존재)
    PRIVATE     // 게시글이 비공개 상태 (작성자만 볼 수 있음)
}

글을 조회할 때는 INACTIVE나 PRIVATE 상태인 글을 제외해 주면 됩니다.

Optional<ArticleEntity> findByIdAndStatusIn(final Long articleId, final List<ArticleStatus> status);

또한, 자신의 글인 경우에는 PRIVATE 상태의 글도 조회할 수 있도록 조건을 추가했습니다. 제가 사용한 방법은 응답(Response)에 isEditable 필드를 함께 보내는 것으로, 작성자가 쓴 글이라면 이 값이 true로 설정되어 PRIVATE 상태의 글도 조회할 수 있습니다.

 

소프트 딜리트의 장점

1. 데이터 복구 가능: 실수로 데이터를 삭제하더라도 손쉽게 복구할 수 있습니다.
2. 데이터 히스토리 관리: 소프트 딜리트를 통해 삭제된 데이터의 히스토리를 추적하거나, 이를 바탕으로 통계를 낼 수 있습니다.
3. 비법적인 데이터 분석 가능: 삭제된 데이터를 유지함으로써, 법적인 범위를 넘어가지 않는 선에서 분석에 활용할 수 있습니다.

 

소프트 딜리트의 단점

1. 데이터베이스 용량 증가: 삭제된 데이터를 포함한 모든 레코드가 그대로 저장되기 때문에, 시간이 지남에 따라 데이터베이스의 용량이 증가할 수밖에 없습니다.
2. 코드 복잡성 증가: 매번 쿼리문에 Status 조건을 추가해야 하므로, 코드가 길어지고 복잡해지는 단점이 있습니다. 특히 모든 조회 시 상태 값 필터링을 고려해야 하기 때문에, 쿼리 작성 시 더 많은 신경을 써야 합니다.

+) 하드 딜리트와의 선택 문제: 만약 언제든지 삭제되어도 상관없는 데이터를 다룬다면, 소프트 딜리트보다는 하드 딜리트(데이터의 완전 삭제)가 더 나은 선택일 수 있습니다. 예를 들어 로그 데이터나 임시 데이터처럼 나중에 복구가 필요하지 않은 데이터는 소프트 딜리트보다 하드 딜리트를 사용하는 것이 더 효율적일 수 있습니다.

 

해결했던 방법

이 문제를 해결하기 위해, 일정 주기마다 비활성화된 데이터(INACTIVE 상태)를 실제로 삭제하는 시나리오를 사용했습니다. 매달 말까지 삭제된 데이터를 보관한 후, 다음 달 1일에 비활성화된 데이터를 삭제하는 방식으로 데이터베이스의 용량을 관리할 수 있습니다. 이렇게 하면 불필요한 데이터가 누적되는 것을 방지할 수 있습니다.

 

개인적인 의견

소프트 딜리트는 여러 상황에서 매우 유용한 기능입니다. 하지만 사용하는 데이터의 특성에 맞게 하드 딜리트와 소프트 딜리트를 적절히 혼합해서 사용하는 것이 중요하다고 생각합니다. 예를 들어, 개인정보와 같은 민감한 데이터는 실제로 삭제가 필요할 때가 많은데, 이런 데이터는 소프트 딜리트로 남겨두기보다는 하드 딜리트로 완전히 삭제해야 법적 규제를 피할 수 있지 않을까 생각이 듭니다.

 

또 하나 생각해 볼 수 있는 건, 아카이빙입니다. 주기적으로 데이터를 백업해 두고, 오래된 데이터를 아카이빙(저장 공간을 줄이면서 장기적으로 보관하는 방법)하는 방식으로 데이터베이스 용량을 효율적으로 관리할 수도 있을 거 같습니다. 데이터를 영구히 삭제하기는 어렵지만, 실제로 자주 조회되지 않는 데이터라면 따로 아카이빙해서 보관할 수 있다는 점에서 유용할 것이라고 생각합니다.

 

마지막으로, 소프트 딜리트 상태를 더 세분화할 수도 있을 거 같습니다. 예를 들어, RESTORE_PENDING 같은 중간 상태를 두면, 비활성화된 데이터를 복구하기 전에 확인 작업을 할 수 있게 될 수 있습니다. 사용자 실수로 삭제된 데이터를 복원할 때 이런 추가 상태를 두면 더 안전한 소프트 딜리트 시스템을 만들 수 있을 거라고 생각합니다!