프로젝트를 진행하면서 데이터 삭제 로직을 구현할 때 고민이 많았다. "사용자가 삭제 버튼을 누르면 DB에서 완전히 지워버릴까?" 처음엔 당연히 그래야 한다고 생각했는데, 조금만 생각해보니 문제가 보이기 시작했다.

문제 상황

우리 프로젝트는 데이터 분석 플랫폼이다. 사용자들이 데이터를 업로드하고, 데이터에 대한 분석 프로젝트를 작성하고, 피드백을 이어 남길 수 있다. 그런데 만약 사용자가 실수로 삭제 버튼을 눌렀다면? 또는 악의적인 사용자가 남의 데이터를 삭제한다면? 법적 문제로 특정 데이터에 대한 이력 추적이 필요하다면?

데이터를 완전히 삭제해버리면(Hard Delete) 복구가 불가능하다. 백업에서 복구할 수도 있겠지만, 그동안 다른 사용자들이 작성한 데이터와의 정합성 문제가 생긴다.

Soft Delete란?

Soft Delete는 데이터를 물리적으로 삭제하지 않고, "삭제됨" 표시만 해두는 방식이다.

// Hard Delete (물리적 삭제)
DELETE FROM users WHERE user_id = 123;

// Soft Delete (논리적 삭제)
UPDATE users SET is_deleted = true WHERE user_id = 123;

DB에는 그대로 남아있지만, 일반적인 조회 쿼리에서는 보이지 않게 처리한다.

삭제된 게시글, 왜 보존해야 할까?

"그냥 지우면 되는데 뭐가 문제야?"라고 생각할 수 있다. 하지만 실제 서비스를 운영하다 보면 삭제된 데이터를 보존해야 하는 상황이 생각보다 많다.

1. 법적 증거 보존

어떤 사용자가 악의적인 게시글을 올리고 바로 삭제해버렸다고 생각해보자.

1. 사용자 A가 명예훼손성 게시글 작성
2. 피해자 B가 신고 전에 A가 게시글 삭제
3. 증거가 사라짐 → 법적 대응 불가능

Hard Delete를 쓰면 이런 상황에서 속수무책이다. 하지만 Soft Delete로 구현하면, 겉으로는 삭제됐지만 DB에는 남아있어서 필요할 때 증거로 제출할 수 있다.

부적절한 데이터셋 설명을 올리고 삭제한 케이스가 있을 것 같기에, Soft Delete 덕분에 운영 과정에서 해당 내용을 확인하고 경고 조치를 취할 수 있다.

2. 악의적인 삭제 공격 방어

계정이 해킹당했거나, 퇴사하는 직원이 앙심을 품고 데이터를 대량 삭제하는 경우를 생각해보자.

// 악의적인 사용자가 자신의 모든 게시글 삭제
for (Post post : userPosts) {
    post.delete();  // Soft Delete
}

Hard Delete였다면 모든 데이터가 영구 삭제되지만, Soft Delete는 복구가 가능하다. 관리자가 이상 징후를 발견하면 바로 복구할 수 있다.

// 관리자가 한 번에 복구
deletedPosts.forEach(Post::restore);

3. 서비스 운영과 보안

스팸/어뷰징 패턴 분석

삭제된 게시글을 분석하면 스팸 패턴을 파악할 수 있다.

• "이 사용자는 항상 광고 게시글을 올리고 30분 뒤 삭제하네?"
• "특정 키워드가 포함된 게시글이 자주 삭제되네?"

이런 인사이트는 Hard Delete로는 얻을 수 없다. Soft Delete로 보존하면 스팸을 사전에 차단할 수도 있다.

어뷰징 사용자 추적

-- 최근 1주일간 50개 이상 게시글을 작성하고 삭제한 사용자
SELECT user_id, COUNT(*) as deleted_count
FROM posts
WHERE is_deleted = true
  AND deleted_at > NOW() - INTERVAL '7 days'
GROUP BY user_id
HAVING COUNT(*) > 50;

이런 쿼리로 어뷰징 사용자를 쉽게 찾을 수 있다.

4. 삭제 이유 분석

"왜 사용자들이 게시글을 삭제할까?"를 분석하면 서비스 개선 포인트를 찾을 수 있다.

• 대부분 업로드 직후 5분 이내에 삭제됨 → UI/UX가 불편해서 다시 올리는 거구나
• 특정 카테고리의 데이터가 유독 많이 삭제됨 → 카테고리 분류가 헷갈리는구나

이런 걸 발견하고 업로드 플로우를 개선할 수 있다.

5. 산업별 규제 준수

이전에도 여러 플랫폼을 이용해보면 약관에서 데이터 보존과 관련된 내용을 봤었던 것 같다. 산업에 따라서는 법적으로 데이터 보존 의무가 있다.

• 금융: 금융거래 기록 5년 보존 의무
• 의료: 진료 기록 10년 보존 의무
• 전자상거래: 소비자 보호법에 따른 거래 기록 보존

이런 서비스는 Soft Delete가 선택이 아니라 필수이다.

6. 연관 데이터 정합성

게시글을 Hard Delete하면 연관된 데이터 처리가 골치아프다.

게시글 (Hard Delete)
  ↓
댓글 50개는 어떻게 하지?
좋아요 100개는?
알림 기록은?
통계 데이터는?

CASCADE DELETE로 다 지울 수도 있지만, 그럼 사용자가 쓴 댓글까지 전부 사라진다. "내가 분명히 댓글 달았는데 왜 없어요?" 같은 문의가 들어온다.

Soft Delete는 참조 관계를 유지하면서도 조회에서만 제외되니 훨씬 깔끔하다.

// 게시글이 삭제되어도 댓글은 그대로
@Entity
public class Comment {
    @ManyToOne
    @JoinColumn(name = "post_id")
    private Post post;  // 삭제된 게시글도 참조 가능
}

실수로 지운 건 정말 많다

솔직히 말하면, 제일 많은 케이스는 "사용자 실수"다.

• "휴대폰 화면 작아서 잘못 눌렀어요"
• "삭제 확인 팝업이 안 떴어요" (실제론 떴음...)
• "이거 중요한 건데 왜 지웠을까요?" (본인이 지움)

이런 문의가 들어올 가능성도 있다. 복구 기능이 없으면 고객센터 부담이 엄청나다.

우리 프로젝트 적용 사례

1. Entity 설계

모든 주요 엔티티에 isDeleted 필드를 추가했다.

@Entity
@Table(name = "data")
@SQLRestriction("is_deleted = false")
public class DataEntity extends BaseTimeEntity {
    // ... 다른 필드들

    @Column(name = "is_deleted", nullable = false)
    @Builder.Default
    private Boolean isDeleted = false;

    public void delete() {
        this.isDeleted = true;
    }

    public void restore() {
        this.isDeleted = false;
    }
}

여기서 포인트는 @SQLRestriction("is_deleted = false") 이다.

2. @SQLRestriction 마법

Hibernate의 @SQLRestriction (구버전에서는 @Where)을 사용하면, 이 엔티티를 조회할 때 자동으로 WHERE 조건이 붙는다.
-> 이전 Where은 deprecated

// 개발자가 이렇게 작성하면
dataRepository.findById(1L);

// 실제로는 이런 쿼리가 실행됨
SELECT * FROM data WHERE data_id = 1 AND is_deleted = false;

덕분에 비즈니스 로직 코드마다 일일이 isDeleted = false 조건을 추가할 필요가 없다. 삭제된 데이터는 알아서 조회되지 않는다.

3. 삭제 로직 구현

@Repository
@RequiredArgsConstructor
public class SoftDeleteDataDbAdapter implements SoftDeleteDataPort {
    private final DataJpaRepository dataJpaRepository;

    @Override
    public void deleteData(Long dataId) {
        DataEntity data = dataJpaRepository.findById(dataId)
            .orElseThrow(() -> new DataException(DataErrorStatus.NOT_FOUND_DATA));

        data.delete();  // isDeleted = true
        dataJpaRepository.save(data);
    }
}

실제로 데이터를 지우는 게 아니라, delete() 메서드로 플래그만 변경한다.

4. 복구 기능도 보너스

public void restore() {
    this.isDeleted = false;
}

Soft Delete의 큰 장점 중 하나다. 사용자가 "앗 실수로 지웠어요!"라고 하면, 바로 복구해줄 수 있다.

5. Elasticsearch와의 동기화

우리 프로젝트는 검색을 위해 Elasticsearch도 사용한다. DB에서 Soft Delete 했으면, ES에서도 동일하게 처리해야 한다.

@Component
@RequiredArgsConstructor
public class SoftDeleteDataEsAdapter implements SoftDeleteDataPort {
    private final ElasticsearchClient client;

    @Override
    public void deleteData(Long dataId) {
        DataDeletedUpdate update = DataDeletedUpdate.deleted();
        client.update(u ->
            u.index("data_index")
             .id(dataId.toString())
             .doc(update),
            DataSearchDocument.class
        );
    }
}

ES 문서도 삭제하는 게 아니라, isDeleted 필드를 업데이트한다.

---

실제로 적용해보니

장점

1. 데이터 복구 가능
실수로 지운 데이터를 복구할 수 있다. 사용자 만족도가 올라간다.

2. 감사(Audit) 추적
"이 데이터가 언제 누가 지웠는지" 이력을 남길 수 있다. 법적 문제나 분쟁 시 유용하다.

3. 통계 분석
삭제된 데이터도 포함해서 분석할 수 있다. "얼마나 많은 유저가 프로젝트를 지웠는지", "어떤 데이터가 자주 삭제되는지" 같은 인사이트를 얻을 수 있다.

4. 참조 무결성 유지
다른 테이블에서 FK로 참조하고 있어도 문제없다. Hard Delete하면 CASCADE 설정을 어떻게 할지 고민해야 하는데, Soft Delete는 그런 걱정이 없다.

5. 안전한 데이터 관리
프로덕션 환경에서 데이터가 날아갈 걱정을 덜 수 있다.

단점 (솔직히 말하면)

1. 스토리지 비용
삭제된 데이터도 계속 쌓인다. 시간이 지나면 DB 용량이 커진다. 주기적으로 오래된 데이터를 정말로 삭제하는 배치 작업이 필요할 수 있다. -> 아직은 구현 안함.

2. 쿼리 성능 저하
테이블에 데이터가 많아질수록 WHERE is_deleted = false 조건이 오버헤드가 될 수 있다. is_deleted 컬럼에 인덱스를 걸어야 할수도??

CREATE INDEX idx_is_deleted ON data(is_deleted);

3. UNIQUE 제약 조건 이슈
예를 들어 email에 UNIQUE 제약이 있다면, 삭제된 사용자의 이메일을 재사용할 수 없다.

해결 방법:

• Partial Index 사용: CREATE UNIQUE INDEX idx_email ON users(email) WHERE is_deleted = false;
• 또는 삭제 시 이메일을 변조: deleted_20231019_user@example.com

-> 현재는 soft delete 삭제 처리만 했는데 둘 중 어떤 방식이 더 나은 방식일지는 고민이 좀 더 필요 할 것 같다.

4. 코드 복잡도 증가
삭제된 데이터를 정말로 조회해야 하는 경우(관리자 페이지 등), 별도의 쿼리 메서드가 필요하다.

// 삭제된 것 포함 전체 조회
@Query("SELECT d FROM DataEntity d")
List<DataEntity> findAllIncludingDeleted();

---

결론

Soft Delete는 대부분의 프로덕션 환경에서 유용하다. 특히:

• 사용자가 실수할 수 있는 서비스
• 데이터 이력 추적이 중요한 서비스
• 법적 책임이 따르는 서비스

이런 경우라면 무조건 Soft Delete를 권장한다.

다만 스토리지와 성능 이슈는 고려해야 한다. 인덱스 설계를 잘하고, 필요하다면 오래된 삭제 데이터를 아카이빙하는 배치 작업을 구현하자.

Soft Delete 덕분에 사용자가 실수로 지운 데이터를 복구하고, 악의적인 삭제 시도도 추적할 수 있었다.

---

참고한 것들:

• Hibernate @SQLRestriction 문서
• 실제 프로덕션 환경에서 겪은 경험들