ADR-DS-016_데이터 보존 및 삭제 정책
## 1. ?? ??
- ADR ID: ADR-DS-016
- ??: 데이터 보존 및 삭제 정책
- ??: Draft
- ?? ??: 2026-03-02
- ?? ??: Domain Architecture
- ?? ADR: ?? ??
- Supersedes: N/A
- Superseded By: N/A
2. ?? (Context)
? ?? ?? ?? ??/?? ?? ADR ?? ?? v2 ?? ???? ?? ??/?? ?? ?? ??. ?? ??/?? ?? ?? ??/?? ?? ?? ??.
상태: Draft
작성일: 2026-03-02
범위: 사용자 데이터, 위치 데이터, 예약 기록, 슬롯 기록, 로그 데이터, 탈퇴 처리, 가맹점 종료 처리
1. 목적
이 문서는 다음을 명확히 정의한다.
어떤 데이터를 얼마 동안 보존하는가
어떤 데이터는 즉시 삭제해야 하는가
사용자 탈퇴 시 어떻게 처리하는가
가맹점 종료 시 기록을 어떻게 유지하는가
운영 로그를 얼마나 보관하는가
이 문서는 법적 준수와 구조적 일관성을 동시에 고려한다.
2. 핵심 원칙
개인정보는 최소 수집, 최소 보존을 원칙으로 한다.
위치 데이터는 실시간 검증 목적 외 장기 저장하지 않는다.
예약 및 정산 관련 데이터는 분쟁 대응을 위해 일정 기간 보존한다.
삭제는 물리 삭제(hard delete)와 논리 삭제(soft delete)를 구분한다.
로그는 진단 목적 범위 내에서만 보존한다.
3. 데이터 분류
3.1 개인정보 (Personal Data)
userId (식별자)
이메일
OAuth 식별자
로그인 이력
3.2 위치 데이터 (Location Data)
사용 확정 시 lat/lng
정확도(accuracy)
요청 시각
3.3 운영 데이터 (Operational Data)
slot
reservation
penalty
subscription
redeemedAt, expiresAt 등
3.4 로그 데이터 (Event Logs)
view_list
reserve_attempt
usage_verify_fail
penalty_applied
integrity_report 등
4. 보존 기간 정의
4.1 위치 데이터
정책:
위치 좌표는 장기 저장하지 않는다.
사용 확정 후 30일 이내 자동 삭제(또는 비식별화).
정의:
retain_location_data_days = 3030일 경과 후:
- lat/lng는 null 처리 또는 해시/격자 단위로 변환
목적:
분쟁 대응 최소 범위
개인정보 최소화
4.2 예약 데이터
정책:
reservation 기록은 최소 1년 보존
이후 통계용 비식별화 가능
정의:
retain_reservation_data_years = 11년 이후:
userId를 익명화(선택)
위치 정보는 제거
4.3 슬롯 데이터
정책:
slot 기록은 영구 보존(운영 통계 목적)
단, 개인정보 포함 없음
4.4 로그 데이터
정책:
상세 이벤트 로그 90일 보존
90일 이후 집계 데이터만 유지
정의:
retain_event_logs_days = 904.5 제재 데이터
penalty 기록은 최소 1년 보존
사용자 탈퇴 시 논리 삭제 처리 후 통계용 비식별화 가능
5. 사용자 탈퇴 처리
5.1 즉시 삭제 대상
이메일
OAuth 식별자
로그인 세션
FCM/푸시 토큰
5.2 유지 대상(분쟁/통계 목적)
reservation 기록 (익명화)
penalty 기록 (익명화)
이벤트 로그 (비식별)
5.3 익명화 방식
userId -> hashedUserId
email -> nulluserId는 내부 참조용으로 별도 매핑 테이블에서 분리 보관 가능(선택)
6. 가맹점 종료 처리
6.1 즉시 처리
subscriptionStatus = canceled
신규 슬롯 발행 금지
6.2 유지 데이터
기존 slot 기록 유지
reservation 기록 유지
통계 데이터 유지
6.3 공개 노출
종료된 가맹점 슬롯은 closed 처리
웹에서 노출 금지
7. 물리 삭제 vs 논리 삭제
7.1 물리 삭제 (Hard Delete)
위치 데이터(30일 이후)
이벤트 로그(90일 이후)
7.2 논리 삭제 (Soft Delete)
user
merchant
삭제 시:
deletedAt 필드 설정
활성 기능 차단
8. 무결성 및 삭제 상호작용
삭제가 불변 조건을 깨면 안 된다.
예:
user 삭제 시 reservation.userId FK 처리 필요
userId는 null 허용하지 않음
대신 “anonymized_user”로 대체하거나 별도 아카이브 테이블로 이동
slot 삭제는 허용하지 않는다(통계 일관성 유지)
9. 필수 테스트 케이스
T1: 31일 경과 위치 데이터 자동 제거
T2: 91일 경과 이벤트 로그 삭제
T3: 사용자 탈퇴 후 개인정보 제거 확인
T4: 탈퇴 후 기존 예약 통계 유지 확인
T5: 가맹점 종료 후 신규 발행 차단
10. 미결 항목
개인정보 보호법에 따른 정확한 법적 보존 기간 검토
세무/정산 데이터 별도 보존 규칙 필요 여부
해외 확장 시 GDPR 고려
지금까지 도메인 설계는 거의 핵심을 다 덮었다.
이제 전체 구조를 보면:
상태 기계
수량 동시성
시간 규칙
발행 제한 수학
제재 로직
무결성 검증
데이터 보존
Template v2 Addendum
In Scope
- Core domain rules (state/time/quantity/penalty/integrity/retention)
Out of Scope
- Payment settlement, PG integration, UI behavior
Boundaries
- Domain ADR defines policy. Implementation details belong to Tech ADR and code.
Source of Truth (SoT)
- State model: ADR-DS-010; Time/expiry: ADR-DS-012; Quantity/concurrency: ADR-DS-064.
Validation
- Detect state/constraint violations via tests and batch checks.
- Recovery and reprocessing must be idempotent.
Revisit Conditions
- KPI threshold breach (reservation failure, expiry ratio, payment confirmation failure)
- External dependency change (PG, regulation, location API)
Buy me a coffee