Kwangmin Kim - 메타데이터 관리 시스템 설계

1 메타데이터 관리 시스템이란 무엇인가

정의: 메타데이터 관리 시스템 (Metadata Management System)

메타데이터 관리 시스템은 조직이 보유한 데이터 자산의 “데이터에 대한 데이터”를 체계적으로 수집, 저장, 유지, 활용하는 플랫폼이다.

범위: 기술 메타데이터 + 비즈니스 메타데이터 + 운영 메타데이터
목적: 데이터 자산의 가시성 확보, 품질 관리, 변경 추적
참조: DAMA-DMBOK2 Chapter 12 (Metadata Management)

“관리 시스템”이라고 부르는 이유는 메타데이터가 한 번 만들어지면 끝나는 정적 산출물이 아니라, 실제 데이터 자산의 변화를 따라 지속적으로 갱신되어야 하는 살아있는 정보이기 때문이다. 시스템이 없으면 메타데이터는 반드시 부패한다(metadata rot).

2 메타데이터의 3가지 유형

설계를 시작하기 전에 어떤 종류의 메타데이터를 다룰 것인지 명확히 해야 한다.

2.1 기술 메타데이터 (Technical Metadata)

DBMS 안에 실제로 존재하는 물리적 구조에 대한 정보다.

테이블명, 칼럼명, 데이터 타입, 길이, NULL 허용 여부
인덱스, 제약조건(PK, FK, UK, CHECK)
파티션 정보, 스토리지 속성
행 수(Row Count), 최근 변경 일시
쿼리 실행 계획 관련 통계 정보

이것은 DBMS의 시스템 카탈로그(information_schema 또는 각 DBMS 전용 딕셔너리)에서 수집 가능하다. 즉, 자동 수집이 원칙이다. 사람이 손으로 입력하는 것은 곧 불일치의 원인이 된다.

2.2 비즈니스 메타데이터 (Business Metadata)

기술 메타데이터만으로는 알 수 없는, 데이터의 의미와 맥락에 대한 정보다.

한글 테이블명/칼럼명 (물리명과 논리명의 매핑)
업무 정의 (이 컬럼이 비즈니스적으로 무엇을 의미하는가)
데이터 오너십 (어느 부서, 누가 책임자인가)
관련 업무 프로세스
비즈니스 규칙 (예: 나이는 0 이상 150 이하, 성별은 M/F만 허용)

이것은 사람이 입력해야 한다. 따라서 입력 부담을 최소화하는 UI/UX 설계가 핵심 과제가 된다.

2.3 운영 메타데이터 (Operational Metadata)

데이터가 실제로 어떻게 사용되고 있는지에 대한 이력 정보다.

데이터 변경 이력 (언제, 누가, 무엇을 바꿨는가)
데이터 접근 로그 (누가 어떤 테이블을 조회했는가)
품질 진단 결과 이력
ETL/데이터 흐름 실행 이력

2.4 유형별 비교

유형	수집 방식	핵심 과제	예시
기술 메타데이터	자동 (시스템 카탈로그)	멀티 DBMS 대응	칼럼 타입, PK/FK, 행 수
비즈니스 메타데이터	수동 (사람 입력)	입력 부담 최소화	한글명, 업무 정의, 오너십
운영 메타데이터	자동 (로그 수집)	대용량 이력 관리	접근 로그, 변경 이력

3 시스템의 범위: 무엇을 포함하고 무엇을 제외할 것인가

설계에서 가장 흔한 실수는 범위를 처음부터 너무 크게 잡거나, 반대로 너무 좁게 잡는 것이다.

3.1 DAMA 프레임워크 기준 포지셔닝

DAMA International의 DMBOK(Data Management Body of Knowledge)에 따르면 데이터 거버넌스는 다음 10개 지식 영역으로 구성된다.

Data Governance (중심)
├── Data Architecture
├── Data Modeling and Design
├── Data Storage and Operations
├── Data Security
├── Data Integration and Interoperability
├── Document and Content Management
├── Reference and Master Data
├── Data Warehousing and Business Intelligence
├── Metadata          <-- 메타데이터 관리 시스템의 주 관심 영역
└── Data Quality      <-- 메타데이터와 강하게 결합됨

메타데이터 관리 시스템은 “Metadata” 영역이 주 관심사지만, 실제로는 Data Quality, Data Architecture, Reference and Master Data와 강하게 결합된다. 이 결합 관계를 처음부터 설계에 반영하지 않으면 나중에 대규모 리팩터링이 필요해진다.

3.2 핵심 범위 결정 기준

메타데이터 관리 시스템의 범위를 결정할 때 다음 4가지 질문에 답해야 한다.

몇 개의 DBMS를 지원할 것인가?

단일 DBMS 환경이라면 해당 DBMS의 시스템 카탈로그 구조에 맞춘 수집기를 만들면 된다. 그러나 실제 엔터프라이즈 환경에서는 Oracle, MySQL, PostgreSQL, MS SQL Server, IBM DB2, Tibero 등이 혼재하는 경우가 많다. 멀티 DBMS 지원 여부는 저장소 스키마 설계와 수집 아키텍처에 근본적인 영향을 준다.

개발/스테이징/운영 환경을 모두 관리할 것인가?

대부분의 조직은 dev, staging, prod 환경을 분리해서 운영한다. 이 세 환경 간의 스키마 불일치(갭)를 메타데이터 시스템이 감지하고 시각화할 수 있다면 매우 큰 운영 가치를 제공한다. 이것이 “갭 분석(Gap Analysis)” 기능이며, 이를 지원하려면 동일 테이블의 여러 환경 버전을 함께 저장하는 데이터 모델이 필요하다.

변경 관리(Change Management)를 포함할 것인가?

단순 조회용 메타데이터 시스템과, 변경 요청-승인-배포 워크플로를 포함하는 메타데이터 관리 시스템은 복잡도가 10배 이상 차이 난다. 변경 관리를 포함한다면 결재 프로세스, 롤백 메커니즘, 변경 이력 저장 구조가 추가로 필요하다.

품질 진단을 포함할 것인가?

메타데이터에 정의된 도메인 규칙과 업무 규칙을 실제 데이터에 대해 검증하는 기능이다. 이것을 포함하면 메타데이터 시스템이 단순한 “카탈로그”에서 “품질 관리 플랫폼”으로 발전한다. 그러나 실제 DBMS에 쿼리를 실행해야 하므로 운영 서버 부하 관리가 설계 과제로 추가된다.

3.3 범위 결정 요약

질문	최소 범위	확장 범위	영향
DBMS 수	단일	멀티 (Oracle, MySQL, PG 등)	수집기 아키텍처, 저장소 스키마
환경 수	운영만	dev/staging/prod	갭 분석, 버전 데이터 모델
변경 관리	미포함	요청-승인-배포 워크플로	결재, 롤백, 이력 구조
품질 진단	미포함	도메인/업무 규칙 검증	쿼리 실행, 부하 관리

4 저장소 DB와 대상 DB의 분리: 핵심 아키텍처 원칙

메타데이터 관리 시스템 설계에서 가장 중요한 원칙 하나를 꼽으라면, 메타데이터를 저장하는 저장소 DB와 메타데이터를 수집하는 대상 DB를 물리적으로 분리하는 것이다.

[메타데이터 저장소 DB]          [대상 DBMS들]
┌─────────────────────┐         ┌──────────────┐
│  스키마 메타데이터   │ <-수집- │  운영 Oracle │
│  공통코드           │         └──────────────┘
│  중요데이터 등급    │         ┌──────────────┐
│  프로파일링 결과    │ <-수집- │  개발 MySQL  │
│  품질 진단 결과     │         └──────────────┘
│  권한 관리          │         ┌──────────────┐
└─────────────────────┘ <-수집- │  DW PostgreSQL│
                                └──────────────┘

4.1 분리가 중요한 이유

운영 서버 보호 메타데이터 수집 쿼리는 information_schema나 시스템 카탈로그에 접근하므로 운영 DB에 최소한의 부하만 주어야 한다. 스키마 수집, 행 수 계산, 프로파일링은 스케줄 기반으로 실행하고, 결과는 저장소 DB에 적재한다. 이후의 모든 조회는 저장소 DB에서만 이뤄진다.

버전 관리 가능 대상 DB의 스키마가 변경되더라도 이전 시점의 스키마 정보가 저장소 DB에 보존된다. 이를 통해 “3개월 전 이 테이블에는 어떤 칼럼이 있었는가”를 조회할 수 있다.

독립적 확장 저장소 DB는 메타데이터의 양이 증가함에 따라 독립적으로 스케일 업/아웃할 수 있다.

5 사용자 역할과 기능 요구사항

메타데이터 관리 시스템의 기능 요구사항은 사용자 역할에 따라 완전히 다르다. 설계 초기에 각 역할의 주요 업무와 필요 기능을 명확히 정의해야 한다.

5.1 개발자 (Developer)

내가 사용해야 하는 테이블이 어디 있고, 어떤 칼럼이 있는가
개발 환경 변경사항을 운영에 어떻게 반영하는가
공통코드 값이 무엇인가
필요 기능: 데이터 조회, 구조 검색, 코드 조회, 변경 요청

5.2 모델러/DA (Data Architect)

전체 데이터 구조의 표준이 지켜지고 있는가
ERD와 실제 DBMS 구조가 일치하는가
중요데이터(개인정보 등)가 어디에 있는가
필요 기능: 표준 관리, 갭 분석, ERD 편집, 중요데이터 등급 부여

5.3 데이터 분석가 (Data Analyst)

분석에 필요한 데이터가 어느 테이블에 있는가
개인정보가 포함된 경우 어떻게 비식별화하는가
필요 기능: 비즈 메타 조회, 데이터 조회(마스킹 포함), BI 연동

5.4 관리자/운영자 (Administrator)

품질 수준이 전반적으로 어느 정도인가
누가 어떤 데이터에 접근했는가
변경 요청의 처리 현황은 어떤가
필요 기능: 품질 모니터링 대시보드, 접근 권한 관리, 변경 승인, 전체 현황 조회

5.5 역할별 기능 매트릭스

기능	개발자	DA	분석가	관리자
데이터 구조 조회	O	O	O	O
비즈니스 메타 입력	-	O	-	-
변경 요청	O	O	-	-
변경 승인	-	O	-	O
갭 분석	-	O	-	O
품질 대시보드	-	-	-	O
데이터 조회 (마스킹)	O	O	O	O

이 역할 정의가 화면 설계와 권한 모델 설계의 기준이 된다.

6 관련 주제

카테고리 내 연결

시리즈 후속