데이터 마이그레이션 전환 검증 전략

데이터 마이그레이션 검증 전략: 역공학적 접근과 체크리스트

'역공학' 기반의 데이터 전환 검증 전략: 개발자는 단순히 검증자에 머무르지 않고, 숨겨진 규칙을 파헤치는 데이터 탐정이자 시스템의 취약점을 찾아내는 품질 보증 전문가가 되어야 합니다. 안전한 데이터 이관을 위해선 AS-IS 데이터와 TO-BE 시스템을 역공학적으로 분석하여 문제가 될 부분을 선제적으로 찾아내고 조치해야 합니다.

 

목표 : 데이터 정합성 최우선

데이터 마이그레이션 검증의 궁극적인 목표는 데이터 정합성을 유지하고 데이터 유실을 방지하는 것입니다. 위의 단계별 접근법과 체크리스트를 따르면 이러한 목표에 한 걸음 다가설 수 있습니다. 발견된 문제는 적극적으로 해결 방안을 문서화하고, 이해관계자와 소통하여 정책적 결정 사항까지 끌어내세요. 철저한 검증과 커뮤니케이션을 통해 결국 모든 데이터가 빠짐없이, 그리고 정확하게 새로운 시스템으로 이관될 수 있을 것입니다.

 

1단계: AS-IS 데이터 프로파일링 (탐색 및 분석)

첫 번째 단계에서는 현재 시스템(AS-IS)의 데이터에만 집중하여 데이터 현황을 상세히 파악합니다. 이를 통해 데이터 전환 시 문제가 될 수 있는 패턴이나 이상치를 발견하는 것이 목표입니다. TO-BE 시스템은 잠시 잊고, AS-IS 데이터 자체의 전문가가 되어보세요. 마치 자신만의 데이터 사전을 만든다는 느낌으로 세세하게 살펴봅니다.

• 코드 값 분포 분석: 코드성(colum) 데이터는 어떤 값들이 얼마나 존재하는지 모두 추출합니다. 예상했던 코드 이외에 NULL이나 임시 값(99, 기타 등)이 있는지 확인하세요. 예를 들어, 처방 테이블 ORD_SLIP에서 진료과 코드 분포를 파악하는 쿼리는 다음과 같습니다:

SELECT DEPT_CD, COUNT(*)
FROM ORD_SLIP
GROUP BY DEPT_CD
ORDER BY DEPT_CD;

• 위 결과를 통해 'IM'(내과), 'GS'(외과)처럼 정상 코드를 파악하고, NULL이나 '99'처럼 예상치 못한 코드가 존재하는지 확인합니다. 이렇게 사용되지 않거나 예외적인 코드 값을 찾아내는 것이 중요합니다.
• 데이터 형식 이상치 탐색: 숫자형으로 되어 있는 컬럼에 문자 값이 섞여 있지는 않은지, 날짜 형식 컬럼에 이상한 문자열이나 형식이 들어있지는 않은지 점검합니다. 예를 들어, 환자 테이블 PATIENT의 나이 필드가 숫자가 아닌 값을 갖고 있는지 확인하는 쿼리는 다음과 같습니다:

SELECT AGE
FROM PATIENT
WHERE ISNUMERIC(AGE) = 0;  -- SQL Server 기준, 숫자가 아니면 0

• 이처럼 스키마 상으로는 숫자이지만 실제로는 문자 데이터가 들어간 경우를 찾아 정제 대상에 포함시킵니다.
• 문자열 컬럼의 길이 측정: 가변 길이 문자열(VARCHAR 등) 컬럼의 실제 최대 길이를 측정하여, TO-BE 시스템에서 해당 컬럼 길이가 충분한지 검증합니다. 예를 들어 환자 테이블의 환자명 컬럼 PAT_NM의 최대 길이를 구해보면:

SELECT MAX(LENGTH(PAT_NM))  -- Oracle의 경우 LENGTH, SQL Server의 경우 LEN
FROM PATIENT;

• 실제 데이터에서 가장 긴 값의 길이를 알아내어, TO-BE의 해당 컬럼 정의(VARCHAR2(100) 등)가 이보다 작으면 문제가 될 수 있음을 미리 발견할 수 있습니다.

2단계: 가설 기반의 공격적 테스트

AS-IS 프로파일링을 통해 의심스러운 부분을 발견했다면, 이제 그에 대한 가설을 세우고 적극적으로 검증(테스트) 해볼 차례입니다. 이 단계에서는 발견된 데이터 이슈가 실제로 전환 시 어떤 문제를 일으킬지 시뮬레이션해보고, 시스템에 공격적인 테스트를 가하는 마음가짐으로 진행합니다.

• 가설 1: "환자 성별(GENDER) 컬럼에 'M'와 'F' 이외의 값이 있으면, TO-BE 시스템의 성별 코드(예: 1=남, 2=여)로 변환 시 오류가 날 것이다."
  검증: AS-IS에서 SELECT DISTINCT GENDER FROM PATIENT;로 값 종류를 조회해봅니다. 만약 'M', 'F' 외에 'U'(Unknown)나 NULL, 공백 '' 등의 값이 나온다면, 이 데이터들이 TO-BE로 넘어갈 때 어떻게 처리될지 확인해야 합니다. 예를 들어 TO-BE에서는 성별값이 1 또는 2만 허용된다면, 'U'나 NULL은 매핑 규칙 없이 전환할 경우 에러 또는 누락이 발생합니다. 따라서 이런 값들을 사전에 어떻게 변환할지 (예: 'U'는 ‘9: 기타’로 매핑 등) 결정하고 테스트해야 합니다.
• 가설 2: "AS-IS에서 하나의 문자열로 저장된 주소(ADDR) 필드가 TO-BE에서는 우편번호, 기본주소, 상세주소 등의 여러 필드로 분리되는데, 특정 패턴의 주소는 분리 로직에서 누락되거나 잘못 분리될 것이다."
  검증: 주소 데이터 표본을 뽑아 전환 규칙을 적용해봅니다. 예를 들어 'OO시 OO구...' 형태의 일반 주소뿐 아니라 'OO도 OO군 OO면...' 같은 다른 형식의 주소도 골고루 추출합니다. 또한 신주소 vs 구주소 혼합, 주소에 동-호수 정보가 특이하게 들어간 경우 등도 테스트해야 합니다. 추출한 샘플 데이터를 가지고 주소 파싱/매핑 쿼리를 직접 실행해본 후, 분할된 결과가 의도한 대로 나오는지 일일이 확인합니다. 이 과정을 통해 전환 규칙이 모든 주소 패턴에 견고한지 검증할 수 있습니다.

개발자의 자세: 건강한 불신과 적극적인 문서화

데이터 검증을 수행하는 개발자의 마음가짐도 매우 중요합니다. 항상 "건강한 불신"을 갖고 "데이터만이 진실을 말한다"는 자세로 임해야 합니다. 다른 시스템 담당자나 문서가 "그럴 것이다"라고 말해도, 직접 눈으로 확인하기 전까지는 믿지 않는 것이 안전합니다. 모든 규칙과 가정은 실제 데이터로 입증하세요.

"아무도 믿지 마라. 데이터만이 진실을 말한다."
"내가 바로 이관 규칙의 역사가다."

위와 같은 마음가짐으로, 확인된 내용은 반드시 기록으로 남겨야 합니다. 공식 문서가 없거나 부실하다면, 지금 개발자님이 찾아낸 규칙과 결정 사항이 곧 공식 문서가 됩니다. 발견한 문제와 적용하기로 한 해결 방법 등을 이메일이나 협업 툴에 꼼꼼히 문서화하세요. 나중에 문제가 발생했을 때 이런 기록들이 가장 강력한 자신의 방어 근거가 되어 줄 것입니다.

중점 검증 항목 체크리스트

데이터 프로파일링과 테스트를 거치면서, AS-IS와 TO-BE 간에 꼭 확인해야 할 항목들을 정리하면 다음과 같습니다. 아래 체크리스트를 따라가며 전환 설계의 누락이나 오류를 점검하세요:

1. 컬럼 개수 및 명칭 비교
   • AS-IS ↔ TO-BE 테이블의 컬럼 수가 일치하는지 확인합니다. 한쪽에만 있고 누락된 컬럼은 없는지 체크하세요.
   • 컬럼 이름에 오타가 있거나 불명확한 약어를 사용해서 이름이 불일치하는 경우가 있는지 확인합니다. (예: PT_NAME vs PAT_NAME 등 스펠링 차이)
   • 주요 키(PK, FK) 컬럼이 AS-IS와 TO-BE에 모두 존재하는지도 확인해야 합니다.
2. 불필요한 컬럼 이관 방지
   • AS-IS에서 이미 쓰이지 않거나 폐기된 컬럼이 TO-BE에 그대로 생겨나지는 않았는지 확인합니다. 전환하지 않아도 될 데이터를 굳이 이관하면 혼선이 생길 수 있으므로, 필요 없는 컬럼은 제외해야 합니다.
3. 필요한 컬럼 누락 여부
   • TO-BE 설계에 AS-IS 데이터상의 중요 컬럼이 빠져있지는 않은지 확인합니다. 의료 시스템의 경우 처방코드, 진단명, 환자ID와 같이 업무상 반드시 필요한 필드들이 TO-BE에 누락되면 큰 문제가 됩니다.
   • 또한 AS-IS에 존재하던 데이터 중 TO-BE에서 사라지는 것이 없는지, 필수 데이터의 손실 여부를 검토하세요.
4. 데이터 타입 일치성 확인
   • 컬럼의 데이터 타입 변경이 있는 경우, 길이나 정밀도가 축소되지 않았는지 확인합니다. (예: VARCHAR2(10) → VARCHAR2(20)는 길이 확장이므로 OK, 반대로 VARCHAR2(20) → VARCHAR2(10)은 축소이므로 데이터 잘림 위험)
   • 타입 자체가 변경된 경우 문제 소지가 없는지 봅니다. (예: NUMBER → CHAR로 바뀐다면 숫자 데이터를 문자로 변환하는 로직이 필요한지, 또는 예상치 못한 형변환 오류가 없는지 점검)
   • 날짜 타입의 경우 AS-IS는 DATE인데 TO-BE는 TIMESTAMP로 정밀도가 늘어나거나 (혹은 반대의 경우) 포맷 차이가 있습니다. 이러한 포맷/정밀도 차이로 데이터가 잘못 저장되거나 오류가 나지 않도록 확인합니다.
5. Nullable/Not Null 제약 변경
   • AS-IS에서는 NULL을 허용하던 컬럼이 TO-BE에서 NOT NULL로 변경되었다면, 이관 대상 데이터 중 NULL 값이 존재하는지 확인해야 합니다. 만약 NULL이 있다면 전환 시 제약 조건 위배로 실패하므로, 디폴트 값을 넣는다든지 사전에 조치를 취해야 합니다.
   • 또한 TO-BE에서 새롭게 NOT NULL로 바뀐 컬럼은 디폴트 값이 정의되어 있는지도 확인합니다. 디폴트가 없으면 전환 시 해당 값을 채울 로직을 마련해야 합니다.
6. 코드값/ENUM 등의 도메인 일치 여부
   • 코드나 ENUM 값의 체계가 바뀐 경우를 점검합니다. 예를 들어 AS-IS에서 성별을 '1','2'로 저장하던 것을 TO-BE에서는 'M','F'로 바꾼다면, 코드 매핑이 필요합니다. 이러한 값 변환 규칙이 누락되었다면 전환 후 데이터가 엉뚱하게 해석될 수 있습니다.
   • 필요 시 별도의 코드 매핑 테이블이나 변환 로직이 준비되어 있는지 확인하고, 매핑이 정확히 이루어지는지 테스트합니다.
7. 인덱스, 제약조건, 트리거 등
   • 전환 대상 테이블/컬럼에 AS-IS 쪽에서 인덱스나 FK 제약, 트리거 등이 있었다면 TO-BE에도 동일하게 구현되어 있는지 확인합니다.
   • 특히 전환 시점에 필요한 제약 조건은 일시적으로 끄고 켜야 할 수도 있으므로, 어떤 제약과 트리거가 있는지 파악하여 전환 전략에 반영해야 합니다.

이상 현황 통계: (예시) 위 검증을 통해 총 25개 테이블을 점검했고, 아래와 같은 34개의 이상(colum) 항목을 발견했습니다.

• 총 검토 테이블 수: 25개
• 발견된 이상 컬럼 수: 34개
  • 데이터 타입 불일치: 12개
  • 필수 컬럼 누락: 5개
  • 불필요한 컬럼 포함: 8개
  • 도메인 값 매핑 누락: 9개

위 통계는 예시이지만, 이처럼 점검 결과를 정리해두면 전환 작업의 리스크를 한눈에 파악할 수 있습니다. 숫자로 문제를 보여주면 이해관계자들에게도 설득력이 높아집니다.

데이터 정제와 현재 검증 작업의 관계

지금 수행하고 있는 작업은 넓은 의미에서 데이터 정제(Data Cleansing)의 일부분이라고 볼 수 있습니다. 다만, 데이터 정제가 문제의 발견부터 해결까지를 모두 포함하는 개념이라면, 현재의 마이그레이션 검증 작업은 주로 문제를 발견하고 진단하는 단계에 해당합니다.

• 데이터 정제 (Data Cleansing): 데이터베이스 내 부정확하거나 불완전한 데이터를 식별하고 이를 수정 또는 삭제하여 데이터 품질을 높이는 전체 과정을 말합니다. 목표는 데이터의 일관성, 정확성, 완전성 확보에 있습니다.
• 전환 쿼리 검증 (현재 수행 업무): 마이그레이션 관점에서 AS-IS 데이터의 오류나 불일치를 찾아내는 진단 작업입니다. 예를 들어 성별 컬럼에 존재하는 'E'와 같은 비정상 값을 발견하고, 이러한 값이 그대로 두면 TO-BE에서 문제가 될지를 판단하는 등 위험 요소를 식별하는 것이 주목적입니다.

다시 말해, 지금 하고 있는 AS-IS 데이터 프로파일링과 검증은 데이터 정제 프로세스의 첫 단추(문제 식별)에 해당합니다. 정제를 위해 먼저 어디에 문제가 있는지 알아내는 것이지요. 그 후에 TO-BE 스키마와 대조하면서 해결책(정제 규칙)을 수립하게 됩니다.

정확한 역할 분담: AS-IS 분석 vs TO-BE 대응

• AS-IS 데이터 분석 (문제 발견 단계): 이 단계에서는 오직 AS-IS 데이터 자체에 집중합니다. 현재 데이터가 어떤 상태인지, 이상값이나 누락, 규칙성 등을 파악하여 문제 리스트를 만들어냅니다. 예를 들어 성별 컬럼에 'E'라는 값이 X건 있다, 주소 컬럼에 잘못된 형식이 Y건 있다 등 있는 그대로의 사실을 수집합니다. 이 과정을 흔히 데이터 프로파일링(Data Profiling)이라고 부릅니다.
• TO-BE와의 비교 및 규칙 수립 (정제 규칙 정의 단계): AS-IS에서 발견된 문제 목록을 가지고 TO-BE 시스템의 규칙과 요구사항을비교합니다. 여기서 업무적 판단이 들어갑니다. 예를 들어 AS-IS에 성별 'E'가 10건 있다 -> TO-BE는 성별이 'M'/'F'만 가능 -> 정책 결정: 'E'는 의미를 알 수 없으므로 TO-BE에서는 '미지정' 코드(예: '9')로 변환한다. 이렇게 데이터 변환 규칙을 정의하는 것입니다.
  이 과정에서 개발자는 분석 결과를 가지고 기획자나 도메인 전문가와 협의하여 규칙을 결정하게 됩니다. 공식 문서가 없더라도, 지금 결정된 내용이 나중엔 공식 이관 문서가 되므로 반드시 기록해두세요.

결국, AS-IS 분석은 정제해야 할 대상을 찾아내는 일이고, TO-BE와의 비교는 그 대상을 어떻게 정제할지 방법을 정하는 일입니다. 두 단계 모두 성공적인 데이터 정제와 마이그레이션을 위해 꼭 필요하며, 톱니바퀴처럼 맞물려 돌아가야 합니다.

비즈니스 및 소통 방법 (결과 전달의 기술)

기술적인 분석 못지않게, 이렇게 찾아낸 결과를 이해관계자에게 보고하고 논의하는 방식도 중요합니다. 특히 비개발자나 PM/기획 담당자는 지나친 기술적 상세보다는 의사결정을 위한 정보를 원합니다. 아래 사항을 염두에 두고 소통하세요:

• 그래서 문제인가요? – 발견된 현상이 단순 참고사항인지, 실제로 전환에 치명적인 문제인지 분류해서 알려줘야 합니다. (예: "A 컬럼은 사용되지 않으므로 영향 없습니다" vs "B 데이터 209건이 누락될 수 있는 심각한 문제입니다.")
• 어떤 영향이 있나요? – 이 문제가 비즈니스나 시스템에 끼칠 영향 범위를 설명해야 합니다. 데이터 209건 누락 시 사용자에게 과거 기록이 안 보이는 것인지, 시스템 오류로 이어지는 것인지 등 전환 후 결과를 그림으로 그려줍니다.
• 무엇을 결정하거나 조치해야 하나요? – 기술적으로 해결 가능한 부분은 개발자가 처리하면 되지만, 정책이나 규칙 결정이 필요한 부분은 명확히 질문 형태로 전달해야 합니다. (예: "NULL 담당자 항목을 '미상'으로 표시해도 될까요?"와 같이 결정을 요청)

위 세 가지를 염두에 두면, 단순히 문제 나열이 아닌 문제-영향-대응의 형태로 커뮤니케이션하게 되어, 비기술자도 쉽게 이해하고 대응책을 함께 논의할 수 있습니다.

예시 보고 : 검증 과정에서 담당자 정보가 없는 과거 데이터 209건이 전환 누락될 우려가 있다고 가정해 봅시다. 기획자/코디네이터에게는 아래와 같은 형식으로 전달하면 이해하기 쉽습니다.

(정책 결정 시급) 데이터 누락 위험 건

• 현상: 과거의 데이터 중 일부 레코드에서 특정 필드(예: 담당자 ID)가 NULL로 되어 있는 사례가 209건 발견되었습니다. 기존 데이터 전환 쿼리는 이 필드를 기준으로 데이터를 매칭하고 있기 때문에, 해당 209건의 레코드는 새로운 시스템으로 이관되지 않습니다.
• 영향: 별도의 조치를 취하지 않으면 이 209건의 데이터는 새로운 시스템으로 이관되지 않아 기존 기록을 조회할 수 없는 상황이 발생합니다. 이로 인해 과거 데이터의 무결성 및 연속성이 손상될 수 있습니다. 특히 기록을 추적하거나 분석하는 데 어려움이 발생할 수 있습니다.
• 질의: 해당 209건에 대한 처리를 어떻게 할지 결정이 필요합니다. 예를 들어, 담당자가 지정되지 않은 경우 ‘담당자 미지정’으로 표기하여 시스템에서 해당 기록을 조회할 수 있도록 하는 방안을 검토할 수 있습니다. 이에 대한 의견이나 다른 대안이 있다면 제시해 주세요.

 

 

위와 같이 문제의 심각도와 영향, 결정 사항을 명확히 해주면, 코디네이터나 관련 부서는 무엇을 해야 하는지 한눈에 이해할 수 있습니다. 기술적인 쿼리 상세보다 "데이터 209건 유실 위험"처럼 비즈니스 임팩트를 강조하는 것이 포인트입니다.