SaaS 교체 전 데이터 반출 계획에서 확인할 7가지

SaaS를 교체하기 전에는 현재 서비스의 모든 데이터를 한 번에 내려받을 수 있다고 가정하면 안 됩니다. 먼저 어떤 데이터를 가져갈지 목록으로 고정하고, 원본·첨부파일·권한·감사 기록의 보존 여부와 새 시스템에서 읽을 형식을 확인해야 합니다. 반출 계획의 완료 기준은 파일이 생겼다는 사실이 아니라, 다른 환경에서 복원하고 대조할 수 있다는 증거입니다.

실무에서는 계약 종료일보다 앞서 일곱 가지를 점검하면 이관 누락과 잠금 기간을 줄일 수 있습니다. 데이터 주체의 요청이나 조직의 보안 정책처럼 별도 의무가 걸린 항목은 담당자와 함께 확인하되, 이 글은 법률 자문이 아니라 운영상 이식성과 검증 가능성을 확보하는 체크리스트로 활용하세요.

1. 반출 범위를 객체 단위로 정의하기

사용자와 프로젝트만 적은 범위표는 부족합니다. 레코드 본문, 상태값, 댓글, 첨부파일, 태그, 사용자·그룹 관계, 자동화 규칙, 웹훅 설정, 감사 로그를 각각 데이터 객체로 나누고 담당자를 지정하세요. 삭제된 항목과 보관함, 휴지통도 포함 여부를 명시해야 합니다. 화면에서 보이는 목록과 API로 조회되는 전체 집합이 다를 수 있으므로 목록 수를 API 응답의 총량과 비교하는 절차를 둡니다.

2. 내보내기 형식과 원본성을 확인하기

CSV 하나로 모든 관계를 표현할 수 있는지 먼저 시험합니다. 날짜와 시간대, 식별자, 줄바꿈, 다중 선택값, 빈 값의 표현 규칙이 문서에 없으면 재수입 때 의미가 바뀝니다. 구조화 데이터는 JSON이나 표준 내보내기 형식을 우선하고, 첨부파일은 파일명 충돌 규칙과 메타데이터 매핑을 함께 받습니다. 제공자가 변환한 값인지 원본 값인지도 필드별로 표시해야 합니다.

3. 권한과 개인정보 경계를 분리하기

반출 담당자가 모든 데이터를 볼 수 있어야 한다는 뜻은 아닙니다. 운영 데이터, 계정 식별자, 비공개 메모, 감사 로그를 분류하고 최소 권한의 전용 계정과 만료 시각을 정하세요. 추출 파일 자체의 접근 권한, 암호화, 전송 경로, 보관 기간을 기록하고 다운로드 링크를 이메일로 재전송하지 않도록 합니다. 새 시스템에서 원래 권한이 재현되지 않는다면 공개 범위를 임시로 줄이는 이관 규칙이 필요합니다.

4. 반복 추출과 변경분 전략을 세우기

서비스를 사용하는 동안 데이터는 계속 바뀝니다. 첫 전체 추출 뒤 최종 전환 직전에 변경분을 한 번 더 추출할지, 읽기 전용 잠금 시간을 둘지 결정하세요. 각 추출에는 기준 시각, 필터, API 버전, 실행자, 파일 목록을 남깁니다. 증분 추출을 지원하지 않는 서비스라면 최종 전체 추출과 전환 중 신규 입력을 임시 대장에 기록하는 대안을 준비해야 합니다.

5. 무결성과 완전성을 검증하기

압축 파일의 해시만 확인하면 내부 누락을 알 수 없습니다. 객체별 건수, 필수 필드 누락 수, 첨부파일 수와 총 용량, 관계가 끊긴 참조 수를 계산해 원본 서비스의 기준값과 대조하세요. 샘플 레코드는 원본 화면·API·반출 파일·새 시스템의 결과를 순서대로 비교하고, 불일치가 있으면 승인 상태를 보류합니다. 검증 로그에는 도구 버전과 실행 시각을 남겨 나중에 같은 결과를 재현할 수 있게 합니다.

6. 복원 리허설과 운영 인수 조건을 정하기

새 시스템에 파일을 넣는 것과 실제 업무가 이어지는 것은 다릅니다. 테스트 공간에서 대표 프로젝트와 예외적인 오래된 레코드를 복원하고, 검색·권한·첨부 열기·보고서 생성까지 업무 시나리오를 수행하세요. 담당자가 빈 화면이나 변환 오류를 발견했을 때 누구에게 재추출을 요청하는지도 정합니다. 리허설에서 허용할 누락률, 수동 보정 대상, 중단 기준을 사전에 승인받아야 일정 압박이 품질 기준을 바꾸지 못합니다.

7. 종료 후 삭제와 증거 보관을 연결하기

반출이 끝났다고 곧바로 기존 테넌트를 삭제하지 마세요. 새 시스템의 복원 검증, 사용자 승인, 백업 확인이 끝난 뒤에만 종료 절차를 시작합니다. 제공자에게 삭제 대상과 백업·로그의 처리 방식을 서면으로 확인하고, 삭제 요청·완료 응답·최종 반출 해시·승인 기록을 한 묶음으로 보관합니다. 보관해야 할 운영 증거와 더 이상 필요하지 않은 사본을 구분하는 것이 안전한 종료의 핵심입니다.

전환 승인 전에 확인할 체크리스트

• 객체별 범위표에 원본·첨부·관계·감사 기록의 포함 여부와 담당자가 적혀 있다.

• 파일 형식, 문자 인코딩, 시간대, 식별자, 변환 규칙을 새 시스템 담당자가 확인했다.

• 전체 추출과 최종 변경분의 기준 시각, 해시, 건수, 오류 로그가 보관되어 있다.

• 테스트 복원에서 검색·권한·첨부·보고서의 핵심 업무 시나리오가 통과했다.

• 기존 서비스의 삭제 요청과 백업 처리 확인을 새 시스템 승인 이후에 실행하도록 순서가 고정됐다.

이 일곱 가지를 문서와 실행 로그로 남기면 SaaS 교체는 공급자를 바꾸는 프로젝트가 아니라 데이터를 통제된 형태로 이동시키는 운영 절차가 됩니다. 반출 파일의 존재보다 재현 가능한 검증과 종료 증거를 최종 산출물로 삼으세요.