소프트 삭제(Soft Delete), 함정에 빠지지 않는 방법?

게시글에서는 archived_at 컬럼(Column)을 활용한 소프트 삭제 방식이 쿼리, 운영, 애플리케이션 코드에 복잡성을 더한다고 지적한다. 특히, 모든 쿼리에 `WHERE archived_at IS NULL` 조건을 추가해야 하는 점, 인덱스(Index) 관리의 어려움, 그리고 마이그레이션(Migration) 과정에서의 문제점을 강조한다. 데이터 격리 아키텍처(Data Isolation Architecture)를 고려하지 않으면, 성능 저하 및 유지보수 비용 증가로 이어진다는 점을 꼬집는다.

게시글은 트리거(Trigger)를 사용하여 삭제된 데이터를 별도의 아카이브 테이블에 저장하는 방식을 제안한다. 트리거 기반 아카이빙(Archiving)은 라이브 테이블을 깨끗하게 유지하고, 쿼리 성능을 향상시키며, 백업(Backup) 및 마이그레이션(Migration)을 단순화하는 장점이 있다. 특히, 데이터 미저장 정책(Zero-Retention Policy)을 준수하면서도 데이터 복구 및 감사 기능을 제공할 수 있다는 점에서 높은 평가를 받는다. PostgreSQL의 트리거 기능을 활용하여 구현할 수 있다.

게시글은 CDC(Change Data Capture)를 활용하여 데이터 변경 사항을 캡처하고, 이를 별도의 저장소로 스트리밍하는 방식을 소개한다. Debezium과 Kafka를 활용한 CDC 파이프라인은 모든 변경 사항을 캡처하고, 다양한 대상(S3, 데이터 웨어하우스 등)으로 데이터를 전송할 수 있다. 하지만, Kafka와 같은 추가적인 인프라 운영에 대한 부담과, CDC 파이프라인의 장애 발생 시 데이터 유실 위험이 존재한다는 단점을 지적한다.

댓글에서는 소프트 삭제(Soft Delete) 방식에 대한 다양한 의견이 제시되었다. 쿼리 복잡성(Query Complexity) 문제를 지적하며, 뷰(View)를 활용한 접근 방식의 한계를 언급한다. 또한, 트리거 기반 방식의 장점을 강조하며, 파티셔닝(Partitioning) 전략을 통해 아카이브 테이블의 성능을 최적화할 수 있다고 주장한다. GDPR 규제 준수(GDPR Compliance)를 위해 소프트 삭제가 필수적이라는 의견도 제시되었다.

게시글은 삭제 쿼리를 처리하지 않는 PostgreSQL 복제본(Replica)을 활용하는 방안을 제시한다. 이 방식은 아카이브 데이터를 쉽게 쿼리할 수 있다는 장점이 있지만, 스키마 마이그레이션(Schema Migration) 문제, 추가적인 비용 발생, 그리고 운영상의 복잡성 증가 등의 단점을 지적한다. 데이터 미저장 정책(Zero-Retention Policy)을 준수하면서도 데이터 보존 및 복구 기능을 제공하기 위한 또 다른 시도로 볼 수 있다.