데이터에서 '삭제'란 무엇인가?
필요없음. 더이상 정보로서의 가치가 없어 현재도 미래에도 보존할 가치가 없어 그 기록을 제거함. 이라 정의할 수 있다.
정보의 가치가 0인 것이다. 그런데 왜 soft delete으로 보관하는가?
그것은 아마도 지금은 정보로서의 가치가 없다고 판단되나 혹시 모를 다가올 미래에 참조할 경우가 있지않을까? 그리고 한번 지워지면 다시 되돌릴 수 없으니까...
정도로 그 이유를 찾을 수 있겠다.
이걸 수치로 생각해보자.
정보로서의 가치가 없어 정말 삭제해도 되는 데이터의 가치를 0라고 보고, 현재도 미래에도 가치가 있는 데이터를 100으로 본다면,
앞서말한 soft delete의 가치는 어디쯤 일까?
정확힌 어디쯤인지는 몰라도 0보다는 크다고 판단했기에 soft delete으로 보관했을 것이다.
그럼 0보다 큰 0.001의 가치를 가지는 데이터와 가치가 100인 데이터의 DB의 기록 방법은 다른가? 0.001짜리 데이터는 힘을 좀 빼고(?) 기록할 방법이란게 있나?
그런건 없다.
0보다 크면 0.001짜리 가치든 100짜리 가치든 자료의 기록방법은 다를게 없다.
결국 0.001의 가치도 결국 100짜리 가치와 마찬가지로 보관대상이라는 관점에서는 동일하게 취급되는 데이터다.
자주찾지는 않으나 보관해야하는 데이터이지 정말 가치가 0인 데이터는 아니라는 것이다.
다시 말해 0인 것과 0이 아닌 0.001은 다른 것이다. 다르게 취급해야 되는 것이다.
그런데 왜 가치가 0가 아닌 데이터를 '삭제'라고 낙인하여 관리하는가?
이것은 데이터의 life cycle상 정보의 가치등급이라는 개념으로 관리하는것이 0.001을 보다 정확히 해석한 것이다.
그리고 무작정 hard delete으로 삭제하면 안되는 민감 데이터는
이미 하나의 instance가 생성되면서 부터 상태값이라는 속성으로 대부분 관리되고 있다.
그 상태값이 곧 데이터의 life cycle을 관리하는 속성인데 왜 진정한 '삭제'가 아닌 데이터를 '삭제'라는 명칭으로 데이터 등급관리를 이중으로 하는가가 문제의 본질이다.
설사 상태값을 관리하는 속성이 별도로 없다하더라도 이것은 이미 진정한 '삭제'가 아니기에 가치등급을 나타내는 상태값 관리 속성으로 도출되어야 한다.
속성은 그 의미를 명확히 정의하여 다른 속성과 의미가 겹치거나 중복되지 않아야 하고,
정확한 값의 경계선으로 정보의 완전성과 다른 속성에 의존하지 않는 독립성을 지켜야 한다.
어떤 데이터가 미래에 어떻게 취급될지 예측할 수 없다면 복잡하게 생각할 것 없이
그저 그 데이터의 진정한 본질을 찾고 의미를 훼손하지는 방법으로 관리하는 것이 여러모로 정신건강에 좋다.
조금 더 구체적으로 알아보자.
삭제여부필드(soft delete)는 따져 보면 사용 수 있는 경우가 잘 없고, 잘못 활용하면 오히려 데이터 관리가 복잡해진다.
명확한 데이터 관리전략을 생각하지 않고 일단 보관하고 보자는식의 soft delete(이것은 설계자의 나태다)은 hard delete과 상태값으로 관리하는 방식보다 비용만 올라가고 오용의 소지만 유발한다.
실체, 행위, 가공, 기준
이렇게 4가지 엔터티기준으로 한번 따져보자.
1. 먼저 생각하기 쉬운 가공 데이터 부터 알아보자.
일단 삭제여부속성필드를 관리하는 이유는 데이터가 한번 삭제되면 복원이 불가능하기에 삭제라는 중요작업으로 부터 데이터를 보호하기 위한 이유가 클 것이다.
혹 백업을 통하여 중요 데이터 삭제에 대응할 수 있지 않을까 착각 할 수 있는데, 백업은 데이터의 단순 보존이지 데이터의 관리전략을 의미하지 않음을 알아야한다.
이미 잘못 관리된 데이터를 백업하고 복원 해본들 무슨 소용인가? 지금 이 주제는 데이터의 삭제관리 전략을 말하고 있음을 이해해야 한다.
다시 이어나가면 원천 데이터로 부터 다시 재현 가능한 데이터이거나 변경이력 관리대상이 아닌 데이터는 삭제여부속성(soft delete)의 존재가치가 없다 것이다.
이런 데이터중 대표적인 엔터티가 가공 엔터티다.
즉, 년간, 월간 집계데이터, Report성 데이터, TO-DO List 데이터는 삭제여부속성이 필요없다는 말이다.
어차피 이런 데이터는 원천 데이터로 부터 일정한 주기로 Batch로 생성하기 때문이다. 얼마든지 재생성 가능한 데이터들이다.
가공 데이터(엔터티)에서는 삭제여부속성을 관리한다고 얻을 이익자체가 없다.
2. 실체 데이터는 모든 행위 데이터의 행위 주체이기 때문에 삭제란 개념이 있을 수 없다, 즉 실체 데이터는 존재가치가 없는 순간이 절대 있을 수 없기 때문이다.
왜? 아무리 오래된 과거 행위 데이터라 하더라도 당시의 행위 주체가 누구인지를 추적할 수 없다면 행위 데이터 정보가 불완전 정보가 되기 때문이다.
데이터의 가치는 품질에 있지 보존 그 자체에 있는 것이 아니기 때문이다.
사용자(직원, 고객), 상품(제품, 서비스), 거래업체(법인, 은행) 등 행위주체가 되는 실체 데이터를 생각해 보자.
직원이 퇴사했다고 삭제 할 수 있는가? 그럼 그 직원이 작성한 문서는?, 고객을 관리하는 당시 담당직원의 추적은?
고객이 탈퇴했다고 삭제 할 수 있는가? 그럼 해당 고객이 구매하거나 제공받은 서비스 정보는?, 매출발생의 대상의 타겟층은 어떻게 분석?
제품을 더 이상 생산하지 않는다고 삭제할 수 있는가? 그럼 그간 해당 제품이 판매한 매출 실적은?
보험상품을 더 이상 판매하지 않는다고 삭제 할 수 있는가? 역시 그간 판매한 상품의 수익 실적은?
거래업체가 폐업했다고 삭제할 수 있는가? 그럼 그간 거래한 정보는? 매출, 매입 정보는?
그래서 이런 실체 데이터는 그 활동이 중지되거나, 유효성이 없어진다면 해당 데이터가 비활성된 사유가 상태(퇴사, 탈퇴, 생산중단, 판매중단, 폐업)값으로 관리되어야지 soft delete이나 hard delete등 삭제라는 처리방식으로 관리되어질 성격이 아닌 데이터다.
만약 어떤 사이트에서 "회원탈퇴시 고객정보를 모두삭제 한다"고 고지 했다면
이는 해당 고객의 중요 개인정보만을 clear하여 사용자를 특정할 수는 없으나 ID정보는 보존하여 그 행위주체자가 만들어낸 행위의 실적데이터의 품질은 훼손되지 않도록 하거나,
아니면 해당 사용자 정보를 정말 hard delete을 한다면 그 사용자가 발생시킨 모든 데이터역시 hard delete하는 방식으로 관리할 것이다.
즉 행위 주체정보가 누락된 행위 데이터는 출처를 알 수 없는 정보가 된다. 그래서 행위 주체가 되는 실체 데이터는 삭제처리가 있어선 안된다.
3. 기준 데이터는 이력으로 관리되어야 한다.
코드성 데이터, 상품의 가격, 월급 및 연봉 테이블, 사용자의 등급 테이블 등은 변경이 되면 이력으로 관리 되어야 하기에 삭제가 없다.
물론 어디에서도 아직 참조되지 않는 데이터라면 hard delete하면 된다. soft delete으로 보존할 이유가 없다.
특히 코드성 데이터의 경우 이력(선분이력으로 관리하면 조회성능에 유리하다.)으로 관리하지 않는다면 "사용여부"로 관리해야지 "삭제여부"로 관리되어선 안된다.
특정 코드를 한동안 사용하다가 특정시점 이후로 사용하지 않는다고 해서 hard delete되어선 안되며, soft delete으로 보존한다면 이것은 삭제가 아니라 "사용여부"로 관리되어야 한다.
말 그대로 사용안함일 뿐이지 삭제가 아니기 때문이다.
어떤 신규 데이터를 작성할 경우 특정속성의 값이 코드로 관리된다면 해당 속성의 현재 사용가능한 코드에서 선택되도록 해야 하겠지만,
한번 저장되고 난 후 조회시에는 해당 코드의 사용가능여부와는 상관없이 코드명으로 조회되어야 한다.
특정 코드를 현재 사용하지 않는다고해서 과거 데이터 조회시 해당 코드의 명을 알 수 없다는 것은 잘못된 것이기 때문이다.
언제든 당시의 값을 확인할 수 있어야 한다. 개발자들이 흔히 하는 실수다. 코드값으로 코드명을 조회할때는 사용여부나 삭제여부 조건이 있어선 안되는 이유다.
4. 실체 데이터가 행위 주체가 되어 만들낸 행위 데이터는 중요 데이터이다.
* 행위 데이터를 transaction data라고 관행적으로 말하기도 하는데 본인은 정확한 표현이라 생각하지 않는다. transaction을 유발하지 않는 데이터는 사실 없는데 왜 유독 행위 데이터만 이렇게 표현하는지 모르겠다. 만약 "행위"라는 명칭이 생소하여 그렇수 있다면, 차라리 business data, 업무 데이터라 지칭하는게 더 명확하다 생각한다. - 본인생각
특히 변경 차수로 데이터를 관리하겠다는 전략은 해당 데이터의 변경이력 또한 중요정보로서 보관되어야 한다는 전제이기 때문에 함부로 삭제할 수 없다.
아래의 도식을 보자
Draft상태의 데이터는 데이터 소유자외에는 공개되지 않은 비공식상태이기 때문에 더이상 데이터가 필요하지 않다고 판단했다면 hard delete하면 된다.
그러나 데이터가 공식 데이터로 신분이 상승한 이후에 해당 데이터의 프로세스가 진행이 중단되었다면
그 무효해진 당시 상태(취소, 반려 등)값으로 관리되어야지 삭제로 처리되선 안되기 때문에 여전히 soft delete은 차수관리방식의 행위 데이터에서도 필요가 없다.
그럼 차수로 관리하지않는 행위 데이터는 어떻게 할 것인가? 이미 위에서 기존에 삭제라고 생각했던 개념이 가지는 본질이 무엇인가를 따져 보면서 설명했다. 차수로 관리하는 방식과 다를게 없다.
결론
이처럼 하나하나 분석해 보면 데이터를 soft delete로 처리해야할 경우는 사실상 없다.
삭제 처리될 수 있을것 같은 대부분의 데이터가 상태값으로 관리 되어야 하거나, 삭제해선 안되는 데이터들이다.
그리고 데이터의 참조관계가 없는 Draft상태는 hard delete하면 된다. 복잡할게 없다.
혹 상태값 관리가 결국 삭제여부관리를 대신하므로 달라진 것이 없다고 상각할 수 있는데 애초에 Soft Delete(삭제여부)으로 관리해야할 민감 데이터라면
상태값으로 관리해야지 의미가 겹치는 속성을 이중으로 관리하는것 자체가 잘못임을 알아야 한다.
무엇보다 그 의미가 사실 삭제가 아닌데 삭제로 표현하여 관리하는 것이 잘못이다.
* 참고로 속성 정의시 유의점
속성은 단독으로 그 의미가 완전해야 한다. 다른 속성에 의존해서 함께 봐야지만 그 의미가 해석되는 경우는 최소화 해야 한다.
또 다른 속성과 의미가 중복되거나 속성간의 의미가 포함관계가 있어선 안된다.
즉 속성은 단독으로 최소 의미의 원자성이 지켜지도록 해야 한다.
마지막으로 복합명사(수식어 + 피수식어)를 사용하여 의미를 정확이 전달하도록 한다. ex) 담당자 (×) → 평가 담당자 (○)
데이터의 무효한 상태와 삭제된 상태를 혼동해선 안된다. 무효한 상태값으로 관리해야할 중요데이터는 삭제여부가 사실상 필요가 없다.
무효한 상태와 삭제여부상태가 동시에 관리된다면 오히려 데이터의 관리에 있어서 혼란만 유발한다.
만약 불가피하게 soft delete으로 관리해야할 데이터가 있고, 그 데이터의 엔터티 구조가
할아버지
아버지
손자
등등
n代에 걸친 존재종속관계(=식별관계)의 행위 데이터가 삭제된다면 최상위 엔터티인 할어버지 엔터티에서만 삭제여부속성을 관리해야 한다.
아버지, 손자등 n代까지 모두 삭제여부속성을 관리한다 정합성을 유지하는 비용이 너무크다.
* 이것은 정합성관리에 대한 문제로 이전 "무결성과 정합성"게시물에 언급하였다. 참고하기 바란다.
예를들어 할아버지는 삭제여부가 'Y'인데 그 아래의 아버지, 손자의 삭제여부가 'N'이거나, 그 반대의 경우 혼란만 가중 될 뿐이다.
혹자는 최상위 엔터티에만 삭제여부 속성을 관리하면 특정 데이터가 삭제되었는지 아닌지 체크하기 위해서는
각 엔터티별로 삭제여부속성을 가질때와는 달리 항상 최상위 엔터티를 바라봐야 해서 불편하다 불평 할 수 있는데.
개발의 편이성추구가 결코 데이터 품질의 보장보다 우위에 있을 수 없다는 것을 말하고 싶다. 이 말이 개발의 편이성은 무시되어야 한다는 뜻은 아니다.
설계는 구축하고자 하는 시스템을 구성하는 개별 엔터티의 본질을 도출하여
그 Business rule이 스키마에 녹여져 누가 보더라도 그 본질의 의미가 훼손없이 전달 될 수 있어야 한다.
그 규칙성을 단순히 개발의 편의를 위해 변경할 수 있는 대상이 아니다.
설계 과정에 개발 용이성을 고려한다 하더라도, Business rule이 훼손되지 않는 범위여야 한다.