SaaS 서비스를 오래 운영하다 보면 고객이 요금제를 변경하거나 다른 시스템으로 옮기는 날도 옵니다. 이때 종료 경험이 좋지 않으면 계약 기간 동안 쌓은 신뢰가 마지막 한 번에 무너질 수 있습니다. “데이터를 CSV로 보내 드렸습니다”는 충분한 답이 아닙니다. 첨부 파일이 빠졌는지, 각 행의 관계를 새 시스템에서 재구성할 수 있는지, 누가 언제까지 기존 계정에 접근할 수 있는지가 모두 중요합니다. 오프보딩은 삭제 버튼이 아니라 통제된 이관 프로젝트입니다.
첫 단계는 데이터 범위의 합의다
고객 테넌트에 속한 데이터를 목록으로 만듭니다. 업무 레코드와 댓글, 첨부 파일, 워크플로 상태, 사용자·조직 정보, API 연동 설정, 감사 이력처럼 저장소가 흩어져 있을 수 있습니다. 전부 내보낼 수 있는지와 어떤 정보가 제외되는지를 미리 설명해야 합니다. 예를 들어 비밀번호 해시나 내부 보안 탐지 기록은 일반적인 이관 패키지에 넣지 않을 수 있습니다. 반면 파일의 식별자와 원래 레코드 사이의 참조 관계가 빠지면 고객은 파일을 받을 수 있어도 활용하지 못합니다.
내보내기 형식은 기계가 읽을 수 있고 버전이 명확해야 합니다. 테이블별 CSV 또는 JSON 파일만 던져 주기보다 스키마 설명, 인코딩 UTF-8, 시간대 기준, 열거값 의미, 관계 키, 파일 체크섬, 생성 시각을 담은 매니페스트를 함께 제공하세요. 대량 데이터는 여러 조각으로 나누되 누락 여부를 확인할 수 있는 레코드 수를 적습니다. 민감한 데이터가 포함되면 암호화된 전달 경로와 별도 비밀번호 전달 절차가 필요합니다.
이관이 끝났다는 판단은 누가 하는가
서버에서 아카이브 생성이 성공해도 고객이 파일을 온전히 받았다는 뜻은 아닙니다. 다운로드 링크의 만료일과 재발급 절차를 정하고, 고객이 체크섬과 샘플 데이터를 확인할 시간을 둡니다. “내보내기 생성”, “고객 전달”, “수신 확인”, “내용 검증”은 별개 상태여야 합니다. 특히 기존 시스템을 즉시 종료해야 하는 프로젝트라면 새 시스템에서 핵심 업무 한두 건을 복원해 보는 리허설을 권합니다. 운영 중 변경이 계속되면 기준 시점 이후 증분 데이터의 처리 방법도 정해야 합니다.
이관을 위해 임시로 넓힌 권한도 회수 대상입니다. 고객 관리자, 지원팀의 임시 접근, 서비스 계정, API 토큰, 웹훅, SSO 연결을 목록화하고 비활성화 순서를 정합니다. 먼저 계정을 막아 버리면 검증이 불가능하고, 너무 오래 열어 두면 종료 후 접근 위험이 남습니다. 따라서 검증 기한과 최종 차단 시각을 고객과 합의하고 자동으로 만료되게 하는 편이 안전합니다.
보존과 삭제는 계약·정책에 맞춰 증명한다
운영 데이터, 백업, 로그, 분석 저장소는 보존 주기가 다를 수 있습니다. “즉시 삭제”라고 말하면서 백업에는 남아 있다면 설명이 불완전합니다. 계약과 적용되는 요구사항을 확인해 보존 범위와 기한, 복구 가능한 상태인지, 만료 후 처리 방법을 고객에게 명시하세요. 고객별 분리 저장소는 제거 대상이 비교적 명확하지만 공유 저장소라면 테넌트 키가 붙은 레코드와 파생 데이터를 추적해야 합니다. 삭제 작업은 승인, 실행, 검증, 증적 보관을 분리하면 실수를 줄일 수 있습니다.
AWS SaaS Lens도 테넌트 오프보딩 계획에서 보관 또는 삭제 전 데이터를 보존할 필요와 서비스 계약에 절차를 설명할 것을 강조합니다. 이는 특정 기간을 일률적으로 정해 준다는 의미는 아닙니다. 각 서비스의 계약과 데이터 성격을 따져 결정해야 합니다.
제품 기능으로 만들어 두면 운영이 쉬워진다
수동 SQL과 임시 스크립트만으로 매번 처리하면 누락과 개인정보 노출 위험이 커집니다. 고객 관리자에게 내보내기 요청과 진행 상태, 만료된 링크 재발급, 검증 기록을 제공하고 운영자에게는 승인·차단·삭제 체크리스트를 제공할 수 있습니다. 시작은 거창할 필요가 없습니다. 테넌트 데이터 목록과 표준 내보내기 샘플을 만들고, 분기마다 가상의 고객 한 곳을 실제로 내보내어 복원해 보세요. 떠나는 고객에게도 데이터를 명확히 돌려줄 수 있는 서비스가 남아 있는 고객에게도 더 신뢰받습니다.
