Kwangmin Kim - 공통코드와 마스터 데이터 관리

1 공통코드와 마스터 데이터를 혼용하면 생기는 문제

많은 시스템에서 공통코드 테이블(TB_COMMON_CODE 또는 TB_CODE)이 단일 테이블로 존재하고, 거기에 성별 코드, 주문상태 코드, 국가 코드, 언어 코드, 부서 코드, 제품 카테고리 코드가 모두 들어있다. 관리하기 편하다는 이유로 한 곳에 몰아넣은 것이다.

이 설계는 초기에는 편하지만 두 가지 문제를 만들어낸다.

변경 빈도와 변경 주체가 다른 데이터를 같은 관리 정책으로 다루게 된다. “성별 코드(M/F)”는 거의 바뀌지 않는다. 반면 “부서 코드”는 조직 개편이 있을 때마다 추가/변경/삭제된다. 변경이 잦은 데이터와 거의 변경되지 않는 데이터를 같은 변경 프로세스로 관리하면, 잦은 변경이 필요한 팀은 프로세스가 무겁다고 느끼고, 변경이 드문 팀은 프로세스가 왜 있는지 이해를 못한다.

코드 데이터와 마스터 데이터의 성격 차이를 무시한다. “성별 코드”는 단순히 값과 레이블의 쌍이다. 그러나 “제품”은 코드, 이름, 카테고리, 가격, 스펙, 이미지 URL 등 복잡한 속성을 가진 비즈니스 엔티티다. 이것을 코드 테이블에 넣으려면 억지로 평탄화해야 하고, 그 과정에서 데이터 구조가 왜곡된다.

DMBOK은 레퍼런스 데이터와 마스터 데이터를 별도 지식 영역(Ch.10)으로 분리하여 다루며, “많은 조직이 MDM 필요성에서 출발하여 데이터 거버넌스로 확장한다”고 설명한다 (DAMA International, 2017, Ch.3). 이 글에서는 공통코드와 마스터 데이터를 명확하게 구분하고, 각각에 적합한 관리 방식을 설계하는 방법을 다룬다.

2 공통코드(Master Code): 분류 체계의 관리

2.1 공통코드의 본질

공통코드는 조직 전체에서 공통으로 사용하는 분류 체계다. 성별(남/여), 주문상태(접수/처리중/완료/취소), 결제수단(신용카드/계좌이체/무통장), 배송상태(준비중/발송/배달중/완료) 같은 것들이다.

공통코드의 핵심 특성은 세 가지다.

특성	설명	거버넌스 의미
닫힌 값 집합	정의된 값만 허용 (성별: M/F)	정의되지 않은 값은 무결성 위반
시스템 간 공유	주문/배송/CS 시스템이 동일 코드 참조	변경 시 전체 시스템에 전파
변경 영향 범위	코드 삭제/변경 시 기존 레코드 영향	변경 전 영향도 분석 필수

DAMA 프레임워크 개론에서 레퍼런스 데이터를 “조직의 공통 언어”로 설명한 것이 바로 이 특성들을 가리킨다.

2.2 공통코드 데이터 모델

공통코드를 관리하는 데이터 모델에서 핵심 설계 결정은 코드 그룹(Code Group)과 코드 값(Code Value)을 분리하는 것이다.

코드 그룹 테이블은 코드의 분류 단위를 정의한다. ORDER_STATUS(주문상태), GENDER(성별), PAYMENT_METHOD(결제수단)처럼 코드 집합 자체를 정의한다. 코드 그룹에는 이 그룹이 실제로 어느 테이블의 어느 칼럼에 저장되는지가 연결되어야 한다. 이 연결이 있어야 코드 도메인 품질 진단이 가능하다.

코드 값 테이블은 각 코드 그룹의 실제 값들을 저장한다.

-- 코드 그룹 정의 예시
INSERT INTO TB_CODE_GROUP (group_id, group_name, description)
VALUES ('ORDER_STATUS', '주문상태', '주문의 처리 단계를 나타내는 코드');

-- 코드 값 정의 예시
INSERT INTO TB_CODE_VALUE
  (group_id, code_value, code_label, sort_order,
   effective_from, effective_to, status)
VALUES
  ('ORDER_STATUS', 'PENDING',    '접수',   1, '2020-01-01', NULL, 'ACTIVE'),
  ('ORDER_STATUS', 'PROCESSING', '처리중', 2, '2020-01-01', NULL, 'ACTIVE'),
  ('ORDER_STATUS', 'COMPLETED',  '완료',   3, '2020-01-01', NULL, 'ACTIVE'),
  ('ORDER_STATUS', 'CANCELLED',  '취소',   4, '2020-01-01', NULL, 'ACTIVE');

코드 값에 유효 기간(effective_from, effective_to)을 두는 것이 중요한 설계다. 과거에 유효했지만 현재는 사용하지 않는 코드가 있을 수 있다. 이전에 사용하던 결제수단이 서비스를 종료했을 때 코드 값을 삭제하면 과거 데이터에서 그 코드가 고아 레코드가 된다. 유효 기간을 설정해서 현재는 비활성이지만 과거 데이터 조회에는 여전히 참조 가능하도록 한다.

코드 값에는 환경 구분도 필요하다. 개발 환경에서 새 코드를 추가한 후 운영에 배포되기 전까지 두 환경의 코드 집합이 다른 상태가 된다. 이 상태를 코드 갭으로 감지하고 관리해야 한다.

2.3 공통코드 변경 관리 워크플로

공통코드 변경은 DML(INSERT/UPDATE/DELETE) 작업이다. 구조 관리에서 다룬 스키마 변경(DDL)과는 다른 성격이지만, 동일한 변경 요청 워크플로 패턴을 따른다.

1. 개발자/업무 담당자가 변경 요청 작성
   - 대상 코드 그룹, 추가/수정/삭제할 코드, 변경 사유

2. 작업 규칙 자동 검증
   - 사용 중인 코드 삭제 시: 해당 코드 보유 레코드 수 표시 + 경고
   - 코드 값 중복 체크
   - 유효 기간 정합성 체크

3. DA 검토 -> 승인

4. DML 실행 (개발 환경)

5. 갭 분석으로 운영 배포 요청 자동 생성

2.4 코드 갭 분석의 특수성

코드 갭은 스키마 갭과 성격이 다르다. 스키마 갭은 구조의 차이지만, 코드 갭은 데이터의 차이다. 개발에는 GIFT_CARD 결제수단 코드가 있는데 운영에는 없다. 운영에서 실행되는 코드가 PAYMENT_METHOD = 'GIFT_CARD'를 처리하려고 할 때 코드 데이터가 없으면 참조 오류가 발생한다.

갭 유형	비교 대상	탐지 내용
스키마 갭	테이블/칼럼 구조	칼럼 누락, 타입 불일치, NULL 정책 차이
코드 갭	코드 그룹별 값 목록	개발에만 있는 코드, 운영에만 있는 코드, 레이블 차이

코드 갭 분석은 코드 그룹별로 개발/운영의 코드 값 목록을 비교한다. 개발에만 있는 코드, 운영에만 있는 코드, 양쪽에 있지만 레이블이나 정렬 순서가 다른 코드를 각각 탐지한다.

3 마스터 데이터 관리(MDM): 비즈니스 엔티티의 단일 진실점

3.1 마스터 데이터와 공통코드의 결정적 차이

마스터 데이터는 비즈니스 엔티티의 핵심 정보다. 고객 마스터, 제품 마스터, 공급업체 마스터, 직원 마스터, 조직 마스터가 대표적이다. DMBOK은 마스터 데이터를 “조직 전체에서 공유되는 핵심 엔티티의 정본(Single Source of Truth)”으로 정의한다 (DAMA International, 2017, Ch.10).

공통코드와의 결정적 차이는 두 가지다.

구분	공통코드	마스터 데이터
데이터 복잡도	코드 키 + 레이블 (2~3개 속성)	수십 개의 속성을 가진 엔티티
핵심 과제	닫힌 값 집합의 일관된 관리	여러 시스템에 분산된 정본 통합
변경 단위	코드 값 추가/비활성화	엔티티 속성 갱신, 중복 해소, 정본 결정
예시	성별(M/F), 주문상태, 국가코드	고객, 제품, 공급업체, 직원

CRM에는 고객 기본 정보가 있고, 주문 시스템에는 고객 배송 주소가 있고, 마케팅 플랫폼에는 고객 행동 데이터가 있다. 이 세 곳의 고객 데이터가 서로 다를 때 어느 것이 정본인가를 결정하고 동기화하는 것이 MDM의 핵심 과제다.

3.2 MDM의 3가지 구현 패턴

MDM을 구현하는 방식은 조직의 시스템 환경과 데이터 통합 요구 수준에 따라 달라진다.

패턴	방식	장점	한계
레지스트리(Registry)	소스 데이터는 그대로 두고 교차 참조 테이블만 관리	구현 단순, 소스 시스템 변경 없음	통합 뷰 제공 시 런타임 조인 필요
통합(Consolidation)	소스 데이터를 중앙 저장소에 복사/정제하여 골든 레코드 생성	통합된 분석 뷰 제공	중앙 마스터는 읽기 전용, 소스 시스템 변경 없음
허브(Hub)	중앙 마스터가 데이터의 실제 소유자, 소스 시스템은 마스터 참조	가장 강력한 단일 진실점	구현 복잡도, 조직 변화 관리 비용 최고

레지스트리 방식의 구체적 예시: 고객 ID가 CRM에서는 CRM-001234, 주문 시스템에서는 ORD-USER-5678일 때 이 두 값이 같은 사람임을 교차 참조 테이블이 기록한다. 통합된 고객 뷰를 보려면 런타임에 양쪽 시스템을 조인해야 한다.

3.3 메타데이터 시스템에서의 MDM 역할

메타데이터 관리 시스템에서 MDM 컴포넌트는 허브 방식에 가깝게 설계되는 경우가 많다. 공통 코드가 아닌 마스터 데이터(개별 코드, 시스템 메시지 등)의 변경을 중앙에서 관리하고 각 환경에 배포한다.

예를 들어 시스템 메시지 마스터(TB_MESSAGE)가 있다고 하자. 개발자가 새 메시지를 추가하거나 기존 메시지를 수정할 때 직접 DB에 DML을 실행하는 대신 MDM 변경 요청을 통해 처리한다. 요청이 승인되면 개발 환경에 먼저 적용되고, 검증 후 운영 환경에 배포된다.

MDM 컴포넌트가 공통코드 컴포넌트와 다른 점은, 변경 요청 시 해당 데이터의 코드 칼럼 유효성을 교차 검증한다는 것이다. 메시지 테이블에 메시지 유형 코드(MSG_TYPE_CD) 칼럼이 있다면, 새 메시지를 추가할 때 MSG_TYPE_CD에 입력하는 값이 공통코드로 등록된 유효한 값인지 자동으로 검증한다.

4 코드 도메인: 공통코드와 품질 진단의 연결

4.1 코드 도메인 설계

표준 관리에서 표준 도메인의 유형 중 CODE 타입을 설명했다. 코드 도메인은 특정 코드 그룹의 값만 허용하는 도메인이다. 이 설계의 핵심은 도메인이 코드 그룹 테이블을 직접 참조한다는 것이다.

품질 진단 엔진의 코드 도메인 처리 흐름:

1. 진단 대상 칼럼의 도메인 조회 -> rule_type = 'CODE'
2. rule_value에서 코드 그룹 ID 읽기 (예: 'ORDER_STATUS')
3. 해당 코드 그룹의 현재 유효 코드 값 목록 조회
   (effective_from <= 현재 AND (effective_to IS NULL OR effective_to > 현재))
4. 진단 대상 칼럼 값이 목록에 없는 레코드 -> 오류로 집계

이 구조 덕분에 코드 그룹에 새 코드가 추가되면 도메인 규칙을 수정하지 않아도 자동으로 새 코드가 허용된 값으로 인식된다. 코드가 비활성화되면 품질 진단 시 해당 코드를 사용하는 레코드가 오류로 감지된다.

4.2 코드 변경과 품질 재진단

코드 그룹의 값이 변경될 때 기존 데이터에 미치는 영향을 사전에 파악하는 것이 중요하다. 코드 값을 삭제하거나 비활성화하기 전에 그 코드를 현재 데이터로 갖고 있는 레코드 수를 조회해서 알려주는 기능이 필요하다.

예를 들어 PAYMENT_METHOD 코드 그룹에서 GIFT_CARD 코드를 비활성화하려고 할 때:

시스템이 코드 그룹-칼럼 매핑에서 PAYMENT_METHOD를 사용하는 칼럼 목록을 조회한다
각 칼럼에서 PAYMENT_METHOD = 'GIFT_CARD'인 레코드 수를 집계한다
“TB_ORDER 테이블에 1,234건, TB_REFUND 테이블에 56건이 해당 코드를 사용 중입니다. 비활성화 시 품질 오류로 감지됩니다”라는 경고를 표시한다

이것이 표준 관리에서 다룬 “표준 변경의 영향 관리”가 코드 영역에서 구체적으로 구현되는 방식이다.

5 공통코드/MDM의 멀티 환경 배포 전략

5.1 배포 순서가 중요하다

코드 데이터는 스키마와 달리 데이터 자체가 배포의 대상이다. 스키마 배포는 DDL을 실행하는 것이지만, 코드 배포는 DML을 실행하는 것이다.

개발 환경에서 새 코드를 추가하고 개발을 완료했다면, 운영에 배포할 때 두 가지를 함께 배포해야 한다: 코드를 사용하는 기능의 애플리케이션 배포(스키마 변경 포함)와 코드 데이터 배포.

배포 순서	상황	결과
앱 먼저, 코드 나중	`GIFT_CARD` 처리 로직 배포 -> 코드 데이터 없음	참조 오류 발생
코드 먼저, 앱 나중	`GIFT_CARD` 코드 존재 -> 기존 앱이 미인식	대부분 안전 (미사용 코드일 뿐)

일반적으로 코드 데이터를 먼저 배포하고 애플리케이션을 배포하는 순서가 더 안전하다.

5.2 배포 묶음 관리

코드 데이터 변경과 스키마 변경, 애플리케이션 배포를 하나의 배포 묶음(Release)으로 관리하는 것이 이상적이다. 구조 관리의 변경 요청 시스템에 배포 묶음 개념을 도입해서 관련 변경 요청들을 묶어 순서대로 실행한다.

v2.5 배포 묶음:
  1. [DDL] TB_ORDER에 CANCEL_REASON VARCHAR(500) 칼럼 추가
  2. [DML] ORDER_CANCEL_REASON 코드 그룹 추가
  3. [DML] 주문 취소 사유 코드 값 5개 추가
  4. [APP] 주문 취소 기능 애플리케이션 배포

이 네 가지를 순서대로 실행해야 정합성이 보장된다.

6 실무에서의 코드 관리 안티패턴

6.1 안티패턴 1: 하드코딩된 코드 값

애플리케이션 코드에 if (status.equals("COMPLETED"))처럼 코드 값이 직접 하드코딩되어 있으면, 코드 값이 변경될 때 애플리케이션 코드를 수정하고 재배포해야 한다. 코드 관리 시스템과 애플리케이션의 연결이 끊어진 상태다.

올바른 방식은 애플리케이션이 코드를 코드 관리 시스템에서 읽어오거나, 빌드 시 코드 상수(enum)를 코드 관리 메타데이터에서 자동 생성하는 것이다.

6.2 안티패턴 2: 의미 없는 숫자 코드

코드 값을 1, 2, 3, 4로 정의하고 “1이 접수, 2가 처리중, 3이 완료, 4가 취소”로 운영하는 방식이 있다. 새 코드를 추가할 때 다음 번호를 사용하면 되어 편하지만, 코드 값 자체만 봐서는 의미를 알 수 없다. SQL 쿼리에 WHERE order_status = 3이 나오면 3이 완료인지 외우고 있어야 한다.

코드 값에는 의미가 드러나는 문자열을 사용하는 것이 좋다. PENDING, PROCESSING, COMPLETED, CANCELLED 같이 영문 대문자로 의미를 표현하면 코드 값만 봐도 어느 정도 의미를 파악할 수 있다.

6.3 안티패턴 3: 코드 삭제

더 이상 사용하지 않는 코드를 DB에서 완전히 삭제하면 그 코드를 데이터로 갖고 있는 기존 레코드에서 참조 무결성이 깨진다. 코드 값은 삭제하지 않고 비활성화(effective_to 설정 또는 status = 'INACTIVE' 처리)해야 한다.

이 원칙은 코드 관리 시스템의 작업 규칙으로 강제해야 한다. 삭제 요청이 들어오면 “해당 코드를 보유한 레코드가 존재합니다. 삭제 대신 비활성화를 권장합니다”라는 경고를 표시하고, 삭제가 아닌 비활성화 처리로 안내한다. 구조 관리에서 다룬 “PK 칼럼 삭제 차단” 작업 규칙과 동일한 원리다.

7 관련 주제

카테고리 내 연결