데이터 매핑 템플릿: 원본 필드와 대상 스키마 연결하기

데이터 매핑 템플릿에는 원본의 각 필드가 대상 필드로 어떻게 바뀌는지 기록합니다. 값이 어디에서 오고, 어떤 변환을 허용하며, 사용할 수 없는 값은 어떻게 처리할지 정하는 것입니다. ‘고객 ID’와 ‘ID’를 선으로 잇는 것만으로는 가져오기 작업을 구현하거나 테스트하기에 부족합니다.

다음 예시는 작은 고객 CSV를 새 고객 테이블로 옮기는 작업입니다. 필드별 규칙, 정상 처리할 레코드 한 건, 보류할 입력, 재사용 가능한 매핑 카드 형식을 포함합니다. 예시의 조직과 레코드는 모두 설명을 위해 만든 가상의 데이터입니다.

원본에서 대상으로 매핑할 때 기록할 정보

열 제목을 캡처한 화면만 보지 말고 원본과 대상의 정의부터 확인합니다. 각 필드의 자료형, 필수 여부, 변환 방식, 허용 값, 실패 시 처리 방식을 기록하세요. Boardmix의 공유 다이어그램 캔버스에 원본 필드, 규칙, 대상 필드를 배치하면 데이터를 제공하는 쪽과 받는 쪽이 같은 매핑을 보며 논의할 수 있습니다.

다이어그램은 데이터를 어떻게 옮길지 합의한 내용입니다. 그림 자체가 마이그레이션을 실행하지는 않습니다. 가져오기 스크립트나 연동 도구가 규칙을 구현하고 정상 처리한 데이터와 보류한 데이터를 출력해야 합니다.

서로 관련된 세 문서의 역할을 구분하세요.

• ER 다이어그램:데이터 모델의 엔터티, 속성, 관계를 설명합니다.
• 데이터 흐름도:프로세스, 저장소, 외부 참여자 사이에서 데이터가 어떻게 이동하는지 설명합니다.
• 원본-대상 매핑:데이터를 전달할 때 개별 필드에 어떤 처리를 할지 설명합니다.

세 문서를 함께 놓을 수는 있지만, Customer와 Order의 관계만으로는 기존 상태 코드를 새 값으로 어떻게 바꿔야 하는지 알 수 없습니다.

작성 예시: 고객 데이터의 필드 다섯 개 가져오기

기존 시스템에서 고객 한 명당 한 행을 내보내고, 새 시스템에는 필드 다섯 개가 필요하다고 가정하겠습니다. 비어 있는 대상에 한 번 가져오는 작업이며 기존 레코드를 갱신하거나 병합하는 작업은 아닙니다.

이 예시에서는 대상 필드 다섯 개가 모두 필수입니다. 국가 코드는 GB, JP, ES만, 상태 값은 active와 inactive만 허용합니다. 설명을 위해 목록을 작게 정한 것이며 실제 고객 시스템을 세 국가로 제한하라는 권고는 아닙니다.

식별자는 숫자로만 이루어져 있어도 텍스트입니다. ‘0017’을 숫자 17로 바꾸면 식별자가 달라집니다. 자료형은 단순한 표시 형식이 아니라 값의 의미를 담고 있습니다.

필드마다 변환 규칙과 실패 처리 정하기

이 예시는 알 수 없는 값을 임의로 고치지 않습니다. 원본 명세가 대문자 A와 I만 허용하므로 소문자 ‘a’는 보류합니다. 대소문자를 구분하지 않으려면 매핑 규칙을 명시적으로 바꾸고 소문자 테스트 사례를 추가하세요. 가져오기 도구의 편리한 기본값이 이 정책을 대신 결정하게 해서는 안 됩니다.

‘03/09/26’도 작업을 실행하는 사람의 지역 설정으로 추측하지 않습니다. 서로 다른 날짜를 뜻할 수 있기 때문입니다. 원본 담당자에게 합의한 형식으로 제공해 달라고 요청하거나, 변환 전에 원본의 확실한 날짜 형식을 기록하세요.

필드 이름을 대응시키는 일과 필드 자료형을 변환하는 일은 다릅니다. Microsoft의 스키마 및 자료형 매핑 문서에서도 실제 연동 도구를 기준으로 둘을 구분합니다. 구현 설정은 플랫폼마다 다르지만, 도구를 설정하기 전에 필드 합의에 의도한 결과가 적혀 있어야 합니다.

레코드 한 건을 입력부터 출력까지 따라가기

다음은 완전한 원본 레코드입니다. 따옴표는 값의 앞뒤 공백을 보여주기 위한 표시이며 저장되는 값에 포함되지 않습니다.

• source_ref: “ 0017 ”
• company_label: “Orion Studio ”
• country: “United Kingdom”
• joined: “2026-09-03”
• state: “A”

앞뒤 공백을 없앤 식별자 0017이 다른 원본 행과 중복되지 않는다면, 정상 처리한 대상 레코드는 다음과 같습니다.

• customer_id: “0017”
• display_name: “Orion Studio”
• country_code: “GB”
• joined_date: 2026-09-03
• account_status: “active”

이 변환에는 회사 이름을 나누거나 영어로 바꾸거나 식별자를 숫자로 바꾸는 작업이 없습니다. 그런 작업은 단순한 정리가 아니라 별도 규칙입니다. 결과를 입력까지 추적할 수 있도록 가져오기 작업의 기록에 원본 행을 보관하세요.

보류 레코드 처리도 설계에 포함하기

성공하는 행만 보여주는 매핑에는 중요한 처리 방식이 빠져 있습니다. 이 예시에서는 필드 하나가 실패해도 행 전체를 보류하며, 일부 필드만 채운 고객 레코드는 저장하지 않습니다.

이유 라벨은 문제를 구분해주지만, 보류 출력에는 원본 행을 찾을 수 있는 참조와 문제가 있는 필드도 필요합니다. 오류 메시지에는 불필요한 개인정보를 넣지 마세요. 실제 마이그레이션에서는 고객 레코드를 제한 없는 보드에 복사하지 말고 승인된 샘플 데이터와 조직의 접근 제어를 사용합니다.

중복 처리는 필드 변환과 별도로 정해야 합니다. ‘마지막 행을 남긴다’는 방법은 간단하지만 파일 순서에 따라 결과가 달라집니다. 확인된 타임스탬프나 다른 업무 규칙으로 올바른 레코드를 정한다면, 값이 같은 경우의 우선순위까지 적으세요. 그런 기준이 없다면 임의로 고르지 말고 충돌하는 레코드를 보류합니다.

필드마다 사용할 수 있는 매핑 카드 형식

많은 필드를 한눈에 보려면 넓은 스프레드시트가 유용하지만, 복잡한 변환을 논의할 때는 작은 카드가 편합니다. 다음 카드에는 같은 핵심 정보를 담았습니다.

• 매핑 ID:M-03
• 원본:customer_export.country, 텍스트
• 대상:customer.country_code, 필수 텍스트
• 의미:대상에서 사용하는 국가 분류
• 규칙:앞뒤 공백을 제거하고 승인된 United Kingdom/GB, Japan/JP, Spain/ES 조회 목록을 사용
• 누락되거나 알 수 없는 값:원본 행 전체를 보류
• 예시:“ Japan ”은 “JP”로 바뀌고 “JPN”은 보류됨
• 문의 담당자:원본의 국가 값을 관리하는 사람

여러 필드를 사용하는 변환은 모든 입력을 한 카드에 나열합니다. given_name과 family_name으로 full_name을 만드는 작업은 독립적인 직접 매핑 두 개가 아닙니다. 순서, 구분자, 일부 값이 없을 때의 처리를 함께 정의하세요. 다른 테이블을 조회한다면 조회 키와 검색 결과가 없거나 여러 개인 경우의 처리 방식도 기록합니다.

정상 배치와 실패 배치로 팀과 매핑 검토하기

Boardmix 캔버스의 왼쪽에는 원본 스키마, 오른쪽에는 대상 스키마를 배치합니다. 그 사이에 매핑 카드를 놓고 변환이 필요한 필드는 라벨이 있는 선으로 연결하세요. 정상 처리할 레코드 예시는 주 흐름 아래에, 보류 경로는 별도 영역에 둡니다. 그러면 이견이 필드 이름, 업무상 의미, 잘못된 값 중 어디에 있는지 드러납니다.

원본 담당자에게 원본 값의 의미를, 대상 담당자에게 받는 시스템의 요구사항을 설명해 달라고 요청하세요. 그런 다음 샘플 레코드를 각 매핑에 따라 추적합니다. 한 사람은 ‘UK를 받아야 한다’고 생각하고 다른 사람은 ‘보류해야 한다’고 생각한다면, 가져오기를 실행하기 전에 조회 목록부터 합의해야 합니다.

첫 구현 테스트에서는 입력 행 수와 정상 처리한 행 수 및 보류한 행 수의 합계를 대조합니다. 이 예시에서 원본 행은 두 그룹 중 정확히 하나에만 속해야 합니다. 식별자와 필드 값도 비교하세요. 합계만 맞는다고 해서 고객에게 잘못된 상태가 부여된 문제까지 발견할 수 있는 것은 아닙니다.

Boardmix를 열어 원본-대상 매핑을 만들고 검토해 보세요. 합의한 규칙과 샘플 결과를 마이그레이션 구현 담당자에게 전달합니다. 매핑은 합의 내용을 기록하고, 가져오기 테스트는 구현이 그 합의를 따르는지 보여줍니다.