2. 삭제는 기록이다

사고 시나리오

고객이 삭제를 요청해서 DELETE로 지웠다. 몇 달 뒤 그 고객과 결제 분쟁이 생겼는데, 주문했다는 기록도, 삭제를 요청했다는 기록도 남아 있지 않다. 증명할 수단이 없다. 게다가 거래 기록은 법적으로 일정 기간 보존 의무가 있는 경우가 많다 — 지우면 안 되는 걸 지운 것이다.

원칙

운영 데이터에서 삭제는 상태 변경이다. 물리 삭제(DELETE)가 아니라 삭제 시각을 기록(deleted_at)하고 조회에서 제외하는 방식이 기본값이다. “누가, 언제, 무엇을” 지웠는지가 남아야 분쟁에서 말할 거리가 있다.

실무 처방

• 테이블에 deleted_at(또는 is_active) 컬럼을 두고, 일반 조회는 이를 필터링한다.
• 삭제 행위 자체를 변경 이력(ledger)에 남긴다 — 삭제 직전 스냅샷과 실행자를 함께.
• 원장성 데이터(거래, 재고 이동, 결제)는 아예 수정·삭제 없는 추가 전용(append-only)으로 설계하고, 정정은 상쇄 기록을 추가하는 방식으로 처리한다.
• 개인정보 삭제 요청(법적 요구)과 거래 기록 보존 의무는 충돌할 수 있다 — 개인 식별 정보만 파기하고 거래 사실은 남기는 분리 설계를 미리 정한다.
• 삭제 기능마다 “이건 진짜 지워도 되는 데이터인가”를 한 번 묻는다. 마스터 데이터와 문서 초안 정도만 물리 삭제 후보다.

체크리스트

• 운영 데이터의 삭제가 물리 DELETE가 아니라 상태 변경이다
• 삭제 이력(누가·언제·무엇을)이 남는다
• 원장성 데이터는 append-only이고 정정은 상쇄 기록이다
• 법적 보존 의무가 있는 데이터 목록을 확인했다