용어 차이만 외웠는지, 아니면 인덱스·유니크 제약·복구·법적 보존까지 묶어서 판단하는지를 가른다. "무조건 논리 삭제" 같은 단정을 하는지도 같이 본다.
물리 삭제는 DELETE로 레코드 자체를 지워 저장 공간과 조회 대상을 같이 줄인다. 논리 삭제는 deleted_at 같은 플래그 컬럼만 채우고 행은 그대로 둬서 복구와 이력 추적이 가능하다. 대신 모든 조회 쿼리·인덱스·유니크 제약·FK가 "삭제된 행"이라는 상태를 함께 고려해야 한다. 복구·감사·법적 보존 요구가 있으면 논리 삭제로 가고, 그게 없으면 물리 삭제 + 아카이브가 보통 더 단순하다.
탈퇴 회원이 검색이나 추천에 노출돼 장애를 친 적이 있다면, 글로벌 필터 누락과 논리 삭제의 한계로 자연스럽게 연결할 수 있다
재가입 시 이메일 유니크 충돌을 부분 인덱스나 식별자 분리로 풀어본 경험이 있다면 그 설계 판단을 그대로 답변으로 쓸 수 있다
GDPR·개인정보보호법 대응으로 보존 기간 만료 데이터를 일괄 파기·비식별화한 적이 있다면 "논리 삭제만으로는 부족했던 이유"로 풀 수 있다
논리 삭제 누적으로 쿼리가 느려져 아카이브 테이블이나 파티셔닝을 도입했던 과정이 있으면 운영 관점 답변으로 강하게 들어간다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.