되돌릴 수 없는 삭제, 백엔드 안전장치는 어디까지?

삭제 버튼 하나로 돌이킬 수 없는 일이 벌어지는 순간이 있어요. 맥 정리 앱으로 파일을 비우다 필요한 폴더까지 날려본 적, 혹시 없나요? 화면 앞이라면 그나마 다행이에요. 서버 쪽 DELETE는 사용자가 눈치채기도 전에 조용히 사라지거든요.

그래서 백엔드에서 삭제를 설계할 때는 버튼이 아니라 흐름을 먼저 그려요. 어디까지 안전장치를 넣을지, 직접 만들어 보며 정리해 봤어요.

진짜 지우기 전에, 표시만 먼저

가장 손쉬운 1차 방어는 소프트 삭제예요. 행을 실제로 지우지 않고 deleted_at 컬럼 하나만 채워두는 방식이죠. 조회 쿼리에서 WHERE deleted_at IS NULL로 걸러주면, 사용자에겐 사라진 것처럼 보여도 데이터는 남아 있어요.

직접 소프트 삭제 흐름을 만들어 보니, 복구가 그냥 컬럼을 다시 비우는 UPDATE 한 줄로 끝나더라고요. 되돌릴 수 없던 일이 되돌릴 수 있는 일로 바뀌는 거예요.

삭제 요청소프트 삭제(deleted_at 기록)유예 기간하드 삭제

소프트 삭제만으론 부족해요. 언젠가는 진짜로 지워야 저장 공간도, 개인정보 보관 부담도 줄거든요. 그래서 저는 3단계로 나눠요. 표시만 하는 소프트 삭제, 며칠간의 유예 기간, 그다음 배치가 도는 하드 삭제요.

예를 들어 유예를 30일로 두면, 그 사이 사용자가 "실수였어요" 하고 복구 API를 부를 수 있어요. 테스트로 삭제와 복구를 여러 번 돌려 보니, 이 창 하나가 문의를 확 줄여주는 느낌이었어요.

주의할 점도 있어요. 결제·정산 기록처럼 법으로 몇 년씩 보관해야 하는 데이터는 사용자가 지워달라 해도 함부로 못 지워요. 이건 별도 테이블로 분리해서 일반 조회 경로에서만 안 보이게 막는 편이 안전해요.

삭제는 권한 확인이 특히 중요해요. 서버에서 본인 소유인지를 반드시 검증하고, 남의 리소스 ID를 넣어도 막히게 해야 해요. 여기에 삭제 로그를 한 줄 남겨두면, 나중에 이거 누가 지웠는지 추적할 수 있어요.

멱등성도 챙겨야 해요. 같은 삭제 요청이 두 번 들어와도 결과가 같도록 만들면, 네트워크가 불안한 순간에도 안전하거든요.

안전장치는 많을수록 좋은 게 아니에요. 되돌려도 되는 임시 데이터에 30일 유예와 감사 로그까지 다 붙이면, 그건 과해요. 위험이 큰 데이터일수록 장치를 두껍게, 가벼운 데이터는 얇게 잡는 감각이 핵심이에요.

라이프케어로그에서 플랜비(plan-b)의 동호회 회비 기록 같은 걸 다룰 때도 같은 원칙을 적용해 봤어요. 돈과 얽힌 데이터는 소프트 삭제와 로그를 함께, 단순한 설정값은 바로 지우는 식으로요.

삭제 기능을 만들 때 딱 하나만 기억하면 좋겠어요. 되돌릴 수 없는 건 코드가 아니라 사용자의 데이터라는 거요.