Saram Consulting모델 컨텍스트 프로토콜(Model Context Protocol, 이하 MCP)은 현재 AI 생태계에서 가장 주목받는 미들웨어입니다. LLM을 외부 도구 및 데이터 소스와 연결하기 위해 앤트로픽(Anthropic)이 제안한 이 개방형 표준은 마이크로소프트, 구글, CData를 비롯한 수백 명의 오픈소스 기여자들에게 채택되었습니다. CData 한 곳만 해도 2025년에 350개 이상의 MCP 서버를 출시했습니다. 구글은 2025년 12월 자사를 “설계부터 에이전트 지원 준비 완료(agent-ready by design)” 상태라고 선언하며 BigQuery, Maps, Kubernetes용 관리형 MCP 서버를 선보였습니다. 마이크로소프트의 Copilot Studio 역시 기업용 거버넌스와 감사 추적(Audit Trail) 기능을 탑재한 MCP를 공식 지원하고 있습니다.
생명과학 산업계도 이를 주목하고 있습니다. 이그나이트(Egnyte)는 규제 대상 콘텐츠를 위해 OAuth 2.0, 권한 인식 기반 접근 제어, 전체 감사 로깅을 갖춘 프로덕션용 MCP 통합 기능을 출시했습니다. 2025년 29억 달러 규모에서 2030년 50억 달러를 넘어설 것으로 예상되는 실험실 자동화(Lab Automation) 시장 역시 MCP 네이티브 아키텍처로 빠르게 전환하고 있습니다. 일각에서는 이를 “호환되는 모든 클라이언트 및 서버와 연동되는 단 하나의 표준화된 커넥터, 즉 AI를 위한 USB-C”라고 부르기도 합니다.
하지만 규제 환경에서 시스템을 구축하는 모든 이들에게 가장 중요한 질문은 바로 이것입니다. 과연 미국 FDA가 여러분의 MCP 서버에 신경을 쓸까요?
*“규제 대상 생명과학 산업에서 MCP 서버를 도입하는 것이 허용되는가?”*라는 질문에 대해, 2026년 1월 14일 발표된 FDA/EMA 공동 기본 원칙(Joint Guiding Principles), EU AI 법(EU AI Act), ICH E6(R3), GAMP 5 등 핵심 규제 프레임워크를 상호 대조하여 도출한 답은 미묘하면서도 복합적입니다.
규제 기관들의 시각이 수렴하는 지점은 매우 명확합니다. 동시에, 대다수의 분석이 잘못 짚고 있는 부분 또한 뚜렷하게 드러납니다.
만장일치의 답변
업계의 일치된 결론은 다음과 같습니다. “그렇다. MCP 서버 도입은 허용된다. 다만, 강력한 구현 가드레일이 반드시 수반되어야 한다.” 신뢰할 만한 분석 중 ’도입 불가’라고 말하는 곳은 없습니다. 그렇다고 ’플러그 앤 플레이(Plug and Play)로 바로 쓸 수 있다’고 말하는 곳도 전무합니다. 의견 차이는 주의를 기울여야 하는 정도의 문제였을 뿐, 방향성에 대한 이견은 아니었습니다.
공통된 입장은 이렇습니다. MCP라는 프로토콜 자체가 본질적으로 규정을 위반하는 것은 아닙니다. 규제 기관이 통제하는 대상은 시스템 전체, 데이터 완전성(Data Integrity), 그리고 환자의 안전이지, 특정 통신 프로토콜 그 자체가 아닙니다. MCP 서버는 여타 데이터베이스, API 게이트웨이, 미들웨어 계층과 마찬가지로 GxP 밸리데이션 대상이 되는 대규모 컴퓨터화 시스템(Computerized System)의 한 구성요소일 뿐입니다.
이는 분명 맞는 말입니다. 하지만 동시에 위험할 정도로 불완전한 설명이기도 합니다.
모든 모델이 동의한 핵심 사항
다음의 6가지 항목은 보편적인 합의 사항으로 도출되었습니다.
1. 감사 추적(Audit Trail)은 절대 타협할 수 없습니다. 모든 모델이 21 CFR Part 11 및 ALCOA+ 원칙에 입각한 감사 추적을 제1 요구사항으로 꼽았습니다. AI 에이전트가 MCP 서버를 이용해 QMS(품질관리시스템)를 조회하거나 임상시험 기록을 가져오고, 또는 제조실행(MES) 데이터를 검색하는 경우, 데이터가 오가는 모든 단계(hop)가 완벽하게 추적 가능해야 합니다. 요청을 시작한 주체(단순히 AI 에이전트가 아니라 실제 사람 사용자), 요청 내용(정확한 JSON-RPC 페이로드), 일시, 반환된 결과값, 그리고 성공 여부까지 빠짐없이 기록되어야 합니다.
기본 오픈소스 MCP 서버에는 GxP 등급의 감사 로깅 기능이 없습니다. 이 역량은 직접 개발하거나 상용 솔루션을 통해 확보해야 합니다.
2. 읽기(Read)와 쓰기(Write)의 분리가 핵심 기준선입니다. 이 둘의 구분은 대단히 명확하고 엄격합니다. GxP 데이터에 대한 읽기 전용 MCP 접근(예: 연구원의 질문에 답하기 위해 LLM이 LIMS 데이터베이스를 조회하거나 SOP를 읽고 배치 레코드를 가져오는 행위)은 위험도가 낮고 규제 측면에서도 충분히 허용되며 밸리데이션도 수월합니다. 반면 쓰기 또는 실행 작업(예: AI 에이전트가 배치 레코드를 업데이트하거나 알림을 트리거하고 제조 공정 변수를 변경하는 행위)은 21 CFR Part 11의 직접적인 규제를 받으며, 전자 서명이 수반된 휴먼 인 더 루프(Human-in-the-loop)를 필수적으로 요구하는 규제적 지뢰밭입니다.
따라서 GxP 데이터 소스에 대해 MCP 서버는 기본적으로 ’읽기 전용’으로 설정되어야 합니다. 쓰기 작업은 반드시 인증된 사람의 승인을 거치도록 통제해야 합니다. 예외는 없습니다.
3. 밸리데이션의 대상은 LLM이 아니라 MCP 서버입니다. 비결정론적(non-deterministic) 언어 모델의 “지능”을 전통적인 CSV 방식으로 밸리데이션하는 것은 불가능합니다. 검증해야 하는 대상은 인터페이스 래퍼(wrapper) 역할을 하는 MCP 서버입니다. JSON-RPC 엔드포인트를 테스트하고, 스키마 유효성 검증, 오류 처리, 경계 조건(boundary conditions)을 확인해야 합니다. 모델의 환각(hallucination)이나 기형적 입력이 들어오더라도 하위 GxP 시스템을 훼손하지 않고 정상적으로 거부하는지 확인해야 합니다. GAMP 5 기준을 적용하여 상용 패키지는 카테고리 3(Category 3), 자체 개발 커스텀 서버는 카테고리 5(Category 5)로 취급하여 검증해야 합니다.
4. 최소 권한 원칙(Least Privilege)과 RBAC. LLM 클라이언트는 모든 권한을 가진 전지전능한 서비스 계정으로 연결되어서는 안 됩니다. MCP 서버는 AI 애플리케이션의 권한이 아닌 실제 사람 사용자의 권한을 상속받아, 작업 단위별 역할 기반(RBAC) 및 속성 기반(ABAC) 접근 제어를 강제해야 합니다. 최종 사용자에게 특정 비바(Veeva) 볼트를 열람할 권한이 없다면, LLM이 무엇을 요청하든 MCP 서버는 해당 작업을 반드시 차단해야 합니다.
5. GxP에 영향을 미치는 작업에 대한 휴먼 인 더 루프(HITL). MCP 도구가 일탈(Deviation) 보고서를 생성하거나 SOP를 수정하고 워크플로우를 승인할 수 있는 권한을 가진 경우, 자율 에이전트 루프가 이를 단독으로 실행해서는 안 됩니다. MCP 서버는 즉시 실행을 중단하고 사람 작업자에게 명시적인 승인 프롬프트를 표시해야 합니다. 문서화된 사람의 의도가 검증된 후에만 최종 작업이 커밋(commit)되어야 합니다.
6. 프라이빗 인프라 환경 원칙. MCP 서버를 공용 인터넷에 노출시키는 방안을 제시한 모델은 단 하나도 없었습니다. 아키텍처는 반드시 ’사용자 -> 내부 AI 애플리케이션 -> 내부 LLM(데이터 상주 요건 보장) -> 내부 MCP 서버 -> 내부 데이터베이스’의 폐쇄망 구조를 따라야 합니다. 어떠한 예외도 허용되지 않습니다.
모델 간 의견이 갈린 부분
의견 차이는 MCP의 수용 가능 여부가 아니었습니다. 쟁점은 다음 세 가지였습니다.
낙관론 대 신중론. 두 모델은 MCP가 맞춤형(bespoke) 개별 연동 방식에 비해 밸리데이션 부담을 대폭 줄여준다고 주장했습니다. 수많은 N×M 형태의 커스텀 파이썬 스크립트보다 표준화된 프로토콜이 훨씬 밸리데이션하기 쉽다는 논리였습니다. 반면 다른 모델은 현재의 오픈소스 MCP 서버들을 “CSV(컴퓨터화 시스템 밸리데이션)의 악몽”이라 표현했습니다. 벤더 적격성 평가(Vendor Qualification) 패키지도 없고, 고정된 버전 관리도 없으며, 공식적인 변경 관리 절차도 부재한 오픈소스 미들웨어이기 때문입니다. 두 주장 모두 타당합니다. 프로토콜 자체는 정교하고 표준화가 용이하지만, 현재의 구현체들은 GxP에 적용하기에 지나치게 미성숙합니다. 프로토콜의 우아함과 구현체의 성숙도 사이의 간극이 바로 실질적인 위험이 존재하는 곳입니다.
프롬프트 인젝션(Prompt Injection). 이는 종종 과소평가되는 위험 요소입니다. GxP 환경에서 프롬프트가 오염되거나 공격을 받으면 LLM이 조작되어 MCP 서버를 통해 권한 없는 데이터를 요청하거나 의도치 않은 작업을 트리거할 수 있습니다. 이는 실질적인 공격 표면(attack surface)이며, LLM 프롬프트 수준이 아닌 MCP 서버 레벨에서 결정론적(deterministic) 방어 기제를 갖추어야 합니다.
도입 일정(Timeline). 낙관적인 시각은 Egnyte의 프로덕션 배포 사례와 CData의 350개 이상의 커넥터를 근거로 업계가 이미 전환 중임을 강조했습니다. 반면 신중론을 펼친 모델들은 명시적인 밸리데이션 계획서, 감사 추적, 벤더 적격성 평가, 직접적인 GxP 데이터 수정 작업과의 격리가 마련되지 않는다면 현재로서는 규제 대상 워크플로우에 MCP를 도입할 수 없다고 지적했습니다. 진실은 이렇습니다. 얼리어답터들은 현재 비(非) GxP 및 저위험 유스케이스에서 빠르게 도입을 진행하고 있으며, 완전한 GxP 밸리데이션을 거친 엔터프라이즈 배포까지는 9~18개월이 소요될 것입니다.
LLM들이 간과하거나 축소 평가한 부분
대다수의 모델이 가볍게 넘어가거나 완전히 놓친 3가지 핵심 사안이 있습니다.
MCP 사양(Specification) 자체가 보안을 강제할 수 없음을 인정하고 있다는 점입니다. 공식 명세(2025-03-26)는 다음과 같이 명시하고 있습니다: “MCP 자체는 프로토콜 수준에서 이러한 보안 원칙을 강제할 수 없으므로, 구현자(implementor)는 강력한 동의 및 권한 부여 플로우를 직접 구축해야 합니다(SHOULD).” 즉, 규제 준수에 대한 모든 부담이 오롯이 ’구현 계층’에 전가된다는 의미입니다. 프로토콜은 표준화된 JSON-RPC 규격(envelope)만 제공할 뿐입니다. 인증, 권한 인가, 감사 로깅, 데이터 마스킹, 암호화 등 그 밖의 모든 것은 구축하는 사람의 몫입니다.
오픈소스 출처(Provenance)는 심각한 컴플라이언스 리스크입니다. 현재 GitHub 커뮤니티 저장소에는 수백 개의 오픈소스 MCP 서버가 올라와 있습니다. 그러나 GxP 환경에서는 사용하는 모든 도구의 소프트웨어 개발 수명주기(SDLC)를 증명해야 합니다. 문서화된 SDLC, 공식 변경 관리, 벤더 적격성 평가가 결여된 비검증 오픈소스 코드는 철저한 위험 평가 없이는 GxP 워크플로우에 결코 용인될 수 없습니다. 검증되지 않은 오픈소스 MCP 서버를 다운로드하여 LIMS에 연결하는 것은 FDA Form 483(지적서)을 자청하는 것이나 다름없습니다.
EU AI 법(EU AI Act)이 판도를 바꿉니다. 2026년 8월 2일부터 독립형(standalone) AI에 대한 고위험 AI 규정이 시행되고, 2027년 8월 2일부터는 CE 마크 의료기기 내장 AI에 대한 규제가 적용됨에 따라, 유럽연합(EU) 내에서 운영되는 모든 MCP 기반 AI 에이전트는 지금 당장 AI Act의 분류 체계에 따라 평가되어야 합니다. 의료기기에 내장된 AI나 임상 의사결정을 지원하는 AI는 자동으로 고위험(High-Risk)으로 분류됩니다. 이에 따라 지속적인 위험 관리, 데이터 품질 통제, 포괄적인 기술 문서화, 인적 감독(Human Oversight) 조치, 그리고 AI 동작을 자동으로 기록하는 ‘기능적 추적성(Functional Traceability)’ 로그 보관이 의무화됩니다.
아무도 이야기하지 않는 규제 프레임워크
2026년 1월 14일, 미국 FDA와 유럽 EMA는 향후 구속력 있는 가이던스의 기초가 될 10가지 기본 원칙을 담은 **“신약 개발에서의 모범적 AI 실무를 위한 기본 원칙(Guiding Principles of Good AI Practice in Drug Development)”**을 공동 발표했습니다. 이는 신약 개발 분야의 AI 활용을 구체적으로 다룬 최초의 FDA-EMA 공동 프레임워크입니다.
10대 원칙은 다음과 같습니다.
- 인간 중심 설계(Human-centric by design) — 윤리적 기준 및 인간의 가치와 일치하는 AI
- 위험 기반 접근법(Risk-based approach) — 사용 맥락에 비례하는 적정한 밸리데이션
- 표준 준수(Adherence to standards) — GxP, 사이버보안, 법적 규제 요건 준수
- 명확한 사용 맥락(Clear context of use) — 명확히 정의된 역할, 범위, 데이터 입력 및 출력
- 다학제적 전문성(Multidisciplinary expertise) — 전체 수명주기에 걸쳐 임상, 과학, 데이터 과학, 사이버보안 전문 인력 참여
- 데이터 거버넌스 및 문서화(Data governance and documentation) — 추적 가능하고 검증 가능하며 GxP를 준수하는 데이터 관리
- 모델 설계 및 개발 실무(Model design and development practices) — 해석 가능성, 설명 가능성, 견고성 확보
- 위험 기반 성능 평가(Risk-based performance assessment) — 사람과 AI의 상호작용을 포함한 전체 시스템 평가
- 수명주기 관리(Life cycle management) — 지속적인 모니터링, 주기적인 재평가, 데이터 드리프트(Data Drift) 감지
- 명확하고 핵심적인 정보 제공(Clear, essential information) — 성능, 한계점, 데이터 소스에 대한 평이하고 명확한 설명
이 원칙들은 법적 구속력은 없습니다. 또한 특정 기술을 직접 규제하지도 않으며, 결과(outcome)를 규제합니다. 그러나 이는 양대 규제 기관이 신약 개발 분야의 AI 구현체에 무엇을 기대하고 있는지를 정확하게 보여주며, 향후 제정될 구속력 있는 규제 가이던스는 바로 이 기반 위에 구축될 것입니다.
MCP의 관점에서 보면, 특히 원칙 2, 4, 6, 8, 9번이 직접적으로 결부됩니다. MCP 서버의 위험 프로필은 해당 서버가 어떤 GxP 데이터에 접근하느냐에 따라 결정됩니다. 모든 도구는 명확하게 정의된 사용 범위를 가져야 하며, 데이터 흐름은 완전히 문서화되어야 합니다. 또한 서버만을 독립적으로 평가하는 것이 아니라 사람-AI-MCP 전체 시스템 차원에서 평가되어야 하며, 지속적인 모니터링, 버전 관리, 주기적인 재밸리데이션 체계가 갖춰져야 합니다.
컴플라이언스 매트릭스
21 CFR Part 11, GAMP 5, CSA, HIPAA, GDPR, EU AI 법, MDR/IVDR, ICH E6(R3), NIST AI RMF, ISO 14971, 그리고 FDA/EMA 공동 원칙 등 규제 환경 전반을 종합하여 도출한 MCP 배포 시나리오별 컴플라이언스 요건은 다음과 같습니다.
GxP 데이터에 대한 읽기 전용(Read-only) MCP: 감사 추적 권장. 위험 기반의 경량 밸리데이션 적용. 환자 개인건강정보(PHI) 포함 시 HIPAA 준수. EU 데이터 처리 시 GDPR 준수. EU AI Act는 연구개발(R&D) 단계일 경우 통상 면제. 비례적인 ICH E6(R3) 준수. 휴먼 인 더 루프(HITL) 불필요.
GxP 시스템에 대한 쓰기 가능(Write-capable) MCP: 21 CFR Part 11 전체 감사 추적 필수. GAMP 5 기반의 완전한 IQ/OQ/PQ 수행 필수. HIPAA 및 GDPR 준수 필수. EU AI Act 개별 사안별 평가 필요. ICH E6(R3) 완전 준수. ISO 14971 위험 관리 체계 권장. 모든 쓰기 작업에 대한 휴먼 인 더 루프 필수 적용. 사이버보안 평가 필수.
의료기기(Medical Device)의 구성요소로서의 MCP: 위의 모든 요건에 더해 ISO 13485 품질경영시스템(QMS), IEC 62304 소프트웨어 수명주기 표준, MDR 규정 하의 CE 마크 획득, 2027년 8월까지 EU AI Act 고위험군 요건 충족 필수. ISO 14971 위험 관리는 단순 권장이 아니라 법적 필수 요건.
한 줄 요약
데이터베이스 도입이 허용되는 것과 똑같은 방식으로 생명과학 분야에서 MCP 서버 도입은 허용됩니다. 즉, 프로토콜 자체는 문제없으나, 구현체를 반드시 밸리데이션하고, 접근 제어를 강제하며, 모든 것을 로깅하고, 사람의 승인 없이 AI가 GxP 시스템에 데이터를 직접 쓰지 못하도록 해야 합니다.
밸리데이션 프로토콜, 감사 로깅, 접근 제어, 위험 평가 등 컴플라이언스 계층에 지금 투자하는 기업들은 MCP가 규제 환경에서 AI 연동의 표준 패턴으로 자리 잡을 때 구조적인 비교우위를 확보하게 될 것입니다. 규제 당국이 “완벽히 공인된” 청신호를 켜주기만을 기다리는 기업들은 뒤처질 수밖에 없습니다. 왜냐하면 표준은 규제 기관의 일방적인 법령 선포가 아니라 현장의 실제 실무를 통해 정립되어 가고 있기 때문입니다.
FDA와 EMA의 공동 원칙은 이를 명확히 시사합니다. 규제 당국은 신약 개발에 AI가 도입될 것을 충분히 예상하고 있습니다. 그들이 기대하는 것은 AI 시스템이 거버넌스 하에 철저히 관리되고, 밸리데이션되며, 적절한 감독을 받는 것입니다. 여러분이 MCP를 쓰든, REST API를 쓰든, 전서구(carrier pigeons)를 날리든 규제 기관은 관여치 않습니다. 그들의 유일한 관심사는 해당 시스템이 적절한 인적 감독 하에 신뢰할 수 있고, 추적 가능하며, 정확한 결과를 산출하는가에 있습니다.
그에 맞추어 설계하고 구축하십시오.
본 분석은 다중 LLM 합의 연구, 2026년 1월 발표된 FDA/EMA의 신약 개발 AI 모범 실무 기본 원칙(Joint Guiding Principles of Good AI Practice in Drug Development), EU AI 법(Regulation 2024/1689), ICH E6(R3), GAMP 5, 21 CFR Part 11 및 40여 편의 규제 문헌을 종합적으로 검토하여 작성되었습니다. 전체 연구 노트는 작성자의 리서치 볼트(Research Vault)에 보관되어 있습니다.