44/ 50
＋ Maps nearly every requirement to the supplied data.
－ It does not locate the six-month advertising records.
Design a data retention and deletion policy
Sets how long each table keeps data and when it goes, starting from what must not be deleted.
| Category | Development › Data & databases |
|---|---|
| Tags | ChecklistReviewingDeveloper |
Design a retention policy for this data. Per table or data type: 1. **Classification** — must retain (legal or contractual) / should retain (operational value) / should delete (privacy or risk) / no reason to keep. 2. Retention period, with the reason. A period with no reason attached will be argued about later. 3. What happens at the end: hard delete, anonymize, archive to cold storage. 4. **What breaks when it goes** — foreign keys, audit trails, reports that query historical ranges, aggregates computed from raw rows. *This is why retention policies get written and never implemented.* Then: - Conflicts where one rule says retain and another says delete. These need a decision, not a default. - Deletion order, so referential integrity survives. - How to delete at volume without locking the table. - What to keep as an aggregate after the raw rows are gone. - Growth projection if nothing is deleted, at my stated rate. Rules: - ⚠️ **This is not legal advice.** Retention requirements vary by jurisdiction and industry. Mark every legal claim as needing confirmation and say who should confirm it. - Anonymization that leaves a re-identifiable combination is not deletion. Flag any such case. - Do not propose deleting anything whose retention requirement is unclear. Flag it for review instead.
After pasting, fill in the fields at the bottom (Tables · Legal context · Growth rate)
What this prompt does
Without a policy, data accumulates forever. This separates what must be retained from what must be erased, and finds where deletion breaks references.
Model comparison
ChatGPT is clearly strongest in completeness, specificity, and calculation. Gemini defers the required detail to an external file and adds unsupported figures, while [C] is missing.
19/ 50
＋ Concise prioritization of urgent operational actions.
－ Relies on an external file and invents periods and size.
| Criterion | ChatGPT | Gemini | Leader |
|---|---|---|---|
| Instruction following | 9 | 3 | ChatGPT +200% |
| Accuracy | 9 | 2 | ChatGPT +350% |
| Specificity | 9 | 5 | ChatGPT +80% |
| Structure | 9 | 6 | ChatGPT +50% |
| Right length | 8 | 3 | ChatGPT +167% |
Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.
Read full answers
We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.
Tables: orders(주문내역), payment_logs(PG사 응답 원문 포함 결제 로그), user_activity_logs(접속·행동 로그), marketing_consents(마케팅 수신동의 이력), cs_tickets(고객센터 문의 및 첨부파일) Legal context: 국내 전자상거래 소비자보호법 적용 대상 쇼핑몰(화장품 정기구독). 청약철회 관련 기록 5년, 표시·광고 기록 6개월 보관 의무 존재, 개인정보보호법상 목적 달성 시 지체없이 파기 원칙 적용. Growth rate: user_activity_logs 하루 약 200만 건 적재, payment_logs 하루 약 1만 건, cs_tickets 하루 약 300건
아래는 제공된 사실을 기준으로 한 초안 정책입니다. ⚠️ 법적 보관기간과 파기 가능 여부는 관할·계약·PG사 약관에 따라 달라지므로, 모든 법적 판단은 법무팀과 개인정보보호책임자(DPO), 필요 시 외부 변호사 및 PG사 계약 담당자의 확인이 필요합니다.
1. 테이블·데이터별 정책
| 데이터 | 분류 | 보관기간 및 이유 | 종료 시 처리 | 없어질 때 깨지는 것 |
|---|---|---|---|---|
orders 주문내역 |
must retain: 청약철회·거래 증빙에 필요한 필드 | 청약철회 관련 필드 5년. 사용자가 제시한 법정 요건이며 법무팀 확인 필요. 주문 전체를 5년 보관해야 하는지는 별도 확인 | 5년 후 하드 삭제 또는 비식별화. 법적 증빙 필드는 냉동보관 가능성 검토 | payment_logs, cs_tickets, 환불·구독·배송 이력의 FK, 기간별 매출·환불 보고서 |
payment_logs PG 응답 원문 포함 |
혼합: 최소 결제 증빙은 must retain 가능성, 원문은 should delete 후보 | 결제 성공·실패·환불·승인번호 등 최소 증빙은 관련 주문과 동일 기간 보관 필요성 검토. PG 원문 전체는 30~90일 임시안이나, 법적·계약적 보관의무 확인 전 삭제 금지 | 원문은 민감정보 제거 후 삭제 후보. 최소 증빙은 5년 냉동보관 또는 주문과 동일하게 처리 | 환불·분쟁 대응, PG 대사, 감사 추적, 주문-결제 연결 |
user_activity_logs 접속·행동 로그 |
should delete 또는 목적 없는 데이터는 no reason to keep | 보안 사고 조사·서비스 운영 목적을 정한 뒤 보관. 90일 임시안을 검토할 수 있으나, 보안팀·개인정보보호책임자 승인 전에는 삭제하지 않음 | 기간 만료 시 하드 삭제. 장기 분석이 필요하면 개인 식별이 불가능한 일·주 단위 집계만 보관 | 보안 조사, 사용자별 행동 분석, 원시 로그 기반 리포트 |
marketing_consents 동의 이력 |
must retain 가능성: 동의·철회 증빙 | 동의 상태, 시각, 수집 문구 버전, 채널, 출처는 동의의 유효성 입증에 필요할 수 있음. 정확한 기간은 법무·DPO 확인 전 결정 불가 | 기간 확정 후 냉동보관 또는 직접식별자 분리·비식별화. 재식별 가능한 조합이면 비식별화로 보지 않음 | 수신동의 입증, 철회 시점 확인, 마케팅 발송 적법성 감사 |
cs_tickets 문의 및 첨부파일 |
혼합: 분쟁·청약철회 관련 건은 must retain 가능성, 일반 문의는 should retain | 청약철회·환불·분쟁 관련 티켓은 관련 orders와 동일한 5년 보관 필요성 검토. 일반 문의와 첨부파일의 기간은 현재 근거 부족 |
관련 건은 냉동보관. 일반 문의와 첨부파일은 기간을 정한 뒤 하드 삭제 또는 첨부파일 우선 삭제 | 고객 분쟁 대응, 주문 이력, 상담 품질 보고서, 첨부파일 링크 |
중요한 구분
orders 전체를 자동으로 5년 보관한다고 결정하면 개인정보가 과도하게 남을 수 있습니다. 다음처럼 필드를 나누는 것이 안전합니다.
- 5년 보관 후보: 주문번호, 주문일, 상품·금액, 청약철회·환불 상태와 시각, 증빙에 필요한 최소 고객 식별자
- 조기 삭제·분리 후보: 배송지, 전화번호, 상세 상담 내용, 불필요한 메모
- 원문 보관 제한 후보: PG 응답 전체, 카드·결제수단 관련 민감 필드, CS 첨부파일
2. 법적·정책 충돌
| 충돌 | 결정이 필요한 사항 |
|---|---|
| 청약철회 기록 5년 vs 개인정보보호법상 목적 달성 후 지체 없는 파기 | 5년 보관이 필요한 정확한 필드와 기록 유형을 법무팀·DPO가 확정해야 함. 전체 주문·전체 상담 원문을 보관하는 근거로 확대하지 않음 |
| PG 원문 보관 필요성 vs 개인정보·결제정보 위험 | PG 계약, 분쟁 대응 요건, 내부 대사 요건을 확인해 원문과 최소 증빙을 분리할지 결정 |
| 마케팅 동의 이력 보관 vs 철회 후 개인정보 최소화 | 철회 사실과 당시 동의 증빙을 얼마나 오래 보관해야 하는지 법무팀·DPO가 확정. 철회했다고 동의 이력 전체를 즉시 삭제하면 입증이 불가능할 수 있음 |
| CS 티켓 보관 vs 문의 해결 후 목적 달성 | 청약철회·분쟁 관련 건과 일반 문의를 분리. 일반 문의 기간은 근거가 없으므로 현재 삭제하지 않음 |
| 활동 로그 분석 가치 vs 대규모 개인정보 축적 | 보안·장애·부정행위 탐지에 필요한 최소 기간과 항목을 보안팀이 정해야 함. 정해지기 전 임의 삭제 금지 |
법적 보관기간은 모두 사용자가 제공한 전제에 기반한 것으로, 법적 확정사항으로 취급하면 안 됩니다. 특히 “청약철회 관련 5년”과 “표시·광고 기록 6개월”이 각 테이블의 어떤 필드에 적용되는지 확인해야 합니다. 확인 주체는 법무팀·DPO이며, 필요 시 외부 변호사입니다.
3. 삭제·아카이브 순서
- 보존기간 만료 대상과 법적 보류 대상(분쟁, 감사, 소송, 수사)을 분리한다.
- 리포트·집계·검색 인덱스를 먼저 갱신하거나 보존된 집계로 전환한다.
cs_tickets첨부파일을 삭제 또는 냉동보관한다.- CS 메시지와 티켓 본문을 처리한다.
payment_logs원문을 삭제하고, 보존 대상 최소 증빙만 남긴다.user_activity_logs를 파티션 단위로 삭제한다.marketing_consents는 법무 승인된 보존기간이 지난 기록만 처리한다.orders의 개인정보 필드를 비식별화하거나, 연결된 자식 데이터가 모두 처리된 뒤 주문을 삭제한다.- 고아 레코드, FK 위반, 집계 차이를 검증한다.
- 삭제 작업 자체의 감사 로그는 별도로 보관한다. 단, 감사 로그에 원래 개인정보를 복제하지 않는다.
실제로는 FK 때문에 orders를 부모 테이블로 두고 자식 데이터를 먼저 처리해야 합니다. 주문을 삭제하지 않고 익명화할 경우에도 order_id, 고객 식별자, 결제 식별자 조합이 재식별 가능하면 삭제나 비식별화로 인정하지 않아야 합니다.
4. 대량 삭제 방법
user_activity_logs는 하루 200만 건이므로 행 단위 DELETE는 피해야 합니다.
- 날짜 기준 파티션을 만든다.
- 보존기간이 지난 파티션은 검증 후
DROP PARTITION또는 파티션 교체 방식으로 제거한다. - 파티션을 바로 삭제할 수 없으면 작은 PK·시간 범위로 배치 삭제한다.
- 배치 사이에 짧은 커밋과 지연을 두고, lock wait·replication lag·DB 부하를 감시한다.
- 인덱스와 보조 검색 시스템에도 동일한 만료 정책을 적용한다.
- 삭제 전 보존 대상, 법적 보류, 집계 완료 여부를 자동 검증한다.
- 삭제 작업은 멱등적으로 만들어 재시도해도 중복 처리되지 않게 한다.
payment_logs와 cs_tickets는 날짜와 order_id 기준으로 배치 처리하고, 첨부파일은 DB 레코드 삭제 전에 객체 저장소에서 보존·삭제 상태를 확인해야 합니다.
5. 원시 데이터 삭제 후 남길 집계
개인 단위가 아닌 기간·상품·채널 단위 집계를 남기는 방안을 권장합니다.
- 일·월별 주문 건수, 취소·환불 건수와 금액
- 상품·구독 플랜별 판매량과 매출
- 결제 성공·실패·환불 건수
- PG사별 승인·실패율 및 대사 차이
- CS 문의 건수, 유형별 건수, 평균 처리시간
- 청약철회 건수와 처리시간
- 마케팅 동의율·철회율을 기간 단위로 집계
- 활동 로그의 일별 방문자 수, 이벤트 수, 오류율
작은 집단의 집계는 재식별 위험이 있으므로 최소 집계 단위, 셀 억제, 범주 통합을 적용해야 합니다. 집계값에 user_id, 정확한 시각, 주문번호, 티켓번호가 남으면 원시 데이터 삭제 효과가 약해집니다.
6. 삭제하지 않을 경우의 증가량
| 데이터 | 증가율 | 연간 증가량 | 5년 증가량 |
|---|---|---|---|
user_activity_logs |
하루 200만 건 | 약 7억 3,000만 건 | 약 36억 5,000만 건 |
payment_logs |
하루 1만 건 | 약 365만 건 | 약 1,825만 건 |
cs_tickets |
하루 300건 | 약 10만 9,500건 | 약 54만 7,500건 |
orders |
미제공 | 계산 불가 | 계산 불가 |
marketing_consents |
미제공 | 계산 불가 | 계산 불가 |
저장용량은 평균 레코드 크기와 첨부파일 크기가 없어 산정할 수 없습니다. 계산식은 다음과 같습니다.
연간 저장량 ≈ 연간 건수 × (평균 DB 레코드 크기 + 인덱스·복제·백업 오버헤드)
특히 user_activity_logs는 5년 동안 36억 건 이상이므로, 보존기간을 정하지 않으면 운영·백업·검색 비용과 개인정보 위험이 빠르게 커집니다. 다만 법적·보안상 필요한 보존기간이 확정되기 전까지는 삭제를 실행하지 말고, 우선 필드 최소화·파티셔닝·보존 대상 분리부터 적용하는 것이 안전합니다.
More in this category
| Advanced Text Converter for Large Datasets | |
| AI-powered data extraction and organization tool | |
| AI2sql SQL Model — Query Generator | |
| Backend Architect | |
| base-R |