Soft Delete(논리 삭제)와 Hard Delete(물리 삭제)

 

1. Soft Delete 논리 삭제

Soft Delete는 데이터베이스에서 데이터를 삭제하지 않지만 사용자 입장에서는 데이터에 접근 할 수 없게 하는 방식이다.

테이블에 deleted 컬럼을 만들어 boolean 값으로 데이터 사용 여부를 결정한다고 생각하면 된다. deleted가 false면 조회가 가능하도록 하고 deleted가 true면 조회가 불가능하도록 한다. 데이터가 삭제된 것처럼 해당 데이터에 사용자가 접근할 수는 없지만 데이터베이스에서 여전히 데이터가 존재한다.

 

장단점

Soft Delete의 장점은 다음과 같다.

• 데이터 복구 쉬움 : 실수로 삭제해도 UPDATE를 사용하여 복구할 수 있다.
• 참조 무결성 유지 : 다른 테이블에서 참조 중인 데이터를 유지하면서 삭제가 가능하다.
• 삭제 로그 관리 용이 : 언제, 누가 삭제했는지 삭제 이력을 관리할 수 있다.

 

하지만 실제로 데이터를 삭제하지 않기 때문에 여러 한계도 가지고 있다.

• 실제로 데이터를 삭제하지 않으므로 데이터베이스가 커질 수 있다.
• 성능 저하 가능성 : 특히 대량의 데이터가 논리적으로 삭제된 경우, 해당 데이터를 매번 건너뛰어야 하므로 성능에 영향을 줄 수 있다.
• deleted = false 조건을 넣지 않으면 삭제된 데이터도 조회될 수 있다.

 

Hibernate를 사용할 때 엔터티 클래스에 특정 조건을 적용하여 데이터를 필터링하면, deleted = false  조건을 별도로 추가하지 않고 삭제된 데이터를 조회하지 않을 수 있다.

@Where(clause = "deleted = false")
@Entity
@Table(name = "comment")
public class Comment {
    // ...
}

 

@Where 애노테이션은 Hibernate에서 제공하는 기능으로, 특정 조건을 가진 데이터만 조회하도록 한다. 이 애노테이션을 사용하면 clause 조건을 가지는 데이터만 조회하도록 제한한다.

@Where(clause = "deleted = false") 에서 clause = "deleted = false" 는 SQL의 WHERE절에 해당하며, deleted = true인 데이터는 조회할 때 자동으로 제외된다. 이를 통해 쿼리마다 deleted = false 조건을 자동으로 추가해주어 실수로 삭제된 데이터를 조회하는 일을 방지할 수 있다.

 

하지만 @Where를 사용할 때 주의할 점이 몇가지 있다.

첫째, @Where은 SELECT 쿼리에만 적용된다. DELETE나 UPDATE에는 영향을 주지 않는다.

둘째, @Where은 엔티티 전부를 조회하는 경우에만 명시한 조건이 쿼리에 반영된다. 특정 필드만 조회하는 경우에는 반영되지 않는다는 것이다. 예를 들어,   select * from comment; 처럼 엔티티 전부를 조회하면 @Where 애노테이션에 명시한 조건이 적용되지만,  select comment_id, content from comment; 과 같이 특정 필드만 조회하는 경우에는 해당 조건을 추가하지 않는다.

이 2가지를 조심하면서 @Where 애노테이션을 사용하자.

 

 

2. Hard Delete 물리 삭제

Hard Delete는 데이터베이스에서 데이터를 직접 삭제하는 방식이다. DELETE문을 날린다고 생각하면 된다. 더 이상 사용하지 않는 데이터를 DB에 저장하는 것은 저장 공간 낭비일 수 있다. Hard Delete를 사용하면 이 공간 낭비를 줄일 수 있다.

 

장단점

Hard Delete 또한 장단점을 가지고 있다. 먼저, Hard Delete의 장점은 다음과 같다.

• 공간 절약 : 데이터가 데이터베이스에서 완전히 제거되어 저장 공간을 절약할 수 있다.
• deleted = false  조건을 추가할 필요 없이 데이터 조회가 가능하다.

 

하지만 아래와 같은 단점도 가지고 있다.

• 복구 불가능: 삭제된 데이터를 되돌릴 수 없으므로 실수로 삭제된 데이터를 복구할 수 없다.
• 참조 무결성 문제: 다른 테이블에서 참조 중이면 삭제가 어렵거나, 삭제할 때 추가적인 처리(Foreign Key CASCADE 설정 등)가 필요하다.

 

 

3. Soft Delete와 Hard Delete 비교

 

Audit Table

먼저 비교에 앞서 Audit Table에 대해 알아보자. Soft Delete과 Hard Delete 모두 Audit Table을 통해 히스토리를 기록할 수 있다. Audit Table은 관리 권한이 있는 경우에만 접근 할 수 있는 테이블로, 특정 테이블에서 수행되는 작업을 추적하는 기능을 한다. 일반적으로 생성일자, 수정일자, 삭제일자 같은 시간정보와 생성자, 수정자 등 사용자 정보를 저장한다. Audit Table의 레코드는 업데이트하거나 삭제할 수 없으며, 삽입만 가능하다. 레코드를 업데이트 및 삭제하려면 추가 승인과 같은 프로세스가 필요하다. 

 

Audit Table의 예시는 다음과 같다.

CREATE TABLE comment_audit (
    audit_id BIGINT PRIMARY KEY AUTO_INCREMENT,  -- 감사 로그의 고유 식별자
    table_name VARCHAR(255) NOT NULL,      --  변경이 발생한 테이블명
    record_id INT NOT NULL,                -- 변경된 레코드의 고유 식별자
    action_type VARCHAR(10),               -- 변경 유형 (INSERT, UPDATE, DELETE)
    old_values TEXT,                       -- 변경 전 레코드 값 (JSON 또는 XML 형식)
    new_values TEXT,                       -- 변경 후 레코드 값 (JSON 또흔 XML 형식)
    created_by VARCHAR(255),               -- 변경을 수행한 사용자
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- 변경된 시간
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  -- 변경이력 수정 시각
);

 

위 예시의 주요 컬럼은 다음과 같다. 

 

• audit_id: 감사 로그의 고유 식별자 (Primary Key, AUTO_INCREMENT)
• table_name: 변경이 발생한 테이블명
• record_id: 변경된 레코드의 고유 식별자
• action_type: 변경 유형 (INSERT, UPDATE, DELETE)
• old_values: 변경 전 레코드 값
• new_values: 변경 후 레코드 값
• created_by: 변경을 수행한 사용자
• created_at: 변경된 시간 (타임스탬프)
• updated_at: 감사 로그 수정 시각

이와 같은 Audit Table을 통해 데이터 변경 이력을 안전하게 관리할 수 있다.

 

 

 

Soft Delete VS Hard Delete

Soft Delete와 Hard Delete를 비교해보자. 아래 표의 내용에서 ✅는 장점인 있는 경우  🟥는 단점인 경우이다.

	Soft Delete	Hard Delete
설정 용이성	✅ 단순히 열을 UPDATE하는방식으로 구현이 더 쉬움	🟥 삭제할 데이터를 Audit table로 복사하는 작업이 포함되어 설정이 어려움
디버깅	✅ deleted과 Audit table를 통해 디버깅 가능	✅ Audit table를 통해 디버깅 가능
데이터 복원	✅ deleted=true 로 삭제된 데이터를 복원하기 쉬움	🟥 데이터 복원이 어려움
active data 쿼리	🟥 where 조건에 deleted=false 조건을 추가하는 것을 잊었을 때 문제가 발생할 가능성 있음 (@where를 사용하여 해결 가능)	✅ 삭제된 데이터를 조회할 가능성 없음
뷰 단순성	🟥 active data와 삭제된 데이터가 한 테이블에 존재	✅ 삭제된 데이터는 audit table에만 있고 active data는 나머지 테이블에 존재 (분리)
작업 성능	✅ UPDATE는 DELETE보다 빠름(microsecond)	🟥DELETE는 UPDATE보다 느림
애플리케이션 속도	🟥 모든 SELECT 쿼리에 deleted=false 가 추가되어 더 느림	✅ 조건이 더 적으므로 쿼리 속도가 더 빠름
애플리케이션 크기	🟥 삭제된 데이터와 active 데이터가 한 테이블에 존재하여 테이블 크기가 커짐	✅ active data만 테이블에 존재하여 공간 절약
DB UNIQUE Index	🟥 UNIQUE index 사용 어려움 ex) unique index : (컬럼a, 컬럼b, deleted)	✅ 데이터가 아예 삭제되므로 새로운 데이터를 삽입할 때 UNIQUE index가 충돌하지 않음
DB CASCADING	🟥 ON DELETE CASCADE 사용 불가	✅ ON DELETE CASCADE 사용

 

1. 설정 용이성 : Soft Delete는 단순히 deleted열을 UPDATE하므로 설정 용이성이 좋지만, Hard Delete의 경우, 삭제할 데이터를 Audit Table로 복사하여 히스토리를 기록하는 작업이 포함되어 설정이 어렵다.
2. 디버깅 : Soft Delete와 Hard Delete 모두 Audit Table을 가지고 로그를 추적할 수 있기 때문에 디버깅 하기 좋다. Soft Delete는 추가적으로 deleted로 디버깅이 가능하다.
3. 데이터 복원 : Soft Delete는 실제로 데이터를 삭제하지 않기 때문에 deleted=true 로 삭제된 데이터를 복원하기 쉽다.
4. active data 쿼리 : Soft Delete에서는 where 조건에 deleted=false 조건을 추가하는 것을 빼먹으면 문제가 발생할 수 있다. 하지만 Hard Delete에서는 아예 삭제하므로 삭제된 데이터는 조회하지 않고 active data만 조회한다.
5. 뷰 단순성 : Soft Delete는 실제 데이터가 삭제되지 않기 때문에 삭제된 데이터와 active data가 한 테이블에 존재한다. 반면, Hard Delete에서는 삭제된 데이터는 audit table에만 있고 active data는 나머지 테이블에 존재하여 분리된다.
6. 작업 성능 : UPDATE가 DELETE보다 microsecond 단위로 좀 더 빠르다.
7. 애플리케이션 속도 및 크기 : Soft Delete에서는 모든 SELECT 쿼리에 deleted=false 라는 조건이 더 추가되므로 쿼리 속도가 느려진다. 삭제된 데이터도 테이블에 존재하므로 테이블 크기가 커진다.
8. DB UNIQUE Index : Soft Delete에서는 Unique Idex 사용이 어렵고, Hard Delete에서는 새로운 데이터를 삽입할 때 Unique Index가 충돌하지 않는다.
9. DB CASCADING : Soft Delete는 ON DELETE CASCADE 사용이 불가능하고 Hard Delete는 ON DELETE CASCADE을 사용할 수 있다.

 

DB Unique Index에 대해 좀 더 자세히 설명하면 다음과 같다.

Unique Index는 중복 데이터를 막기 위해 특정 컬럼 조합에 대해 유일한 값만 저장하도록 강제하는 기능이다.

Unique Index가 (컬럼 A, 컬럼 B, deleted)일 때의 예시를 보면 왜 Soft Delete에서는 Unique Idex 사용이 알 수 있다.

1. 테이블에 (a1, b1, false)값이 각 컬럼에 들어가 있다고 생각하자. 이때 soft delete를 하면 이 값이 (a1, b1, true)가 된다.
2. 테이블에 (a1, b1)가 추가되고, (a1, b1, false)가 저장된다.
3. 이 때 (a1, b1, false)를 soft delete하려고 하면 기존 (a1, b1, true) 값과 Unique Index가 충돌하게 된다.

반면에, Hard Delete는 데이터가 아예 삭제되므로 새로운 데이터를 삽입할 때 UNIQUE index가 충돌하지 않게 된다.

 

 

 

4. Soft Delete과 Hard Delete의 사용

그렇다면 Soft Delete와 Hard Delete는 언제 사용하는 것이 좋을까?

 

먼저, Soft Delete의 경우, 데 데이터 복구가 필요하거나, 참조 무결성을 유지해야 할 때, 데이터 분석과 통계를 목적으로 데이터를 유지해야 할 때 적합하다. 또한 사용자에게 복구 기능을 제공하거나 삭제된 데이터를 추후 확인할 필요가 있을 때 유용하다.

 

반면, Hard Delete의 경우, 데이터가 아예 삭제되기 때문에 데이터베이스의 저장 공간을 효율적으로 활용하고 싶을 때 사용할 수 있다. 성능 최적화가 필요하거나, 데이터가 특정 상황에서만 필요하고 남겨도 되지 않는다면 물리 삭제를 수행하는 것이 좋을 것 같다. 또한 법적 요구사항이나 개인정보 보호 등을 위해 특정 데이터를 완전히 삭제해야 하는 경우에 사용된다.

 

프로젝트에서 Soft Delete와 Hard Delete 중 어떤  것을 활용하면 좋을지는 요구사항에 맞게 각 삭제 방식의 특성과 장단점을 고려하여 선택하면 될 것 같다.

 

 

---

참고자료

https://velog.io/@heypop/2023.10.22-Soft-Delete-Hard-Delete

https://dgjinsu.tistory.com/77

https://abstraction.blog/2015/06/28/soft-vs-hard-delete#recommendation

https://velog.io/@yhlee9753/soft-delete-와-hard-delete-비교