데이터 전환 계획·매핑·ETL·변환 | 정보처리기사 필기

데이터 전환 계획

데이터 전환은 기존 시스템의 데이터를 새 구조와 업무 규칙에 맞게 변환해 옮기는 작업이다. 단순 복사와 달리 코드·자료형·키·제약조건이 달라질 수 있다. 초기 데이터 구축은 새 시스템이 운영을 시작하는 데 필요한 기준·업무 데이터를 처음 적재하는 것이다.

계획 항목	정할 내용
대상·범위	원천 시스템, 테이블·파일·기간, 제외 데이터
분석	자료형·코드·중복·NULL·용량·테이블 관계
매핑·정제	어떤 원천 값을 어떤 목표 값으로 바꿀지
일정·자원	수행 순서, 작업 시간, 담당자, 장비·도구
검증	건수·키·합계·참조 관계·업무 기준
실패 대응	오류 격리, 재실행 범위, 중단·복구 기준

일괄 전환은 정한 시점에 전체를 바꾸고, 단계적 전환은 업무·조직·데이터를 나누어 바꾼다. 병행 운영은 일정 기간 기존·새 시스템을 함께 운영해 비교하는 방식이다. 각 방식은 중단 시간, 위험, 이중 운영 부담이 다르다.

리허설은 실제에 가까운 데이터와 절차로 사전 실행해 소요 시간·오류·검증 결과를 확인하는 것이다. 실전에서는 승인된 순서와 체크리스트에 따라 추출·변환·적재·검증·업무 전환을 수행한다.

소스-타깃 매핑 명세

소스-타깃 매핑(Source-to-Target Mapping)은 소스 데이터가 타깃의 어느 객체와 열로 이동하며, 어떤 규칙으로 값이 바뀌는지를 기록한 계약이다. 열 이름이 같아도 의미·단위·코드가 다를 수 있고, 이름이 달라도 같은 업무 개념일 수 있으므로 이름 일치만으로 자동 매핑하면 안 된다.

매핑 유형

유형	설명	예
직접 매핑	값을 그대로 옮김	`legacy.name` → `customer.name`
이름·자료형 변환	의미는 같지만 이름이나 자료형을 변경	문자 `'20260905'` → 날짜 `2026-09-05`
코드·도메인 매핑	소스 코드값을 타깃 코드값으로 변환	`A/H/D` → `ACTIVE/PAUSED/CLOSED`
파생 매핑	하나 이상의 소스 값으로 새 값을 계산	수량 × 단가 → 금액
분할 매핑	한 소스 열을 여러 타깃 열로 분해	전체 주소 → 우편번호·기본 주소·상세 주소
통합 매핑	여러 소스 열을 하나의 타깃 열로 결합	성·이름 → 표시 이름
키 매핑	기존 식별자를 새 식별자로 대응	`C001` → `1001`
기본값·상수	소스 값이 없을 때 합의한 값을 생성	`source_system='LEGACY'`
제외	타깃에서 사용하지 않는 항목을 명시적으로 제외	폐기된 임시 열

“매핑되지 않은 열”과 “업무적으로 제외한 열”은 다르다. 제외라면 이유와 승인자를 기록해야 하며, 타깃의 모든 필수 열은 직접·변환·파생·기본값 중 하나로 설명되어야 한다.

매핑 명세에 포함할 항목

매핑 식별자와 규칙 버전
소스 시스템·스키마·테이블·열, 소스 자료형
타깃 시스템·스키마·테이블·열, 타깃 자료형
직접·코드·파생·분할·통합·키 매핑 등의 유형
변환식과 계산 순서
NULL, 빈 문자열, 공백, 기본값 처리
길이·정밀도·스케일·반올림 규칙
코드표와 유효 기간, 미정의·폐기 코드 처리
포함·제외 행 조건
오류 시 거부·격리·수동 승인 등의 처리
소스 키와 타깃 키, 부모–자식 적재 의존성
데이터 소유자·작성자·검토자·승인자
검증 조건과 예상 결과

매핑 예시

소스	타깃	규칙	오류 처리	확인 기준
`old_customer.customer_no`	`customer.customer_id`	별도 키 매핑표에서 대리키 조회	키 생성 실패 시 격리	소스 고객별 타깃 키 1개
`old_customer.name_txt`	`customer.customer_name`	앞뒤 공백 제거, 빈 결과 금지	빈 이름 격리	`NOT NULL`, 최대 길이 준수
`old_customer.status_cd`	`customer.status`	`A→ACTIVE`, `H→PAUSED`, `D→CLOSED`	미정의 코드는 자동 기본값 금지, 격리	허용 코드만 존재
`old_customer.joined_ymd`	`customer.joined_on`	`YYYYMMDD`를 실제 달력 날짜로 엄격 파싱	존재하지 않는 날짜 격리	타깃 날짜형 변환 성공
`old_customer.credit_cents`	`customer.credit_limit`	센트를 100으로 나누어 달러 단위 `DECIMAL(12,2)`로 변환	음수·오버플로 격리	합의된 반올림과 범위 준수

키 매핑과 참조 관계

현행 자연키를 그대로 유지할 수 없는 경우가 많다. 여러 소스의 키가 충돌하거나, 타깃에서 대리키를 사용하거나, 보안상 기존 키를 노출하지 않는 경우에는 키 매핑표가 필요하다.

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

(source_system, source_key) → target_key
(LEGACY_CRM, C001)          → 1001
(LEGACY_MALL, C001)         → 8107

소스 시스템 식별자를 빼면 서로 다른 시스템의 C001을 같은 고객으로 잘못 합칠 수 있다. 반대로 동일인을 여러 시스템에서 찾았다고 임의로 합치면 안 된다. 고객 통합 규칙과 업무 승인을 별도로 적용해야 한다.

부모 고객의 새 키가 정해져야 주문의 외래키를 변환할 수 있으므로 일반적인 적재 순서는 다음과 같다.

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

기준 코드·참조 데이터
→ 부모·마스터 데이터
→ 키 매핑표 확정
→ 자식·거래 데이터의 외래키 변환
→ 자식·거래 데이터 적재

키 매핑은 전환 실행 중에도 동일한 소스 키에 동일한 타깃 키를 돌려주어야 한다. 실행할 때마다 새 키를 발급하면 자식 데이터 연결과 재실행 결과가 달라진다.

NULL·빈 문자열·0·기본값은 같지 않다

값 상태	가능한 의미	자동 변환의 위험
`NULL`	미입력, 알 수 없음, 해당 없음	하나의 의미로 단정하면 정보 손실
빈 문자열 `''`	입력 칸은 있었으나 값이 없음	DBMS에 따라 NULL 취급 차이가 있을 수 있음
공백 문자열 `' '`	잘못된 입력 또는 유효한 형식의 일부	무조건 제거하면 원본 의미 훼손 가능
숫자 `0`	실제 수치 0	미입력과 합치면 집계 왜곡
코드 `'0'`	정상 코드, 미정, 해지 등 시스템별 의미	숫자 0과 같은 뜻으로 가정하면 안 됨
기본값	값 생략 시 시스템이 채우는 값	명시적 NULL까지 자동으로 대체한다고 단정 불가
특수값 `99991231`	종료일 없음, 무기한, 미정 등	실제 날짜로만 해석하면 업무 의미 손실

정제 규칙은 값의 모양이 아니라 업무 의미를 기준으로 정한다. 예를 들어 전화번호에서 하이픈을 제거하는 것은 허용될 수 있지만, 빈 생년월일을 1900-01-01로 바꾸면 실제 1900년 출생자와 미입력을 구분할 수 없게 된다.

ETL·ELT와 스테이징

ETL의 단계

추출(Extract): 소스에 미치는 영향을 통제하면서 합의한 범위와 기준 시점의 데이터를 읽는다.
변환(Transform): 정제·자료형·코드·키·단위·시간대 규칙을 적용한다.
적재(Load): 타깃의 참조 관계와 제약조건을 고려해 데이터를 기록한다.

ELT와의 차이

ETL은 타깃 본 테이블에 적재하기 전에 외부 처리 엔진이나 중간 영역에서 변환한다.
ELT는 원시 또는 최소 변환 데이터를 타깃 플랫폼에 먼저 적재한 뒤 타깃의 연산 기능으로 변환한다.

어느 방식이 항상 우수한 것은 아니다. 민감한 원시 데이터를 타깃에 먼저 적재할 수 있는지, 타깃의 계산 능력과 비용, 규정상 중간 감사 자료가 필요한지, 원시 데이터 보존이 필요한지를 보고 선택한다.

스테이징 영역의 역할

스테이징(Staging)은 소스와 최종 타깃 사이의 임시 중간 저장 영역이다. 다음 역할을 수행할 수 있다.

소스 추출과 타깃 적재 시간을 분리해 두 시스템의 결합을 줄임
원시 추출을 실행 ID·추출 시각·소스 키와 함께 보존
변환 전 값과 변환 후 값을 비교하고 오류 행을 격리
타깃 제약조건을 건드리기 전에 자료형·코드·참조 관계를 점검
여러 번의 리허설에서 같은 입력으로 변환 규칙을 재현
전체 적재와 마지막 변경분 적재를 단계적으로 준비

스테이징은 영구 보관소가 아니며 민감정보가 복제되는 영역이다. 접근 권한, 암호화, 보존 기간, 파기와 마스킹 기준을 별도로 정해야 한다. 스테이징 데이터를 운영 타깃으로 착각해 업무 사용하면 안 된다.

전환 과정과 오류 격리

소스 추출 → 스테이징 → 변환·정제 → 적재 → 검증·업무 승인으로 진행한다. 실패 행은 격리·수정·재검증 후 해당 단계로 돌아간다. ETL은 변환 후 적재, ELT는 적재 후 변환이다. 매핑 버전과 부모·자식 키를 유지하고 최종 변경분까지 검증한다.

파일 처리 기술

파일로 데이터를 옮길 때에는 파일이 열린다는 사실만이 아니라 레코드와 필드를 같은 규칙으로 해석하는지 확인한다.

항목	확인할 내용
형식	CSV 같은 구분자 방식인지 고정 길이 방식인지
필드 경계	구분자, 인용부호, 구분자가 값 안에 들어갈 때의 처리
레코드 경계	줄바꿈·헤더·빈 행·여러 줄 문자열
문자	인코딩, 한글 깨짐, 문자 수·바이트 수
값 의미	NULL 표기, 날짜 형식, 숫자 소수점, 앞자리 0

예를 들어 CSV의 "서울,강남"은 인용 규칙을 적용하면 한 필드다. 쉼표마다 무조건 자르면 두 필드로 오해한다. 고객 코드 0012를 숫자 12로 바꾸면 원래 코드 의미가 달라질 수 있다.

추출 파일의 레코드 수와 적재 대상 수를 대조하고 형식이 잘못된 행은 원인을 기록해 별도로 분리한다. 파일 수신 성공과 데이터 전환 성공은 다르다.

전체·증분 적재와 적재 순서

전체 적재는 대상 범위 전체를 옮기고 증분 적재는 기준 시점 이후 바뀐 부분을 옮긴다. 변경 데이터 캡처(CDC)는 변경을 식별·전달하는 기술로 증분 반영에 활용할 수 있다. 필기에서는 전체 복사와 변경분 반영의 차이를 구분한다.

전체 적재 중에도 원천이 바뀌면 누락이나 중복이 생길 수 있으므로 비교 기준 시점과 변경분 처리 범위를 정해야 한다. 변경 시각만으로 추출할 경우 삭제된 행을 놓칠 수 있다는 기본 한계도 고려한다.

고객–주문 관계에서는 보통 부모 고객을 먼저 적재하고 자식 주문을 이어 적재한다. 기존 고객 번호를 새 대리키로 바꾸었다면 고객의 키 매핑표로 주문 외래키도 변환한다. 부모 키가 없는 행을 정상 완료로 처리하면 참조 무결성이 깨진다.

변환·정제의 기본 규칙

정제는 중복·누락·오류 등을 찾아 기준에 맞게 고치는 일이고 변환은 원천 형식을 목표 형식으로 바꾸는 일이다. 서로 함께 수행될 수 있지만 같은 의미는 아니다.

사례	규칙 예	오류 처리
상태 코드	A→ACTIVE, H→PAUSED	미정의 X는 임의 추정하지 않고 분리
날짜	YYYYMMDD→정한 날짜 형식	20260230 같은 달력 오류 검출
금액 단위	센트÷100→달러 표시액	반올림·자릿수 기준 명시
문자 길이	공백 제거 후 허용 길이 확인	초과값을 무단 절단하지 않음
식별자	기존 고객 코드→신규 키	관련 주문 참조도 함께 변환

예를 들어 상태 A·날짜 20260228·금액 12345센트는 ACTIVE·2026-02-28·123.45로 변환한다. 코드 X 또는 날짜 20260230은 규칙·원천 수정이 필요한 오류다. 이 예의 단위 변환은 같은 통화 단위 사이의 변환이며 환율 계산이 아니다.

NULL, 빈 문자열, 공백, 0, 기본값은 다르다. 모르는 금액을 0으로 채우거나 미정의 상태를 정상 코드로 바꾸면 적재는 성공해도 의미가 틀릴 수 있다. 변경한 값과 사용한 규칙을 확인할 수 있게 남긴다.

파일을 읽을 때 값의 경계를 보존하기

CSV에서 쉼표가 인용부호 안에 있으면 보통 필드 구분자가 아니라 값의 일부다. 7,"서울,강남",ACTIVE를 인용 규칙에 따라 읽으면 세 필드다. 문자열을 단순히 쉼표마다 자르는 방식은 주소를 두 값으로 잘라 잘못된 매핑을 만든다.

문자 인코딩 전환은 소스의 실제 인코딩으로 바이트를 문자로 해석한 뒤 타깃 인코딩으로 기록한다. 소스 바이트를 잘못 해석한 상태에서 파일 표시만 UTF-8로 바꾸면 이미 깨진 문자를 보존할 수 있다. NULL·빈 문자열·공백 구분도 전환 규칙에 남긴다.

프로파일링에서 소스 값의 최대 길이가 35인데 타깃 열의 길이가 20이라면 자료형·길이 또는 업무상 정제 규칙을 검토해야 한다. 임의로 앞 20자만 저장하는 것은 잘림에 의한 데이터 손실을 숨긴다. 허용되는 축약이라면 승인된 변환 규칙과 검증 기준이 필요하다.