데이터 표준화란?

데이터 표준화는 다양한 소스에서 수집된 데이터를 일관된 형식으로 변환하는 과정입니다. 컬럼명, 데이터 형식, 분류 체계를 통일하여 데이터 통합과 분석을 용이하게 합니다. 특히 AI 모델 학습에서는 데이터의 일관성이 모델의 정확도와 성능에 직접적인 영향을 미치기 때문에 매우 중요합니다. 비표준화된 데이터는 모델 학습 시 오류를 유발하거나 성능을 저하시킬 수 있습니다.

이 글에서는 데이터 표준화 과정에서 자주 발생하는 문제점과 그 해결 방안, 그리고 실무 적용 시 고려해야 할 사항을 정리합니다.


* 이미지: snowflake.com


데이터 표준화의 주요 문제점

AI 모델 학습을 위한 데이터 마트 구축 시 자주 발생하는 문제는 다음과 같습니다:

  1. 컬럼명 불일치
  2. 동일한 데이터가 서로 다른 컬럼명으로 저장됩니다.
  3. 예: 고객 식별자를 "CustomerID", "ClientID", "Cust_No"로 다르게 명명.
  4. 분류 체계 상이
  5. 동일 데이터가 다른 분류 기준으로 기록됩니다.
  6. 예:
  7. 지역: "Seoul" vs. "서울특별시" vs. "KR-SEO".
  8. 카테고리: "Electronics" vs. "전자제품" vs. "Gadgets".
  9. 날짜: "2023-01-01" vs. "01/01/2023" vs. "20230101".
  10. 데이터 형식 불일치
  11. 동일 의미의 데이터가 다른 포맷으로 저장됩니다.
  12. 예: 금액 데이터에서 "1000" vs. "$1,000" vs. "1,000원".
  13. 데이터 값 기준 상이
  14. 동일 데이터가 다른 세분화 수준으로 저장됩니다.
  15. 예:
  16. 지역: "서울시" vs. "강남구" vs. "강남구 역삼동".
  17. 약품: "파라세타몰 500mg" vs. "파라세타몰" vs. "파라세타몰 정제".

결과: 데이터 통합이 어려워지고, AI 모델 학습 시 오류가 발생하거나 성능이 저하됩니다.


해결 방안

1. 명명 규칙 표준화

설명: 동일 데이터를 다른 컬럼명으로 저장한 경우, 메타데이터 매핑 테이블을 통해 표준화합니다.

예시: 고객 ID 컬럼 통합

  1. 상황: "CustomerID", "ClientID", "Cust_No"로 나뉨.
  2. 해결: 매핑 테이블로 "CustomerID"로 통일.

매핑 테이블 예시:

source_tablesource_columnstandard_column
table_aCustomerIDCustomerID
table_bClientIDCustomerID
table_cCust_NoCustomerID

SQL 예시:

SELECT
CASE
WHEN source_column = 'ClientID' THEN 'CustomerID'
WHEN source_column = 'Cust_No' THEN 'CustomerID'
ELSE source_column
END AS CustomerID
FROM raw_data;

2. 데이터 분류 기준 통합

설명: 동일 데이터가 다른 분류 체계나 세분화 수준으로 저장된 경우, 표준 코드북과 규칙 기반 매핑으로 통합합니다.

예시 1: 지역 데이터 통합

  1. 상황: "Seoul", "서울특별시", "KR-SEO" 혼재.
  2. 해결: 표준 코드북으로 매핑.
source_valuestandard_code
SeoulKR-SEO
서울특별시KR-SEO
BusanKR-BUS

예시 2: 카테고리 통합

  1. 상황: "Electronics", "전자제품", "Gadgets" 혼재.
  2. 해결: 표준 카테고리 매핑.
source_valuestandard_category
ElectronicsElectronics
전자제품Electronics
GadgetsElectronics

예시 3: 날짜 형식 통합

  1. 상황: "2023-01-01", "01/01/2023", "20230101" 혼재.
  2. 해결: 표준 형식(YYYY-MM-DD)으로 변환.
source_valuestandard_date
01/01/20232023-01-01
202301012023-01-01

예시 4: 세분화 수준 통합

  1. 상황: 지역("서울시" vs. "강남구") 또는 약품("파라세타몰 500mg" vs. "파라세타몰").
  2. 해결: 계층적 매핑 테이블로 통합.

지역 매핑 (시 단위로 통일):

detailed_regionstandard_city
강남구서울시
강남구 역삼동서울시

약품 매핑 (성분명 기준):

source_valuestandard_drug
파라세타몰 500mg파라세타몰
파라세타몰 정제파라세타몰

검증 쿼리:

INSERT INTO data_quality_log (record_id, column_name, issue)
SELECT id, 'region', 'Non-standard region level'
FROM raw_data
WHERE region NOT IN (SELECT detailed_region FROM region_hierarchy);

3. 알고리즘 활용 (LLM 기반 매핑)

설명: 복잡한 데이터 불일치를 해결하기 위해 대규모 언어 모델(LLM)을 활용합니다. 문맥 이해와 다국어 처리에 강점이 있습니다.

예시 1: 지역 데이터 매핑

  1. 상황: "Seoul", "Seoul City", "서울특별시" 혼재.
  2. 해결: LLM으로 표준 코드 매핑.
Input RegionStandard Code (LLM Output)Notes
SeoulKR-SEOExact match
Seoul CityKR-SEOSemantic match
서울특별시KR-SEOMultilingual match

예시 2: 약품 데이터 매핑

  1. 상황: "파라세타몰 500mg", "Paracetamol" 혼재.
  2. 해결: LLM으로 성분명 기준 통합.
Input DrugStandard Drug (LLM Output)Notes
파라세타몰 500mgParacetamolDosage removed
ParacetamolParacetamolExact match

구현 팁:

  1. LLM 프롬프트에 표준 코드북과 매핑 지침 명시.
  2. 소규모 샘플 테스트 후 대규모 적용.
  3. 비용 절감을 위해 오프라인 LLM(예: LLaMA) 고려.

주의점:

  1. API 호출 비용 발생 (일회성 작업에 적합).
  2. 명확한 프롬프트로 일관성 확보.

4. 정규 표현식 활용

설명: 패턴 기반 데이터 정제에 유용.

예시: 금액 형식 통합.

Input AmountStandard AmountNotes
$1,0001000Removed currency, commas
1,000원1000Removed currency


실무 적용 시 고려사항

  1. 세분화 수준 정의
  2. AI 모델 요구사항에 따라 데이터 세분화 수준 결정.
  3. 예: 지역 데이터는 시 단위로 통일? 동 단위까지 포함?
  4. 예: 약품 데이터는 성분명만? 용량별 구분 필요?
  5. 도메인 지식 활용
  6. 현업 전문가의 지식을 매핑 규칙 설계에 반영.
  7. 예: 약품 분류 시 약리학적 기준 필요.
  8. 예: 지역 데이터 통합 시 행정 구역 코드 참조.
  9. 데이터 품질 관리
  10. 비표준 데이터 검출 및 처리 방안 마련.
  11. 예: 로깅 후 수작업 검토 vs 자동 대체값 적용.
  12. 매핑 방식 선택
  13. 규칙 기반(반복 작업) vs LLM(일회성 작업) 선택.
  14. 검증 프로세스
  15. 매핑 결과 정확도 점검 기준 정의.
  16. 예: 샘플링 검토, 오류율 기준 설정.

상황별 논의 예시:

상황문제점논의 포인트
발표 시점 차이데이터 수집 시점에 따라 기준 상이최신 기준 선정, 갱신 주기 정의
지역 구분 차이세분화 수준 달라 통합 어려움세분화 수준 결정, 계층적 매핑 룰 설계
약품 분류 기준 차이용량, 제형, 성분 기준 상이분류 기준 정의, 도메인 전문가 검토

현업 참여 방안:

  1. 워크숍: 데이터 샘플 공유, 매핑 기준 논의.
  2. 검토 회의: 표준 코드북 및 매핑 결과 검증.
  3. 도메인 전문가 참여: 약품, 지역 등 전문 지식 필수.
  4. 피드백 루프: 초기 매핑 후 피드백 반영.