SaaS 고객이 계약을 끝내며 데이터 삭제를 요청했을 때, 운영 DB의 행만 지우면 끝일까요? 검색 인덱스, 파일 저장소, 로그, 백업, 분석 데이터에 같은 정보가 남을 수 있습니다. 삭제를 약속하려면 데이터가 어디에 있는지와 각 저장소의 삭제 상태를 추적해야 합니다.
테넌트 데이터 지도를 만든다
주 DB뿐 아니라 첨부파일, 캐시, 검색 인덱스, 이벤트 큐, 분석 저장소를 열거합니다. 어떤 데이터가 개인·업무정보인지, 어떤 식별자로 테넌트에 연결되는지 기록합니다. 테넌트 ID가 없는 복제본은 삭제 범위를 찾기 어렵습니다.
삭제 요청을 상태 기계로 다룬다
요청 접수, 보존 의무 확인, 서비스 중지, 각 저장소 삭제, 검증, 완료 통지의 단계를 분리합니다. 장애가 생겨 일부만 삭제됐을 때 재시도할 수 있어야 합니다. 단순한 '삭제 성공' 플래그로는 누락된 저장소를 알 수 없습니다.
백업의 특성을 명확히 설명한다
백업은 특정 테넌트만 즉시 지우기 어려울 수 있습니다. 보존기간, 암호키 정책, 백업 복원 시 삭제된 데이터가 다시 활성화되지 않는 절차를 설계합니다. 고객과 약속하는 삭제 범위와 완료 시점을 기술 현실에 맞게 명시해야 합니다.
삭제 증빙에 원문을 남기지 않는다
증빙을 위해 개인정보 원문을 다시 저장하면 모순입니다. 요청 ID, 테넌트 식별자, 저장소별 작업 시각, 결과 코드, 검증자만 필요한 기간 보관합니다. 증빙 기록도 접근 권한과 보존 정책을 가집니다.
복원 테스트까지 해야 완성된다
백업 복원 훈련 중 삭제된 고객 데이터가 돌아오는지 확인합니다. 인덱스 재구축과 이벤트 재처리도 같은 위험이 있습니다. 삭제 완료는 운영 DB에서 안 보이는 상태가 아니라 재생성 경로까지 통제된 상태입니다.
현장에 적용할 때의 순서
- 테넌트 데이터가 남는 저장소를 목록화한다
- 삭제 요청을 저장소별 상태로 추적한다
- 백업 복원·인덱스 재생성에서 삭제 유지 여부를 시험한다
주의할 실패: 운영 DB만 지우고 재처리 경로를 방치하면 삭제 데이터가 다시 나타날 수 있다.
관찰할 지표: 저장소별 삭제 완료율, 재시도 건수, 복원 후 재출현 여부를 본다.
적용 전 체크리스트
- 모든 데이터 저장소에 테넌트 식별자가 있는가
- 백업 복원 뒤 삭제 상태를 다시 적용하는가
- 삭제 증빙에 원문을 남기지 않는가
참고 자료
AWS Well-Architected SaaS Lens, user behavior patterns. AWS SaaS Lens는 테넌트 오프보딩과 데이터 보관·삭제를 계획하도록 권고합니다. 실제 법적 보존 의무와 삭제 기한은 계약·관할 법령별 검토가 필요합니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#SaaS #테넌트삭제 #데이터거버넌스 #멀티테넌트 #백업 #개인정보보호 #오프보딩 #감사증빙 #검색인덱스 #데이터삭제
