규제 대상 바이오제약 환경에서의 MCP: 순수 프로토콜이 GxP에서 실패하는 이유와 해결책

2024년 11월, Anthropic은 LLM이 범용 통합 레이어를 통해 외부 도구를 호출하고, 데이터베이스를 쿼리하며, API를 실행할 수 있도록 지원하는 개방형 표준인 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)을 발표했습니다. 2025년 중반에 이르러 Glama 디렉터리에는 5,000개 이상의 활성 MCP 서버가 등록되었습니다. Microsoft는 이를 Copilot Studio에 통합했고, Google은 데이터베이스용 MCP Toolbox를 출시했으며, OpenAI 역시 이를 채택했습니다. 이 프로토콜은 모든 이가 연결하고자 하는 “AI 세계의 USB-C”가 되었습니다.

그러자 품질(Quality) 부서의 누군가가 당연한 질문을 던졌습니다: “이것을 우리 GxP 환경에서도 사용할 수 있을까요?”

MCP 공식 명세서, OWASP의 MCP Top 10, FDA의 최종 CSA 가이던스, 그리고 EMA의 AI 반추 보고서(Reflection Paper)를 바탕으로 검증한 답변은 일관됩니다. 바로 ’순수(raw) MCP는 GxP 요구사항을 충족하지 못한다’는 것입니다. 그러나 적절한 아키텍처 제어(architectural controls)를 적용한다면, 규제 기관 앞에서도 충분히 방어 가능한(defensible) 시스템으로 탈바꿈할 수 있습니다.

본 글에서는 규제 조사관(inspector) 앞에서도 MCP의 정당성을 입증할 수 있도록 만드는 핵심 분석, 근거 데이터, 그리고 아키텍처를 상세히 살펴봅니다.

핵심적인 역설 (The Core Paradox)

MCP가 강력한 이유는 역설적이게도 그것이 위험하기 때문입니다.

이 프로토콜은 수동적인 챗봇을 능동적인 에이전트로 탈바꿈시킵니다. 이제 LLM은 단순한 질문 답변을 넘어 LIMS에서 배치 레코드(배치 제조 기록서)를 쿼리하고, QMS의 일탈(Deviation) API를 호출하며, 임상시험 데이터베이스를 검색하고, MES에서 워크플로우 작업을 트리거하는 등의 모든 과정을 자연어만으로 수행할 수 있습니다. 모델 스스로가 어떤 도구를, 언제, 어떤 파라미터로 호출할지 결정합니다.

이는 아키텍처적 혁신인 동시에, 규제 준수(compliance) 측면에서는 악몽과도 같습니다.

전통적인 밸리데이션 시스템은 단순한 로직을 따릅니다. 인간(또는 사전에 정의된 자동화)이 알려진 파라미터를 사용하여 기지의 API 엔드포인트를 호출하면, 시스템은 결정론적(deterministic)이고 로깅 가능한 결과를 산출합니다. GAMP 5와 21 CFR Part 11은 바로 이러한 전제 위에 설계되었습니다. 전체 V-모델(V-model)은 시스템이 무엇을 수행할지 사전에 예측할 수 있다는 가정을 바탕으로 구축되었습니다.

하지만 MCP는 이러한 모든 가정을 무너뜨립니다.

Traditional API:
  User → Fixed Endpoint → Deterministic Response → Audit Log

MCP:
  User → LLM → [Dynamic Tool Selection] → MCP Server → Target System
              ↑                                    ↑
        Non-deterministic                   No native audit trail
        (same prompt, different             (protocol doesn't mandate
         tool calls possible)                logging of who/what/when)

MCP 명세서 자체도 이 점을 인정하고 있습니다. 보안 및 신뢰(Security and Trust) 섹션에는 다음과 같이 명시되어 있습니다: “MCP 자체는 프로토콜 수준에서 이러한 보안 원칙을 강제할 수 없으므로, 구현자(implementor)는 강력한 동의 및 권한 부여 플로우를 구축해야 한다(SHOULD).”

필수(MUST)가 아닌 권장(SHOULD)입니다. 프로토콜은 보안과 규제 준수의 책임을 구현체로 명시적으로 미루고 있습니다. GxP 환경에서 이는 단순한 틈새(gap)가 아니라 거대한 협곡(canyon)과도 같습니다.

핵심 분석 결과

본 분석을 통해 타협 불가능한 5가지 핵심 결과와 몇 가지 세부적인 고려 사항(nuance)이 도출되었습니다.

만장일치 합의: 5가지 타협 불가능한 핵심 결과

1. 순수 MCP는 기본 상태 그대로 사용할 수 없습니다. LLM을 GxP 시스템에 바로 연결하는 상용(off-the-shelf) MCP 배포는 규제 기관의 엄격한 조사를 통과할 수 없습니다. 프로토콜 자체에 결함이 있어서가 아니라, 규제 환경을 염두에 두고 설계되지 않았기 때문입니다.

2. MCP 게이트웨이 패턴이 해답입니다. 분석 결과는 중앙 집중식 통제 레이어, 즉 LLM과 MCP 서버 사이에 위치하는 프록시(Proxy)를 가리킵니다. 이 게이트웨이는 모든 JSON-RPC 메시지를 검사하고, RBAC(역할 기반 접근 제어)을 강제하며, 감사 추적(Audit Trail)을 생성하고, 모델에 도달하기 전 민감 데이터를 마스킹(redact)합니다.

3. 쓰기(Write) 작업에는 인간 참여(HITL, Human-in-the-Loop)가 필수적입니다. 읽기 전용 쿼리(예: “배치 #12345의 상태는 무엇인가요?”)는 상대적으로 위험도가 낮습니다. 하지만 GxP 기록을 수정하거나 변경하는 모든 MCP 도구 실행은 반드시 인간의 검토와 승인(이상적으로는 21 CFR Part 11을 준수하는 전자 서명)을 위해 일시 중지되어야 합니다.

4. MCP 서버는 GxP 소프트웨어 자산으로 관리되어야 합니다. 분석 근거에 따르면 내부 승인 허용 목록(Allowlist), 커밋 해시를 통한 버전 고정(Version Pinning), 공식적인 변경 관리 절차, 그리고 서드파티 서버에 대한 공급업체 적격성 평가(Supplier Qualification)가 반드시 수반되어야 합니다.

5. FDA의 CSA 프레임워크가 올바른 밸리데이션 접근 방식입니다. 기존의 번잡한 전통적 CSV에서 벗어나 컴퓨터 소프트웨어 보증(CSA, Computer Software Assurance)으로 전환해야 합니다. 이는 가능한 모든 LLM 출력을 검증하려 애쓰는 대신, 시스템의 가드레일(보호 장치)을 엄격히 테스트하는 위험 기반 밸리데이션 방식입니다.

세부 고려 사항 및 팩트체크

차이점은 본질이 아니라 구체적인 세부 사항에 있었습니다:

OWASP의 경고: MCP Top 10 취약점

현재 베타 버전으로 공개된 OWASP MCP Top 10은 본 분석에서 식별된 모든 보안 우려 사항이 현실적임을 입증합니다. 다음은 10대 취약점 범주와 이들이 GxP에 미치는 영향을 매핑한 내용입니다:

┌─────────────────────────────────────────────────────────┐
│                   OWASP MCP Top 10                      │
│               (Beta Release, 2025)                      │
├──────┬──────────────────────────────────┬───────────────┤
│  #   │  Vulnerability                   │  GxP Impact   │
├──────┼──────────────────────────────────┼───────────────┤
│ M01  │ Token Mismanagement &            │ Unauthorized  │
│      │ Secret Exposure                  │ data access   │
├──────┼──────────────────────────────────┼───────────────┤
│ M02  │ Privilege Escalation via         │ Confused      │
│      │ Scope Creep                      │ deputy risk   │
├──────┼──────────────────────────────────┼───────────────┤
│ M03  │ Tool Poisoning                   │ Data          │
│      │ (incl. rug pulls, schema         │ integrity     │
│      │  poisoning, tool shadowing)      │ violation     │
├──────┼──────────────────────────────────┼───────────────┤
│ M04  │ Supply Chain Attacks &           │ Unvalidated   │
│      │ Dependency Tampering             │ software      │
├──────┼──────────────────────────────────┼───────────────┤
│ M05  │ Command Injection &              │ System        │
│      │ Execution                        │ compromise    │
├──────┼──────────────────────────────────┼───────────────┤
│ M06  │ Intent Flow Subversion           │ Non-determin- │
│      │ (prompt injection via context)   │ istic actions │
├──────┼──────────────────────────────────┼───────────────┤
│ M07  │ Insufficient Authentication      │ Part 11       │
│      │ & Authorization                  │ violation     │
├──────┼──────────────────────────────────┼───────────────┤
│ M08  │ Lack of Audit and Telemetry      │ ALCOA+        │
│      │                                  │ violation     │
├──────┼──────────────────────────────────┼───────────────┤
│ M09  │ Shadow MCP Servers               │ Uncontrolled  │
│      │                                  │ systems       │
├──────┼──────────────────────────────────┼───────────────┤
│ M10  │ Context Injection &              │ Data leakage  │
│      │ Over-Sharing                     │ / privacy     │
└──────┴──────────────────────────────────┴───────────────┘

이 취약점들 하나하나는 21 CFR Part 11, ALCOA+, 또는 GAMP 5의 요구사항과 직접적으로 맞닿아 있습니다. OWASP MCP 보안 치트시트(Security Cheat Sheet)는 각 항목에 대한 구체적인 방어책을 제시하고 있으며, 그 모든 방어 전략은 여기서 제시하는 아키텍처 분석과 완벽히 일치합니다.

MCP를 규제 환경에서 방어 가능하게 만드는 아키텍처

복수 LLM 간의 일치된 합의, OWASP 가이드라인, 그리고 검증된 규제 프레임워크를 기반으로 품질 팀이 반드시 요구해야 하는 아키텍처는 다음과 같습니다:

┌──────────┐    ┌─────────────────────────────────────────┐
│          │    │         MCP GATEWAY (Validated)         │
│   User   │───▶│                                         │
│ (Human)  │    │  ┌─────────┐ ┌────────┐  ┌────────────┐ │
│          │    │  │ Identity│ │ Policy │  │  Audit     │ │
│          │    │  │ (SAML/  │ │ Engine │  │  Logger    │ │
│          │    │  │  OIDC)  │ │ (RBAC) │  │ (Immutable)│ │
│          │    │  └────┬────┘ └───┬────┘  └─────┬──────┘ │
│          │    │       │          │             │        │
│          │    │  ┌────▼──────────▼─────────────▼──────┐ │
│          │    │  │     JSON-RPC 2.0 Inspector         │ │
│          │    │  │  (inspect all MCP messages before  │ │
│          │    │  │   forwarding to MCP server)        │ │
│          │    │  └────────────────┬───────────────────┘ │
│          │    └───────────────────┼─────────────────────┘
│          │                        │
│          │    ┌───────────────────▼─────────────────────┐
│          │    │            MCP SERVER LAYER             │
│          │    │                                         │
│          │    │  ┌──────────┐ ┌──────────┐ ┌─────────┐  │
│          │    │  │ LIMS     │ │ QMS      │ │ Clinical│  │
│          │    │  │ Server   │ │ Server   │ │ DB      │  │
│          │    │  │ (pinned) │ │ (pinned) │ │ (pinned)│  │
│          │    │  └──────────┘ └──────────┘ └─────────┘  │
│          │    │                                         │
│          │    │  All servers: allowlisted, version-     │
│          │    │  pinned, supplier-qualified             │
│          │    └─────────────────────────────────────────┘

모든 품질 팀이 반드시 강제해야 하는 6대 제어 항목

1. 중앙 집중식 MCP 게이트웨이(Centralized MCP Gateway): LLM과 서버 간의 직접 연결을 전면 금지합니다. 모든 MCP 메시지는 사용자 신원 식별, 정책 적용, 로깅을 강제하는 밸리데이션된 게이트웨이를 통과해야 합니다. 이 게이트웨이가 바로 공식 시스템 기록(System of Record)이 됩니다.

2. 엔터프라이즈 신원 페더레이션(Enterprise Identity Federation): SAML/OIDC를 통해 모든 MCP 요청을 특정 인간 사용자와 연계합니다. LLM 에이전트는 절대 서비스 전용 자격 증명(Service Credentials)을 직접 보유해서는 안 되며, 사용자의 신원을 위임받아 수행해야 합니다. 이를 통해 모든 작업의 귀속성(Attributability)을 완벽히 확보합니다.

3. 엄격한 허용 목록(Strict Allow-Listing) 관리: 에이전트가 사용할 수 있는 MCP 도구, 리소스, 프롬프트를 정확히 지정하여 통제합니다. 승인되지 않은 도구를 호출하려는 모든 시도는 차단되며 보안 이벤트로 로깅됩니다. 이를 통해 동적 도구 탐색(Dynamic Tool Discovery)으로 인한 위험을 원천 차단합니다.

4. 불변 감사 로깅(Immutable Audit Logging): 사용자 신원, 타임스탬프, 프롬프트, 호출된 도구, 전달된 파라미터, 반환된 응답 등 모든 MCP 상호작용은 위변조 방지 시스템(SIEM, WORM 스토리지, 또는 밸리데이션된 아카이브)에 기록됩니다. 이는 ALCOA+ 및 21 CFR Part 11 요건을 완벽히 충족합니다.

5. 쓰기 작업에 대한 인간 개입(Human-in-the-Loop for Writes): 읽기 전용 쿼리는 로깅과 함께 통과됩니다. 반면 배치 레코드 업데이트, 일탈 생성, SOP 개정과 같은 상태 변경 작업은 실행 전에 반드시 인간의 검토와 Part 11 준수 전자 서명을 거치도록 일시 중단됩니다.

6. 버전 고정(Version Pinning) 및 변경 관리(Change Control): MCP 서버, SDK, LLM 모델을 특정 버전으로 고정합니다. 어떠한 업데이트든 위험 평가 및 재밸리데이션 절차를 포함하는 공식 변경 관리 프로세스를 거쳐야만 합니다.

반드시 숙지해야 할 규제 프레임워크 스택

결론 (The Bottom Line)

근거는 명확합니다. MCP는 프로토콜일 뿐, 완제품이 아닙니다. HTTP와 마찬가지로 그 자체만으로는 규제 환경에 결코 “그대로 수용”될 수 없습니다. 즉, 규제 환경이 요구하는 보안, 밸리데이션, 거버넌스 계층 없이 배포하는 것은 명백히 규정 위반입니다.

품질 부서의 역할은 MCP 도입을 무조건 가로막는 것이 아닙니다. MCP를 둘러싼 검증된 방어 경계(Validated Perimeter)를 구축하는 것입니다.

다음은 실무 결정을 위한 의사결정 프레임워크입니다:

Is the MCP deployment read-only?
  ├─ YES → Lower risk. Validate the gateway, log everything,
  │         require HITL for any GxP decision based on AI output.
  │
  └─ NO (state-changing) → Higher risk. Full GAMP 5 validation.
            Part 11 electronic signatures before writes.
            Continuous monitoring. Formal change control.

Is the MCP server accessing GxP data?
  ├─ NO (public data, literature) → Phase 1 pilot. 4-6 weeks.
  │         Prove the architecture works.
  │
  └─ YES (indirect GxP — published SOPs, historical records) →
  │         Phase 2. 3-6 months. Partial validation scope.
  │
  └─ YES (direct GxP — batch records, clinical data, LIMS) →
            Phase 3. 9-18 months. Full IQ/OQ/PQ. Supplier
            qualification. Continuous drift monitoring.

FDA는 프로토콜 자체를 승인하지 않습니다. 프로토콜의 실제 ’구현체(Implementation)’를 승인하고 검증합니다. 여러분의 구현체가 MCP를 밸리데이션된 게이트웨이로 감싸고, 엔터프라이즈 신원을 엄격히 강제하며, 모든 내역을 위변조 없이 로깅하고, GxP에 영향을 미치는 작업에 인간 승인을 요구한다면, 규제 기관 앞에서도 충분히 방어 가능한 견고한 시스템을 갖춘 것입니다.

만약 지금 순수 MCP 서버를 띄워 LIMS에 직접 연결하려 하고 있다면, 당장 멈추십시오. 품질 부서가 이를 제지하는 것은 지극히 정당합니다. 그러나 프로토콜 자체를 폐기하지는 마십시오. 그 주위에 검증된 방어 경계를 세우십시오.

연구 노트: [[MCP-Regulated-Biopharma-Consensus-Analysis]]

관련 글

• MCP 게이트웨이 패턴: GxP 컴플라이언스를 위해 팩트체크된 아키텍처
• 생명과학 분야의 MCP 서버 도입, 원칙적으로 타당하지만 현재의 출시 방식은 틀렸다
• GxPChat: 하나의 챗봇, 5개의 전문 에이전트, MCP로 연결된 규제 준수 아키텍처