기준 정보(Master Data)와 트랜잭션 데이터(Transaction Data)의 구조적 차이 및 물리적 데이터 모델링 방법론

성공적인 마스터 데이터 관리(MDM) 허브를 구축하여 전사적 데이터 사일로(Data Silo)를 타파하기 위해서는, 가장 먼저 ‘어떤 데이터를 중앙에서 통제할 것인가’에 대한 아키텍처 관점의 명확한 기준이 필요합니다.

엔터프라이즈 환경에서 발생하는 모든 데이터는 그 속성과 생명주기에 따라 크게 두 가지 축으로 나뉩니다. 본 문서에서는 데이터 아키텍처(DA) 설계의 핵심인 기준 정보(Master Data)와 트랜잭션 데이터(Transaction Data)의 본질적 차이를 분석하고, 실무적인 물리적 데이터베이스 모델링(Data Modeling) 방법론을 제시합니다.

1. 생명주기(Lifecycle)와 발생 빈도에 따른 구조적 차이

시스템을 설계할 때 데이터를 명확히 분류하지 않으면 스토리지 낭비와 성능 저하(Performance Degradation)가 필연적으로 발생합니다.

  • 트랜잭션 데이터(Transaction Data): 비즈니스 프로세스에 의해 매 순간 발생하는 이벤트 기록입니다. (예: 고객의 상품 구매 내역, 센서의 온도 측정 로그, 웹사이트 클릭 기록). 데이터의 발생 빈도가 매우 높고 대용량(High Volume)이며, 특정 시점의 사실을 기록하므로 시계열적(Time-series) 특징을 갖습니다.
  • 기준 정보 / 마스터 데이터(Master Data): 트랜잭션 데이터가 참조하는 비즈니스의 주체이자 객체입니다. (예: 고객 정보, 상품 스펙, 조직도, 계정과목). 데이터의 변동성(Volatility)이 낮고 시스템 내에서 장기적인 생명주기를 가지며, 기업 전반에 걸쳐 공통된 식별 기준으로 사용됩니다.

2. 식별자(Identifier) 체계와 관계형 설계(ERD) 전략

데이터베이스 모델링에서 가장 중요한 것은 식별자(PK, Primary Key)의 논리적 설계입니다. 두 데이터는 이 PK를 구성하는 방식에서 극명한 차이를 보입니다.

A. 마스터 데이터의 무결성을 위한 인조 식별자(Surrogate Key)

마스터 데이터의 식별자는 절대 변하지 않는 유일성(Uniqueness)을 확보해야 합니다. 실무에서는 주민등록번호나 사업자번호 같은 의미 있는 속성(Natural Key)보다는, 시스템이 채번하는 무의미한 일련번호 형태의 인조 식별자(Surrogate Key) (예: 사원번호 ‘EMP-001’, 상품코드 ‘PRD-1004’)를 PK로 설계하는 것이 원칙입니다. 이는 외부 요인으로 인해 키 값이 변경되어 시스템 전체의 참조 무결성(Referential Integrity)이 깨지는 것을 방지합니다.

B. 트랜잭션 데이터의 외래키(FK) 참조 모델링

트랜잭션 데이터는 독자적으로 존재할 수 없습니다. ‘누가, 무엇을’ 했는지 명시하기 위해 반드시 마스터 데이터의 PK를 외래키(FK, Foreign Key)로 참조해야 합니다. 트랜잭션 테이블의 식별자는 주로 ‘발생 일시’나 ‘순번’을 마스터 데이터의 FK와 결합한 복합키(Composite Key) 형태로 설계되어 거래의 순서와 시점을 엄격하게 통제합니다.

3. 정규화(Normalization)와 차원 모델링(Dimensional Modeling) 관점

데이터가 저장되는 목적(OLTP vs OLAP)에 따라서도 두 데이터의 취급 방식은 완전히 달라집니다.

  • OLTP (온라인 트랜잭션 처리) 환경: 데이터의 입력과 수정이 빈번한 운영 시스템에서는 마스터 데이터의 중복을 제거하기 위해 엄격한 제3정규화(3NF) 이상을 적용해야 합니다. 반면, 트랜잭션 데이터는 빠른 쓰기(Write) 성능을 위해 정규화를 최소화하고 발생 시점의 스냅샷을 빠르게 적재하는 데 집중합니다.
  • OLAP (온라인 분석 처리) 환경: 데이터를 분석하는 데이터 웨어하우스(DW) 환경에서는 스타 스키마(Star Schema) 구조를 사용합니다. 이때 마스터 데이터는 분석의 기준이 되는 ‘차원 테이블(Dimension Table)’ 역할을 수행하고, 트랜잭션 데이터는 집계 대상인 수치(매출액, 클릭수 등)를 담은 ‘팩트 테이블(Fact Table)’ 역할을 수행합니다.

4. 데이터 이력 관리(History Management) 방식의 차이

데이터의 상태가 변했을 때 이를 추적하는 방식 역시 설계의 핵심입니다.

트랜잭션 데이터는 발생 시점의 확정된 사실이므로 수정(Update)이나 삭제(Delete)가 원칙적으로 발생하지 않으며, 지속적인 삽입(Insert-only/Append)만 일어납니다.

반면 마스터 데이터는 고객의 주소 변경, 부서의 통폐합, 제품의 단가 변경 등 속성 값의 변화가 발생합니다. 과거의 트랜잭션 기록이 변경된 마스터 데이터를 참조하여 통계가 왜곡되는 것을 막기 위해, 데이터 아키텍트는 ‘서서히 변화하는 차원(SCD, Slowly Changing Dimension)’ 기법을 적용해야 합니다. 특히 실무에서는 기존 레코드를 만료 처리하고 새로운 레코드를 생성하여 선분 이력(시작일자~종료일자)을 관리하는 ‘SCD Type 2’ 모델링이 가장 널리 사용됩니다.

결론

마스터 데이터와 트랜잭션 데이터의 명확한 구조적 분리와 물리적 모델링은 데이터 거버넌스의 뼈대를 세우는 가장 중요한 작업입니다. 이 뼈대가 완벽하게 설계되었다면, 다음으로 확인해야 할 것은 그 뼈대 안에 흐르는 데이터 자체의 ‘수질’입니다.

다음 장에서는 데이터 거버넌스와 MDM의 실질적인 성공을 좌우하는 핵심 모니터링 체계, ‘데이터 품질 관리(DQM, Data Quality Management)의 핵심 지표와 데이터 프로파일링(Data Profiling) 기법’에 대해 심도 있게 다루겠습니다.

댓글 남기기