서비스 데이터 이전, 검수와 전환 기준 정하기

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 서비스 데이터 이전은 파일 복사 이후의 검수와 서비스 전환까지 포함합니다.

• 담당자는 데이터 개수뿐 아니라 값과 연결 관계도 확인해야 합니다.

• 전환 계획에는 새로 들어오는 데이터와 복구 결정 기준이 필요합니다.

서비스를 리뉴얼하거나 개발사를 바꿀 때 기존 회원과 주문 데이터를 어떻게 옮길지 고민하게 됩니다. 새 화면이 완성되어도 예전 기록을 제대로 불러오지 못하면 운영을 이어가기 어렵습니다. 개발 견적에 데이터 이전이 한 줄로만 적혀 있다면 어떤 작업까지 포함하는지부터 살펴보세요.

이전 범위에는 옮길 데이터와 변환 규칙, 결과 검수, 서비스 전환 및 복구 계획이 함께 들어가야 합니다. 오늘은 서비스 데이터 이전을 맡길 때 발주 담당자와 개발사가 어떤 기준을 정해야 하는지 알아보겠습니다.

1. 옮길 데이터의 범위를 정해야 합니다

먼저 기존 시스템의 정보를 이전 대상 목록으로 정리합니다. 회원과 주문처럼 데이터베이스에 있는 기록 외에도 첨부 파일, 상품 이미지, 외부 서비스에 저장한 식별자가 있는지 살펴봅니다. 새 서비스에서 계속 보여줄 기록과 따로 보관할 기록을 나누면, 옮기지 않기로 한 데이터를 누락으로 오해하는 일도 줄어듭니다.

기존 항목과 새 항목의 대응 관계도 필요합니다. 예전에는 하나였던 주소를 새 시스템에서는 여러 칸으로 나눌 수 있고, 사용하던 주문 상태 이름이 달라질 수도 있습니다. 필드 이름이 같아도 값의 뜻과 형식이 같은지 확인해야 합니다. 개발사가 임의로 빈칸을 채우거나 상태를 바꾸지 않도록 변환 규칙을 함께 검토합니다.

예외 값의 처리 방법을 정해야 합니다

중복된 회원, 읽을 수 없는 파일, 필수값이 빠진 기록은 예외 목록으로 남깁니다. 모두 새 시스템에 넣을지, 별도 확인 후 옮길지, 제외할지 담당자가 결정할 수 있어야 합니다. 정상 데이터만 골라 시험했다면 이런 예외를 실제 이전 당일에 처음 마주칠 수 있습니다.

범위 확인에는 아래처럼 이전 대응표를 사용할 수 있습니다. 예외 처리 기준을 정하지 못한 칸은 비워 둔 채 완료로 넘기지 않고, 누가 언제 판단할지도 함께 남겨 둡니다.

2. 개수와 실제 사용 결과를 검수해야 합니다

이전 완료 메시지는 작업이 끝났다는 표시이지, 데이터 일치를 모두 확인했다는 뜻은 아닙니다. 이전 대상으로 정한 데이터의 개수를 확인한 뒤 금액·날짜·상태 같은 주요 값도 대조합니다. 제외하기로 한 항목이 있다면 개수가 달라지는 이유와 목록을 함께 남겨야 검수 결과를 이해할 수 있습니다.

데이터 사이의 연결 관계도 별도로 살펴봅니다. 주문이 엉뚱한 회원에게 연결되거나 첨부 파일 주소만 있고 실제 파일을 열 수 없다면, 전체 개수가 같아도 서비스를 정상적으로 쓸 수 없습니다. 새 화면에서 기존 내역을 조회하고 필요한 업무를 이어가는 점검이 필요한 이유입니다.

자동 비교와 화면 검수를 나눠야 합니다

반복 대조는 도구로 처리하되 도구가 확인하는 범위를 알아야 합니다. AWS DMS의 데이터 검증은 원본과 대상의 대응 행을 비교해 불일치를 보고하는 방식이며, 검증 쿼리에는 추가 자원이 듭니다. 비교 방법과 지원 조건을 살펴보고 싶다면 AWS DMS 데이터 검증 문서를 참고해 보세요.

개발사는 자동 검증 결과를 정리하고, 현업 담당자는 업무 화면의 동작을 확인하는 식으로 역할을 나눌 수 있습니다. 전체 비교가 가능한 항목과 대표 기록을 골라 확인할 항목도 구분합니다. 표본에서 문제가 없었다는 결과를 전체 데이터가 동일하다는 결론으로 바꾸지 않는 것이 중요합니다.

예를 들어 회원과 주문을 함께 옮긴다고 가정해 보겠습니다. 회원 수와 주문 수가 맞더라도, 기존 회원이 로그인한 뒤 자기 주문을 찾고 상세 내용을 열 수 있는지까지 확인해야 합니다. 데이터 대조와 실제 업무 검수를 연결하는 예시입니다.

3. 전환과 복구 조건을 함께 정해야 합니다

시험 이전과 실제 전환 사이에도 기존 서비스에는 새 데이터가 쌓일 수 있습니다. 이전 도중 주문이나 수정 요청을 계속 받을지, 일정 시간 쓰기를 멈출지 개발사와 합의합니다. 계속 받는다면 시험 이후의 변경분을 마지막에 어떻게 반영할지도 필요합니다. 점검 시간 안내 역시 이 방식에 맞춰 정하게 됩니다.

실제 전환 전에는 리허설로 작업 순서와 소요 시간을 확인합니다. 개발 작업이 끝나는 시간만 보지 말고 최종 데이터 반영과 검수, 서비스 재개까지 포함해 측정합니다. 확인이 오래 걸리는 항목은 미리 준비하고 현업 담당자가 참여할 점검 시간도 일정에 넣어 둡니다.

되돌릴 시점과 데이터를 정해야 합니다

복구 계획에는 결정 기준과 담당자가 필요합니다. 어떤 문제가 생기면 전환을 중단할지, 수정해서 계속 진행할지 누가 판단하는지 정해 둡니다. 새 서비스가 이미 주문을 받았다면 예전 시스템으로 연결만 되돌려서는 새 주문이 따라오지 않습니다. 전환 뒤에 바뀐 데이터까지 처리하는 방법은 AWS의 전환·롤백 지침에서 구체적으로 살펴보실 수 있습니다.

검수 결과를 전달받을 때는 미해결 항목도 함께 요청하세요. 완료된 작업과 남은 문제를 구분해야 운영을 시작할 수 있는지 판단할 수 있습니다. 이전 파일을 전달받는 것과 새 서비스의 운영을 재개하는 시점을 별도로 정하는 이유도 여기에 있습니다.

• 마지막 변경분까지 반영했는지 확인할 방법이 있나요?

• 전환을 멈추거나 되돌릴 기준과 담당자가 정해졌나요?

• 새 서비스에서 생긴 데이터는 복구 시 어떻게 처리하나요?

기존 운영과 새 서비스를 함께 살펴야 합니다

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 프로덕트를 기획·디자인·개발·운영해 온 경험을 바탕으로 기존 시스템과 새 서비스의 연결을 함께 검토합니다. 리뉴얼을 준비할 때도 새 화면의 기능과 기존 운영 업무를 함께 살펴 이전 범위를 정할 수 있습니다.

기존 서비스를 바꾸면서 데이터를 어디까지 옮겨야 할지 고민되시나요? 아래 똑똑한개발자 링크로 문의해 주시면 이전 대상과 검수·전환 범위를 함께 정리해 보겠습니다.

감사합니다. :)

📚 이어서 읽어보세요

• 홈페이지 리뉴얼, 기존 주소도 연결해야 합니다

• 서비스 운영 로그, 고객 문의를 추적하는 방법