Saram ConsultingMasterControl은 2026년 5월, 생명과학 분야를 위한 새로운 마스터 데이터 관리(MDM) 제품인 MasterControl Catalog를 소개하는 블로그 글을 게시했습니다. 마케팅 메시지는 익숙합니다. 제품(Products), 장비(Equipment), 공급업체(Suppliers), 고객(Clients)을 위한 사전 구성된 카탈로그 유형, 필드 수준의 감사 추적(Audit trail), 플랫폼 수준의 데이터 흐름, 그리고 MasterControl 생태계 내부에서 작동하는 ’단일 진실 공급원(Single Source of Truth)’입니다.
해당 글은 규제 실사를 준비하던 품질 책임자가 동일한 공급업체에 대한 서로 다른 3가지 버전의 레코드가 2개의 시스템과 스프레드시트에 분산되어 있는 상황을 상상해 보라고 권유합니다. 이는 실제로 빈번하게 발생하는 심각한 문제입니다. 모든 생명과학 기업이 이 문제를 겪고 있습니다. 마스터 데이터 관리가 필요한지 여부는 논쟁거리가 아닙니다. 당연히 필요합니다. 핵심 질문은, 가장 중요한 핵심 데이터를 타사의 플랫폼에 결합시키는 ’벤더 호스팅 카탈로그’가 과연 올바른 해답인가 하는 점입니다.
MasterControl의 글에서 주장하는 몇 가지 사항은 면밀히 검토해 볼 가치가 있습니다. 마케팅 용어 뒤에 가려진 트레이드오프(trade-off)를 명확히 드러내기 때문입니다.
“사전 구성되고 확장 가능한 카탈로그 유형”
MasterControl은 제품, 장비, 공급업체, 고객을 위한 사전 구축 템플릿을 제공하며, 각 템플릿에는 “비즈니스에 맞게 맞춤 구성”할 수 있는 사전 정의된 필드가 포함되어 있습니다. 언뜻 들으면 시간을 크게 절약해 줄 것처럼 보입니다. 그러나 실제로는 제약 조건에 불과합니다.
사전 구성된 템플릿에는 데이터 모델이 어떠해야 하는지에 대한 가정이 내재되어 있습니다. 그리고 그 가정은 귀사의 특화된 운영 방식이 아니라 일반적인 생명과학 제조업체를 기준으로 작성된 것입니다. 사전 정의된 템플릿에 커스텀 필드를 추가할 때, 귀사는 자체적인 스키마를 소유하는 것이 아니라 타인의 스키마를 확장하고 있을 뿐입니다. 귀사의 운영 로직은 그들의 데이터 모델, 필드 타입, 유효성 검증 규칙, 명명 규칙에 종속됩니다.
실제로 이는 엔터프라이즈 아키텍트들이 **스키마 포섭(schema captivity)**이라고 부르는 현상을 초래합니다. 데이터 정의가 벤더의 시스템 내부에 종속됩니다. 비즈니스 규칙은 벤더의 필드 구조를 참조합니다. 연동 체계는 벤더의 API 계약에 의존합니다. 제품 변형을 위한 새로운 속성, 특정 지역 시장을 위한 상이한 분류 체계, 또는 벤더의 템플릿에 맞지 않는 규제 요건 등 변경이 필요할 때마다 벤더의 플랫폼이 이를 지원할 때까지 기다리거나 기형적인 우회책을 써야 합니다.
마스터 데이터 아키텍처는 이와 정반대여야 합니다. 데이터 모델은 조직의 가장 전략적인 IT 자산입니다. 데이터 모델은 조직이 제품, 공급업체, 사업장, 인력을 어떻게 바라보고 정의하는지를 규정합니다. 이러한 모델은 “일반적인” 생명과학 기업에 무엇이 필요할 것인가에 대한 벤더의 추측에서 물려받는 것이 아니라, 귀사의 고유한 비즈니스를 중심으로 설계되어야 합니다.
PostgreSQL이나 직접 제어 가능한 유사 데이터베이스에서 실행되는 자체 데이터 모델을 소유하면 스키마, 관계, 유효성 검증 규칙, 비즈니스 로직을 처음부터 직접 정의할 수 있습니다. 물론 초기 구축에는 더 많은 노력이 듭니다. 그러나 그 결과물은 타인이 추상화한 결과물이 아니라, 귀사의 실제 운영을 정확히 반영하는 데이터 아키텍처가 됩니다.
“플랫폼 수준의 데이터 흐름”
MasterControl의 글에서는 “플랫폼 수준의 데이터 흐름”을 하나의 주요 기능으로 설명합니다. 즉, 정보가 “모든 MasterControl 애플리케이션 및 워크플로 전반에 걸쳐 일관되고 접근 가능한 상태를 유지한다”는 것입니다. 이 문장을 다시 한번 천천히 읽어보십시오. 정보가 MasterControl 플랫폼 내에서 흐른다는 뜻이지, 귀사가 이미 보유하고 있는 기존 시스템으로 흘러간다는 뜻이 아닙니다.
생명과학 기업은 방대하고 이기종으로 구성된 기술 스택을 운영합니다. SAP나 Oracle의 레거시 ERP, 수십 년간 실험실 정보학 분야에 자리 잡아온 벤더들의 전자연구노트(ELN), 품질관리시스템(QMS), 임상시험관리시스템(CTMS), 제조실행시스템(MES), 문서관리시스템(DMS), 약물감시(PV) 데이터베이스 등이 혼재되어 있습니다. 이 중 일부는 클라우드 기반이고, 일부는 온프레미스이며, 일부는 자체 구축된 시스템입니다. 심지어 15년 동안 운영되어 아무도 손대고 싶어 하지 않는 시스템도 존재합니다.
단일 벤더의 생태계 내부 흐름만을 우선시하는 마스터 데이터 전략은 ’폐쇄된 정원(Walled Garden)’을 만듭니다. 정원 내부에서는 데이터가 매끄럽게 흐릅니다. 하지만 정원 밖에서는 해당 벤더의 플랫폼이 지원하도록 설계되지 않은 통합 연동을 직접 구축해야 하거나, 심지어 기본적으로 연결되어 있어야 마땅한 시스템들을 연결하기 위해 ’특화 통합 티어(specialized integration tiers)’에 추가 비용을 지불해야 합니다.
이에 대한 대안은 독립적인 데이터 추상화 계층(independent data abstraction layer)입니다. 표준 API(REST, GraphQL, 헬스케어 상호운용성을 위한 FHIR 등)와 이벤트 스트림(어떤 시스템이든 구독할 수 있는 Kafka 토픽)을 통해 골든 레코드(Golden Record, 단일 기준 데이터)를 발행하는 중앙 집중식 MDM 허브를 구축하는 것입니다. 이 허브는 데이터를 소비하는 시스템이 MasterControl 제품이든, Veeva Vault이든, 자체 구축 데이터베이스이든, AI 에이전트이든 상관하지 않습니다. 허브는 골든 레코드를 발행하고, 소비 시스템은 필요한 데이터를 가져갈 뿐입니다.
이것이 바로 데이터를 내부에서만 유통하는 ’플랫폼’과 엔터프라이즈 전반으로 데이터를 유통하는 ’아키텍처’의 차이입니다.
“AI 기반 인사이트의 토대”
MasterControl의 글에서는 “정제되고 잘 거버넌스된 마스터 데이터야말로 의미 있는 AI 기반 카탈로그 분석을 가능하게 하는 원동력”이라고 주장합니다. 이는 사실입니다. 하지만 역설적이게도 이는 해당 데이터를 벤더 플랫폼 내부에 두어서는 안 된다는 가장 강력한 논거이기도 합니다.
모든 생명과학 기업은 AI를 도입하게 될 것입니다. 관건은 다른 모든 MasterControl 고객과 동일하게 벤더가 구조화한 데이터 위에서 동일한 AI 모델을 실행할 것인가, 아니면 직접 제어하는 데이터를 바탕으로 독점적인 자체 AI 역량을 구축할 것인가입니다.
마스터 데이터가 벤더의 플랫폼 내에 존재할 때, AI의 접근은 벤더의 API, 벤더의 데이터 구조, 그리고 벤더의 제품 로드맵에 의해 매개되고 제한됩니다. 마스터 데이터를 실시간 제조 센서 데이터와 결합하거나, 공급업체 적격성 평가 이력과 QMS의 일탈 발생률을 상호 연관 분석하거나, 제품에서 유효 성분, 공급업체, 제조 현장, 규제 허가 신청서로 이어지는 커스텀 그래프 순회(graph traversal)를 구축하는 작업은 벤더가 해당 쿼리 패턴을 명시적으로 지원하지 않는 한 불가능합니다.
자체 데이터 인프라를 직접 소유하면 벤더가 예상하지 못한 방식으로 데이터 스트림을 결합하는 맞춤형 통합 파이프라인을 구축할 수 있습니다. 골든 레코드를 지식 그래프(Knowledge Graph)에 공급할 수 있습니다. 타사 API를 거치지 않고도 자체 마스터 데이터로 도메인 특화 모델을 파인튜닝하거나 학습시킬 수 있습니다. 또한 거버넌스와 감사 추적이 적용된 인터페이스를 통해 정제된 데이터셋을 데이터 과학 팀에 안전하게 제공할 수 있습니다.
AI 시대는 경쟁사와 똑같이 사전 패키징된 데이터 구조 위에서 똑같이 사전 패키징된 AI를 사용하는 기업에 보상을 안겨주지 않습니다. 독점적인 데이터를 독점적인 방식으로 결합하는 기업에 진정한 경쟁 우위를 제공합니다. 그리고 그 출발점은 바로 데이터를 직접 소유하는 것입니다.
“규제 기관 수준의 감사 추적 (Regulatory-Grade Audit Trail)”
MasterControl은 필드 수준의 변경 이력, 생애주기 상태 추적, 그리고 “모든 상호작용에 대한 완전한 추적성”을 제공합니다. 이는 반드시 필요한 기능입니다. 하지만 이는 규제 환경에서 당연히 갖추어야 할 기본 요건(table stakes)일 뿐, 차별화 요소가 아닙니다.
벤더 플랫폼에서 실행되든 오픈소스 소프트웨어에서 실행되든, 모든 MDM 구현체는 규제 대상 데이터에 대해 불변의 감사 추적(Immutable Audit Trail), 전자 서명, 수명주기 관리를 제공해야 합니다. 문제는 감사 추적이 존재하는가가 아니라, 그것을 누가 통제하는가입니다.
벤더 마케팅이 은폐하기 쉬운 규제 현실은 다음과 같습니다. FDA가 귀사의 시설을 실사하고 마스터 데이터에서 데이터 완전성(Data Integrity) 문제를 발견했을 때, 지적 사항(finding)은 소프트웨어 벤더에게 발부되지 않습니다. 바로 귀사에 발부됩니다. 법적 책임도 귀사의 몫이며, 시정 조치와 CAPA(시정 및 예방 조치) 역시 전적으로 귀사의 몫입니다.
감사 추적이 벤더의 블랙박스 내부에 갇혀 있다면, 규제 방어(Regulatory Defense)에 필요한 증거를 오로지 벤더의 구현 방식에 의존해야 합니다. 감사 로직을 직접 수정할 수 없습니다. 귀사 고유의 운영 환경에서 발생하는 예외 사례(edge case)를 포괄하도록 확장할 수도 없습니다. 벤더의 문서를 맹신하지 않고서는 데이터의 완전성을 독자적으로 검증할 방법도 없습니다. 게다가 벤더가 플랫폼을 변경하거나 기능을 중단하거나 가격을 인상하면, 원하든 원치 않든 귀사의 감사 인프라까지 함께 흔들리게 됩니다.
PostgreSQL의 pg_audit 확장 프로그램, 추가 전용(append-only) 이력 테이블, Keycloak이나 유사한 아이덴티티 플랫폼을 기반으로 구축된 전자 서명 워크플로 등을 활용하여 감사 추적 구현체를 직접 소유하면, 모든 변경 사항이 어떻게 캡처되고 저장되며 조회되는지에 대한 완전한 가시성을 확보할 수 있습니다. 밸리데이션 게이트를 직접 정의하고, 데이터 보존 정책을 완전히 제어할 수 있습니다. 직접 구축했기 때문에 언제 어떤 감사관이 방문하더라도 시스템의 정확한 동작 메커니즘을 증명해 보일 수 있습니다.
MasterControl 게시글에서 타당하게 짚은 점
공정하게 평가하자면, MasterControl의 글은 실제 존재하는 문제들을 정확히 짚어냈습니다:
데이터의 무질서(Data chaos)는 실재하는 위험입니다. 중복 레코드, 불일치하는 공급업체 정보, 파편화된 제품 데이터는 실질적인 컴플라이언스 리스크와 운영상의 비효율을 초래합니다. 이 점에 대해서는 이견이 없습니다.
MDM은 단순한 기술이 아니라 하나의 원칙(Discipline)입니다. 해당 글은 MDM이 데이터 소유권, 거버넌스, 조직적 헌신을 필요로 한다는 점을 올바르게 지적했습니다. 거버넌스가 결여된 도구는 그저 또 하나의 데이터베이스에 불과합니다.
정제된 데이터는 AI의 토대입니다. 전적으로 맞는 말입니다. 다만 의견이 갈리는 부분은 그 정제된 데이터가 어디에 저장되어야 하며, 누가 그것을 제어해야 하는가입니다.
확장성(Scalability)은 매우 중요합니다. 해당 글은 MasterControl이 “수백만 건의 레코드를 처리한다”고 강조합니다. PostgreSQL 역시 마찬가지입니다. 올바르게 설계된 데이터베이스라면 모두 가능한 일입니다. 확장성은 엔지니어링의 문제이지, 특정 벤더만의 전유물이 아닙니다.
진정한 결정: 두 가지 전략의 갈림길
선택지는 MasterControl을 도입할 것인가 아무것도 하지 않을 것인가의 문제가 아닙니다. 근본적으로 상이한 두 가지 전략 간의 선택입니다:
전략 A: 플랫폼 종속형 MDM (Platform-dependent MDM). 벤더의 사전 구성된 데이터 모델을 채택하고, 골든 레코드를 벤더의 플랫폼 내에 저장하며, 연동을 위해 벤더의 API를 사용하고, 향후 기능 확장을 벤더의 로드맵에 의존합니다. 데이터는 벤더의 생태계 내에서는 원활히 흐릅니다. 그러나 AI 역량은 벤더 플랫폼의 한계에 갇히게 되며, 규제 컴플라이언스는 전적으로 벤더의 구현 방식에 종속됩니다.
전략 B: 소유 기반 MDM 아키텍처 (Owned MDM architecture). 오픈소스 인프라(PostgreSQL, Kafka, Airflow)를 기반으로 자체 데이터 모델을 직접 설계하고, 직접 제어하는 데이터베이스에 골든 레코드를 보관하며, 표준 API와 이벤트 스트림을 통해 발행하고, 직접 소유한 데이터를 기반으로 독자적인 AI 역량을 구축합니다. 데이터는 엔터프라이즈 전체에 걸쳐 자유롭게 흐릅니다. AI 역량의 한계는 오직 엔지니어링 역량에 의해서만 결정됩니다. 규제 컴플라이언스는 완전히 투명하고 감사 가능한 자체 구현체로 보장됩니다.
전략 B는 초기 아키텍처 및 엔지니어링에 더 많은 투자를 필요로 합니다. 데이터 모델링, 연동 패턴, GxP 컴플라이언스를 깊이 이해하는 팀이 필수적입니다. 또한 거버넌스, 즉 데이터 거버넌스 협의체, 도메인 스튜어드, 매칭 규칙(matching rules), 생존 로직(survivorship logic) 체계가 마련되어야 합니다.
하지만 전략 B는 벤더 플랫폼이 결코 제공할 수 없는 가치를 선사합니다. 바로 가장 핵심적인 기업 데이터 자산에 대한 완전한 소유권입니다.
AI 시대에 가장 유리한 고지를 선점할 생명과학 기업은 사전 구성된 카탈로그를 가장 많이 보유한 기업이 아닙니다. 마스터 데이터를 타사의 소프트웨어 안에 포함된 일개 부가 기능이 아니라, 독립적이고 거버넌스가 확립된 전사적 자산으로 대우하는 기업입니다.
동일한 공급업체 레코드의 3가지 버전을 앞에 두고 고민하는 품질 관리자에게 필요한 것은 또 다른 새로운 플랫폼이 아닙니다. 바로 올바른 아키텍처입니다.