모든 생명과학 기업은 동일한 문제에 직면해 있습니다. 동일한 의약품이 ERP에는 하나의 명칭으로, LIMS(실험실 정보 관리 시스템)에는 또 다른 명칭으로, 규제 인허가(Regulatory) 시스템에는 제3의 명칭으로 등록되어 있습니다. 동일한 임상시험 책임자(Investigator)가 CTMS(임상시험 관리 시스템)에는 한 이름으로, CRM에는 다른 이름으로, 안전성(Safety/약물감시) 데이터베이스에는 또 다른 이름으로 존재합니다. 어느 버전이 맞는지 아는 사람은 아무도 없습니다. 모두가 자신이 가장 신뢰하는 시스템에서 데이터를 복사해 옵니다. 데이터가 일치하지 않아 규제 기관 허가 신청(Regulatory submission)이 지연됩니다. 전체 공급망 및 이력을 온전히 추적할 수 없어 배치(Batch/제조단위) 회수에 몇 시간이면 끝날 일이 며칠씩 걸립니다.

지난 15년 동안 업계의 해법은 인포매티카(Informatica), 렐티오(Reltio), 스티보(Stibo), SAP MDG와 같은 상용 MDM 스위트를 구매하는 것이었습니다. 이들은 훌륭한 제품들입니다. 하지만 연간 라이선스 비용만 50만~200만 달러에 달할 정도로 비싸고, 점차 클라우드 우선(Cloud-first) 정책을 취하면서 규제 대상 데이터를 사내(In-house)에 보관하려는 요건과 충돌하며, 블랙박스 형태로 밸리데이션되어 매칭 규칙을 하나 바꿀 때마다 컨설턴트 비용을 지불해야 합니다.

더 나은 방법이 있습니다. 성숙한 오픈소스 소프트웨어를 기반으로 완벽한 GxP 규제 준수 다중 도메인(Multi-domain) MDM 플랫폼을 구축하고, 자체 온프레미스 데이터센터의 범용 하드웨어에 배포하여 어떠한 FDA나 EMA 실사도 통과할 수 있습니다. 3년 기준 상용 스위트 비용의 약 4분의 1 수준으로 말입니다.

이는 이론적인 연습이 아닙니다. 여기에 설명된 아키텍처의 모든 구성 요소는 규제 대상 데이터를 대규모로 처리하는 조직의 실제 프로덕션 환경에서 운영되고 있습니다. 기술 스택은 PostgreSQL, Kafka, Airflow, Keycloak, 그리고 몇 개의 특화된 Python 서비스로 이루어져 있습니다. 벤더 종속(Vendor lock-in)도 없고, 레코드당 라이선스 비용도 없으며, 데이터가 사옥 밖으로 유출되지도 않습니다.

생명과학 분야의 MDM이 특별한 이유

일반적인 범용 MDM은 마스터 데이터를 ’정합성(Consistency)’의 문제로 다룹니다. 반면 생명과학 MDM은 이를 ’컴플라이언스(규제 준수)’의 문제로 취급합니다.

그 차이는 결코 미묘하지 않습니다:

모든 변경 사항은 추적 가능해야 합니다. FDA가 “누가 이 품목 분류를 변경했고 그 이유는 무엇인가?“라고 물었을 때 타임스탬프, 사용자 ID, 전자서명이 포함된 불변의 감사 추적(Immutable audit trail)을 제시할 수 있어야 합니다. 이는 선택 사항이 아니라 21 CFR Part 11의 법적 요구조건입니다.

매칭 규칙은 규제 위험을 수반합니다. 확률적 매칭(Probabilistic matching) 엔진이 실제로는 다른 사람인 두 환자를 병합(Merge)해 버리면 HIPAA(미국 의료정보보호법) 위반이 발생합니다. 반대로 동일한 한 명의 환자를 두 명으로 분리해 버리면 약물 안전성 시그널 탐지(Safety signal detection) 체계가 무너집니다. 매칭 임계값(Threshold)은 유통이나 금융 서비스와는 비교할 수 없을 정도로 결정적인 무게를 갖습니다.

데이터 무결성은 법적 의무입니다. ALCOA+ — 기인성(Attributable), 가독성(Legible), 동시성(Contemporaneous), 원본성(Original), 정확성(Accurate), 완전성(Complete), 일관성(Consistent), 영속성(Enduring), 가용성(Available) — 는 단순한 데이터 품질 프레임워크가 아닙니다. 규제 당국의 명확한 기대치입니다. MDM 플랫폼은 단순한 운영 정책이 아닌 아키텍처 설계 자체(By design)를 통해 이 모든 원칙을 충족해야 합니다.

생존 규칙(Survivorship rules)은 도메인에 종속적입니다. ’가장 최근에 업데이트된 값이 우선한다(Most recent update wins)’는 규칙은 유통업의 고객 주소에는 적합할 수 있습니다. 하지만 규제인허가(RA) 부서의 확인도 거치지 않은 CRM 사용자가 의약품의 규제 인허가 상태를 덮어써도 되는가의 문제라면 이야기가 전혀 달라집니다.

오픈소스를 선택한다고 해서 이러한 요구사항들이 사라지지는 않습니다. 다만 플랫폼을 설계하는 방식이 근본적으로 달라집니다.

검증된 표준 아키텍처

오픈소스 도구, 통합 패턴, 그리고 생명과학 규제 요구사항 전반을 면밀히 검토하면 명확한 아키텍처적 합의점에 도달하게 됩니다. 이 스택은 6개의 계층으로 구성됩니다.

┌─────────────────────────────────────────────────┐
│              CONSUMING SYSTEMS                  │
│  ERP │ LIMS │ CTMS │ CRM │ MES │ BI │ AI Agents │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│            API & DISTRIBUTION LAYER             │
│  Kong Gateway │ Kafka Events │ Batch Extracts   │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│              MDM CORE ENGINE                    │
│  Golden Records │ Matching │ Stewardship │ Audit│
│  (PostgreSQL + Python microservices)            │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│         DATA QUALITY & GOVERNANCE               │
│  Great Expectations │ OpenMetadata │ Lineage    │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│           INGESTION & STREAMING                 │
│  Debezium CDC │ Apache NiFi │ Airflow │ dbt     │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│              SOURCE SYSTEMS                     │
│  SAP ERP │ Veeva Vault │ LIMS │ CTMS │ LegacyDBs│
└─────────────────────────────────────────────────┘

이들 계층 하부에서는 공통 횡단 서비스(Cross-cutting services)가 신원 인증(Keycloak), 시크릿 관리(HashiCorp Vault), 모니터링(Prometheus + Grafana), 로깅(Loki 또는 ELK)을 처리합니다. 모든 시스템은 쿠버네티스(Kubernetes) 환경에서 구동되며, 소규모 배포에는 k3s를, 대규모 배포에는 RKE2를 적용합니다.

세부 기술 스택

데이터베이스: PostgreSQL 16

PostgreSQL은 MDM 허브를 구축할 때 만장일치로 선택되는 데이터베이스이며, 그 이유는 단순히 ’무료이기 때문’에 그치지 않습니다.

JSONB 컬럼은 생명과학 마스터 데이터가 본질적으로 반정형(Semi-structured) 데이터라는 현실을 완벽하게 수용합니다. 미국의 의약품에는 NDC 코드, 제형(Dosage forms), SPL 라벨링 요구사항이 적용됩니다. 동일한 품목이라도 EU에서는 전혀 다른 규제 속성을 갖습니다. 단일한 관계형 스키마는 이러한 차이 앞에서 무너지기 마련입니다. JSONB를 활용하면 테이블 구조를 수시로 변경(DDL)하지 않고도 도메인별 유연한 속성을 안전하게 저장할 수 있습니다.

pg_trgm 및 fuzzystrmatch 확장은 레벤슈타인 거리(Levenshtein distance), 사운덱스(Soundex), 메타폰(Metaphone)과 같은 내장 퍼지 매칭(Fuzzy matching) 기능을 제공하므로, 결정론적 매칭 및 단순 확률적 매칭 케이스에 별도의 외부 매칭 엔진이 필요하지 않습니다.

**행 수준 보안(Row-Level Security, RLS)**은 데이터베이스 엔진 레벨에서 접근 권한을 분할합니다. QA(품질보증)는 품질 데이터만 볼 수 있고, 인허가(Regulatory) 팀은 등록 인허가 데이터만 보며, 커머셜(영업/마케팅) 팀은 HCP(보건의료전문가) 데이터만 열람합니다. 이는 애플리케이션 레벨의 필터링이 아니라 데이터베이스 엔진 자체에서 강제하는 보안 통제입니다.

pg_audit은 21 CFR Part 11 규정 준수를 위해 모든 DDL 및 DML 구문을 캡처합니다. 이를 추가 전용(Append-only) 감사 테이블과 결합하면, 마스터 레코드에 가해진 모든 변경 이력을 위변조 불가능한(Immutable) 형태로 영구 보존할 수 있습니다.

**논리적 복제(Logical replication)**는 운영 MDM 데이터베이스의 트랜잭션 성능에 영향을 주지 않으면서 리포팅 및 분석용 읽기 전용 복제본(Read replica)을 제공합니다.

이벤트 버스: Apache Kafka

골든 레코드의 모든 변경 사항은 이벤트를 생성합니다. 제품 승인 완료, HCP 레코드 병합, 공급업체 상태 변경 등의 이벤트는 다운스트림 시스템들이 구독(Subscribe)하는 Kafka 토픽을 통해 실시간으로 흐릅니다.

그 누구도 MDM 데이터베이스를 폴링(Polling)하지 않습니다. 변경 사항을 확인하기 위해 매일 밤 배치 추출 작업을 돌리지도 않습니다. MDM 허브가 발행(Publish)하고, 이를 사용하는 소비 시스템들이 구독(Subscribe)합니다. 이것이 바로 2010년대식 구형 통합 아키텍처와 실제로 민첩하게 작동하는 현대적 아키텍처의 차이입니다.

또한 Kafka는 이벤트 재생(Replay)을 위한 내구성 높은 로그(Durable log) 역할을 합니다. 다운스트림 시스템에 장애가 발생해 이벤트를 놓치더라도, 마지막으로 커밋된 오프셋(Offset)부터 다시 소비할 수 있습니다. 이는 모든 시스템이 관련 변경 사항을 누락 없이 수신했음을 입증해야 하는 GxP 규제 환경에서 매우 중요한 요건입니다.

데이터 수집: Debezium + NiFi + Airflow

세 가지 도구, 세 가지 수집 패턴, 중복 없는 명확한 역할 분담:

Debezium은 소스 데이터베이스(SAP, LIMS, CTMS)의 트랜잭션 로그를 직접 읽고 변경 데이터 캡처(CDC, Change Data Capture)를 통해 변경 사항을 준실시간(Near-real-time)으로 Kafka에 전송합니다. 소스 시스템에 성능 부담을 주지 않으며, 별도의 커스텀 추출 스크립트도 필요 없습니다.

Apache NiFi는 파일 기반 수집을 전담합니다. 레거시 시스템의 CSV 파일 드롭, 임상 사이트의 HL7 FHIR 메시지, FDA 및 CMS의 참조 데이터 피드 등을 처리합니다. 시각적 플로우 설계를 통해 코드를 일일이 작성하지 않고도 파이프라인을 구축하고 수정할 수 있습니다.

Apache Airflow는 야간 대사 작업(Reconciliation), 주간 NPI(미국 의료진 고유 식별 번호) 검증, 분기별 참조 데이터 업데이트, 월간 데이터 품질(DQ) 점수표 산출 등 예약된 정기 워크플로우를 오케스트레이션합니다. 재시도(Retry), 모니터링, 알림 기능이 결합된 DAG 기반 스케줄링을 제공합니다.

dbt(Data build tool)는 변환(Transformation) 계층을 담당합니다. 포맷 표준화, 비즈니스 규칙 적용, 스테이징 모델 구축 등을 수행하며 SQL 기반으로 버전 관리 및 자동화된 테스트가 가능합니다.

데이터 품질: Great Expectations

Great Expectations는 시스템의 모든 계층이 참조하는 선언적(Declarative) 규칙 엔진을 제공합니다. 마스터 레코드가 골든 스토어에 적재되기 전, 반드시 다음 검증을 통과해야 합니다:

  • NDC 코드는 올바른 형식의 정확히 10자리 숫자여야 함
  • NPI는 정확히 10자리 숫자여야 하며 CMS NPPES 데이터베이스와 대조 검증이 가능해야 함
  • DEA(마약단속국) 번호는 정규식 패턴과 일치하고 유효한 체크 디지트(Check digit)를 가져야 함
  • 수명주기(Lifecycle) 상태가 ’Marketed(시판)’인 경우 NDC, 제형(Dosage form), 투여 경로(Route of administration)가 모두 필수 입력되어야 함
  • 규제 대상 의약품(Controlled substance)인 경우 DEA 스케줄 등급이 반드시 존재해야 함
  • 공급업체는 최근 12개월 이내에 발급된 유효한 GMP 인증 일자를 보유해야 함

각 규칙은 합격/불합격 판정과 함께 데이터 품질 점수를 생성합니다. 70점 미만의 레코드는 데이터 스튜어드(데이터 관리 책임자)의 수동 검토 큐로 전송되며, 50점 미만의 레코드는 격리(Quarantine)되어 골든 스토어에 절대 유입되지 않습니다.

신원 및 시크릿 관리: Keycloak + HashiCorp Vault

Keycloak은 조직의 기존 Active Directory 또는 LDAP을 MDM 플랫폼과 연동합니다. SSO, 다중 요소 인증(MFA), 역할 기반 접근 제어(RBAC)를 중앙에서 일괄 관리합니다. 데이터 스튜어드가 골든 레코드 변경을 승인할 때, Keycloak이 신원을 인증하고 역할을 확인하며 해당 세션을 기록합니다.

HashiCorp Vault는 시크릿(API 키, 데이터베이스 자격 증명, 암호화 키)을 관리하고 감사 로그 해시 체인을 위한 전송 중 암호화(Transit encryption)를 제공합니다. 시크릿은 자동으로 로테이션되며, 환경 변수나 설정 파일에 자격 증명이 평문으로 남지 않습니다.

검색: OpenSearch

PostgreSQL의 마스터 데이터는 전문 검색(Full-text search)이 아니라 트랜잭션 무결성에 최적화되어 있습니다. OpenSearch는 골든 레코드를 인덱싱하여 스튜어드가 “tablet Japan 500mg released”와 같은 검색어로 질의해도 수 밀리초 만에 결과를 도출할 수 있게 합니다. 또한 엔티티 식별(Entity Resolution)을 위한 퍼지 매칭 인덱스 엔진 역할도 겸합니다.

객체 스토리지: MinIO

품질 증명서(COA), 밸리데이션 보고서, 이미지, 제품 사양서 등은 PostgreSQL에 보관할 데이터가 아닙니다. MinIO는 온프레미스 하드웨어에서 S3 호환 객체 스토리지를 제공합니다. 메타데이터는 데이터베이스에 남고, 실제 파일은 MinIO에 저장됩니다. 저장 시 암호화(Encryption at rest), 버전 관리, 수명주기 정책 등 클라우드 객체 스토리지의 모든 핵심 기능을 클라우드 의존 없이 구현합니다.

마스터 데이터 도메인: 무엇을 언제 마스터링할 것인가

MDM 프로젝트에서 저지르는 가장 큰 실수는 모든 것을 한 번에 마스터링하려는 욕심입니다. 생명과학 기업에는 수십 개의 잠재 도메인이 존재합니다. 거버넌스 투자 대비 가장 높은 투자 수익(ROI)을 거둘 수 있는 2~3개 도메인부터 먼저 시작해야 합니다.

1단계: 제품/원자재 마스터 및 참조 데이터

**제품 마스터(Product Master)**는 가장 자연스러운 출발점입니다. 구조화 수준이 높고 주로 ERP 및 규제 인허가 시스템에 상주하며 명확한 고유 식별자(NDC, GTIN, CAS 번호 등)를 갖추고 있습니다. 조달 오류와 인허가 혼선을 초래하는 중복 제품 레코드를 제거함으로써 즉각적인 ROI를 제공합니다.

대상 엔티티: 완제의약품(Drug products), 원료의약품(API), 첨가제(Excipients), 포장 자재(Packaging components), 의료기기.
핵심 속성: NDC 코드, 제형, 함량/강도(Strength), 투여 경로, 규제 인허가 상태, 수명주기 단계, 유효기한(사용기간), 보관 조건.

**참조 데이터(Reference Data)**는 병행하여 구축합니다. MedDRA, SNOMED CT, ICD-10, RxNorm, ATC 코드, WHO 의약품 사전(WHO Drug Dictionary), ISO 국가 코드, 단위(UOM) 등은 다른 모든 도메인이 참조하는 ’로제타 스톤’입니다. 참조 데이터를 중앙 집중화하면 5개 부서가 동일한 개념에 대해 5가지 서로 다른 코드 체계를 사용하는 혼란을 방지할 수 있습니다.

2단계: 조직(HCP/HCO) 및 공급업체/협력사

HCP/HCO 마스터는 상업화 및 영업(Commercial) 운영에서 가장 큰 고통을 유발하는 데이터 품질 문제를 해결합니다. 동일한 의사가 CRM에 이름이 조금씩 다르게 입력되어 세 개의 서로 다른 레코드로 존재하는 경우가 흔합니다. NPI 기반 결정론적 매칭을 적용하면 이를 즉시 단일 레코드로 통합할 수 있으며, 이름, 주소, 진료과목(Specialty)에 대한 퍼지 매칭으로 잔여 중복을 처리합니다.

대상 엔티티: 보건의료전문가(HCP), 보건의료기관(HCO), 임상시험수탁기관(CRO), 주요 오피니언 리더(KOL).
핵심 속성: NPI, DEA 번호, 주 면허 번호, 전문 진료과목, 소속 계층 구조, KOL 플래그.

**공급업체/협력사 마스터(Vendor/Supplier Master)**는 구매 부서와 품질 부서가 모든 공급업체의 적격성 평가 상태, 감사 이력, GxP 인증 상태에 대해 완벽하게 동일한 단일 진실 공급원(Single source of truth)을 공유하도록 보장합니다.

3단계: 사업장/시설, 임상시험, 제조단위(배치)

**사업장/시설 마스터(Site/Facility Master)**는 제조 공장, 품질관리(QC) 시험실, 물류 창고, 임상시험 기관을 하나로 통합합니다.

**임상시험/프로토콜 마스터(Study/Protocol Master)**는 CTMS, EDC(전자자료수집), 안전성 시스템 전반에 걸쳐 임상시험 참조 데이터를 조화롭게 표준화합니다.

**배치/로트 마스터(Batch/Lot Master)**는 제조 배치 기록을 제품 마스터 데이터와 연계하여 엔드투엔드 추적성을 확보하며, 이는 신속한 제품 회수(Recall) 관리에 필수적입니다.

엔티티 식별(Entity Resolution): 매칭의 실제 작동 원리

기술 스택에 상관없이 모든 MDM 아키텍처는 동일한 2단계 매칭 전략으로 수렴합니다.

1단계: 결정론적 매칭(자동 병합)

고유 식별자를 기반으로 하는 높은 신뢰도의 매칭입니다:

도메인 매칭 키 신뢰도
제품(Product) NDC 코드 완전 일치 100%
원자재(Material) CAS 번호 완전 일치 100%
의료진(HCP) NPI 완전 일치 100%
공급업체(Vendor) DUNS / 사업자등록번호(Tax ID) 완전 일치 100%
사업장/시설(Site) GLN / DUNS 완전 일치 100%

두 레코드가 동일한 NDC 코드를 공유한다면, 두 레코드는 의심의 여지 없이 동일한 제품입니다. 모호함이 없으므로 스튜어드의 수동 검토가 필요하지 않습니다.

2단계: 확률적 매칭(점수 산출 + 스튜어드 검토)

여기서부터가 핵심입니다. 철자 오류, 불완전한 주소, 표기 형식의 차이 등으로 인해 고유 식별자가 공유되지 않을 때는 확률적 점수 산출(Probabilistic scoring)이 필요합니다.

의료진(HCP) 매칭의 경우 일반적인 규칙 세트는 다음과 같이 구성됩니다:

  • 성(Last name) 유사도 ≥ 0.90 (레벤슈타인 거리)
  • 이름(First name) 유사도 ≥ 0.85
  • 주(State/지역) = 동일
  • 진료과목(Specialty) = 동일
  • 종합 점수 ≥ 0.85 → 자동 병합(Auto-merge)
  • 점수 0.60–0.84 → 스튜어드 검토 큐(Steward review queue)
  • 점수 < 0.60 → 불일치로 반려(Reject)

이 단계에서 활용되는 기술은 단순 케이스를 위한 PostgreSQL 내장 fuzzystrmatch 함수부터, 펠레기-선터(Fellegi-Sunter) 가중치를 활용하여 복잡한 다중 필드 매칭을 수행하는 전용 확률적 매칭 라이브러리 Splink(영국 법무부 개발, MIT 라이선스)에 이르기까지 다양합니다.

처음에는 PostgreSQL의 fuzzystrmatch로 시작하십시오. 매칭 정밀도가 충분하지 않아 스튜어드 검토 큐가 지나치게 비대해지면 그때 Splink를 도입하면 됩니다.

생존 규칙(Survivorship Rules)

두 레코드가 병합될 때 어떤 속성값이 살아남아야 할까요? 이는 기술적인 질문이 아닙니다. 도메인별, 그리고 속성별로 명확히 답을 내려야 하는 비즈니스 거버넌스 차원의 문제입니다.

대표적인 패턴은 다음과 같습니다:

  • 연락처 데이터(전화번호, 이메일, 주소): 가장 최근에 검증된 소스가 승리(Most recent verified source wins)
  • 서술형 설명 필드: 가장 완전한 레코드가 승리(Most complete record wins)
  • 품목 분류 및 규제 상태 필드: 규제 인허가 소스가 승리(Regulatory source wins)
  • 스튜어드의 수동 결정은 언제나 자동화 규칙보다 우선(Manual steward decision always overrides)

모든 생존 규칙은 데이터베이스 저장 프로시저(Stored procedure) 깊숙이 묻어두지 말고 반드시 Git으로 버전 관리해야 합니다. FDA가 특정 골든 레코드에 왜 그 값이 부여되었는지 질의할 때, 버전 관리된 규칙, 소스 원본 레코드, 그리고 당시의 타임스탬프를 명확히 제시할 수 있어야 합니다.

규제 컴플라이언스 계층 (타협 불가능한 필수 요건)

21 CFR Part 11: 전자 기록 및 전자 서명

MDM 플랫폼은 전자기록을 생성, 수정, 유지, 배포하는 전자 시스템입니다. 따라서 21 CFR Part 11의 규제 대상에 정확히 부합합니다.

구현 방안:

불변의 감사 추적(Immutable audit trail). 모든 마스터 레코드의 모든 변경 사항은 추가 전용(Append-only) 감사 테이블에 기록됩니다. UPDATE나 DELETE는 절대 발생하지 않습니다. 감사 기록에는 레코드 ID, 변경된 필드, 이전 값, 신규 값, 변경자(사용자 ID, IP 주소, 세션 정보), 타임스탬프, 변경 사유, 워크플로우 단계가 포함됩니다.

전자서명(Electronic signatures). 스튜어드가 골든 레코드 변경을 승인할 때, Keycloak을 통해 자격 증명을 재입력하여 재인증하고 “본인은 이 골든 레코드를 공식 기준 버전으로 승인함”이라는 서명 의미(Signature meaning)를 첨부합니다. 이 서명은 감사 추적에 기록되며 부인할 수 없습니다(Non-repudiation).

시스템 접근 통제(System access controls). 고유 사용자 ID, 역할 기반 접근 권한, 세션 타임아웃, 기기 검증 등은 LDAP/AD와 통합된 Keycloak을 통해 체계적으로 관리됩니다.

ALCOA+ 데이터 무결성

원칙 MDM 플랫폼의 충족 방식
기인성 (Attributable) 모든 레코드 변경에 인증된 사용자 ID 및 소스 시스템 태깅
가독성 (Legible) 표준화된 데이터 포맷, PDF로 내보내기 가능한 가독성 높은 감사 로그
동시성 (Contemporaneous) 애플리케이션 계층 시계가 아닌 NTP 동기화된 데이터베이스 서버 타임스탬프 사용
원본성 (Original) 스테이징 스키마에 수신된 원본 소스 데이터를 있는 그대로 완벽 보존
정확성 (Accurate) 데이터 수집 시 Great Expectations 검증 수행, 공인 외부 소스(NPPES, FDA NDC 디렉토리)와 교차 검증
완전성 (Complete) 도메인별 필수 필드 규칙 강제, 데이터 품질(DQ) 엔진 내 완전성 점수화
일관성 (Consistent) 교차 필드 유효성 검증 규칙 적용, 데이터베이스 레벨의 참조 무결성 강제
영속성 (Enduring) WAL 아카이빙, 시점 복구(PITR), 7년 이상의 규제 데이터 보존 정책 준수
가용성 (Available) 스트리밍 복제, 자동 장애 조치(Failover), 분기별 재해 복구(DR) 훈련 수행

GAMP 5 밸리데이션

바로 이 지점에서 오픈소스의 숨겨진 진가가 발휘됩니다. MDM 플랫폼의 구성 요소들은 GAMP 5 범주에 명확히 분류됩니다:

  • 카테고리 3 (인프라 소프트웨어): PostgreSQL, Kafka, Kubernetes, MinIO — 표준 인프라 상용 제품군입니다. 인프라 적격성 평가(IQ)에서 문서화하면 되며, 핵심 엔진 기능 자체를 처음부터 재검증할 필요는 없습니다.
  • 카테고리 4 (설정 가능한 소프트웨어): Great Expectations 규칙, Airflow DAG, 매칭 설정값 — 기반 소프트웨어가 아닌 비즈니스 설정(Configuration) 자체를 밸리데이션하는 설정형 애플리케이션입니다.
  • 카테고리 5 (커스텀 소프트웨어): 자체 개발한 Python 매칭 마이크로서비스, 스튜어드십 UI, API 계층 — 완벽한 IQ/OQ/PQ(설치/운전/성능 적격성 평가)를 수행해야 하는 영역입니다.

매 변경마다 플랫폼 전체를 재밸리데이션해야 하는 카테고리 4 또는 5 형태의 블랙박스 상용 MDM 스위트와 비교해 보십시오. 오픈소스 기반 아키텍처에서는 조직이 직접 구축하거나 설정한 구성 요소만을 타깃팅하여 밸리데이션할 수 있으며, 대부분의 테스트 케이스를 자동화할 수 있습니다.

보안 아키텍처

네트워크 분할(Network segmentation)을 통해 MDM 서버군을 전용 VLAN에 격리 배치합니다. 방화벽 규칙은 인가된 서브넷의 승인된 포트만을 허용합니다. 모든 외부 통신에는 TLS 1.3을 적용하며, 내부 인증 기관(CA)을 통해 인증서를 발급 및 관리합니다.

데이터베이스 레벨에서는 PostgreSQL의 행 수준 보안(RLS)을 통해 도메인 수준의 접근 제어를 강제합니다. QA 분석가는 제품 마스터 데이터를 읽을 수 있지만 규제 인허가 필드를 편집할 수는 없습니다. 규제 인허가 담당자는 등록 데이터를 수정할 수 있지만 품질 판정을 승인할 수는 없습니다. 감사관(Auditor) 역할에는 전체 데이터와 감사 추적 일체에 대한 읽기 전용 권한이 부여됩니다.

컬럼 수준 암호화를 통해 개인식별정보(PII) 및 건강보호정보(PHI) 필드를 보호합니다. 환자 데이터는 MDM 허브에 유입되기 전에 토큰화(Tokenization)됩니다. 플랫폼은 토큰을 기반으로 매칭을 수행하며, 인가된 임상 시스템만이 토큰을 식별 가능한 원본 데이터로 역토큰화할 수 있습니다. 즉, 식별 가능한 형태의 PHI는 MDM 골든 스토어에 절대 저장되지 않습니다.

단계별 로드맵

0단계: 탐색 및 계획 수립 (3~6주)

가장 중요한 단계이자 대다수의 팀이 건너뛰려다 실패를 겪는 단계입니다.

  • 소스 시스템 전수 조사: 마스터 성격의 데이터를 보유한 모든 시스템을 목록화합니다. 데이터 소유자, 데이터 모델, 인터페이스 방식(API, CDC, 파일 드롭), 데이터 품질 기준선을 문서화합니다.
  • 데이터 품질 프로파일링: 핵심 소스 시스템 3개를 대상으로 Great Expectations 또는 프로파일링 도구를 실행합니다. 중복률, 완전성, 표준 준수율을 측정합니다. 관리되지 않은 마스터 데이터에서는 통상 15~30%의 중복이 발견됩니다.
  • 파일럿 도메인 선정: ERP 데이터가 비교적 정돈되어 있고 비즈니스 케이스가 명확하다면 제품/원자재 도메인을 선택합니다. 영업 마케팅 부서가 중복 데이터로 심각한 고통을 겪고 있다면 HCP/HCO 도메인을 선택합니다.
  • 골든 레코드 스키마 정의: 어떤 속성이 골든 레코드에 포함되어야 하는가? 소스 시스템에 그대로 두어야 할 속성은 무엇인가? 각 속성의 표준 규격(Canonical format)은 무엇인가를 확정합니다.
  • 밸리데이션 전략 초안 수립: IQ/OQ/PQ 템플릿, 위험 기반 접근법(Risk-based approach), 추적성 매트릭스(Traceability matrix)를 수립합니다.

1단계: 기반 구축 및 파일럿 (3~6개월)

  • 인프라 프로비저닝: 3~5대의 서버, 쿠버네티스 클러스터, PostgreSQL HA(기본 노드 + 복제본 2대), Kafka(브로커 3대 클러스터), MinIO, Keycloak, Kong 게이트웨이 구축.
  • 보안 기준선 배포: 전 구간 TLS 적용, 유휴 데이터 암호화(Encryption at rest), RBAC, 감사 로깅 활성화.
  • 3~5개 소스 시스템 수집 파이프라인 구축: 데이터베이스는 Debezium CDC, 파일은 NiFi, 정기 추출은 Airflow 적용.
  • 결정론적 매칭 구현: 고유 식별자(NDC, NPI, CAS, DUNS) 기반의 완전 일치 규칙부터 적용.
  • 데이터 스튜어드십 UI 개발: 데이터 스튜어드가 매칭 대기 큐를 확인하고, 화면에서 양자 비교(Side-by-side diff)를 검토하며, 전자서명과 함께 병합을 승인 또는 거부할 수 있는 React 애플리케이션 구축.
  • IQ/OQ 수행: 핵심 플랫폼 구성 요소에 대한 밸리데이션 실행.
  • 파일럿 도메인 실운영(Go-live): 첫 번째 골든 레코드가 다운스트림 시스템으로 전송되기 시작.

2단계: 도메인 확장 및 거버넌스 안착 (6~12개월)

  • 2~3개 도메인 추가 확장: HCP/HCO, 공급업체(Vendor), 사업장(Site).
  • 확률적 매칭 구현: 결정론적 규칙 위에 Splink 또는 자체 Python 점수화 로직을 계층화하여 적용.
  • 데이터 품질 대시보드 구축: 경영진 및 실무진 가시성 확보를 위해 Great Expectations 결과를 Grafana로 연동.
  • 다운스트림 시스템 통합: ERP, CRM, LIMS, 데이터 웨어하우스를 위한 Kafka 이벤트 구독 체계 구축.
  • 도메인 거버넌스 위원회 발족: 데이터 정의, 매칭 규칙, 스튜어드십 SLA를 총괄 소유하는 비즈니스 주도 협의체 구성.

3단계: 고도화 및 밸리데이션 완성 (12~18개월)

  • 잔여 도메인 추가: 임상시험(Study), 검체(Sample), 제조단위(Batch).
  • 머신러닝(ML) 보조 매칭 적용: 마스터 데이터 변경에 대한 이상치 탐지(Anomaly detection), 자체 튜닝되는 매칭 임계값 알고리즘 도입.
  • 데이터 카탈로그 배포: 데이터 계보(Lineage), 비즈니스 용어집(Glossary), 영향도 분석을 위한 OpenMetadata 도입.
  • GAMP 5 밸리데이션 완성: 전체 도메인에 대한 완전한 IQ/OQ/PQ 문서화 완료.
  • 스토리지 계층화(Storage tiering): 핫 스토리지(NVMe, 2년 보관), 웜 스토리지(SAS, 5년 보관), 콜드 스토리지(테이프/LTO, 15~25년 규제 장기 보관).

실제 비용 분석: 객관적 수치

소프트웨어 라이선스 비용: $0

구성 요소 상용 제품 대안 연간 라이선스 절감액
MDM 플랫폼 Informatica MDM / Reltio / Stibo $500K–$2M
ETL 도구 Informatica PowerCenter / Talend Enterprise $200K–$500K
데이터 카탈로그 Collibra / Alation $150K–$400K
컨테이너 플랫폼 Red Hat OpenShift $100K–$300K
연간 총 절감액 $950K–$3.2M

인프라 비용: 일회성 약 $100K

항목 비용
데이터베이스 서버 3대 (x86, 128GB RAM, 4TB NVMe) $45,000
애플리케이션 서버 3대 (64GB RAM) $27,000
재해 복구(DR) 서버 1대 (저사양) $12,000
NAS 스토리지 (20TB, ZFS) $8,000
네트워크 장비 (스위치, 방화벽 구성) $5,000
합계 ~$97,000

3개년 총소유비용(TCO)

접근 방식 3개년 총액
상용 MDM 스위트 $3M–$8M+
오픈소스 자체 구축 $500K–$700K
절감액 $2.5M–$7.3M

주요 비용은 소프트웨어가 아니라 인력에 투입됩니다. 시니어 데이터 엔지니어 2~3명, 아키텍트 1명, 데이터 스튜어드 1명, 밸리데이션 전문가 1명에 예산을 배정하십시오. 인포매티카 설정법을 아는 고가의 컨설턴트 대신 Kafka, PostgreSQL, Python을 깊이 이해하는 유능한 엔지니어를 채용해야 합니다.

월요일 아침에 당장 시작해야 할 일

  1. 데이터 거버넌스 위원회를 결성하십시오. 규제 인허가(RA), 품질(QA), 커머셜, IT, 연구개발(R&D) 부서를 한자리에 모으십시오. 위원장(CDO 또는 품질 부문 부사장)을 선임하십시오. MDM에서 가장 어려운 부분은 기술이 아닙니다. 비즈니스 조직들이 ’골든(Golden)’의 진정한 의미가 무엇인지 합의하고, 누가 최종 결정권을 가질 것인지 정하는 것입니다.

  2. 상위 3대 소스 시스템을 프로파일링하십시오. ERP, CRM, LIMS를 대상으로 중복 데이터 분석을 수행하십시오. 문제의 크기를 숫자로 측정하십시오. 경영진에게 그 수치를 보여주십시오. “현재 제품 마스터의 23%, 의료진(HCP) 데이터의 31%가 중복 상태입니다”라는 명확한 데이터야말로 예산 승인을 이끌어내는 가장 확실한 비즈니스 근거가 됩니다.

  3. 샌드박스 환경을 신속히 구성하십시오. 가상머신(VM) 3대, PostgreSQL, Kafka, Airflow면 충분합니다. 주말 동안 한 소스 시스템에서 스테이징 테이블까지 이어지는 실제 동작 파이프라인을 구축하십시오. 시스템을 확장하기 전에 이 기술 스택이 확실히 동작함을 먼저 증명하십시오.

  4. 파일럿 도메인을 선정하십시오. 구조화되어 있고 위험도가 낮으며 빠른 성과(Quick win)를 원한다면 제품/원자재 도메인을 선택하십시오. 커머셜 부서의 즉각적인 갈증 해소가 시급하다면 HCP/HCO를 선택하십시오. 어느 쪽이든 상관없습니다. 이 플랫폼은 특정 도메인에 종속되지 않습니다.

  5. 작게 시작하고, 빠르게 제공하며, 단계적으로 확장하십시오. 3개월 안에 1개 도메인의 골든 레코드를 완성하십시오. 12개월 안에 3개 도메인으로 넓히십시오. 18개월 안에 전체 플랫폼을 완성하십시오. 각 단계마다 측정 가능한 실질적 가치를 입증하여 다음 단계 투자의 타당성을 지속적으로 확보해야 합니다.

MDM에서 성공하는 기업은 가장 막대한 예산을 쓰거나 가장 화려한 도구를 사들인 곳이 아닙니다. MDM을 ’기술 플랫폼이 뒷받침되는 거버넌스 프로젝트’로 대하는 기업입니다. ’거버넌스를 뒤늦게 덧붙인 기술 프로젝트’로 접근해서는 안 됩니다. 거버넌스를 먼저 세우십시오. 기술은 자연스럽게 따라올 것입니다.

관련 글