[백엔드] 회원탈퇴(Soft delete) 및 회원복구

Soft delete란?

데이터를 완전히 삭제하지 않고 논리적으로 삭제되었음을 나타내는 필드를 두어 데이터를 비활성화하는 방식이다.

다음과 같은 상황에서 사용된다.

• 회원 삭제를 호출했지만 회원 정보를 가지고 있어야 하는 경우
• 회원 탈퇴 복구 기능이 필요한 경우
• “회원 탈퇴 후, 30일 뒤 영구삭제” 이런 상황에서 사용된다.

 

 

이전에 진행했던 프로젝트에서는 isDeleted(삭제여부)와 deletedAt(삭제시간) 필드를 두었다.

 

로직

Controller

 

회원 삭제 API가 호출되면 Spring Security가 요청에 포함되어 있는 JWT 토큰을 통해 유저를 인증하고 인증된 유저의 정보(Developer 객체)를 @AuthUser를 통해 파라미터로 주입한다. 메서드 내에서는 주입된 developer 객체의 id를 가져와 Service의 withdraw 함수를 호출한다.

 

Service

 

Service에서는 회원 id를 사용해 Developer 엔티티를 불러온 후 삭제 상태로 수정한다.

또한 삭제된 회원은 더 이상 토큰이 필요 없으므로 회원의 토큰도 삭제한다(완전삭제).

 

Domain

 

도메인에서는 실제로 삭제 상태 필드 값을 true로 바꾸고 삭제 시간을 업데이트 한다.

 

Domain

 

엔티티 soft delete 이후에는 @SQLRestriction("is_deleted = false") 어노테이션을 사용했다.

 

@SQLRestriction("is_deleted = false")는 Hibernate에서 엔티티 조회 시 WHERE 절에 is_deleted = false 조건을 자동으로 추가하여 soft delete된 데이터를 제외하는 어노테이션이다. 즉, is_deleted가 true로 설정된 데이터는 조회되지 않도록 제한한다.

 

soft delete 구현 이전에 developer를 조회하는 코드들이 존재했고 만약 위 어노테이션을 사용하지 않았다면 모든 developer 조회 코드에 is_deleted = false 조건을 추가해주어야 하고, 이후에 개발되는 코드들도 해당 조건을 추가해야 한다.

 

회원 복구

soft delete에서 is_deleted 값을 true로 바꿨던 것을 다시 false로 바꿔주면 된다.

우리 팀은 소셜 로그인 API를 호출 할 때 유저가 삭제 상태라면 다시 복구될 수 있도록 로직을 구현했다.

 

 

기존에 작성했던 코드이다. 두 코드 모두 회원 복구가 정상적으로 되지 않았다.

 

SQL 로그를 확인하고 문제를 찾을 수 있었다. 앞서 말했던 @SQLRestriction 때문에 is_deleted = false 조건이 항상 추가되어 삭제된 회원 조회 자체가 되지 않았던 것이다. 올바른 쿼리를 보내기 위해 @SQLRestriction 보다 더 강력한 코드를 사용해야 했다.

 

nativeQuery를 통해 문제를 해결할 수 있었다. @SQLRestriction과 상관 없이 순수하게 해당 메서드에서 작성한 네이티브 쿼리를 보내기 때문에 삭제된 회원을 올바르게 조회할 수 있었다.

 

느낀점

Spring Data Jpa를 배우며 네이티브 쿼리는 언제쓰지라는 생각을 했었는데 이런 방식으로 사용할 수 있다는 것을 알게되었다.

 

추가할 만한 로직도 생각해 보았다. soft delete된 회원은 언제 삭제할 것인가? 30일 이후 탈퇴 정보 삭제.

개발자가 일일이 지워줄 수는 없으니 자동화를 해야한다. cron 서비스를 사용하여 매일 특정 시간에 soft delete된 시간을 검사하고 30일이 지난 계정을 삭제하는 방법이 있을 것 같다.