SI 데이터 마이그레이션, 범위와 검증 기준을 정하는 4단계

“기존 데이터가 많아서 무엇부터 옮겨야 할지 모르겠습니다.”

“건수만 같으면 이관이 잘된 것으로 봐도 될까요?”

“전환 당일 문제가 생기면 어디까지 되돌려야 하는지 정하지 못했습니다.”

데이터 마이그레이션의 핵심은 가능한 모든 데이터를 새 시스템으로 복사하는 일이 아닙니다. 새 시스템에서 계속 수행할 핵심 업무를 기준으로 이관 범위와 검증 합격선을 함께 정하는 일입니다.

화면과 메뉴 범위가 정리됐다고 전환 준비까지 끝난 것은 아닙니다. 같은 고객 정보라도 중복됐을 수 있고, 이미 종료된 이력일 수 있으며, 특정 담당자만 참고하는 기록일 수도 있습니다. 이 구분 없이 전량 이관을 결정하면 개발 범위와 검증 시간, 전환 후 운영 부담이 함께 커집니다.

저는 개발자로 시작해 13년 이상 개발과 프로젝트 관리를 맡았고, 크로플을 운영하며 50건 이상의 SI 수탁개발을 수행했습니다. 프로젝트 초기에는 화면 요구와 함께 데이터가 어떤 업무 결정에 쓰이는지, 누가 수정하는지, 언제까지 보존해야 하는지를 확인합니다. 그 판단을 범위표, 매핑표, 테스트 시나리오, 전환 실행표로 이어야 전환 당일에도 같은 기준으로 결정할 수 있습니다.

마이그레이션 범위는 테이블 목록보다 업무 상태로 정해야 할까요?

네. 이관 여부는 데이터의 존재 여부가 아니라 새 시스템의 업무, 운영 책임, 보존 목적에 계속 필요한지로 결정해야 합니다. 테이블이나 엑셀 시트 목록은 출발점일 뿐, 범위 확정 기준이 되지는 않습니다.

예를 들어 종료된 주문 이력, 중복 등록된 회원, 더 이상 쓰지 않는 코드값, 내용이 없는 메모는 같은 방식으로 옮길 대상이 아닙니다. 새 시스템에서 조회만 필요하다면 운영 데이터와 분리해 조회 이력으로 제공하는 방안도 검토할 수 있습니다. 반대로 진행 중인 계약, 미결 처리 건, 권한과 연결된 계정 정보는 누락될 경우 업무를 멈출 수 있으므로 우선순위가 높습니다.

한 실무 자료는 마이그레이션 계획에 이관 대상과 제외 항목, 소스와 대상의 필드, 형식, 관계 매핑, 변환 방법, 성공 기준과 검증 절차를 포함하는 방식을 제시합니다.

범위 회의에서는 데이터마다 다음 네 가지 질문에 답을 남겨두는 편이 좋습니다.

1. 새 시스템에서 이 데이터를 생성, 수정, 조회, 집계 중 어디에 쓰는가?
2. 현재 업무가 진행 중인가, 종료됐는가, 단순 참고 이력인가?
3. 새 구조에 맞춰 값의 형식이나 코드 체계를 바꿔야 하는가?
4. 이관하지 않는다면 누가 어떤 방식으로 과거 기록을 확인하는가?

다음 표는 범위 논의에 사용할 수 있는 판단 예시입니다. 실제 이관 여부는 각 조직의 업무 정책과 보관 요구사항을 확인해 확정해야 합니다.

“일단 다 옮기자”는 범위 결정을 뒤로 미루는 표현이 되기 쉽습니다. 전량 이관이 필요하더라도 오래된 데이터의 품질, 조회 방식, 보관 책임, 정제 책임은 별도로 정해야 합니다.

필드 매핑 문서에는 무엇을 남겨야 할까요?

필드 매핑 문서는 기존 컬럼명과 새 컬럼명을 나열하는 표가 아니라, 값의 출처와 변환 규칙, 예외 처리 책임을 담은 실행 문서여야 합니다. 이름이 비슷하다는 이유만으로 같은 의미라고 보면 전환 뒤에야 오류를 발견할 수 있습니다.

레거시의 상태 값 하나가 새 시스템에서는 주문 상태, 결제 상태, 배송 상태로 분리될 수 있습니다. 반대로 여러 화면에 흩어진 연락처가 새 시스템에서는 하나의 고객 기준 정보로 통합될 수도 있습니다. 이때 개발팀만 규칙을 정하면 실제 업무 정의와 어긋날 수 있으므로, 해당 값을 가장 잘 아는 현업 담당자가 판정에 참여해야 합니다.

프로젝트를 설계할 때 저는 단일 진실 공급원 원칙을 중요하게 봅니다. 같은 정보를 여러 화면과 기능에서 따로 관리하면 이관 시점에도 어느 값을 기준으로 삼을지 흔들립니다. 새 시스템의 기준 데이터를 먼저 정하고, 나머지 데이터가 그 기준에 어떻게 연결되는지 설계해야 이후 수정과 검증도 같은 기준으로 진행할 수 있습니다.

필드 매핑표에는 적어도 다음 항목을 넣는 편이 좋습니다.

• 원본 시스템과 대상 시스템의 데이터 위치
• 각 필드의 업무상 의미와 입력 주체
• 값 변환 규칙과 코드 매핑표
• 비어 있는 값, 중복 값, 형식 오류의 처리 방식
• 변환 후 기본값을 넣는 조건
• 확인 담당자와 최종 승인자

특히 “모름”도 처리 규칙으로 남겨야 합니다. 판단이 필요한 값을 임의로 채울지, 제외할지, 현업 확인 대기 목록으로 보낼지를 정하지 않으면 테스트 결과가 나와도 합격 여부를 판단하기 어렵습니다.

데이터 검증은 건수 비교만으로 충분할까요?

아닙니다. 건수 비교는 첫 관문일 뿐이며, 업무에 필요한 값이 맞게 옮겨졌는지와 데이터 간 연결 관계가 유지됐는지까지 확인해야 합니다. 코드 변환, 상태 분리, 고객과 거래의 연결처럼 구조가 바뀌는 영역은 단순 건수만으로 오류를 찾기 어렵습니다.

마이그레이션 검증에서는 레코드 수와 필드 상세 비교로 완전성을 확인하고, 값과 형식, 유형, 길이 검사로 정확성과 호환성을 확인할 수 있습니다. 시스템 간 형식 일치와 동기화 상태는 일관성 관점에서, 기본 키와 외래 키, 테이블 간 연결은 참조 무결성 관점에서 점검할 수 있습니다.

검수 기준은 “데이터가 들어갔다”가 아니라 “특정 업무를 새 시스템에서 끝까지 처리할 수 있다”는 문장으로 쓰는 편이 더 유용합니다. 예를 들어 고객 수의 일치만 확인하는 대신, 권한이 있는 사용자가 고객을 조회하고 연결된 진행 건을 확인한 뒤 후속 업무를 처리할 수 있는지 점검합니다.

표본 검증도 임의 추출만으로 끝내지 않는 편이 좋습니다. 상태가 복잡한 건, 금액이나 수량이 큰 건, 오래된 이력, 예외 코드가 있는 건처럼 오류 발생 시 영향이 큰 구간을 별도 표본으로 잡아야 합니다. 이는 모든 프로젝트에 동일하게 적용하는 규칙이 아니라, 업무 중단의 영향이 큰 데이터를 먼저 확인하기 위한 실무상 우선순위입니다.

전환 당일에는 어떤 기준으로 진행 또는 되돌림을 결정해야 할까요?

전환 당일의 핵심은 문제가 전혀 없게 만드는 데 있지 않고, 누가 어떤 기준으로 진행 중단과 되돌림을 결정할지 미리 합의하는 데 있습니다. 테스트를 통과했더라도 운영 전환에서는 입력 중지 시점, 최종 추출, 사용자 공지, 권한 전환이 맞물립니다.

실무 자료에서는 전환 준비에 사전 백업, 통제된 테스트 환경에서의 전체 시험 운행, 롤백 절차와 검증 시나리오를 포함하고, 이관 중 로그와 모니터링, 오류 알림을 운영하며, 이관 후에는 데이터, 기능, 성능을 검증하는 방식을 제시합니다.

다만 이 자료는 최종 추출 순서나 업무 재개 승인 기준, 중단 조건을 구체적으로 제시하지 않습니다. 따라서 아래 항목은 프로젝트의 핵심 업무와 운영 인력 구조에 맞춰 발주사와 수행사가 전환 전에 합의해야 합니다.

1. 입력 중지 시각: 레거시 시스템에 새 데이터가 더 들어오지 않게 하는 시점을 정합니다.
2. 최종 데이터 추출 기준: 어느 시각의 데이터까지 가져오는지와 추출 담당자를 확정합니다.
3. 전환 검증 순서: 계정, 기준 정보, 진행 중 업무, 핵심 조회와 등록 기능 순으로 확인합니다.
4. 진행 중단 기준: 핵심 업무를 처리할 수 없거나 데이터 연결 오류가 확인됐을 때의 중단 조건을 정합니다.
5. 되돌림 책임자: 되돌림을 선언할 사람, 원본 시스템 재개 방법, 사용자 공지 담당을 지정합니다.

되돌림 기준은 “문제가 크면”처럼 쓰기보다 업무 영향으로 써야 합니다. 예를 들어 핵심 담당자가 진행 중인 업무를 조회할 수 없는 경우는 중단 판단의 기준이 될 수 있습니다. 반대로 조회 전용 이력의 일부 표시 오류는 즉시 업무를 멈출 사유인지, 이슈로 기록해 우선순위를 조정할 사안인지 구분할 수 있습니다. 이 판단을 위해서는 전환 전부터 핵심 업무와 허용 가능한 임시 대응 범위를 합의해야 합니다.

결론

마이그레이션의 합격 기준은 옮긴 데이터의 양이 아니라, 새 시스템에서 중요한 업무를 신뢰할 수 있게 이어 갈 수 있는지입니다. 범위, 매핑, 검증, 전환 결정을 각각 다른 문서로 흩어두지 말고 하나의 판단 흐름으로 연결해야 합니다.

착수 전에 모든 예외를 없앨 수는 없습니다. 대신 진행 중 업무 데이터와 조회 전용 이력, 정제 대상과 제외 대상을 구분하고, 확인이 필요한 값을 이슈 목록으로 관리하면 전환 시점의 불확실성을 줄일 수 있습니다.

임원은 “얼마나 많이 옮기는가”보다 “무엇이 누락되면 업무가 멈추는가”를 물어야 합니다. PM은 그 답을 일정표에만 두지 말고 필드 매핑표, 테스트 시나리오, 전환 실행표에 남겨야 합니다. 새 시스템에서 계속 수행할 핵심 업무를 기준으로 이관 범위와 검증 합격선을 함께 정하세요.

자주 묻는 질문

데이터 정제는 개발사가 맡아야 하나요?

변환 로직 구현은 개발사가 맡을 수 있지만, 어떤 값이 맞는지에 대한 업무 판단은 현업 책임자가 맡아야 합니다. 중복 고객 판정, 폐기 대상 결정, 코드의 실제 의미처럼 업무 맥락이 필요한 기준은 발주사 담당자가 승인할 수 있게 역할을 나누는 편이 좋습니다.

테스트 이관은 몇 번 해야 하나요?

정해진 횟수보다 중요한 것은 주요 오류가 발견될 때마다 규칙과 검증 기준을 고치고 다시 확인하는 일입니다. 데이터 구조가 복잡하거나 정제 대상이 많다면 한 번의 테스트 결과만으로 전환 여부를 결정하지 않는 편이 좋습니다.

원본 시스템을 계속 열어두면 새 시스템 전환이 쉬워지지 않나요?

조회 목적으로 일시 운영할 수는 있지만, 두 시스템에 같은 업무 데이터를 동시에 입력하면 기준 데이터가 다시 갈라질 수 있습니다. 병행 운영이 필요하다면 어느 시스템을 입력 기준으로 삼을지와 운영 기간을 명확히 정해야 합니다.

과거 데이터를 모두 이관하지 않아도 되나요?

새 시스템에서 직접 사용할 필요가 없는 이력은 별도 보관이나 원본 조회 방식도 검토할 수 있습니다. 다만 보관 목적, 접근 권한, 원본 시스템 종료 일정은 범위 결정 전에 조직의 관련 담당자와 확인해야 합니다.

제 도움이 필요하시다면

데이터 이관은 개발 막바지의 부가 작업이 아니라, 요구사항과 데이터 모델을 정할 때부터 함께 설계해야 할 범위입니다. 크로플은 웹, 앱, 업무 시스템 수탁개발과 프로젝트 관리 경험을 바탕으로 초기 기획 단계에서 다음과 같은 정리를 도울 수 있습니다.

• 레거시 업무 흐름을 기준으로 이관 대상과 제외 대상을 나누는 요구사항 정리
• 새 시스템의 기준 데이터와 권한, 운영 화면을 연결하는 데이터 모델 검토
• 필드 매핑표, 테스트 시나리오, 전환 전 확인 항목을 구현 브리프로 구체화하는 작업

이미 개발 견적을 받았지만 데이터 이관 범위가 한 줄로만 적혀 있거나, 현업과 개발팀의 데이터 정의가 다른 상황이라면 착수 전에 문서부터 다시 점검하는 편이 좋습니다. 문의 시 현재 시스템의 업무 흐름과 전환 목표를 알려주시면 먼저 정리해야 할 판단 항목부터 살펴보겠습니다.