서비스의 심장을 옮기는 대수술, QA 데이터 마이그레이션 테스트

우리 회사가 10년 넘게 사용해온 낡은 시스템을 버리고, 최신 기술의 ‘차세대 시스템’을 도입하기로 결정했습니다.

이때 가장 중요하고 위험한 작업은, 기존 시스템에 수십 년간 쌓여있는 수억 건의 고객과 거래 데이터를 새로운 시스템으로 단 하나의 오류도 없이 안전하게 옮기는 일입니다.

이 과정을 ‘데이터 마이그레이션(데이터 이관)’이라고 부릅니다.

이번 글에서는 이 대수술과도 같은 프로젝트의 성공을 보증하는 QA의 역할에 대해 알아보겠습니다.이 글에서 다루는 것

  • 데이터 마이그레이션의 위험성
  • 테스트의 3단계: 사전, 본, 사후 마이그레이션
  • 핵심 데이터 검증 방법
  • QA를 위한 실무 꿀팁

왜 ‘데이터 마이그레이션’이 그렇게 위험한가요?

단 하나의 데이터라도 유실되거나, 잘못 변환되면 심각한 금융 사고로 이어질 수 있기 때문입니다.

  • 주요 리스크:
    • 데이터 유실 (Data Loss):
      • 일부 고객의 정보나 거래 내역이 통째로 사라지는 최악의 상황이 발생할 수 있습니다.
    • 데이터 변환 오류 (Data Corruption):
      • 데이터가 옮겨지는 과정에서 깨지거나, 잘못된 값으로 변환될 수 있습니다.
      • 예: 고객 등급 ‘VIP’가 ‘일반’으로 바뀌거나, 계좌 잔액의 소수점이 잘못 찍히는 경우
    • 긴 서비스 중단 시간 (Downtime):
      • 마이그레이션 작업이 예상보다 길어져, 서비스 전체가 몇 시간, 심지어는 며칠 동안 멈출 수 있습니다.

QA는 ‘데이터 마이그레이션’을 어떻게 테스트하나요?

‘데이터 마이그레이션 테스트’는 크게 세 단계로 나뉩니다.

  • 1. 사전 마이그레이션 테스트 (Pre-Migration):
    • 실제 이관 작업을 시작하기 ‘전’에 수행합니다.
    • 원본(Source) 데이터와 목표(Target) 데이터의 스키마(구조)를 비교 분석하여, 데이터 타입이나 길이가 맞지 않는 부분이 없는지 확인합니다.
    • 원본 데이터에 존재하는 문제점(중복 데이터, 깨진 데이터 등)을 미리 파악하고, 이를 어떻게 처리할지 정제(Cleansing) 계획을 수립합니다.
    • 데이터를 옮기는 데 사용될 스크립트(ETL)에 대한 코드 리뷰를 수행하여 논리적 오류를 찾아냅니다.
  • 2. 본 마이그레이션 테스트 (Migration):
    • 실제 이관 작업을 테스트 환경에서 수행하면서, 또는 수행 직후에 검증합니다.
    • 가장 중요한 단계로, 데이터가 정확히 옮겨졌는지 검증합니다.
    • 전체 데이터 이관에 걸리는 시간을 측정하여, 실제 작업 시 서비스 중단 시간을 정확하게 예측합니다.
  • 3. 사후 마이그레이션 테스트 (Post-Migration):
    • 데이터 이관이 완료된 ‘후’, 새로운 시스템에서 테스트를 수행합니다.
    • 옮겨진 데이터를 가지고, 새로운 시스템의 모든 기능(조회, 수정, 삭제 등)이 정상적으로 동작하는지 전체 회귀 테스트를 수행합니다.

핵심 데이터 검증은 어떻게 하나요?

QA는 SQL과 자동화 스크립트를 사용하여, 원본(구 시스템)과 대상(신 시스템)의 데이터를 직접 비교 검증해야 합니다.

  • 주요 검증 방법:
    • 건수 검증 (Row Count Validation):
      • 원본 테이블의 총 row 수와, 대상 테이블의 총 row 수가 100% 일치하는지 확인합니다. (SELECT COUNT(*) 활용)
    • 데이터 형식 및 스키마 검증 (Schema Validation):
      • 대상 테이블의 컬럼명, 데이터 타입, 길이 등이 설계된 대로 정확히 생성되었는지 확인합니다.
    • 필드 데이터 검증 (Field Data Validation):
      • 두 시스템의 데이터를 무작위로 샘플링하여, 각 필드의 값이 1:1로 정확하게 일치하는지 비교합니다.
      • 특히, 금액이나 잔액과 관련된 숫자 필드는 합계(SUM)를 비교하여 전체 정합성을 반드시 검증해야 합니다.

현직자만 아는 ‘데이터 이관’ 꿀팁

꿀팁 1: ‘되돌릴 수 있는가’를 가장 먼저 확인하라 (롤백 테스트)

만약 마이그레이션이 실패했을 때, 아무 일도 없었던 것처럼 이전 시스템으로 안전하게 되돌아갈 수 있는지(롤백)에 대한 시나리오를 가장 먼저, 그리고 가장 철저하게 테스트해야 합니다. 롤백 계획이 없는 마이그레이션은 재앙으로 이어질 수 있습니다.

꿀팁 2: 리허설, 리허설, 또 리허설

실제 마이그레이션은 단 한 번의 기회밖에 없습니다. QA는 실제 운영 데이터의 복사본을 가지고, 실제 작업과 100% 동일한 과정의 ‘리허설’을 최소 2~3회 이상 반복해야 합니다. 이 리허설을 통해 예상치 못한 문제점을 발견하고, 실제 작업 시간을 정확하게 예측할 수 있습니다.

결론: 서비스의 역사를 안전하게 이식하는 역할

‘데이터 마이그레이션 테스트’는 서비스의 과거를 새로운 미래로 안전하게 옮기는, 매우 막중한 책임이 따르는 품질 활동입니다.

QA는 탐정처럼 데이터의 모든 흔적을 추적하고, 외과의사처럼 정밀하게 데이터를 비교 검증해야 합니다.

성공적인 ‘데이터 이관’은 사용자가 어제와 똑같이, 하지만 더 좋은 시스템에서 자신의 소중한 데이터를 안전하게 만날 수 있다는 신뢰를 주는 과정입니다.

부록: 데이터 마이그레이션 테스트 미니 체크리스트 ✅

  • 마이그레이션 전후의 테이블별 총 row 수가 100% 일치하는가?
  • 숫자(금액, 잔액) 타입 필드의 총 합계(SUM)가 100% 일치하는가?
  • 날짜, 시간, 타임존 데이터가 변환 과정에서 유실되거나 변경되지 않았는가?
  • 개인정보 등 민감 데이터는 마스킹 또는 암호화되어 이관되었는가?
  • 마이그레이션 실패 시, 롤백 절차는 정상적으로 동작하는가?

참고 자료 (References)

  • AWS Database Migration Service (DMS) (클라우드 데이터베이스 마이그레이션 서비스 공식 문서)
  • Google Cloud – Database Migration (클라우드 데이터베이스 마이그레이션 서비스 공식 문서)

댓글 남기기