기업용 SaaS에서는 고객사마다 계약과 업무 방식이 다릅니다. 한 고객사는 작업 기록을 오래 조회해야 하고, 다른 고객사는 일정 기간이 지나면 삭제를 원합니다. 운영 DB의 행에만 만료일을 넣어서는 문제가 끝나지 않습니다. 첨부 파일, 검색 색인, 분석 테이블, 백업, 다운로드용 임시 파일에도 같은 데이터가 남을 수 있기 때문입니다. 데이터 수명주기는 저장 위치별 청소 작업이 아니라 고객사 정책에서 실제 데이터 상태까지 이어지는 설계입니다.
무엇을 언제부터 계산할까
‘3년 보관’이라는 문장만으로는 시스템을 구현할 수 없습니다. 생성 시각인지, 업무가 완료된 시각인지, 계약이 끝난 시각인지 보관 기간의 시작점을 정해야 합니다. 파일과 문서에 다른 기간이 필요한지, 고객사가 정책을 바꾸면 이미 생성된 데이터에도 소급 적용할지 확인합니다. 법률이나 계약상 예외가 있다면 제품팀 혼자 판단하지 않고 해당 책임자와 합의해야 합니다. 시스템은 합의된 정책의 버전과 적용 범위를 정확히 실행하는 역할을 맡습니다.
정책 모델에는 테넌트 ID, 데이터 종류, 기준 이벤트, 활성 조회 기간, 아카이브 기간, 삭제 가능 시점, 예외 보류 상태, 정책 버전을 넣을 수 있습니다. 모든 고객사의 설정을 코드의 if 문으로 나누면 변경과 감사가 어렵습니다. 반면 자유로운 규칙 언어를 그대로 관리자에게 열어 주면 예측하지 못한 삭제가 발생할 수 있습니다. 허용된 정책 조합을 명시하고 미리보기로 영향을 받는 데이터의 종류와 건수를 보여주는 방식이 안전합니다.
아카이브는 단순한 이동이 아니다
오래된 데이터를 저비용 저장소로 옮기면 운영 DB의 부담은 줄어듭니다. 그러나 고객이 다시 찾아야 할 때 몇 분 또는 몇 시간이 걸리는지, 검색에서 계속 보이는지, 복원 후 권한이 그대로 적용되는지를 정의해야 합니다. 아카이브 상태를 일반 목록에서 숨기되 ‘기록은 존재하며 복원 요청 가능’이라고 보여줄 수도 있습니다. 조회 API가 이전 경로로 파일을 열다가 오류를 내는 상황은 피해야 합니다. 데이터 이동과 애플리케이션의 상태 표현을 함께 바꿔야 합니다.
아카이브 배치가 중간에 실패해도 일부 파일만 이동하고 DB는 그대로인 상태를 발견할 수 있어야 합니다. 원본과 대상의 개수만 비교하기보다 각 객체의 식별자와 무결성 값을 검증합니다. 성공이 확인된 뒤에만 원본 삭제를 진행하고, 단계별 실행 ID를 기록합니다. 작업을 다시 실행해도 중복 복사나 조기 삭제가 일어나지 않는 멱등성도 필요합니다.
삭제는 여러 저장소의 합의다
활성 DB에서 지운 데이터가 검색 결과나 분석 데이터에 남으면 사용자는 삭제가 끝났다고 생각하지만 시스템은 그렇지 않습니다. 데이터 종류별로 원본 DB, 객체 저장소, 검색 색인, 이벤트 스트림, 데이터 웨어하우스, 캐시, 임시 내보내기 파일을 목록화하세요. 각 저장소에 삭제 이벤트를 전달하고 완료 여부를 추적합니다. 일부 저장소가 실패했다면 재시도와 운영자 확인이 가능해야 합니다. 복구용 백업의 처리 방식은 즉시 삭제 가능한 저장소와 다를 수 있으므로 별도 정책과 복원 시 재삭제 절차를 문서화해야 합니다.
삭제 요청은 되돌리기 어려운 작업입니다. 테넌트 전체 삭제처럼 영향이 큰 경우에는 요청자와 승인자를 분리하고, 대상 건수와 대표 샘플을 미리 보여주세요. 법적 보존 또는 분쟁 대응으로 삭제를 잠시 보류해야 하는 데이터가 있다면 예외 사유와 해제 권한을 별도로 관리합니다. 이런 예외를 개발자가 DB에서 임의로 바꾸게 해서는 안 됩니다.
운영 검증과 고객 설명
정책별 테스트 테넌트를 만들어 만료 경계 전후, 계약 변경, 테넌트 이전, 파일 누락, 색인 지연을 시험하세요. 운영 지표에는 예정 대상, 성공, 보류, 실패, 재시도 건수를 테넌트별로 분리해 표시합니다. 삭제 완료 증빙에는 내용 자체를 다시 남기지 않고 실행 ID, 대상 범위, 시각, 결과와 예외만 기록하는 편이 낫습니다. 고객에게는 ‘언제 안 보이는가’와 ‘언제 실제 삭제되는가’를 구분해 안내해야 신뢰를 얻습니다.
Microsoft의 멀티테넌트 스토리지 가이드는 고객사마다 서로 다른 보존 정책이 필요할 수 있고 수명주기 규칙을 설계할 때 제약을 고려해야 한다고 설명합니다. 특정 클라우드 기능이 정책 설계를 대신해 주지는 않습니다. 고객사별 요구를 명확한 상태 전이와 검증 가능한 실행으로 바꾸는 것이 핵심입니다.
