스키마 표준화 정규화와 엔터티 통합

AI Daily Special · Part 3 · 16/36

스키마 표준화 정규화와 엔터티 통합

2026년 9월 14일 · 전체 36회 중 16회 · 예상 읽기 10분 · Asia/Seoul

구조와 의미를 함께 정의한 표준 스키마를 만들고 원천 식별자와 변경 이력을 보존하는 엔터티 통합 기준을 설계할 수 있다.

15회에서 원본 보존 계층(Raw), 검증 계층(Validated), 목적별 활용 계층(Curated)을 나눴다. 이번에는 계층을 건너는 값의 의미를 맞춘다. 스키마(Schema)는 필드와 자료형, 관계와 제약조건을 정의한 데이터 구조다. 표준화(Standardization)는 이름과 단위, 시간과 코드의 표현 및 업무 정의를 합의된 기준에 맞추는 과정이다. 같은 열 이름을 붙여도 판매 단위와 상품의 범위가 다르면 같은 데이터가 아니다. 구조 검사 뒤 의미 검사와 식별자 매핑까지 연결해야 AI가 비교 가능한 입력을 얻는다.

이번 회차의 흐름

1. 1 구조가 맞아도 업무 의미는 다를 수 있다
2. 2 표현을 바꿀 때 원래 값과 변환 근거를 남긴다
3. 3 정규화라는 말의 세 가지 의미를 구분한다
4. 4 다온커머스는 상품의 범위부터 통합한다
5. 5 스키마 변경을 소비자의 관점에서 승인한다

1 구조가 맞아도 업무 의미는 다를 수 있다

온라인몰의 quantity와 매장 POS의 qty를 sold_qty로 바꾸는 작업부터 생각하자. 한쪽이 개수이고 다른 쪽이 상자 수라면 합계는 틀린다. 한 행이 주문 전체인지 주문의 상품 한 줄인지 정하는 데이터 단위(Grain)부터 합의한다. 판매 수량은 주문량인지 결제 완료량인지, 취소와 반품을 언제 반영하는지 명시한다. 이 정의는 12회 데이터 계약(Data Contract), 즉 생산자와 소비자가 합의한 운영 약속으로 돌아간다.

공식 JSON Schema 안내에서 properties는 필드별 검사를, required는 필수 필드 존재를, additionalProperties는 추가 필드 허용을 다룬다. 필드를 선언한 것만으로 필수가 되지 않고 null은 필드가 없는 상태와 다르다. [S1] 구조 검사 통과는 상품 실재나 판매량의 정확성을 증명하지 않으므로 업무 규칙을 별도 검사한다.

자료형 옆에는 단위, 허용 코드, 결측 의미, 원천과 책임자를 적는다. PostgreSQL 문서는 기본 키가 유일하고 비어 있지 않은 행 식별자이며 외래 키가 참조 관계를 제한한다고 설명한다. [S2] 기본 키는 행을 구별하지만 두 시스템의 상품이 같은 실물이라는 판단까지 대신하지 않는다.

판단 기준

표준 스키마는 열 이름 사전과 업무 정의를 함께 가진다. 한 행의 단위와 수량의 단위를 먼저 정하고 필수 여부와 null 허용을 각각 기록한다.

2 표현을 바꿀 때 원래 값과 변환 근거를 남긴다

시간은 RFC 3339 형식처럼 오프셋을 포함해 교환하되 영업일과 원천 시간대는 별도 정의한다. 단위 변환에는 원래 수량과 단위, 적용 계수와 기간, 규칙 버전을 남긴다. 앞자리 0이 있는 식별자는 문자열로 보존한다. [S3]

문자 정규화 NFC와 NFKC의 범위는 다르다. NFKC는 의미 있는 구별을 지울 수 있으므로 비교 필드에 선택 적용하고 원문을 보존한다. 시간대나 포장 수량을 확정하지 못하면 미확정 상태로 둔다. [S4]

판단 기준

표현 통일은 정보를 잃을 수 있다. 원문 참조와 변환 규칙을 보존하고 단위나 시간대를 확정할 수 없으면 격리 또는 미확정 상태로 남긴다.

3 정규화라는 말의 세 가지 의미를 구분한다

데이터베이스 정규화는 의존 관계에 맞게 표를 나눠 중복과 갱신 모순을 줄이는 설계다. 문자 정규화와 수치 스케일링은 목적이 다르며, 조회용 비정규화를 선택해도 기준 표와 시점을 보존해야 한다. [S5]

StandardScaler는 학습 평균과 표준편차로 수치를 변환하며 이상치에 민감하다. 평균과 분산은 학습 데이터에서만 추정하고 검증 및 운영 입력에는 같은 변환을 적용한다. 스케일링으로 단위 오류나 데이터 품질 문제가 해결되지는 않는다. [S6] [S7]

판단 기준

정규화 여부를 한 번의 체크로 승인하지 않는다. 어떤 종류의 처리인지, 무엇을 보존하는지, 어느 계층에서 어떤 버전으로 적용하는지 구분한다.

4 다온커머스는 상품의 범위부터 통합한다

가상 조직 다온커머스는 상품 모델, 판매 규격, 개별 실물과 채널 제안을 구분한 뒤 공통 product_id를 설계한다. GTIN은 거래 품목의 식별자이며 내부 SKU와 같다고 가정하지 않는다. 이름이 비슷해도 포장 규격이 다르면 수요가 섞일 수 있다. [S8]

대응표에 원천 시스템과 코드, 공통 ID, 유효 기간, 매핑 상태와 버전을 남긴다. 속성별 기준 원천과 승인 근거를 정하고 미확정 후보와 충돌은 보존한다. 원천 데이터는 삭제하지 않는다. 규칙 및 확률 매칭과 오탐 검증은 다음 17회에서 다룬다.

판단 기준

통합의 결과는 원본 삭제가 아니라 추적 가능한 연결이다. 공통 ID와 원천 ID, 유효 기간, 승인 근거를 보존하고 서로 다른 규격과 미확정 후보를 분리한다.

5 스키마 변경을 소비자의 관점에서 승인한다

Iceberg는 고유 필드 ID로 열을 추적하며 구조 변경을 지원하지만 기술적 스키마 진화가 업무 호환성을 보장하지는 않는다. 단위나 코드 의미가 달라지면 자료형이 같아도 소비자 재검사가 필요하다. [S9]

원천 스키마, 공통 스키마와 특징 스키마를 각각 버전으로 식별한다. 변환 실패, 미등록 코드, 미확정 매핑, 참조 실패와 조인 전후 행 수를 원천과 기간별로 본다. 임계값은 오류 비용에 따라 승인하고 계보를 근거로 정확성을 단정하지 않는다. [S10]

판단 기준

회차의 결과물은 표준 스키마 초안이다. 구조와 의미, 식별 범위, 원천 대응, 변환 버전, 실패 처리와 변경 승인을 한 묶음으로 검토한다.

표준 스키마 초안의 검토 항목

1. 1 행의 단위 주문 상품 한 줄인지 매장 상품 하루인지 명시
2. 2 필드 구조 자료형 필수 여부 null 허용 범위
3. 3 업무 의미 단위 영업일 판매 취소 반품의 정의
4. 4 원천 대응 원천 필드 원문 참조 변환 계수와 기간
5. 5 식별 범위 모델 판매 규격 실물 채널 제안 구분
6. 6 매핑 이력 공통 ID 원천 ID 유효 기간 상태 승인 근거
7. 7 실패 행동 미등록 코드 변환 실패 충돌의 격리와 책임자
8. 8 변경 승인 스키마 매핑 특징 버전 소비자 검사와 전환일

마무리와 다음 회차

AI가 비교할 수 있는 데이터는 구조뿐 아니라 업무 의미와 대상의 범위까지 맞아야 한다. 원문과 원천 ID를 보존하면서 단위와 시간, 코드와 문자를 필드별로 표준화하고 정규화의 종류를 구분하자. 공통 ID 대응표에는 기간과 승인 근거를 남긴다. 이번 표준 스키마 초안을 바탕으로 다음 17회에서는 정제와 중복 제거, 같은 상품과 고객을 판별하는 엔터티 해소를 검증한다.

다음 17회차 정제 중복 제거 엔터티 해소 실무 2026년 9월 16일

출처 및 읽을거리

확인일 2026-09-14 KST · 본문의 조직 설계는 실무 권고이며 사례는 교육용 가정이다.

• [S1] JSON Schema - Object reference
  확인일 2026-09-14 · 구조 검사가 업무 정확성을 증명하지 않음
• [S2] PostgreSQL - Constraints
  확인일 2026-09-14 · 데이터베이스 제약은 원천 간 동일 대상 판별을 대신하지 않음
• [S3] IETF RFC Editor - RFC 3339 Date and Time on the Internet
  확인일 2026-09-14 · 오프셋은 영업일과 지역 시간대 규칙을 대신하지 않음
• [S4] Unicode Consortium - UAX 15 Unicode Normalization Forms
  확인일 2026-09-14 · 호환 정규화는 구별을 없앨 수 있음
• [S5] Microsoft Learn - Database normalization description
  확인일 2026-09-14 · 교육용 요약에서 반복 그룹과 의존 분리 원칙만 참조함
• [S6] scikit-learn - StandardScaler
  확인일 2026-09-14 · 수치 변환이 품질 문제를 해결하지 않음
• [S7] scikit-learn - Common pitfalls and recommended practices
  확인일 2026-09-14 · 개별 모델의 변환 적합성은 별도 평가함
• [S8] GS1 GO - What is the Global Trade Item Number GTIN
  확인일 2026-09-14 · 내부 SKU의 동일성과 실제 원천 매핑은 별도 확인함
• [S9] Apache Iceberg - Evolution
  확인일 2026-09-14 · 기술적 구조 변경이 소비자의 업무 호환성을 보장하지 않음
• [S10] W3C - PROV O The PROV Ontology
  확인일 2026-09-14 · 계보 표현은 매핑 정확성이나 삭제 실행을 대신하지 않음

2026-09-14-ai-ready-data-ep16-schema-entity-integration.pdf

1.5 MB