Kwangmin Kim - 데이터 표준 관리

1 표준 없이 쌓인 데이터의 실제 비용

개발 속도가 중요한 초기 스타트업이나 빠르게 성장하는 팀에서는 칼럼명 표준 같은 것은 사치처럼 느껴진다. 기능이 동작하면 된다는 압박 속에서 cust_nm, customerName, CUSTOMER_NM, c_name이 서로 다른 테이블에 혼재해도 일단 서비스가 돌아간다.

문제는 2~3년 후에 온다. 신규 개발자가 온보딩할 때 “이 칼럼이 뭘 의미하는지”를 기존 팀원에게 직접 물어봐야 한다. 두 시스템을 통합할 때 같은 개념을 가리키는 칼럼을 찾는 작업이 수동 조사가 된다. 데이터 품질 진단 도구를 도입하려는데 칼럼별 허용 값의 범위가 어디에도 정의되어 있지 않아서 규칙을 처음부터 만들어야 한다. DW에 데이터를 적재할 때 소스 시스템마다 같은 개념을 다른 타입으로 저장해서 변환 로직이 복잡해진다.

이 비용들은 처음에 표준을 만들지 않은 것의 누적 이자다. 데이터 표준은 초기에 투자하면 이후 모든 단계에서 비용을 줄이는 인프라다. 앞선 글에서 라이프사이클의 1단계로 정책/표준 수립을 배치한 이유가 바로 이것이다.

이 글에서는 표준이 어떤 구조로 설계되어야 하는지, 각 구성 요소가 실제로 어떤 문제를 해결하는지, 그리고 기존에 표준 없이 운영되던 시스템에 표준을 적용하는 현실적인 방법을 다룬다.

2 표준의 3계층 구조: 왜 하나가 아닌 셋인가

데이터 표준을 “칼럼명 규칙 문서”로 이해하면 3계층 구조가 불필요하게 복잡해 보인다. 그러나 표준이 품질 진단, 변경 관리, 자동화와 연결되는 순간 이 3계층이 왜 필요한지 명확해진다.

[표준 용어 (Term)]
  비즈니스 개념의 공식 이름
  예: 고객, 주문금액, 결제일시
       |
       | 용어는 단어의 조합으로 구성됨
       v
[표준 단어 (Word)]
  용어를 구성하는 최소 단위 + 약어 정의
  예: 고객(CUST), 금액(AMT), 일시(DTTM)
       |
       | 단어는 기본 도메인과 연결됨
       v
[표준 도메인 (Domain)]
  데이터 타입과 허용 값 범위 정의
  예: 금액도메인(NUMBER(15,2), >= 0), 날짜도메인(DATE)

이 세 계층의 핵심은 상호 참조 관계다.

연결	효과
단어 -> 도메인	“이 단어로 끝나는 칼럼은 이 도메인을 따른다”는 추론 규칙 생성
용어 -> 단어 조합	“이 용어에 해당하는 칼럼명을 자동 생성할 수 있다”는 자동화 기반
도메인 -> 품질 규칙	도메인을 가진 모든 칼럼에 동일한 품질 규칙 자동 적용

DMBOK은 도메인을 “속성 간 형식과 값 집합의 일관성을 보장하는 수단”으로 설명하며, Student Tuition Amount와 Instructor Salary Amount가 모두 Amount 도메인에 할당되는 예시를 제시한다 (DAMA International, 2017, Ch.5). 이 예시가 보여주는 것은 도메인이 단순한 타입 정의가 아니라 표준화된 규칙의 재사용 단위라는 점이다.

3 표준 용어: 비즈니스 개념의 단일 진실점

3.1 용어가 없으면 발생하는 문제

같은 비즈니스 개념이 시스템마다 다른 이름으로 불리면 통합 작업에서 매핑 테이블을 수동으로 만들어야 한다. “고객”이 어떤 시스템에서는 CUSTOMER, 어떤 시스템에서는 USER, 어떤 시스템에서는 CLIENT로 불린다. 이 세 개가 모두 같은 비즈니스 개념인지, 아니면 미묘하게 다른 개념인지(예: USER는 서비스 가입자, CUSTOMER는 실제 구매 이력이 있는 사람)를 코드와 문서를 모두 읽어봐야 판단할 수 있다.

표준 용어는 이 비즈니스 개념에 공식 이름을 부여하고, 그 이름이 전사에서 단일하게 사용되도록 강제한다. DMBOK은 이를 비즈니스 용어사전(Business Glossary)으로 구현할 것을 권고하며, “비즈니스 용어 관련 시스템 오브 레코드(system of record)”로서의 역할을 강조한다 (DAMA International, 2017, Ch.3).

3.2 용어 정의서의 구성 요소

표준 용어를 정의할 때 이름만 정하는 것으로는 부족하다. 실제로 활용 가능한 용어 정의서는 다음 내용을 포함해야 한다.

구성 요소	설명	예시
용어명(한글/영문)	공식 명칭. 영문은 테이블/칼럼명의 기초	고객 / CUSTOMER
약어	칼럼명에서의 축약 형태	CUST
정의(Definition)	업무적 의미와 경계	“서비스에 가입 완료한 사람. 가입 신청 중이거나 탈퇴한 사람은 미포함”
관련 용어	유사 개념과의 차이	고객 vs 회원 vs 사용자
소속 표준 세트	전사 표준 / 로컬 표준 구분	Public Standard
상태	ACTIVE / DEPRECATED	ACTIVE

정의에서 가장 중요한 것은 경계다. “고객은 우리 서비스의 사용자다”는 정의가 아니다. “서비스에 가입 완료한 사람. 가입 신청 중이거나 탈퇴한 사람은 포함하지 않는다”가 정의다. 경계가 명확해야 데이터를 추출할 때 WHERE 조건이 결정된다.

상태를 DEPRECATED로 관리하는 이유는 히스토리 보존이다. 용어를 삭제하면 이 용어를 참조하는 기존 시스템들에 대한 추적이 불가능해진다.

4 표준 단어: 칼럼명 생성의 기초

4.1 단어 표준이 칼럼명 목록보다 강력한 이유

표준 접근 방식으로 “칼럼명 목록을 만들자”가 있다. 주요 칼럼들의 표준 이름을 목록으로 관리하는 것이다. 이 방식의 문제는 목록에 없는 칼럼이 생길 때마다 담당자가 임의로 결정한다는 것이다. 새로운 칼럼이 수백 개 생기는 사이 표준 목록은 현실을 따라가지 못한다.

단어 표준은 이 문제를 구조적으로 해결한다. 조합 가능한 단어 집합을 표준화하면 새로운 칼럼명이 필요할 때 표준 단어를 조합해서 만들면 된다. “입고일시”라는 칼럼이 새로 필요하면 “입고(INBOUND)” 단어와 “일시(DTTM)” 단어를 조합해서 INBOUND_DTTM으로 명명한다. 이 칼럼은 목록에 없어도 표준을 따른다.

4.2 단어의 구성 요소

단어명(한글/영문)과 약어(Abbreviation). 칼럼명에서 이 단어를 표현할 때 사용하는 축약어다. 예: AMOUNT -> AMT. 약어는 3~6자 이내로 통일하는 것이 일반적이다.

단어 유형. 단어는 역할에 따라 구분된다.

유형	역할	예시
명사어(NOUN)	대상을 나타낸다	고객, 주문, 상품
수식어(MODIFIER)	명사어를 수식한다	등록, 승인, 완료
분류어(CLASSIFIER)	데이터 성격을 나타낸다	코드, 명, 번호, 금액, 일자, 여부

칼럼명은 일반적으로 [명사어] + [수식어] + [분류어] 구조로 구성된다. 예: 고객(명사) + 등록(수식) + 일자(분류) -> CUST_REG_DT

기본 도메인(Default Domain). 이 단어로 끝나는 칼럼에 자동 적용될 기본 도메인이다. “금액(AMT)” 단어의 기본 도메인은 “금액 도메인(NUMBER(15,2), >= 0)”. “일자(DT)” 단어의 기본 도메인은 “날짜 도메인(DATE)”. 이 연결 관계 덕분에 칼럼명이 _AMT로 끝나면 도메인을 별도로 지정하지 않아도 자동으로 금액 도메인이 매핑될 수 있다.

4.3 약어 충돌 문제

단어 수가 많아지면 약어 충돌이 발생한다. “고객(CUST)”과 “관세(CUST)”가 같은 약어를 가질 수 없다. 약어 체계를 설계할 때 이 충돌을 사전에 방지하는 규칙이 필요하다. 일반적인 접근은 약어를 알파벳 앞에서부터 취하되, 충돌 시 음절 단위로 조정하는 방식이다.

약어를 너무 짧게 만들면 가독성이 떨어진다는 점도 고려해야 한다. CUST_REG_DT는 이해할 수 있지만 C_R_D는 맥락 없이는 읽을 수 없다. 실무에서는 약어 3~6자, 칼럼명 전체 30자 이내를 기준으로 사용하는 경우가 많다.

5 표준 도메인: 데이터 품질 자동화의 기반

5.1 도메인이 만드는 유지보수 효율

품질 진단 도구를 도입했는데 칼럼이 10,000개라면 각 칼럼에 대해 진단 규칙을 직접 작성하는 것은 불가능에 가깝다. 도메인 개념이 없으면 이 문제를 피할 수 없다.

도메인은 “동일한 성격의 데이터를 다루는 칼럼들의 규칙 집합”이다. 10,000개의 칼럼이 있더라도 도메인은 수십~수백 개 수준이다. 도메인 규칙 관리는 수십 개이고, 칼럼-도메인 매핑 작업만 10,000개인 것이다. 도메인 규칙을 수정하면 그 도메인을 참조하는 모든 칼럼에 자동으로 반영된다.

-- 표준 도메인 정의 예시
CREATE DOMAIN 금액도메인 AS NUMBER(15,2)
    CHECK (VALUE >= 0)
    COMMENT '0 이상의 통화 금액. 소수점 2자리까지 허용';

CREATE DOMAIN 사용자ID도메인 AS VARCHAR(20)
    CHECK (VALUE ~ '^[A-Z]{2}[0-9]{6}$')
    COMMENT '부서코드(2자리) + 일련번호(6자리)';

5.2 도메인 유형별 설계

도메인 유형	정의 방식	적용 대상	예시
범위(RANGE)	최솟값/최댓값	숫자형 칼럼	나이: 0~150, 할인율: 0~100
정규식(REGEX)	패턴	형식이 중요한 문자열	전화번호: `^[0-9]{2,3}-[0-9]{3,4}-[0-9]{4}$`
코드(CODE)	코드 그룹 참조	코드성 칼럼	성별: M/F, 주문상태: PENDING/COMPLETED/…
사용자 정의(CUSTOM)	SQL/스크립트	복합 규칙	“주문완료일시 > 주문등록일시”

코드 도메인은 코드 관리 컴포넌트와 연결되어야 한다. 코드 그룹의 값이 추가되거나 삭제되면 코드 도메인의 허용 값도 자동으로 갱신된다. 이 연결이 끊어지면 코드 값이 추가되었는데 품질 진단에서 “허용되지 않은 값” 오류가 발생하는 문제가 생긴다.

5.3 도메인 그룹: 관련 도메인을 묶어서 관리

도메인 수가 많아지면 탐색이 어려워진다. 도메인 그룹을 도입해서 관련 도메인을 묶으면 관리가 용이해진다.

도메인 그룹	포함 도메인
날짜/시간	날짜(DATE), 일시(DATETIME), 연월(YYYYMM)
금액	원화금액, 외화금액, 환율
식별자	사용자ID, 주문번호, 상품코드

6 복수 표준 관리: 이상과 현실의 균형

6.1 전사 표준 단일화의 함정

표준 관리를 처음 도입하는 조직에서 가장 흔한 실수는 “모든 시스템이 전사 표준을 따라야 한다”고 선언하는 것이다. 이 선언은 다음 두 가지 경우에 즉시 좌초한다.

패키지 솔루션. SAP, Oracle ERP, Salesforce 같은 패키지 솔루션은 자체 데이터 모델을 갖고 있고 이를 수정할 수 없다. MANDT, BUKRS, KUNNR 같은 SAP 전용 칼럼명을 전사 표준으로 바꾸는 것은 불가능하다.

레거시 시스템. 10~20년 된 시스템에 전사 표준 칼럼명을 적용하려면 수천 개의 칼럼명을 변경하고, 그 칼럼을 참조하는 모든 애플리케이션 코드를 수정해야 한다. 비용이 편익을 압도한다.

현실적인 접근은 표준 세트의 유형을 명시적으로 구분하는 것이다.

유형	적용 대상	관리 방식
Public Standard (공개 표준)	신규 개발 시스템	의무 적용, 표준 사전에서 정의
Local Standard (로컬 표준)	패키지 솔루션, 인수합병 시스템	전사 표준으로의 매핑 관계 관리
Non-Standard (비표준)	레거시 시스템	표준 준수율 현황 파악 후 점진적 개선

이 세 가지 유형을 메타데이터로 관리하면 “전체 칼럼 중 전사 표준 적용 비율”을 정확히 측정할 수 있다. 측정 가능하면 목표를 세우고 개선할 수 있다. 측정 불가능한 상태에서 “표준 준수”를 요구하는 것은 의미가 없다.

6.2 로컬 표준과 전사 표준의 매핑 관리

패키지 솔루션의 칼럼이 전사 표준 용어의 어떤 개념에 해당하는지를 매핑 테이블로 관리한다. 예: SAP의 KUNNR(고객번호)는 전사 표준의 “고객번호(CUST_NO)” 용어에 해당한다. 이 매핑이 있으면 SAP 데이터를 DW로 적재할 때 전사 표준 칼럼명으로 변환하는 ETL 매핑 규칙을 이 메타데이터에서 자동으로 생성할 수 있다.

7 AI 자동화와 표준 관리의 연결

7.1 표준 매핑의 병목과 LLM 활용

표준 관리에서 가장 노동집약적인 작업은 기존 시스템의 비표준 칼럼을 표준 용어와 매핑하는 것이다. 칼럼이 수만 개인 조직에서 이것을 완전히 수동으로 하면 수개월이 걸린다.

LLM(Large Language Model) 기반 자동화가 이 병목을 줄일 수 있는 유력한 지점이다. 칼럼명, 칼럼 코멘트, 샘플 데이터를 입력으로 주면 LLM이 표준 용어 후보를 제안한다.

입력	LLM 제안	DA 판단
칼럼: `c_nm`, 코멘트: “고객의 이름”	표준 용어 “고객명(`CUST_NM`)” 매핑 제안	확정
칼럼: `amt_01`, 코멘트: 없음	표준 용어 후보 3개 제시 (매핑 불확실)	수동 검토

자동화가 100%의 정확도를 보장할 수는 없다. 그러나 1만 개 칼럼 중 80%를 자동 제안으로 처리하고 20%만 수동으로 검토한다면 작업량이 5분의 1로 줄어든다. 자동화의 목표는 DA의 판단을 대체하는 것이 아니라, 반복적인 패턴 매칭 작업을 AI가 담당하고 DA가 예외 케이스에 집중할 수 있게 하는 것이다.

7.2 자동 표준 준수 검증

칼럼이 새로 추가될 때 해당 칼럼명이 표준 단어 조합인지 자동으로 검증하는 것도 자동화 가능하다. 변경 요청이 제출되면 시스템이 칼럼명을 파싱해서 각 구성 단어가 표준 단어 목록에 있는지 확인한다. 없으면 “표준 미등록 단어 포함” 경고를 반환한다. 이것이 작업 규칙(Work Rule) 자동 검증이다.

8 표준과 품질 진단의 연결: 표준이 규칙이 되는 순간

표준 도메인이 칼럼에 매핑되는 순간 그 도메인의 규칙이 품질 진단 규칙이 된다. 이 연결이 표준 관리와 품질 관리를 통합하는 핵심 설계 결정이다.

품질 진단 엔진의 동작 순서는 다음과 같다.

진단 대상 칼럼의 도메인을 조회한다 (메타데이터 저장소에서 domain_id 참조)
도메인 유형에 따라 진단 SQL을 동적으로 생성한다
- RANGE: 범위 조건 쿼리
- REGEX: 패턴 매칭 쿼리
- CODE: 코드 그룹과의 NOT IN 쿼리
대상 테이블에 쿼리를 실행해서 오류 건수를 집계한다
결과를 품질 결과 테이블에 저장한다

도메인 규칙이 바뀌면 다음 진단 실행부터 자동으로 바뀐 규칙이 적용된다. 규칙 변경을 반영하기 위해 진단 로직을 수정할 필요가 없다. 이것이 메타데이터 기반 자동화의 핵심 장점이다.

9 실무에서 표준 관리를 시작하는 방법

9.1 기존 시스템에 표준을 적용하는 현실적 순서

이미 수백 개의 테이블이 있는 시스템에 표준을 도입할 때 권장하는 순서가 있다.

1단계: 현황 파악. 시스템 카탈로그에서 모든 테이블과 칼럼을 수집한다. 칼럼명을 분석해서 이미 표준처럼 사용되는 패턴을 파악한다. _DT, _NM, _ID, _CD, _AMT로 끝나는 칼럼들은 이미 분류어 관행이 있다는 신호다. 이 패턴에서 표준 단어 후보를 역으로 추출한다.

2단계: 핵심 도메인과 단어부터 정의. 모든 칼럼을 커버하는 완전한 표준을 한 번에 만들려고 하지 않는다. 사용 빈도가 높은 분류어(날짜, 금액, 코드, 번호, 이름, 여부)에 해당하는 도메인과 단어를 먼저 정의한다. 이 소수의 핵심 표준이 전체 칼럼의 상당 부분을 커버한다.

3단계: 신규 개발에 즉시 적용. 레거시 시스템 적용은 비용이 크므로 신규 개발부터 표준을 의무화한다. 변경 요청 단계에서 표준 준수 검증을 자동화하면 개발자가 표준 확인을 잊어도 시스템이 알려준다.

4단계: 레거시 매핑은 점진적으로. 레거시 칼럼에 대해서는 물리적 변경 없이 비즈니스 메타데이터(논리명, 도메인 매핑)만 등록하는 것으로 시작한다. 물리 칼럼명을 변경하는 것은 장기 계획으로 가져간다.

9.2 표준 변경의 영향 관리

한 번 정의한 표준은 바꾸기 어렵다. 특히 도메인 정의를 바꾸면 그 도메인을 참조하는 모든 칼럼의 품질 진단 결과가 달라진다. 따라서 표준 변경도 변경 요청 워크플로를 거쳐야 한다.

도메인 규칙이 강화되면(예: 금액 도메인에 소수점 2자리까지만 허용하던 것을 정수만 허용으로 변경) 기존 데이터에 새로운 오류가 대량 발생할 수 있다. 표준 변경 전에 영향도 분석(해당 도메인을 참조하는 칼럼 목록과 현재 데이터의 해당 규칙 적용 결과)을 먼저 실행해야 한다. 라이프사이클 설계에서 다룬 영향도 분석이 이 지점에서 구체적으로 적용되는 것이다.

10 관련 주제

카테고리 내 연결