TIL.38 Soft Delete 와 Hard Delete

소프트 딜리트와 하드 딜리트는

데이터 삭제에 대한 서로 다른 철학과 용도를 반영합니다.

이들은 각각 데이터 보존, 복구, 시스템 성능, 데이터 무결성 유지와 같은

다양한 요구사항을 충족시키기 위해 사용됩니다.

1. 소프트 딜리트 (Soft Delete)

소프트 딜리트는 데이터가 논리적으로 삭제되었음을 나타내지만

실제 데이터는 여전히 데이터베이스에 존재하는 방식입니다.

이는 특정 열을 사용하여 삭제 상태를 표시하는 방식으로 구현됩니다.

보통 is_deleted 또는 deleted_at 같은 필드가 사용됩니다.

• 구현 방법
  • 데이터베이스 테이블에 "삭제 여부"를 나타내는 플래그 필드(e.g., is_deleted)를 추가하거나, 삭제 시점을 기록하는 deleted_at 필드를 추가합니다.
  • 데이터를 삭제할 때는 해당 필드의 값을 변경하여 데이터가 삭제된 상태임을 표시합니다. 예를 들어, is_deleted 필드를 true로 설정하거나, deleted_at 필드에 현재 타임스탬프를 기록합니다.
• 쿼리 예시
  • 삭제 처리

UPDATE schedules SET is_deleted = true WHERE id = 1;

• 삭제된 데이터 제외하고 조회

SELECT * FROM schedules WHERE is_deleted = false;

• 장점
  1. 데이터 복구 용이성
     • 데이터가 물리적으로 삭제되지 않으므로, 실수로 삭제된 데이터를 쉽게 복구할 수 있습니다.
     • 예를 들어, 단순히 is_deleted 필드를 false로 업데이트하는 것으로 데이터 복구가 가능합니다.
  2. 감사 및 추적 용이성
     • 데이터가 삭제된 이유를 감사하거나 이력을 추적할 수 있습니다.
     • 특히 금융 및 의료와 같은 데이터 보존 요구사항이 중요한 도메인에서 이 방식이 유용합니다.
  3. 참조 무결성 유지
     • 데이터베이스에서 서로 연관된 테이블이 많은 경우, 데이터를 소프트 딜리트하면 관련된 데이터의 무결성을 유지할 수 있습니다.
     • 예를 들어, 사용자 계정 삭제 시 관련된 모든 거래 기록을 남겨둘 수 있습니다.
• 단점
  1. 저장 공간 문제
     • 데이터가 물리적으로 삭제되지 않기 때문에 저장 공간을 계속 차지하게 됩니다. 데이터의 양이 많아지면 저장소가 불필요하게 커질 수 있습니다.
  2. 쿼리 복잡도 증가
     • 삭제된 데이터를 필터링하기 위해 모든 조회 쿼리에 추가 조건을 넣어야 합니다. 이는 성능에 영향을 미칠 수 있고, 쿼리가 복잡해집니다.
  3. 잠재적 데이터 불일치
     • 논리적으로 삭제된 데이터가 여전히 존재하기 때문에 다른 기능이나 비즈니스 로직에서 이 데이터를 잘못 참조할 가능성이 있습니다.

2. 하드 딜리트 (Hard Delete)

하드 딜리트는 데이터를 데이터베이스에서 완전히 제거하는 방식입니다.

삭제된 데이터는 더 이상 데이터베이스에서 볼 수 없으며 복구하기 어렵습니다.

• 구현 방법
  • 단순히 SQL DELETE 문을 사용하여 데이터를 삭제합니다.
  • 데이터가 삭제되면, 관련된 모든 참조도 삭제하거나 외래 키 제약 조건에 의해 자동으로 삭제(ON DELETE CASCADE)될 수 있습니다.
• 쿼리 예시

DELETE FROM schedules WHERE id = 1;

• 장점
  1. 저장 공간 절약
     • 데이터가 완전히 삭제되기 때문에 데이터베이스에 불필요한 데이터가 남아 있지 않아 저장 공간을 절약할 수 있습니다.
  2. 쿼리 성능 향상
     • 삭제된 데이터가 데이터베이스에 없으므로 조회 쿼리 시 추가적인 조건을 적용할 필요가 없으며, 쿼리가 단순하고 효율적입니다.
• 단점
  1. 데이터 복구 불가
     • 삭제된 데이터는 물리적으로 제거되기 때문에, 잘못 삭제된 경우 복구가 매우 어렵거나 불가능합니다. 복구를 위해서는 별도의 백업에서 데이터를 가져와야 합니다.
  2. 감사 어려움
     • 데이터 삭제 후에는 해당 데이터의 흔적이 남지 않기 때문에, 누가 언제 무엇을 삭제했는지 추적하기 어렵습니다.
     • 이로 인해 규제 준수나 감사가 중요한 환경에서는 적합하지 않을 수 있습니다.

3. 언제 소프트 딜리트와 하드 딜리트를 선택할까요?

• 소프트 딜리트 사용 시
  • 데이터가 삭제된 후에도 복구해야 할 가능성이 높은 경우 (e.g., 사용자가 실수로 데이터를 삭제했을 때 복구가 필요한 시스템).
  • 삭제된 데이터를 이용해 분석이나 감사가 필요한 경우 (e.g., 사용자의 활동 이력 추적).
  • 데이터베이스의 참조 무결성을 유지해야 하는 경우 (e.g., 부모 데이터가 삭제되어도 자식 데이터가 무결성을 유지해야 하는 경우).
• 하드 딜리트 사용 시
  • 데이터 삭제 후 복구가 필요하지 않으며, 삭제된 데이터는 더 이상 사용할 필요가 없는 경우 (e.g., 임시 캐시 데이터).
  • 저장 공간이 제한되어 있고, 불필요한 데이터를 최대한 제거해야 하는 경우.
  • 시스템 성능이 중요한 경우 (삭제된 데이터를 필터링할 필요 없이 쿼리를 간단하게 유지하고 싶은 경우).

4. 실제 사용 예시

• 소프트 딜리트 예시
  • 사용자 계정 관리 시스템 : 사용자가 계정을 삭제해도, 관련된 데이터(예: 주문 이력, 메시지 등)를 보존해야 하는 경우 소프트 딜리트를 사용하여 계정을 비활성화 상태로 표시합니다.
  • 블로그 게시물 : 게시물을 삭제해도 데이터가 복구될 수 있어야 하는 경우, 삭제된 게시물은 단순히 "삭제됨"으로 표시되지만 데이터베이스에는 여전히 남아 있습니다.
• 하드 딜리트 예시
  • 하드 딜리트 예시 : 업로드된 임시 파일을 일정 시간이 지난 후에 영구적으로 삭제할 때 하드 딜리트를 사용합니다.
  • 로그인 세션 : 만료된 로그인 세션 데이터를 제거할 때는 하드 딜리트를 사용하여 공간을 절약하고 성능을 유지합니다.

이와 같이 소프트 딜리트와 하드 딜리트는 각기 다른 상황에 맞춰 사용되며,

시스템의 요구사항에 따라 적절한 방식을 선택해야 합니다.

소프트 딜리트는 데이터 복구 및 추적에 유리하지만 성능과

저장 공간 측면에서 비용이 들 수 있고,

하드 딜리트는 단순하지만 데이터 복구가 어렵다는 점에서 주의가 필요합니다.