3과목 — 데이터 표준화

10문항 / 20 %. 공식 출제 범위는 셋이다.

개요        필요성 · 개념 · 관리 도구
표준 수립   원칙 정의 · 표준 정의 · 표준 확정
표준 관리   관리 프로세스 · 준수 점검 · 변경 관리

네 가지 구성 요소(단어·도메인·용어·코드)의 관계만 정확히 잡으면 절반 이상이 풀린다.

---

1부 · 개요

1. 표준화가 없으면 무슨 일이 생기는가

같은 것을 시스템마다 다르게 부르고 다르게 저장한다.

영업 시스템    고객명    VARCHAR(30)
회원 시스템    회원이름   VARCHAR(50)
CRM           CUST_NM   CHAR(20)

셋을 합치려면 이름을 맞추고, 길이를 맞추고, 잘린 데이터를 복구해야 한다. CHAR(20) 에 저장하면서 이미 잘려 나간 이름은 되살릴 수 없다.

데이터 표준화 — 데이터의 명칭·형식·규칙을 조직 차원에서 통일하여 일관성을 확보하는 활동.

2. 표준화의 필요성

· 시스템마다 다른 명칭으로 같은 데이터를 찾을 수 없다
· 형식이 달라 통합 시 변환·손실이 발생한다
· 같은 데이터인지 몰라 중복 개발한다
· 데이터의 의미를 물어볼 곳이 없다
· 품질 점검의 기준이 없다

3. 기대 효과

3.1 과장된 효과를 조심한다

✗  표준화만으로 프로젝트 기간이 절반이 된다   → 근거 없는 수치
✗  통합에 필요한 서버가 자동 확보된다         → 하드웨어와 무관
✗  연계할 시스템 수가 자동으로 줄어든다       → 시스템 수는 계획이 정함
✗  데이터 품질이 자동으로 100% 가 된다        → 기준을 줄 뿐

---

4. 데이터 표준의 네 가지 구성 요소

이 관계가 이 과목의 핵심이다.

4.1 방향을 뒤집은 보기를 조심한다

✓  표준 용어는 표준 단어의 조합이다
✗  표준 단어는 표준 용어의 조합이다        ← 뒤집힘

✓  표준 용어는 표준 도메인을 참조한다
✗  표준 도메인은 표준 코드의 조합이다      ← 관계 없음

✗  표준 코드는 표준 단어를 참조해 생성된다  ← 코드는 값의 목록이지 이름이 아님

단어가 작은 것, 용어가 조합된 것. 이 방향만 놓치지 않으면 된다.

---

5. 표준 관리 도구

5.1 기능

· 표준 단어·도메인·용어·코드 등록과 조회
· 표준 준수 여부 자동 점검
· 물리명 자동 생성
· 변경 이력 관리
· 모델링 도구와 연계

5.2 도구가 하지 않는 것

✗  어떤 용어가 필요한지 스스로 판단
✗  업무 의미를 해석
✗  표준 위반을 강제로 수정

도구는 등록된 규칙에 따라 검사할 뿐이다.

---

2부 · 표준 수립

6. 원칙 정의

· 표준화 적용 범위 결정 (어느 시스템, 어느 데이터까지)
· 표준화 원칙과 방침 수립
· 추진 조직과 역할 정의
· 기존 시스템 적용 방침 (전면 / 단계적 / 신규만)
· 예외 인정 기준

7. 표준 정의

7.1 표준 단어

· 더 이상 분해되지 않는 최소 단위여야 한다
· 하나의 의미만 가져야 한다 (동음이의어 배제)
· 하나의 의미에는 하나의 단어만 (이음동의어 배제)
· 영문 약어를 함께 정의한다
· 금칙어를 지정한다 (예약어 충돌 방지)

이음동의어와 동음이의어

이음동의어를 방치하면 같은 데이터를 두 번 만들고, 동음이의어를 방치하면 다른 데이터를 하나로 합친다. 둘 다 정합성을 깬다.

영문 약어 정하기

· 한 단어에 하나의 약어만 (일관성)
· 지나치게 줄여 의미를 잃지 않기
· 예약어와 충돌하지 않기
· 이미 널리 쓰이는 약어를 존중 (고객 → CUST)

7.2 표준 도메인

속성이 가질 수 있는 값의 형식을 정의한다.

도메인을 쓰면 무엇이 좋은가

도메인 없이     고객명 VARCHAR(30) · 회원이름 VARCHAR(50) · 담당자명 VARCHAR(20)
도메인 적용 후  셋 다 '명칭' 도메인 → VARCHAR(100) 로 통일

도메인 제약은 품질과 직결된다. "도메인 제약은 데이터 품질과 무관하다" 는 오답이다. 잘못된 값을 들어오기 전에 막는 것이 사후 점검보다 효과적이다.

7.3 표준 용어

표준 단어를 정해진 순서로 조합한다.

[수식어] + [주요 단어] + [분류어]

고객  +  주문  +  일자   →   고객주문일자
총    +  주문  +  금액   →   총주문금액

마지막에 오는 단어(분류어)가 도메인을 결정하는 경우가 많다.

…일자   →  일자 도메인  (DATE)
…금액   →  금액 도메인  (NUMBER)
…여부   →  여부 도메인  (CHAR(1))
…코드   →  코드 도메인  (CHAR)

물리 명칭 생성

고객주문일자
   ↓  각 단어를 영문 약어로
고객=CUST · 주문=ORD · 일자=DT
   ↓  구분자로 연결
CUST_ORD_DT

규칙에 따라 기계적으로 생성되는 것이 핵심이다. 사람이 그때그때 정하면 표준이 아니다.

7.4 표준 코드

표준화 이유

A 시스템   주문상태: '접수' '배송중' '완료'
B 시스템   주문상태: '1' '2' '3'
C 시스템   주문상태: 'R' 'S' 'C'

통합 조회도 집계도 불가능하다.

설계 시 고려 사항

✗  코드 값을 각 업무 테이블에 문자열로 중복 정의한다
✗  폐기된 코드는 즉시 삭제한다

8. 표준 확정

순서 문제로 자주 나온다.

정의된 표준안을 관련 부서에 공람
        ↓
이견이 있으면 협의를 거쳐 조정
        ↓
확정된 표준을 공식적으로 공표
        ↓
그 다음에 적용

공표 전에는 적용하지 않는다. "확정 전이라도 개별 시스템이 먼저 적용해도 된다" 는 오답이다. 확정 전에 적용하면 조정 결과와 어긋나 두 번 고치게 된다.

8.1 기존 시스템 적용

신규 개발   표준 적용을 의무화
기존 시스템 전환 계획을 수립해 단계적으로 적용

전면 재정의는 답이 아니다. "확정된 표준을 폐기하고 처음부터 다시 정의한다" 같은 보기는 오답이다.

---

3부 · 표준 관리

9. 관리 조직의 역할

· 표준 제정과 개정
· 표준 준수 여부 점검
· 표준 예외 승인
· 표준 관련 교육과 지원
· 표준 사전 유지 관리

하지 않는 일도 묻는다. 시스템 성능 튜닝, 프로그램 개발, 서버 운영은 표준 관리 조직의 역할이 아니다.

10. 표준 관리 프로세스

10.1 표준 등록

신규 용어 필요 발생  →  기존 표준 검색  →  없으면 신규 신청
→  표준 담당 검토  →  승인  →  사전 등록  →  공지

기존 검색이 먼저다. 이미 있는 용어를 다시 만들면 이음동의어가 생긴다.

10.2 표준 변경

변경 요청  →  영향도 분석  →  심의·승인  →  반영  →  관련 시스템 통보

영향도 분석에서 그 표준을 참조하는 모든 모델과 시스템을 찾아야 한다.

10.3 표준 예외

모든 것을 표준에 맞출 수는 없다. 외부 기관 연계나 패키지 도입처럼 바꿀 수 없는 경우가 있다.

예외 신청 → 사유 검토 → 승인 → 예외 대장에 등록 → 주기적 재검토

예외를 기록으로 남기는 것이 중요하다. 남기지 않으면 표준 위반인지 승인된 예외인지 구분할 수 없다.

11. 준수 점검

11.1 점검 항목

✓  엔터티명·속성명이 표준 용어를 사용했는가
✓  속성이 표준 도메인을 참조하는가
✓  코드성 속성이 표준 코드를 참조하는가
✓  물리명이 명명 규칙으로 생성되었는가
✓  예외가 승인된 것인가

점검 항목이 아닌 것

✗  모델링 도구의 라이선스가 유효한가
✗  엔터티명의 글자 수가 범위 안에 있는가
✗  각 엔터티의 예상 인스턴스 수가 기준치를 넘지 않는가
✗  모델을 그린 사람이 지정 색상을 썼는가

11.2 준수율 지표

표준 준수율 = (표준을 따른 항목 수 / 전체 항목 수) × 100

왜 재는가 — 표준화 활동의 성과를 정량적으로 확인하고 개선점을 찾기 위해서다. 위반자를 처벌하기 위한 지표가 되면, 수치만 맞추는 형식적 대응을 부른다.

---

4부 · 메타데이터와 데이터 사전

12. 정의

13. 메타데이터의 유형

14. 관리 효과

· 어떤 데이터가 어디에 있는지 찾을 수 있다
· 데이터의 의미를 확인할 수 있다 (같은 이름, 다른 의미를 구분)
· 변경 시 영향 범위를 파악할 수 있다
· 표준 준수 여부를 점검할 수 있다
· 데이터 품질 진단의 기준이 된다

---

15. 한 줄 정리