데이터 전환 검증·대사·재처리·롤백·품질 | 정보처리기사 필기

전환 검증과 대사

검증은 데이터가 요구한 조건을 만족하는지 확인하는 일이고, 대사는 원천과 목표를 동일한 기준으로 비교해 누락·과잉·불일치를 찾는 일이다. 적재 프로그램이 성공했다는 것과 업무에 사용할 수 있다는 것은 다르다.

비교 전에는 대상 기간·상태·제외 범위, 기준 시점, 코드 변환·단위·반올림 규칙을 맞춘다. 원천이 계속 변하는데 오래된 목표 데이터와 비교하면 정상적인 시차를 오류로 볼 수 있다.

검증 종류	확인 내용
구조	테이블·칼럼·자료형·길이·키·제약조건
건수	전체·구간·상태별 건수, 계획된 제외·오류 건수
키	원천에만 존재하는 키, 목표에만 존재하는 키, 중복
값	같은 키의 중요 칼럼이 매핑 결과와 같은지
합계·분포	금액 합계, 최소·최대, 코드별 분포
무결성	부모 없는 외래키, NULL·도메인·업무 규칙 위반
업무	실제 조회·보고 결과가 사용 목적에 맞는지

전수 검증은 전체를 확인하고 표본 검증은 일부를 검사한다. 표본이 모두 맞아도 전체 오류가 없음을 보장하지 않는다. 키·금액·참조 관계처럼 위험이 큰 항목은 중요도에 맞춰 검증 범위와 허용 기준을 정한다.

건수와 합계가 같아도 틀리는 예

소스와 타깃에 다음 데이터가 있다고 하자.

소스 키	소스 금액	타깃 키	타깃 금액
O100	10	O100	12
O101	20	O101	18
O102	30	O102	30
O103	40	O999	40

양쪽 모두 4건·합계 100이다. 그러나 O103은 누락됐고 O999가 잘못 추가됐으며 O100·O101의 +2·-2 오류가 상쇄됐다. 따라서 건수와 총합은 필요한 검증이지만 충분한 검증은 아니다.

source_order(order_id,amount)와 target_order(order_id,amount)에서 원천에만 있는 키는 다음처럼 찾는다.

SQL코드 영역 안에서 좌우로 이동할 수 있습니다.

SELECT s.order_id
FROM source_order s
WHERE NOT EXISTS (
    SELECT 1 FROM target_order t
    WHERE t.order_id = s.order_id
);

결과는 O103이다. 소스와 타깃의 역할을 바꾸면 타깃 전용 O999를 찾는다. 같은 키의 값은 조인해 비교한다. NULL도 가능하면 단순 <>만으로 불일치가 모두 잡히지 않으므로 한쪽만 NULL인 조건도 확인한다.

해시·체크섬은 값의 차이를 빠르게 탐지하는 보조 수단이다. 비교 전에 열 순서·NULL 표기·날짜·숫자 형식 등을 맞춰야 한다. 같은 해시만으로 업무 의미와 참조 무결성까지 모두 검증했다고 판단하지 않는다.

건수·합계 일치만으로는 부족하다

소스 (O1,10)·(O2,20)과 타깃 (O1,12)·(O9,18)은 모두 2건·합계 30이지만 O2 누락, O9 초과, O1 값 불일치가 있다. 같은 시점과 변환 규칙으로 키별 대사하고 격리·수정·멱등 재처리·재검증한다. 복귀 시 신규 쓰기도 보존한다.

데이터 품질 분석과 오류 측정

품질은 적재 오류가 없는지만 보는 것이 아니라 업무 목적에 맞는 데이터인지 평가하는 것이다.

차원	뜻	예
완전성	필요한 데이터가 빠지지 않음	필수 고객 번호의 누락 여부
정확성	실제 사실에 맞음	고객 주소가 실제 주소인지
유효성	형식·범위·도메인 규칙에 맞음	유효한 날짜·상태 코드
유일성	중복 없이 필요한 단위를 식별	같은 주문 키 중복 여부
일관성	관련 데이터·규칙 사이에 모순이 없음	시스템 간 상태 코드 의미 일치
적시성	필요한 시점에 충분히 최신임	마감 전 최신 주문 반영

소스와 타깃이 같아도 소스 주소가 틀리면 정확성은 확보되지 않는다. 반대로 의도한 코드 변환이 있는데 문자열이 다르다는 이유만으로 오류라고 판단하면 안 된다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

오류율 = 오류 레코드 수 / 검사 대상 레코드 수 × 100
필수값 완전성 = 필수값이 채워진 대상 수 / 필수 입력 대상 수 × 100

1000건 중 오류 레코드 12건이면 오류율은 1.2%다. 한 레코드에 오류가 두 개여도 '오류 레코드 수'는 한 건이므로 오류 항목 수와 혼동하지 않는다. 분모가 0이면 별도 처리 기준 없이 100%로 표시하지 않는다. 검사 범위·기준 시점·규칙·허용 임계치를 함께 기록한다.

오류 정제와 재처리

오류는 원인과 영향 범위를 기록해 정상 데이터와 분리한다. 미정의 코드·잘못된 날짜는 데이터 또는 매핑 규칙을 수정해야 하고, 일시적인 연결 실패는 상태를 확인한 뒤 재실행을 검토한다. 같은 잘못된 입력을 그대로 반복한다고 품질 오류가 해결되지는 않는다.

기본 절차는 오류 식별 → 원인 분석 → 원천·매핑·프로그램 수정 → 대상 재처리 → 재검증이다. 규칙 자체가 잘못되었다면 발견된 한 행뿐 아니라 같은 규칙이 적용된 데이터 전체의 영향을 확인한다.

재처리할 때 이미 성공한 행을 다시 INSERT하면 중복될 수 있다. 업무키와 처리 이력을 확인하고, 같은 대상을 다시 처리해도 불필요한 중복 결과가 생기지 않도록 한다. 이를 멱등성의 관점에서 점검할 수 있다. 구체적인 분산 이벤트 처리 알고리즘보다 중복·누락 없이 다시 처리해야 한다는 원칙이 중요하다.

재처리 후에는 원래 실패 항목과 건수·키·참조 관계를 다시 확인한다. 정상 처리 건수, 오류 격리 건수, 계획된 제외 건수를 같은 기준으로 합산해 전체 대상과 대사한다.

롤백과 전환 완료 판단

트랜잭션 ROLLBACK은 아직 커밋하지 않은 변경을 취소한다. 이미 확정된 데이터를 과거 상태로 되돌리는 백업 복원이나 기존 시스템으로 업무를 복귀시키는 작업은 별도다.

전환 계획에는 중단·복귀를 결정할 오류 수준, 백업 위치, 처리 범위, 책임자와 검증 방법이 있어야 한다. 새 시스템에서 신규 데이터가 생긴 뒤 단순히 과거 시스템으로 접속만 바꾸면 새 데이터가 빠질 수 있으므로 처리 기준이 필요하다.

시점	확인할 내용
전환 전	대상·매핑·백업·수행 순서·검증·복귀 계획
전환 중	처리 건수·오류·시간·예상 범위 준수
전환 후	데이터 대사·무결성·업무 확인·남은 오류
완료 승인	허용 기준 충족과 승인된 예외·미해결 사항 기록

전환 결과 보고서에는 실제 수행 범위·시각·처리 건수·오류와 조치·재검증 결과·잔여 위험을 기록한다. '적재 성공' 한 줄이 아니라 데이터 검증과 업무 확인을 통과했을 때 완료를 판단한다.

형식 검증과 업무 정확성·전환 복귀

유효성은 값이 정한 형식·범위·허용 목록을 만족하는지 확인하는 차원이다. 정확성은 그 값이 실제 사실을 올바르게 나타내는지를 묻는다. 전화번호가 정해진 자리 수를 만족해도 다른 사람의 번호라면 형식은 유효할 수 있으나 정확하지 않다. 소스와 타깃이 같다는 대사만으로 현실 사실의 정확성까지 증명하지 않는다.

컷오버 후 타깃에서 신규 주문 30건이 발생했다면, 과거 소스로 트래픽만 되돌리면 그 주문들이 누락될 수 있다. 복귀 전 신규 변경분을 식별·보존하고 역반영 가능성, 쓰기 통제, 양쪽의 정합성을 검증해야 한다. DB 트랜잭션 ROLLBACK과 서비스 트래픽 복귀는 같은 명령이 아니다. 새 시스템을 유지하며 오류를 고치는 롤포워드가 더 안전한 상황도 있다.