DB 데이터 삭제에 대한 고민, Soft Delete(논리 삭제) vs Hard Delete(물리 삭제)

1. 개요

개발을 하다보면 어떤 데이터가 삭제되면 연관된 다양한 데이터들이 함께 삭제되야 하는 경우가 종종 발생한다. 

 

예를 들면 게시글이 삭제되면 해당 게시글에 달린 좋아요, 댓글, 답변 등등 연관된 데이터도 함께 삭제되야 한다. 

 

 

하지만, 함께 삭제되면 안 되는 경우도 있다.

 

예를 들어, 상품 거래 서비스에서 판매자의 정보를 삭제하면 판매자가 올린 상품에 대한 정보도 삭제될 것이다. 그러나, 구매자는 자신이 구매했던 상품의 정보나 영수증을 확인해야 할 필요가 있을 수 있다. 만약 판매자 정보와 함께 해당 상품 정보도 삭제된다면, 구매자는 자신의 구매 상품에 대한 정보를 확인할 수 없게 되어 불편을 겪을 수 있다. 따라서 이러한 경우에는 판매자 정보와 연관된 데이터라도, 특정 조건하에서 보존되거나 관리되어야 한다.

 

 

 

지금까지 프로젝트를 진행해오면서 데이터 삭제 어떻게 하지? 하는 고민만 해오다, 이번 기회에 정리하고 넘어가려 한다.

 

 

 

 

 

 

 

 

2. 데이터 삭제 방법

데이터를 삭제하는덴 크게 2가지 방법이 있다. Soft Delete(논리 삭제), Hard Delete(물리 삭제) 방식이 있는데 두 가지 방식의 차이는 아래와 같다.

 

 

- Soft Delete

데이터베이스에서 데이터를 삭제하지 않고, 사용자 입장에서는 데이터에 접근할 수 없게 하는 방식을 의미한다. 보통 테이블에 is_deleted컬럼을 만들어 boolean값으로 데이터를 사용여부를 결정하는 방식이다. is_delete = 0이면 조회 가능, is_deleted = 1이면 조회 불가능한 것처럼 말이다. 조건 컬럼이 들어가므로 is_deleted의 값을 체크하는 쿼리가 들어가야 한다.

 

soft 삭제 시 사용자는 데이터가 삭제된 것처럼 해당 데이터에 접근 불가능하지만, 애플리케이션 DB에는 데이터가 여전히 존재한다. 때문에 내부에서 데이터를 계속 사용해야할 가능성이 있다면 soft delete 방식을 선택하는 것이 적합할 수도 있다.

UPDATE User SET is_deleted = 1 where userId = ?

 

 

 

- Hard Delete

데이터베이스에서도 데이터를 직접 삭제하는 방식을 의미한다. 더이상 사용하지 않는 데이터를 DB에 저장하는 것은 저장공간을 낭비하는 것일 수 있다. 

 

흔히 우리가 Delete 쿼리를 날리는 것이다. 

DELETE FROM User WHERE userId = ?

 

 

 

 

실무에선 경우에 따라 다르겠지만 논리 삭제를 많이 한다고 한다. 

 

다양한 이유가 있겠지만

FK로 사용되는 데이터인 경우나, 복원이 가능해야 하는 도메인일 경우 논리 삭제를 택한다.

 

또한 Update 쿼리가 Delete 쿼리보다 ms 단위로 봤을 땐 더 빠르기도 하다. 

 

마지막으로 데이터는 자산이기 때문이다. 유저들이 서비스를 사용하면서 쌓고 있는 많은 데이터들은 법의 경계를 벗어나지 않는 선에서 데이터 분석을 통해 마켓팅 및 기획 개발, 디버깅 등 다양한 방면에서 사용된다. 

 

 

 

하지만, 단점 또한 명확하다. 

 

데이터가 생성되기만 하고 삭제되지 않는 구조이기 때문에 데이터베이스의 용량이 매우 커질 수 밖에 없다. 이 데이터들 중에는 정말로 필요 없는 데이터들도 있을 수 있다. 

 

또한, 논리 삭제는 애플리케이션 성능 측면에서 생각해봐도 SELECT 조회 시 불필요한 검색 조건을 추가해야 한다. 

SELECT 하는 모든 쿼리의 WHERE 절에 삭제 확인 여부가 들어간다면 꽤나 직관적이지 않을 것이다. 

 

 

 

 

 

 

 

 

 

3. Spring에서의 Soft Delete 방법들

- @SQLDelete

먼저 @SQLDelete를 사용하지 않고 Soft Delete를 하려면 아래처럼 하게 될 것이다. 

@Entity
public class Board {

    @Id
    @GeneratedValue
    private Long id;

    private String title;
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    private boolean isDeleted = false;
}

 

 

public void deleteBoard(Long boardId) {
    Optional<Board> findBoard = boardRepository.findById(boardId);
    findBoard.ifPresent(board -> {
        board.setDeleted(true);
    });
}

 

 

 

 

 

위 방식을 SQLDelete 어노테이션을 사용하면 아래 처럼 변경할 수 있다. 

@Entity
@SQLDelete(sql = "UPDATE board SET is_deleted = true WHERE id = ?")
public class Board {

    @Id
    @GeneratedValue
    private Long id;

    private String title;
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    private boolean isDeleted = false;
}

 

public void deleteBoard(Long boardId) {
    boardRepository.deleteById(boardId);
}

 

 

 

- @Where

위에서 Soft Delete 시 SELECT 하는 모든 쿼리의 WHERE 절에 삭제 확인 여부를 확인해야하는 매우 번거로운 단점이 있었다. 

 

@Where 어노테이션은 이런 비직관적인 문제와 번거로움을 해결해줄 수 있다.  

 

@Entity
@Where(clause = "is_deleted = false")
@SQLDelete(sql = "UPDATE board SET is_deleted = true WHERE id = ?")
public class Board {

    @Id
    @GeneratedValue
    private Long id;

    private String title;
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    private boolean isDeleted = false;
}

 

 

위와 같이 @Where 어노테이션을 사용하면 Board 엔티티를 조회할 때 항상 is_deleted = false 조건이 where절에 추가된다. 

 

이때 엔티티 조회라는 건 
"select b from Board b" 같이 엔티티 전부를 조회하는 경우를 말한다. 

 

즉, "select b.id, b.title from Board b" 같이 엔티티 전체가 아닌 특정 필드만 조회하는 경우엔 @Where 어노테이션에 명시했던 조건이 쿼리에 반영되지 않는다. 

 

* 주의
- 어노테이션에 사용되는 SQL문은 SQL문 기준으로 작성해야 한다. 예를 들어 isDeleted 가 아니라 id_deleted로 작성해야 함. 
- hibernate, JPA등 라이브러리가 설치되어 있어야 한다.
- @SQLDelete 의 ? 에는 해당 엔티티에 @Id 어노테이션을 사용한 프로퍼티의 값이 사용되므로, pk를 id라는 컬럼으로 사용할 때 위와 같이 사용해야 함. 아니라면 각자에 맞게 변경.

 

 

 

 

 

 

4. 프로젝트에 적용

위에 소개할 땐 is_deleted 같은 boolean 형식의 필드를 사용했지만 플젝엔 LocalDateTime 타입의 deleted_at 필드를 사용했다. 

 

 

단순 삭제인지를 나타내기 위해선 boolean을 사용하면 되지만, 추후에 디버깅을 위해 삭제 시간을 기록해두었다. 꼭 필요가 없다면 boolean이 DB 조회 시 더 빠르기 때문에 boolean을 사용하는게 더 좋을 수도 있다. 

 

 

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@SQLDelete(sql = "UPDATE job_post SET deleted_at = NOW() WHERE job_post_id = ?")
@Where(clause = "deleted_at IS NULL")
public class JobPost extends BaseEntity {

    @Id
    @GeneratedValue
    @Column(name = "job_post_id")
    private Long id;

    // 생략    

    private LocalDateTime deletedAt; // 논리 삭제

 

 

public void deleteJobPost(Long companyId, Long jobPostId) {
    Member company = memberRepository.findById(companyId)
        .orElseThrow(() -> new JikgongException(ErrorCode.MEMBER_NOT_FOUND));

    JobPost jobPost = jobPostRepository.findById(jobPostId)
        .orElseThrow(() -> new JikgongException(ErrorCode.JOB_POST_NOT_FOUND));

    List<WorkDate> workDateList = jobPost.getWorkDateList();

    // WorkDate.getDate() 값 중 가장 큰 날짜를 찾기
    LocalDate maxDate = findMaxDate(workDateList);

    // 오늘 날짜
    LocalDate today = LocalDate.now();

    // 7일 이상 지난 공고: 삭제
    // 아닌 공고: 확정된 지원자 없다면 삭제
    validationBeforeDelete(today, maxDate, workDateList);

    // 조건이 충족되면 논리 삭제 실행
    jobPostRepository.delete(jobPost);
}

 

 

이렇게 설정해두고 삭제 요청을 보내면 쿼리가 아래와 같이 뜬다.

 

2024-08-22 19:16:05.727 [http-nio-8080-exec-4]  INFO p6spy - [statement] | 40 ms | 
    delete       
    from
        pickup       
    where
        pickup_id=14
2024-08-22 19:16:05.776 [http-nio-8080-exec-4]  INFO p6spy - [statement] | 46 ms | 
    delete       
    from
        work_date       
    where
        work_date_id=22
2024-08-22 19:16:05.826 [http-nio-8080-exec-4]  INFO p6spy - [statement] | 48 ms | 
    delete       
    from
        work_date       
    where
        work_date_id=23
2024-08-22 19:16:05.884 [http-nio-8080-exec-4]  INFO p6spy - [statement] | 56 ms | 
    delete       
    from
        work_date       
    where
        work_date_id=24
2024-08-22 19:16:05.979 [http-nio-8080-exec-4]  INFO p6spy - [statement] | 93 ms | 
    UPDATE
        job_post       
    SET
        deleted_at = NOW()       
    WHERE
        job_post_id = 8

 

Update 쿼리는 잘 나가는데 연관관계 맺어진 workdate 와 pickup은 DELETE 쿼리가 나가는 걸 확인할 수 있었다. 

 

 

cascade, orphanRemoval 설정과 @SQLDeleted 를 함께 사용한다면 부모 엔티티는 논리 삭제되지만 자식 엔티티는 가차없이 DELETE 쿼리가 나갔다. 

 

 

예전에 임시로 모집공고 삭제 로직을 구현해뒀을 때 함께 삭제하기 위해 아래와 같이 설정해뒀는데,, 덕분에 하나 배워간다.. ㅋㅋㅋ

 

 

 

cascade, orphanRemoval 설정 제거 후엔 의도했던대로 쿼리가 잘 나간다.