Soft Delete를 우리 서비스에 적용해야 할까?

 

서비스를 개발하다 보면 "데이터를 삭제할 때 정말 지워버려야 할지" 고민하게 됩니다.
이번 글에서는 Soft Delete 개념과 함께, 실제 프로젝트에 적용하면서 고민했던 내용들을 공유하려고 합니다.

Soft Delete

Soft Delete는 데이터베이스에서 데이터를 실제로 삭제하지 않고, 삭제된 것처럼 표시하는 방식입니다. deleted_at(datetime) 또는 is_deleted(boolean) 필드를 추가해서 관리합니다.

장점

• 실수로 삭제된 데이터를 쉽게 복구할 수 있음
• 삭제된 데이터의 이력 추적 가능
• 관계형 DB에서 참조 무결성 유지
• 데이터 분석이나 감사에 필요한 정보 보존
• 악의적인 탈퇴 및 재가입 방지

단점

• 쿼리의 복잡도가 높아질 수 있음
• 실제 삭제가 필요한 경우 추가 작업 필요
• 개인정보보호 규정 준수에 추가 고려 필요

 

어떤 상황에서 필요할까?

1. 데이터 복구가 필요한 경우

사용자가 실수로 삭제한 데이터를 되살려야 할 때

2. 참조 무결성이 중요한 경우

다른 테이블에서 해당 데이터를 외래키로 참조하고 있을 때

 

ex. 게시물/댓글에서 탈퇴한 유저명을 "(탈퇴한 사용자)"로 표시하는 경우

     주문 내역에서 삭제된 상품 정보를 조회해야 하는 경우

3. 데이터 분석이 필요한 경우

삭제된 데이터를 포함한 통계 분석이 필요하거나

사용자 행동 패턴 분석에 삭제된 데이터가 필요한 경우

 

질문

Q. deleted_at과 is_deleted 필드를 둘 다 추가해야 하나요?

아니요! 하나만 사용해도 됩니다. deleted_at의 null 여부만 확인하면 삭제 상태를 알 수 있습니다.

Q. 탈퇴한 사용자의 행동 패턴 분석은 개인정보 침해 아닌가요?

개인을 식별할 수 없도록 익명화하거나 집계하면 됩니다.

약관에 해당 내용을 포함하여 사용자 동의를 구하는 방법도 있습니다.

Q. Soft Delete 자체가 개인정보보호 규정에 위배되지 않나요?

영구적으로 보존만 하지 않으면 괜찮습니다.

사용자에게 정확히 며칠 동안 보관하고 파기한다는 사실을 고지해야 합니다. (예: 탈퇴 후 익일로부터 90일 동안 보관 후 완전 삭제)

 

우리 프로젝트에는 어떻게 적용할까?

1. 먼저 고려해야 할 질문

1. 추후에 사용자 탈퇴 행동을 로그 분석할 것인가?
   → 여유가 된다면 할 예정이지만 우선순위는 낮음
2. 탈퇴한 사용자가 등록한 음식 데이터를 다른 사용자도 검색할 수 있게 할 것인가?
   → 직접 등록한 음식 데이터는 탈퇴 시 서비스 자산으로 귀속되며, 유저가 삭제되어도 음식 데이터는 유지해야 함
   만약 유저 삭제 시 음식 데이터도 사라진다면, 동일한 음식을 담아뒀던 다른 유저들의 식단에서도 데이터가 사라지는 문제 발생함
3. 모든 엔티티에 적용할 것인가, 일부만 적용할 것인가?
   → 필요성이 명확한 데이터에만 적용하기로 결정

2. 데이터 연관성 고려하기

처음에는 "유저가 Soft Delete라면 식단, 채팅 로그 등 귀속 데이터도 모두 Soft Delete해야 하는 거 아닐까?"라고 생각했습니다. 하지만 자세히 들여다보니 유저 정보가 진짜로 삭제되기 전까지는 모든 관련 데이터가 자동으로 남아있습니다.

30일 동안은 deleted_at만 표시되고 실제 삭제는 일어나지 않기 때문에, 연관된 식단이나 로그를 따로 Soft Delete 처리할 필요가 없었습니다.

 

결론

1️⃣ Member 엔티티에만 Soft Delete 적용

• 탈퇴한 유저의 로그를 분석하여 기능 확장 가능 (추후 필요시)
• 탈퇴한 유저가 등록한 음식 데이터를 유지 (다른 사용자들이 계속 사용 가능)
• 실수로 탈퇴해도 복구 가능성을 열어둠 (실제 구현은 나중에)

2️⃣ 나머지 엔티티는 선택적으로 적용

• 삭제 복구 기능이 없는 데이터: 적용 X
• 데이터 분석에 사용하지 않는 데이터: 적용 X
• 필요성이 명확히 있는 경우에만 팀 논의 후 적용

3️⃣ 구현 방식

Base Entity에는 created_at, updated_at만 작성하고, Soft Delete가 필요한 엔티티에만 deleted_at을 추가하는 방식으로 진행합니다.

 

배운 점

Soft Delete는 "데이터를 보존하는 게 좋으니까 모든 테이블에 적용하자!"가 아니라 실제로 필요한 곳에만 선택적으로 적용하는 것이 중요하다고 생각합니다.

 

다음과 같은 기준으로 판단하면 좋을 것 같습니다.

• 데이터 복구 기능이 실제로 필요한가?
• 참조 무결성 유지가 중요한가?
• 삭제된 데이터를 분석에 활용할 계획이 있는가?
• MVP 단계에서 구현할 만큼 우선순위가 높은가?

이런 질문들에 명확한 답이 있을 때 적용하면, 불필요한 복잡도 없이 효과적으로 Soft Delete를 활용할 수 있습니다.