🌟 회원 탈퇴 기능
최근 세차새차 서비스 프로젝트에 참여하면서, 첫 번째 이슈로 회원 탈퇴 기능을 맡게 되었습니다. 이 기능은 단순한 작업처럼 보였지만, 실제로는 개인정보 보호법과 관련된 여러 가지 고려 사항이 있었습니다. 온라인 예약 기능이 존재하는 경우, 단순히 탈퇴를 진행해서는 안 된다는 초기 설계 단계에서는 큰 어려움이 없었지만, 이후 좀 더 복잡한 요구 사항이 추가되며 초기 설계가 많이 뒤바뀌었습니다.
🚗 회원 탈퇴와 예약 데이터의 연관성
처음에는 회원 탈퇴 시 예약을 모두 취소하는 방식이 양쪽 모두에게 간편할 것이라 생각했습니다. 그러나 고참 백엔드 개발자분의 의견에 따라, 예약 데이터는 탈퇴 후에도 유지되어야 하며, 예약에 대한 알림 기능도 정상적으로 동작할 것이라는 결론이 나왔습니다. 이는 시스템 복잡성을 높이지만, 더 유연하고 사용자 친화적인 기능을 제공할 수 있는 방법이기도 했습니다.
🛠️ 새로운 설계: Member와 Customer 테이블
이번 설계를 통해 Member와 Customer를 잇는 Member Customer 테이블을 만들기로 했습니다.
- Member가 자신의 예약을 조회할 때, Member -> MemberCustomer -> Customer -> 예약의 경로를 따라 조회가 이루어집니다.
- Member가 탈퇴할 경우, MemberCustomer를 소프트 삭제(Soft Delete)합니다.
- Customer가 삭제될 때는 MemberCustomer는 남겨두어, 예약 데이터가 유지되도록 설계했습니다.
이 설계를 통해 회원이 탈퇴하더라도 예약 데이터는 유지되며, 예약 조회와 알림 기능은 정상적으로 작동하게 됩니다.
대략 위 플로우로 작업하기로 결정했는데, 아직 세차새차 내부에 어떤 식으로 설계되어있는지 정확하게 모르는 것 같아, 조금 많은 이해가 필요할 것 같네요😓
🤔 Soft Delete와 Hard Delete
이 과정에서 자연스럽게 소프트 삭제(Soft Delete)와 하드 삭제(Hard Delete)에 대해 다시 한번 생각하게 되었습니다. 보통 소프트 삭제를 개발하면서 주로 활용했긴 했는데 직접적으로 이 명칭에 대해서 알아본 적도 없었기에 사실 제가 활용하던게 소프트삭제라고 불리는지도 잘 몰랐습니다.
- 소프트 삭제(Soft Delete): 데이터를 실제로 삭제하지 않고, 데이터베이스에서 '삭제됨' 상태로 표시하는 방식입니다. 데이터는 여전히 데이터베이스에 남아 있지만, 비활성화된 상태로 간주됩니다. 이 방법을 사용하면 필요시 데이터를 쉽게 복구할 수 있는 장점이 있습니다.
- 하드 삭제(Hard Delete): 전통적인 방식으로, 데이터를 영구적으로 삭제하는 방법입니다. 백업을 하지 않는 한 복구가 불가능할 수 있습니다.
이번 프로젝트에서는 소프트 삭제를 활용하여 데이터를 물리적으로 삭제하지 않고, 사용자가 접근할 수 없도록 설계하기로 했습니다. 이는 향후 데이터의 가치를 보존하면서도, 개인정보 보호를 준수할 수 있는 방법입니다.
👀 Soft Delete의 작동 방식
소프트 삭제를 구현할 때, 일반적인 방법은 데이터베이스 테이블에 '삭제됨'을 나타내는 플래그를 추가하는 것입니다. 데이터가 삭제될 때 이 플래그가 참(True)으로 설정되며, 이후 애플리케이션은 이 플래그를 참조하여 삭제된 데이터를 쿼리 결과에서 제외합니다.
이 플래그는 불리언 값으로 설정될 수 있으며, 때로는 삭제된 시점을 기록하기 위해 날짜-시간 컬럼으로 구현되기도 합니다. 날짜-시간 컬럼을 사용할 경우, 특정 데이터가 언제 소프트 삭제되었는지 정확히 파악할 수 있습니다.
✔️ 소프트 삭제와 하드 삭제의 중요성
- 데이터 무결성: 소프트 삭제는 데이터를 보존하여 감사, 준법성, 그리고 과거 데이터 분석에 유용합니다.
- 실수로 인한 삭제 방지: 소프트 삭제는 실수로 인한 데이터 손실을 방지하는 데 효과적입니다. 반면, 하드 삭제는 데이터를 삭제하면 영구적으로 사라지게 됩니다.
- 사용자 경험: 소프트 삭제는 사용자가 삭제된 데이터를 복구할 수 있는 기회를 제공하여 사용자 경험을 향상시킵니다. 이는 의도치 않은 삭제로 인한 데이터 손실 위험을 줄여줍니다.
🌱 학습과 성장
이번 이슈를 통해 데이터 삭제 방식과 그에 따른 시스템 설계의 중요성을 깊이 이해할 수 있었습니다. 고참 개발자분들과의 논의를 통해 더 나은 설계를 도출할 수 있었고, 앞으로의 개발 과정에서도 이 경험이 큰 도움이 될 것이라 생각합니다. 프로젝트가 계속 진행되면서, 내부 설계와 시스템 구조를 더 잘 이해하기 위해 많은 노력이 필요할 것 같네요.😓
추가적으로 이번 이슈가 끝나면, Spring security에서 기본으로 제공하는 계정 만료, 계정 잠금, 비밀번호 만료 기능을 구현해볼 것 같습니다. 껄껄
참고 레퍼런스