전산화 시스템 검증: GAMP 5와 CSA로의 전환

📍 현재 위치: 앞 장에서는 전자 기록을 법적으로 신뢰할 수 있게 만들었습니다. 이번 장에서는 그러한 기록을 보관하는 시스템이 실제로 제대로 작동함을 증명하고, 업계가 문서 작업 대신 사고(thinking)로 이를 증명하는 법을 어떻게 배워가고 있는지 보여줍니다.

앞 장에서 우리는 전자 기록이나 서명이 종이를 대신할 수 있으려면 그것을 신뢰할 수 있어야 한다는 점을 살펴보았습니다. 그리고 21 CFR Part 11(미국 연방규정집(Code of Federal Regulations) 제21편의 Part 11로, 전자 기록 규정)과 EU GMP Annex 11(그 유럽판)이 모두, 그러한 기록을 보관하는 컴퓨터 시스템에 의존하기 전에 그 시스템이 검증(validated)되어야 한다고 요구한다는 점도 살펴보았습니다 [8][7]. 그 한 단어, 검증되었다는 말 자체가 하나의 온전한 분야입니다. 이번 장은 규제 대상 데이터 시스템이 마땅히 해야 할 일을 한다는 것을 증명한다는 것이 무엇을 의미하는지, 그리고 업계가 그것을 증명하는 방식에 일어난 조용한 혁명에 관한 이야기입니다.

쉽게 말하면

새 자동차를 도로에 올리는 일을 생각해 봅시다. 옛 방식은 모든 나사, 모든 전선, 라디오, 컵홀더까지 다 테스트했음을 증명하는 사진과 서명된 체크리스트로 바인더를 가득 채우는 것이었습니다. 그 부품이 브레이크든 글로브박스 조명이든 똑같이 빠짐없는 문서 작업을 했습니다. 새 방식은 이렇게 말합니다. 먼저 생각하라. 브레이크와 조향 장치는 사람 목숨이 걸려 있으니 철저하게 두들겨 보라. 컵홀더는 한번 훑어보고 작동한다는 것만 기록한 뒤 넘어가라. 위험이 있는 곳에 노력을 쏟는 것입니다. 모든 것을 똑같이 테스트하고 무겁게 문서화하는 것에서 무엇이 중요한지 생각하고 그것을 잘 증명하는 것으로의 그 전환, 그것이 바로 CSV에서 CSA로의 이동입니다.

이 장에서 다루는 내용

우리는 전산화 시스템 검증(Computerized System Validation, CSV)에서 시작합니다. 그것이 무엇이며 왜 부담이 되었는지를 살펴봅니다. 그다음 업계의 위험 기반 지침서인 GAMP 5를, 그 소프트웨어 범주와 유명한 V-모델과 함께 만나봅니다. 이어서 스크립트보다 비판적 사고를 앞세운 FDA 주도의 전환인 컴퓨터 소프트웨어 보증(Computer Software Assurance, CSA)이 등장합니다. 그다음 요구사항 추적성 매트릭스(requirements-traceability matrix)를 열어봅니다. 검사관이 실제로 읽는 단 하나의 표인데, 그 한 행을 뜯어보며 전체 철학이 어떻게 하나의 셀로 압축되는지를 보입니다. 마지막으로 검증을 지난 두 장의 데이터 무결성 통제와 다시 연결하고, 클라우드 소프트웨어와 AI 모델의 검증이라는 최전선을 살짝 들여다봅니다.

검증이란 무엇이며, 왜 무거워졌는가

전산화 시스템 검증(Computerized System Validation, CSV)은 컴퓨터 시스템이 의도된 일을 수행하고, 해서는 안 될 일은 하지 않는다는 문서화된 증거(documented evidence)를 만들어내는 행위입니다 [6]. 그것은 단일한 테스트가 아니라, 시스템이 의도된 용도에 적합함(fit for its intended use)을 높은 수준의 보증과 함께 입증하는 일련의 활동, 즉 하나의 생애주기(lifecycle)입니다 [6]. FDA의 소프트웨어 검증 일반 원칙(General Principles of Software Validation)(2002)(의료기기 소프트웨어 검증 가이던스로, 그 원칙이 업계 전반에 폭넓게 적용됩니다)이 이 기준선을 정했습니다. 소프트웨어 검증은 위험 관리와 짝을 이루어 시스템 생애 전체에 통합된 일부가 되어야 한다는 것입니다. 복잡한 소프트웨어를 통과하는 가능한 모든 경로를 다 테스트할 수는 없기에, 실패가 어디에서 해를 끼칠지를 추론해야 하기 때문입니다 [6].

이것이 도대체 왜 요구될까요? 규제 대상 바이오 의약품 제조에서는 소프트웨어 자체가 제품 품질 시스템의 일부이기 때문입니다. 잘못 보정된 바이오리액터 컨트롤러나 잘못된 방향으로 반올림하는 스프레드시트는 환자의 약을 망가뜨릴 수 있고, 그 약이 안전하다는 것을 증명해야 할 기록까지 망가뜨릴 수 있습니다. 이 요구는 핵심 GMP(우수 제조 관행, Good Manufacturing Practice) 규정 그 자체에서 출발합니다. 21 CFR 211.68(앞과 같은 제21편 번호 체계이되, 여기서는 Part가 아니라 특정 절(section))은 제조에 사용되는 자동·전자 장비가 적절한 성능을 보장하도록 설계된 문서화된 프로그램에 따라 정기적으로 보정·점검·확인될 것(211.68(a))과, 그러한 시스템이 보유한 데이터가 정확성을 점검받고 백업될 것(211.68(b))을 요구하며, FDA는 이를 전산화 시스템 검증의 GMP 근거로 해석합니다 [12]. 이후 Part 11과 Annex 11이 그러한 시스템이 생산하는 전자 기록과 서명으로 그 기대를 확장하여, 검증을 있으면 좋은 것이 아니라 법적 의무로 만듭니다 [8][7].

여기에 함정이 있습니다. 20여 년에 걸쳐 검증은 의례(ritual)로 변질되었습니다. 팀들은 단계별로 짜인 절차인 거대한 테스트 스크립트(test scripts)를 작성하고 모든 클릭을 스크린샷으로 남겼으며, 멸균 필터를 제어하는 시스템에든 사소한 라벨 프린터에든 똑같이 빠짐없는 처리를 적용했습니다 [9]. 규제 당국에 대한 두려움이 "문서화된 증거"를 "모든 것을 똑같이 문서화하라"로 바꾸어 버렸습니다. 그 결과는 느리고 비싸며, 역설적이게도 종종 품질에 더 나빴습니다. 에너지가, 실제로 환자에게 해를 끼칠 수 있는 것을 테스트하는 데가 아니라 문서의 분량에 쏟아졌기 때문입니다 [2][9].

검증 대 밸리데이션

유용한 구분이 하나 있습니다. 검증(verification)은 "우리가 시스템을 제대로 만들었는가?"를 묻습니다. 즉 명세를 충족하는가입니다. 밸리데이션(validation)은 "우리가 올바른 시스템을 만들었는가?"를 묻습니다. 즉 실제 의도된 용도에 적합한가입니다. 좋은 관행은 둘 다 하며, 현대의 표준은 점점 이 둘을 하나의 위험 기반 우산 아래 묶어가고 있습니다 [1].

GAMP 5: 위험 기반 지침서

의례화된 검증에 대한 가장 영향력 있는 처방은 GAMP 5, 즉 ISPE(국제제약공학회, International Society for Pharmaceutical Engineering)가 펴낸 지침서인 우수 자동화 제조 관행(Good Automated Manufacturing Practice)입니다 [1]. GAMP 5는 법이 아닙니다. 그것은 전산화 시스템을 어떻게 합리적으로 검증할 것인가에 대한, 업계에서 가장 널리 따르는 해석입니다. 그 핵심 발상은 부제에 담겨 있습니다. 위험 기반 접근법(a risk-based approach)입니다 [1]. 노력을 위험에 맞추어 조절하는 것입니다. 이는 ICH Q9(국제의약품규제조화위원회(International Council for Harmonisation), 즉 전 세계적으로 조화된 의약품 가이드라인을 펴내는 기구의 가이드라인)에 성문화된 공식적인 품질 위험 관리(quality risk management)에서 곧바로 빌려온 원칙으로, ICH Q9은 업계에 위험 기반 의사결정을 하고, 노력의 형식성(formality)을 위험 수준에 맞추며, 주관성을 줄이라고 말합니다 [5].

GAMP 5 소프트웨어 범주와 위험 기반 원칙

GAMP 5는 소프트웨어 범주(software categories)를 통해 "노력을 얼마나 들일 것인가"에 실용적인 손잡이를 답니다. 소프트웨어를 그 유형과, 얼마나 구성(configure)되거나 맞춤 제작(custom-built)되었는지에 따라 분류하는 방식인데, 맞춤 코드일수록 알려지지 않은 위험을 더 많이 안고 있기 때문입니다 [1]:

• 범주 1 — 인프라 소프트웨어: 운영체제, 데이터베이스 등 배관에 해당하는 것들. 관리는 하되, 애플리케이션처럼 검증하지는 않습니다.
• 범주 3 — 비구성 제품: 그대로, "있는 그대로(out of the box)" 사용하는 상용 기성품 소프트웨어.
• 범주 4 — 구성 제품: 설정을 통해 맞춤화하는 상용 소프트웨어. 자사 공정에 맞게 구성한 LIMS나 MES(앞 장에서 만난 실험실 시스템과 제조 실행 시스템) 등이 있습니다. 독점 제어 시스템과 함께 공급된 뒤 특정 세포주와 공정 레시피에 맞게 현장에서 광범위하게 구성되는 상용 일회용 바이오리액터가 손에 잡히는 범주 4 사례입니다. 새 코드를 작성하지 않고도 상용 제품을 고객의 공정에 맞게 재구성한 경우입니다.
• 범주 5 — 맞춤(주문 제작) 소프트웨어: 특정 목적을 위해 따로 작성된 코드로, 가장 큰 위험을 안고 있어 가장 면밀한 검토가 필요합니다.

(범주 2는 없습니다. 옛 GAMP 4의 펌웨어 범주는 GAMP 5가 도입되면서 폐지되었고, 펌웨어는 이제 그 복잡성에 따라 범주 3, 4, 5 중 하나로 분류됩니다. 번호만 다시 매기지 않았을 뿐입니다.) 범주가 높을수록 더 많이 증명해야 하며, 결정적으로 제품이 상용으로 공급되는 경우에는 공급자를 활용(leverage the supplier)할 수 있습니다. 공급업체가 이미 자사 제품을 테스트하고 문서화했다면, 처음부터 다시 테스트하는 대신 그 작업을 평가하여 재사용하는 것입니다 [1]. 이것은 바로 과학 및 위험 기반 검증 표준인 ASTM E2500의 철학과 같습니다. ASTM E2500은 모든 구성요소를 기계적으로 똑같이 적격성 평가(qualification)하는 대신, 공급자의 지식을 포함한 가용한 최선의 지식을 사용하여 시스템이 의도된 용도에 적합함을 검증해야 한다고 주장합니다 [4].

V-모델: URS/FS/DS는 내려가고, IQ/OQ/PQ는 올라간다

GAMP 5의 상징적인 그림은 V-모델(V-model)로, 내려가는 길의 모든 명세(specification)를 올라가는 길의 짝이 되는 검증(verification)과 짝지웁니다. 시스템이 무엇을 해야 하는지 명세하고, 만들고, 그다음 증명합니다. 왼쪽에서 한 모든 약속은 오른쪽의 테스트로 확인됩니다 [1].

GAMP 5 V-모델: 왼쪽 내리막의 각 명세는 오른쪽 오르막의 짝이 되는 검증으로 증명됩니다. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

구체적인 예가 도움이 됩니다. LIMS에서 새로운 역가(potency) 분석법을 검증한다고 상상해 봅시다. 사용자 요구사항(User Requirement)은 단순한 목표를 진술합니다. "시스템은 표준품 대비 ±5% 정확도로 역가 결과를 계산해야 한다." 기능 명세(Functional Specification)는 이를 충족하는 계산 논리를 상세히 기술합니다. 설계 명세(Design Specification)는 데이터베이스 스키마와 입력 검증 규칙을 기술합니다. 다시 올라가는 길에서는, 설치 적격성 평가(Installation Qualification)가 소프트웨어가 명세대로 빌드되고 설치되는지를 확인하고, 운영 적격성 평가(Operational Qualification)가 계산 논리가 명세대로 기능하는지를 시험 환경에서 확인하며, 성능 적격성 평가(Performance Qualification)가 고객 자신의 실험실에서 실제 시료로 표준품 대비 ±5% 정확도 요구사항을 충족함을 확인합니다.

배치 실행 시스템(MES)의 경우 OQ 단계는 한 가지 추가 점검을 안고 있습니다. 실행되는 배치 레시피가 ISA-88(IEC 61512) 절차 모델을 따르는지가 검증되는 것입니다. ISA-88은 아키텍처와 통합: ISA-95, OT/IT, 그리고 엣지-투-클라우드 경로에서 설명하는, 레시피가 어떻게 절차(procedure), 단위 절차(unit procedure), 오퍼레이션(operation), 단계(phase)로 분해되는지를 정의하는 레시피 분해 표준입니다.

같은 V는 실험실·플랜트 소프트웨어뿐 아니라 약을 만드는 공정 장비에도 적용되며, 하류 정제 스키드는 위험 기반 해석이 왜 중요한지를 보여줍니다. Protein A 포획(capture) 크로마토그래피 스키드의 크로마토그래피 데이터 시스템(chromatography data system, CDS)과 제어 소프트웨어를 검증한다고 생각해 봅시다. 이것은 청징된 수확물에서 항체를 붙잡아내는 친화성 단계로, 정제에서 가장 영향력이 큰 단일 동작이며 Book 1의 포획: 항체 붙잡기(Protein A)에서 상세히 다룹니다. 그 일부 기능은 분명히 Critical이라 완전한 스크립트 기반 IQ/OQ/PQ를 받습니다. 풀링 윈도(pooling-window) 컷 포인트(실시간 자외선 트레이스 대비 설정되는 두 임계값으로, 그 사이에서 용출 피크가 제품으로 수집됩니다)는 항체 피크의 어느 부분이 원료의약품이 되고 어느 부분이 폐기되는지를 결정합니다. 이를 잘못 설정하면 응집체가 많은 꼬리 물질이나 누출된 Protein A가 풀을 오염시키므로, 피크를 검출하고 컷 기준을 적용하며 풀링 결정을 배치 기록에 기록하는 소프트웨어는 엄격하게 테스트되고, 완전하고 귀속 가능하며 변조되지 않은 원시 크로마토그램(반복되는 데이터 무결성 검사 지적 사항)을 보유하는지가 검증됩니다. 항체가 폐기물로 돌파(breakthrough)하기 전에 로딩을 멈추는 동적 결합 용량(dynamic binding capacity, DBC) 알람도 마찬가지로 Critical입니다. 반면 같은 CDS의 외관상 추세 표시 색상이나 운영자 편의용 보고서 레이아웃은 진정으로 저위험이라 더 가벼운 비스크립트 점검을 받습니다. 바로 다음 절들이 구축하는 그 CSA 식 구분입니다. 장비 측면에서, 스키드의 설치는 공급업체의 FAT와 현장 SAT로 증명되고, 크로마토그래피 단계 자체의 적격성 평가(HETP나 피크 비대칭 같은 컬럼 충전 점검, 입증된 수지 재사용 수명)는 CSA 검증이 다시 도출하는 대신 활용하는 바로 그 증거 묶음에 보태집니다.

전통적인 검증 단계는 IQ / OQ / PQ, 즉 설치 적격성 평가(Installation Qualification), 운영 적격성 평가(Operational Qualification), 성능 적격성 평가(Performance Qualification)입니다. 시스템이 제대로 설치되었고, 제대로 작동하며, 실제 작업 부하에서 제대로 성능을 낸다는 증거입니다 [4]. 고전적 체계에서는 네 번째 단계인 설계 적격성 평가(Design Qualification, DQ)가 IQ에 앞섭니다. 아무것도 만들거나 설치하기 전에 설계 그 자체가 요구사항을 충족할 것임을 문서로 확인하는 것입니다. 그 세 단계(또는 네 단계) 스크립트 사다리는 레거시 기본값이지, 유일한 모델은 아닙니다. ASTM E2500과 GAMP 5 제2판은 IQ/OQ/PQ를, 세 개의 별도 스크립트 적격성 평가를 처음부터 다시 실행하는 대신 공급자의 공장 및 현장 인수 시험(Factory and Site Acceptance Testing, FAT/SAT)과 시운전(commissioning) 증거를 활용하는 단일한 위험 기반 검증(verification)으로 점점 통합하고 있습니다. 그리하여 같은 증거를 세 번 옮겨 적는 대신, 가용한 최선의 증거로부터 한 번에 조립합니다 [4][1]. GAMP 5 제2판(2022)은 이 모든 것을 오늘날 소프트웨어가 만들어지고 구매되는 방식에 맞게 현대화했습니다. 반복적인 애자일(Agile) 개발, 클라우드 서비스, 떠오르는 AI를 수용하고, 노력이 어디로 가야 하는지를 결정하는 명시적인 실로서 비판적 사고(critical thinking)를 끌어올렸습니다 [1].

이제 같은 V는 두 가지 방식으로 읽힙니다. 아래 두 그림을 비교해 봅시다. 첫 번째는 고전적인 V로, 모든 단계가 똑같이 테스트됩니다. 두 번째는 CSA 오버레이로 다시 그린 것으로, 위험이 단계마다 엄격함을 조절합니다. 단순하게 그리면, V는 각 명세를 그 검증과 짝짓습니다. CSA의 렌즈를 통해 그리면, 하나의 오버레이가 더해집니다. 각 단계에 적용되는 엄격함이 더 이상 획일적이지 않고 위험에 따라 조절되어, 중요하고 환자에게 영향을 미치는 기능은 그 단계에서 엄격한 스크립트 기반 증명을 받는 반면 사소한 기능은 더 가벼운 비스크립트 점검과 훨씬 적은 문서 작업을 받습니다.

같은 V-모델을 이제 CSA로 읽기: 각 명세는 여전히 짝이 되는 검증으로 증명되지만, 위험이 각 단계를 얼마나 엄격하게 테스트할지 결정합니다. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

CSV에서 CSA로: 컴퓨터 소프트웨어 보증, 스크립트보다 사고

2022년 FDA 컴퓨터 소프트웨어 보증으로의 전환

그 표현, 비판적 사고가 이 이야기의 가장 최근 막으로 들어가는 경첩입니다. 2022년 FDA는 컴퓨터 소프트웨어 보증(Computer Software Assurance, CSA) — 의료기기 생산 및 품질 시스템 소프트웨어를 위해 작성된 가이던스로, 그 위험 기반 원칙을 의약품·바이오의약품 업계가 빠르게 유추 적용해 온 것입니다 — 을 도입하는 초안 가이던스를 발표했고, 2025년에 최종본을 내놓았습니다 [3][2]. CSA는 CSV가 되어버린 부담에 대한 의도적인 진로 수정입니다. 그 메시지는 이렇습니다. 환자 안전과 제품 품질에 중요한 것에 보증 노력을 집중하고, 각 기능에 얼마나 많은 테스트가 필요한지를 결정할 때 비판적 사고를 적용하며, 그러면서도 확신을 주는 최소 부담(least-burdensome) 접근법을 사용하라는 것입니다 [2].

스크립트 대 비스크립트(탐색적) 테스트

CSA는 태도뿐 아니라 테스트 도구함도 바꿉니다. 무거운 스크립트 기반 테스트(scripted testing)와 더불어, 더 가벼운 방법인 비스크립트 테스트(unscripted testing)(예: 숙련된 테스터가 미리 작성된 스크립트 없이 시스템을 탐색하는 탐색적 또는 임시(ad-hoc) 테스트)를 낮은 위험의 기능에 대해 명시적으로 지지합니다. 이때 문서화는 획일적이고 빠짐없는 것이 아니라 위험에 비례합니다 [2][9]. 그 결정은 먼저 하나의 단순한 질문에서 흘러나옵니다. 이 소프트웨어 기능이 실패한다면 환자에게 해를 끼치거나 제품 품질을 손상시킬 수 있는가? 영향이 크고 환자에게 직접 닿는 기능은 엄격한 스크립트 기반 증명을 받고, 영향이 작은 기능은 더 가볍고 빠른 보증을 받습니다 [9].

구체적인 예가 그 논리를 실제로 보여줍니다. LIMS에서, 시험 결과에 대한 분석자의 자유 서술(free-text) 코멘트를 저장하는 필드는 중요하지 않습니다. 그것이 실패하더라도 보고 대상 분석 결과 자체는 영향을 받지 않으므로, CSA는 이를 더 낮은 위험으로 분류하고 위험에 비례하는 문서화와 함께 비스크립트 테스트를 허용합니다. 반대로, 원시 계측 데이터로부터 분석 역가를 계산하는 코드는 중요합니다. 그것은 환자의 약이 출하되는 근거가 되는 수치에 직접 영향을 미치므로, 엄격한 스크립트 기반 테스트와 완전한 IQ/OQ/PQ를 요구합니다. 같은 시스템, 두 기능, 그리고 매우 다른 두 수준의 보증입니다.

CSA는 시험 노력을 위험에 맞춥니다 — 환자를 보호하는 곳에는 엄격함을, 그렇지 않은 곳에는 절제를. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

결정적으로, CSA는 CSV나 GAMP 5를 내던지지 않습니다. 그것은 이들의 위험 기반 의도를 실행 가능하게 만듭니다(operationalizes) [9]. 2025년 최종 가이던스는 2002년 소프트웨어 검증 가이던스를 보충하며, 오직 그 특정 검증 절(section)만 대체하고 더 넓은 생애주기 접근법은 그대로 둡니다 [2][6]. GAMP 5 제2판과 CSA는 같은 말을 하는 두 목소리로 읽는 것이 가장 좋습니다. 품질을 바인더의 무게로 재는 일을 멈추라는 것입니다 [1][2].

증거의 척추로서의 요구사항 추적성 매트릭스

V-모델이 검증의 형태이고 CSA가 그 태도라면, 요구사항 추적성 매트릭스(requirements-traceability matrix, RTM)는 이 둘을 한데 묶는 기록입니다. 그것은 검사관이 실제로 읽는 산출물입니다. 모든 사용자 요구사항이 그것을 증명하는 테스트로 앞으로 이어지고, 모든 테스트가 하나의 요구사항으로 다시 이어지는 표로, 그리하여 테스트되지 않은 것도, 추적되지 않은 것도 없게 합니다. 매트릭스는 이 장의 철학이 가리킬 수 있는 한 줄의 데이터로 바뀌는 곳입니다.

각 행은 작고 고정된 열 집합을 담습니다. 안정적인 요구사항 id, 평이한 언어의 요구사항 텍스트, 검증 등급을 정하는 GAMP 소프트웨어 범주, 테스트 엄격함을 정하는 위험 등급(risk class), 그것을 다루는 검증, 그리고 가장 중요한 열인, 그것이 해석되어 가리키는 테스트와 그 결과 및 증거 링크입니다. CSA 아래에서 매트릭스는 위험 기반 원칙이 눈에 보이게 되는 곳입니다. Critical 위험 행은 엄격한 스크립트 기반 증명을 끌어오는 반면 저위험 행은 더 가벼운 점검으로 충족되며, 같은 표가 두 결정을 나란히 보여줍니다. 이것은 오픈소스 동반서가 구체화하는 바로 그 기록의 데이터 관리 관점입니다. 오픈소스 GxP 스택 검증하기에서 추적성 매트릭스의 한 행은 — 출하되는 파일에 손으로 적어 넣는 것이 아니라 테스트 ID로부터 생성되며 — 스크린샷 폴더가 아니라, 지속적 통합(continuous-integration, CI)이 커밋마다 재실행하는 실행 가능한 pytest 노드로 해석됩니다. 그리하여 증거는 옮겨 적은 것이 아니라 생성된 것입니다.

추적성 매트릭스 행의 해부

행 하나를 뜯어봅시다. 각 열은 검사관의 질문 하나가 기계가 읽을 수 있는 형태로 답해진 것이기 때문입니다. 아래 행은 URS-003으로, 기록 변경이 귀속 가능하고, 이유가 기록되며, 변조가 드러나야 한다는 요구사항입니다. Part 11 장이 법적 의무로 만든 바로 그 데이터 무결성 통제입니다. 그 gamp_cat이 5인 까닭은, 이 예시에서 변조가 드러나는 해시 체인이 (Part 11 장이 해부한 바로 그 체인) 구성된 벤더 기능이 아니라 이 스택을 위해 작성된 주문 제작 코드이기 때문입니다. 바로 그렇기에 공급자를 활용하도록 두는 대신 가장 높은 검토 수준을 얻는 것입니다. risk는 Critical이며, test_id는 그 결과가 바인더 페이지가 아니라 CI 로그로 뒷받침되는 PASS인 실행 가능한 테스트로 해석됩니다.

추적성 행의 각 열은 하나의 역할을 한다. test_id는 실행 가능한 결정타다 — 그것은 실제로 실행되는 테스트를 가리키므로, 증거는 옮겨 적은 것이 아니라 재생성된다. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

한 필드씩 읽어보면, 처음 다섯 열은 바인더 기반 매트릭스라면 어느 것이든 담았을 장부 기재입니다. 여섯 번째 test_id는 이 문서의 종류를 바꿉니다. 전통적 매트릭스는 검증 열을 사람이 한 번 옮겨 적은 증거에 가리키는 반면, 현대적 매트릭스는 기계가 재생성하는 증거에 가리킵니다. 이것이 CSV와 CSA의 차이 전부를 단 하나의 셀로 표현한 것입니다. 이 행은 또한 독자를 이 삼부작의 실을 따라 넘겨줍니다. 그것이 보호하는 물리적 통제 지점(배치 기록의 귀속 가능한 편집)은 품질, 규제, 데이터 백본의 제조 단계로 거슬러 추적되고, 바로 이 행의 구체적 구현은 오픈소스 검증 장에 있습니다.

그래프로서의 추적성 행: 스프레드시트 셀이 아니라 하나의 셰이프

그 행 아래 깔린 더 깊은 구조에 주목해 봅시다. 매트릭스는 "모든 요구사항이 테스트로 앞으로 이어지고 다시 뒤로 이어져, 테스트되지 않은 것도 추적되지 않은 것도 없게 한다"고 말합니다. 이것은 존재하는 행들에 대한 질의가 아니라, 존재해야 하지만 빠졌을 수도 있는 행들에 대한 주장입니다. 바로 온톨로지 책이 출하를 게이트할 때 끌어오는 닫힌 세계(closed-world) 점검(빠진 필수 사실을 알 수 없음이 아니라 실패로 취급하는 점검)입니다. 같은 URS-003 기록은 사람이 눈으로 훑는 행이 아니라, RDF(Resource Description Framework, 데이터를 주어-술어-목적어 트리플(triple), 즉 그래프의 원자적 사실로 쓰는 표준 방식)로 표현하여 SHACL(Shapes Constraint Language, 그래프 데이터가 요구되는 구조를 갖췄는지 검증하는 언어) 셰이프로 게이트할 수 있습니다.

# URS-003을 트리플로, 그리고 그 추적성을 닫힌 세계로 게이트하는 SHACL 셰이프.
@prefix v:   <https://example.org/validation#> .
@prefix sh:  <http://www.w3.org/ns/shacl#> .

v:URS-003 a v:UserRequirement ;
    v:gampCategory 5 ;
    v:riskClass    "Critical" ;
    v:verifiedBy   v:TEST-003 .          # forward link to the test that proves it

v:TraceabilityShape a sh:NodeShape ;
    sh:targetClass v:UserRequirement ;
    sh:property [ sh:path v:verifiedBy ;  # every requirement MUST resolve to a test
                  sh:minCount 1 ;
                  sh:message "Untraced requirement: no test resolves it." ] ;
    sh:property [ sh:path v:riskClass ;   # and carry a risk class from the controlled set
                  sh:minCount 1 ; sh:maxCount 1 ;
                  sh:in ( "Critical" "High" "Medium" "Low" ) ] .

이제 추적되지 않은 요구사항은 누군가가 알아차려야 할 빈틈이 아니라 검증 보고서입니다. 그리고 매트릭스의 역방향, 즉 *모든 요구사항에 여전히 통과한 테스트가 있는가?*는 한 줄짜리 SPARQL(SQL이 표에 대해 그러하듯 RDF 그래프에 대한 표준 질의 언어) 역량 질문(competency question)(데이터가 답할 수 있어야 하는 평이한 언어의 질문으로, 통과/실패 점검으로 실행됩니다)입니다.

# CQ: list any Critical requirement whose test is missing or not PASS — the inspector's question.
PREFIX v: <https://example.org/validation#>
SELECT ?req WHERE {
  ?req a v:UserRequirement ; v:riskClass "Critical" .
  OPTIONAL { ?req v:verifiedBy ?t . ?t v:result ?r }
  FILTER (!BOUND(?r) || ?r != "PASS")
}

요점은 매트릭스 표를 폐기하자는 것이 아니라, 매트릭스가 이미 작은 그래프이며 그것의 "테스트되지 않은 것도 추적되지 않은 것도 없다"는 약속이 바로 SHACL 게이트가 기계적으로 강제하는 완전성 보장이라는 점을 보는 것입니다. 같은 기록은 또한 W3C PROV-O 의미의 출처(provenance)(어떤 활동으로부터 누가 또는 무엇이 사실을 만들어냈는지를 기록하는 표준 어휘)를 담습니다. test_id 링크는 결과에서 그것을 만들어낸 CI 실행으로 거슬러 잇는 prov:wasGeneratedBy 엣지이므로, 감사자는 PASS만이 아니라 그것을 주장한 활동까지 읽습니다. 온톨로지 책은 바로 이 장치, 즉 빠진 결과 위반이 조사를 라우팅하는 SHACL 셰이프로 모델링된 출하 결정을 검증: 출하 게이트와 SHACL에서 구축하고, 그러한 기록의 FAIR(찾을 수 있고, 접근할 수 있고, 상호 운용 가능하고, 재사용할 수 있음) 테스트를 유지보수: 출판, 조립된 실, 그리고 FAIR에서 측정된 점수표로 바꿉니다. 현대적 RTM과 SHACL 출하 게이트는 두 가지 표기법으로 쓴 같은 발상입니다. 완전성을 기계가 보장할 수 있는 체크리스트입니다.

검증은 끝나지 않는다: 데이터 무결성과 정기 검토

검증은 한 번 통과하고 잊어버리는 일회성 관문이 아닙니다. 규제 대상 시스템은 자신의 데이터 무결성 통제(data-integrity controls)가 계속 작동하도록 유지해야 합니다. 감사 추적(audit trail)(누가, 언제, 무엇을, 왜 했는지에 대한 안전하고 시간이 기록된 기록으로, Part 11 장에서 만난 신뢰의 척추)은 그저 켜놓기만 할 것이 아니라 그 자체가 검증되고 검토되어야 합니다 [8][7]. Annex 11은 이를 명시적으로 만들어, 전산화 시스템이 검증될 것, 데이터가 보호될 것, 그리고 시스템이 생애 전체에 걸쳐 검증된 상태를 유지함을 확인하기 위해 정기 검토(periodic review)를 거칠 것을 요구합니다 [7]. 5년 전에 검증되었으나 그 이후로 패치되고, 재구성되고, 업그레이드된 시스템은 오늘 자동으로 신뢰할 수 있는 것이 아닙니다. 정기 검토는 그 신뢰를 다시 얻어내는 방법입니다 [7].

끊임없이 변하는 세계에서 검증하기

정기 검토는 느리게 변하는 시스템을 가정합니다. 여기 패치 하나, 저기 업그레이드 하나를, 편안한 연간 주기로 검토하는 식입니다. 현대의 소프트웨어 공급망은 그 가정을 깨뜨립니다. 클라우드 또는 SaaS(서비스형 소프트웨어, software-as-a-service) 플랫폼은 움직이는 표적입니다. 공급업체는 자신의 고유한 일정에 따라, 종종 주 단위로 기능과 보안 수정, 인프라 변경을 배포하며, 고객은 한때 잠긴 방의 서버를 동결하던 식으로 버전을 동결할 수 없습니다. 고객 자체 팀 내부의 애자일(Agile) 개발은 안쪽에서 같은 변동을 더합니다. GAMP 5 제2판은 명시적으로 이 세계로 손을 뻗어, 일회성 스크립트 실행이 아니라 반복적 전달, 지속적 통합, 그리고 공급자 및 자동화 증거의 활용을 지지하며 [1], CSA의 최소 부담 자세는 변경을 다시 증명하는 일을 두려워하기보다 지속적으로 할 만큼 충분히 저렴하게 만드는 것입니다 [2]. 그 지향점은 지속적으로 검증되는 시스템입니다. 모든 변경이 비례적이고 대체로 자동화된 보증 점검을 다시 촉발하며, 검증된 상태가 5년 묵은 인증서가 아니라 살아 있는 속성으로 유지되는 것입니다. 규제 당국도 바로 이 간극을 따라잡고 있습니다. EU는 2025년에 개정된 Annex 11(그리고 문서화에 관한 4장의 동반 업데이트)을 공개 의견 수렴에 부쳤는데, 클라우드와 SaaS 서비스 제공업체, 감사 추적 검토, 네트워크로 연결된 다중 시스템 환경 전반의 데이터 무결성, 그리고 AI/ML로 적용 범위를 명시적으로 확장했습니다. 바로 이 절이 깨지고 있다고 말한 2011년 시절의 가정들입니다 [11]. 그 지향점이 실제로 도달 가능한지가 다음 절의 미해결 문제입니다.

미해결 과제: 움직이는 시스템을 검증된 상태로 유지하기

CSA의 약속은 가치가 낮은 문서 작업을 줄이고 보증이 위험을 따르게 하는 것입니다. 그러나 그것은 자신이 완전히 풀지 못한 문제를 더 날카롭게 만듭니다. FDA의 생산 및 품질 시스템 소프트웨어를 위한 컴퓨터 소프트웨어 보증(Computer Software Assurance for Production and Quality System Software) 가이던스(FDA, 2025; 초안 2022)와 GAMP 5 제2판(ISPE, 2022)은 둘 다 노력을 위험에 맞추고 공급자 및 자동화 증거를 활용하라고 말하지만 [2][1], 어느 쪽도 시스템이 주 단위로 바뀔 때 어떻게 GxP 시스템 — GMP나 GLP 같은 우수 관행(Good Practice) 규정의 적용을 받는 시스템 — 을 검증된 상태로 유지하며, 소프트웨어가 공급업체의 멀티테넌트 서비스일 때 누가 증거를 소유하는가에 깔끔하게 답하지 못합니다.

세 가지 매듭이 진정으로 어렵게 남아 있습니다. 첫째, 주기(cadence)입니다. 전통적 정기 검토와 변경 관리는 느린 변화를 위해 만들어졌고, 매주 업데이트되는 클라우드 플랫폼은 사람의 속도에 맞춘 어떤 재검증 주기도 앞지를 수 있습니다. 공급업체가 예정에 없던 업데이트를 밀어 넣는 순간, 검증된 상태는 허구가 될 위험이 있습니다 [2]. 둘째, 증거의 소유권입니다. 멀티테넌트 SaaS에서 고객은 다른 모든 테넌트도 함께 가동하는 공유 인스턴스를 볼 수도, 동결할 수도, 완전히 테스트할 수도 없습니다. 공급업체의 적격성 평가 증거를 평가하고 신뢰해야 하지만, 검사관이 책임을 묻는 규제 대상자는 여전히 고객이므로 부담은 소프트웨어와 함께 실제로 이전되지 않습니다 [1][4]. 이를 실무에서 풀어내는 구체적 수단들, 즉 공급자 감사와 공유(컨소시엄) 감사, 공급업체의 적격성 평가 패키지, 그리고 규제 대상 고객이 평가하고 신뢰하는 제3자 보증으로서의 SOC 2 Type II 보고서는, 인스턴스를 소유하지 않고도 확신을 쌓게 해주지만 책임을 결코 넘겨주지는 못합니다. 셋째, 지속적 증명입니다. "모든 변경이 비례적 점검을 다시 촉발한다"를 현실로 만들려면 보증 자체가 자동화되고 재실행 가능해야 하는데, 이는 대부분의 규제 품질 시스템이 아직 구축하지 못한 공학적 역량입니다. 그리고 자동화된 pytest 스위트가 운영 증거가 될 수 있다는 오픈소스 동반서의 시도가 바로 이것에 대한 하나의 구체적 시도로, 오픈소스 GxP 스택 검증하기와, 기록 측면으로는 오픈소스에서의 Part 11과 Annex 11에서 탐구됩니다. 기술 수준의 정직한 현실은, CSA가 지속적으로 검증할 허락을 주지만 발밑의 소프트웨어가 결코 멈추지 않을 때 그것을 해내는 완성된 방법을 누구에게도 건네주지는 않는다는 것입니다.

왜 중요한가

데이터 관리에서 검증은 "시스템이 그렇게 말한다"를 "시스템이 그렇게 말한다고 신뢰할 수 있다"로 바꾸어 주는 것입니다. 검증은 배치의 데이터 그림자(data shadow), 즉 캠페인 BATCH-2026-001을 시드 바이알에서 출하 바이알까지 따라다니는 완전한 디지털 기록이 분자 그 자체만큼 신뢰받게 해주는 것입니다. 출하된 모든 역가 결과, 모든 감사 추적 편집, 모든 계보 링크는 그것을 생산한 시스템이 목적에 적합함이 증명되었다는 데에 기대고 있습니다. 그것은 또한 FAIR한 데이터 그림자를 들일 노력만큼의 가치가 있게 만드는 것이기도 합니다. 찾을 수 있고(findable), 접근할 수 있고(accessible), 상호 운용 가능하고(interoperable), 재사용할 수 있는(reusable) 데이터는 그것을 기록한 검증된 시스템만큼만 신뢰할 수 있습니다. 검증 없는 FAIR는 그저 잘 정리된 풍문일 뿐입니다. 데이터의 모든 하위 용도, 즉 배치 출하, 일탈 조사, 모델 훈련은 그 데이터를 생산하는 시스템이 목적에 적합함이 증명되었다는 가정 위에 놓여 있습니다. CSA로의 전환이 중요한 까닭은 그것이 위험이 가장 높은 곳, 즉 환자 안전과 데이터 품질을 직접 보호하는 기능에 보증 노력을 집중시키고, 모든 구성요소에 획일적인 정밀 검토를 똑같이 적용하지 않기 때문입니다 [2][9]. 잘만 하면 이는 더 적은 낭비된 문서 작업으로 더 많은 실질적 품질을 의미하며, 이 책의 나머지 부분이 의존하는 현대적이고 데이터가 풍부한 시스템을 더 빠르게 도입하는 길이 됩니다.

현실 세계에서는

여기에 걸린 경제적 문제는 추상적이지 않습니다. 레거시 CSV 접근법은 문서가 워낙 무거워서, 기업들은 재검증 문서 작업을 피하려는 순전한 이유로 소프트웨어 업그레이드를 종종, 때로는 몇 년씩이나 미루었고, 그 결과 공장은 오래되고 덜 안전한 시스템을 가동하게 되었습니다 [3][9]. FDA가 CSA를 출범시킨 것은 부분적으로 이 교착 상태를 깨고 품질을 개선하는 자동화를 장려하기 위해서였습니다 [3]. GAMP 5의 "공급자를 활용하라" 원칙은 이제 일상적인 관행입니다. 바이오 의약품 제조사가 클라우드 또는 SaaS(서비스형 소프트웨어, software-as-a-service) 플랫폼(고객 자체 서버에 설치하는 대신 구독 형태로 제공되는 클라우드 호스팅 MES나 LIMS)을 도입할 때, 자사가 그 소프트웨어를 직접 만든 척하는 대신 공급업체의 테스트 및 적격성 평가 증거를 평가하여 재사용합니다 [1][4]. 범주 3 상용 기성품 SaaS 제품의 경우, 보증의 상당 부분은 현장에서 모든 기능을 재검증하기보다 공급자의 감사받은 문서에서 나올 수 있습니다. 같은 위험 기반·생애주기 사고는 소프트웨어 검증을 넘어 확산되고 있습니다. 분석 절차 개발에 관한 ICH Q14는 데이터를 생성하는 방법들에 대해 향상된 생애주기 접근법을 권장합니다. 즉 중요한 것을 측정하고 그것을 방법의 생애 전반에 걸쳐 관리하라는 것으로, 실험실에서 CSA의 "노력을 위험에 맞추라"는 논리를 그대로 반향합니다 [10]. (Q14는 2023년 11월에 Step 4 단계로 확정되었으며, 분석 절차 검증에 관한 개정된 ICH Q2(R2)와 한 쌍을 이룹니다. 둘은 함께 향상된 접근법이라는 발상을 제품에서 방법으로 확장합니다.) 그리고 최전선은 계속 움직입니다. 학습하면서 행동이 표류(drift)할 수 있는 AI/ML 모델의 검증은 이 프레임워크들을 새로운 방식으로 잡아당깁니다. 그러한 모델은 일회성 IQ/OQ/PQ를 넘어 정기적인 재검증과 표류 모니터링(drift monitoring)을 필요로 하는데, 이는 GAMP 5 제2판이 다루기 시작한 과제이며 [1], 규제 결정을 뒷받침하는 AI에 관한 FDA의 2025년 초안 가이던스와 ISPE의 떠오르는 GAMP AI/ML 가이던스는 이 프레임워크들을 학습 시스템으로 확장하려는 최초의 구체적 시도입니다 [13][14]. 우리가 머신러닝 장에서 다시 돌아올 실타래입니다.

"모델을 검증한다"는 것이 실제로 요구하는 것

AI 모델이 왜 IQ/OQ/PQ 틀을 긴장시키는지는 구체적으로 짚어둘 가치가 있습니다. 그것이 PQ 단계가 만들어내야 할 증거를 바꾸기 때문입니다. 모델의 PQ는 일회성 정확도 측정이 아닙니다. 그 정확도가 일반화된다는 것을 증명해야 하며, 바이오공정에서 그 증명은 일반 소프트웨어 적격성 평가에는 결코 없던 세 부분으로 이루어집니다.

첫째, 보류된(held-out) 테스트는 행 단위가 아니라 배치 단위로 분할되어야 합니다. 이를 그룹(배치 단위 leave-one-batch-out) 교차검증(grouped cross-validation)(한 배치의 모든 행을 학습에서 빼고 그 보지 못한 배치에 대해서만 채점하는 규율)이라 합니다. 단일 배치의 시계열을 무작위로 분할하면 거의 동일한 이웃 행들이 학습과 테스트 양쪽에 들어가는데, 이를 데이터 누수(data leakage)(테스트 집합의 정보가 학습으로 새어 드는 것)라 하며, 이는 보고된 정확도를 진정으로 새로운 배치를 처음 만나는 순간 무너지는 수치로 부풀립니다. 누수된 분할에서 그럴듯한 R²를 보고하는 검증은 검증이 아닙니다. 바인더 시대가 만들어낸 "증명된 것처럼 보이지만 아닌" 바로 그 실패를, 매체만 바꿔 되풀이한 것입니다.

둘째, 적격성 평가는 모델의 적용 범위(applicability domain)를 선언해야 합니다. 이는 모델이 입증된 입력 영역(세포주, 규모, 원자재 로트, 운영 범위)이며, 그 바깥에서 모델의 출력은 정의상 외삽(extrapolation)이고 신뢰할 수 없습니다. 이것은 방법의 검증된 범위에 해당하는 모델의 대응물이며, 모델 표류(model drift)(모델이 학습한 관계가 옮겨가서 모델이 낡아지는 것)와 일반적인 공정 표류(process drift)의 차이를 감사 가능하게 만듭니다. 공정이 그 한계를 벗어남을 알리는 바로 그 입력 분포 이동이, 모델이 이제 적격성 평가받은 데이터 바깥을 예측하도록 요구받고 있다는 신호이기도 합니다.

셋째, 그리고 여기서 CSA의 논리가 정확히 돌아옵니다. 모델은 그것이 닿는 대상에 따라 위험 등급이 매겨집니다. 단지 핵심 품질 속성(critical quality attribute, CQA — 배치를 출하하려면 한계 안에 머물러야 하는 측정 가능한 제품 속성)에 대해 운영자에게 조언만 하는 소프트 센서는, 그것에 대해 자율적으로 작동하는 모델보다 훨씬 가벼운 증거 기준을 적용받습니다. CSA가 모든 소프트웨어 기능에 묻는 바로 그 환자 영향 질문입니다. 규제 당국이 수렴한 해법은 잠그고-다시-학습(locked-then-relearn)입니다. 모델은 생산에서 동결되어 그 자리에서 결코 수정되지 않으며, 모든 재학습은 사전 합의된 사전 결정 변경 관리 계획(Predetermined Change Control Plan, PCCP — 모델을 어떻게 재학습하고 갱신할 수 있는지를 미리 승인해 적은 명세)을 따라 변경 관리를 거쳐 승급되는 새로운 검증된 버전을 만들어냅니다. 모든 재학습을 예상치 못한 변경으로 취급하는 대신, 모델이 사전에 안전하다고 증명된 경로를 따라 진화하도록 해주는 다리입니다. 머신러닝 책은 이 생애주기를 처음부터 끝까지 구축합니다. 그룹 교차검증과 누수는 모델과 검증: PLS에서 트랜스포머까지에서, 표류 탐지와 PCCP, 그리고 검증 대 학습 역설은 MLOps와 생애주기에서 다룹니다.

핵심 용어

• 전산화 시스템 검증(Computerized System Validation, CSV) — 컴퓨터 시스템이 의도된 일을 일관되게 수행하며 의도된 용도에 적합함을 보여주는 문서화된 증거를 만들어내는 것.
• GxP — 규제 대상 생명과학 작업을 규율하는 우수 관행(Good Practice) 규정 전반(GMP, GLP, GCP 등).
• 검증 대 밸리데이션(verification vs. validation) — 검증(verification)은 "제대로 만들었는가?"(명세 충족)를, 밸리데이션(validation)은 "올바른 것을 만들었는가?"(용도 적합)를 묻는 구분.
• GAMP 5 — 규제 대상(GxP) 전산화 시스템 검증을 위한 ISPE의 널리 쓰이는 위험 기반 지침. 여기서 GxP는 GMP, GLP 같은 우수 관행(Good Practice) 규정 전반을 가리킨다. 제2판(2022).
• 소프트웨어 범주(1, 3, 4, 5) — 소프트웨어를 그 유형과 구성·맞춤 제작 정도에 따라 분류하여 요구되는 노력을 조절하는 GAMP 5의 분류 체계.
• 공급자 활용(leverage the supplier) — 처음부터 다시 테스트하는 대신 공급업체의 테스트와 문서를 평가하여 재사용하는 것.
• V-모델(V-model) — 각 명세를 짝이 되는 검증과 짝짓는 GAMP 5 프레임워크.
• IQ / OQ / PQ — 설치, 운영, 성능 적격성 평가(Installation, Operational, Performance Qualification): 전통적인 검증 단계.
• ASTM E2500 — 시스템이 의도된 용도에 적합함을 검증하기 위한 과학 및 위험 기반 표준.
• ICH Q9 — 노력을 위험에 맞추어 조절하는 것을 정당화하는 품질 위험 관리 가이드라인.
• 컴퓨터 소프트웨어 보증(Computer Software Assurance, CSA) — 전통적 CSV를 잇는 FDA의 위험 기반·최소 부담·비판적 사고 접근법.
• 비판적 사고(critical thinking) — 환자 안전과 제품 품질에 미치는 영향을 바탕으로 한 기능에 얼마나 많은 테스트가 필요한지를 결정하는 것.
• 스크립트 대 비스크립트 테스트(scripted vs. unscripted testing) — 미리 작성된 단계별 테스트 대 낮은 위험 기능을 위한 더 가벼운 탐색적/임시 테스트.
• 정기 검토(periodic review) — 시스템이 생애 전체에 걸쳐 검증된 상태를 유지함을 반복적으로 확인하는 것.
• 요구사항 추적성 매트릭스(requirements-traceability matrix, RTM) — 각 요구사항을 그것을 증명하는 테스트로 앞으로, 그리고 다시 뒤로 잇는 표로, 테스트되지 않은 것도 추적되지 않은 것도 없게 하는 검증의 증거 척추.
• 위험 등급(risk class) — CSA 아래에서 요구사항별로 매겨지는 등급(예: Critical)으로, 그 검증을 얼마나 엄격하게 테스트할지를 정한다.
• 지속적 검증(continuous validation) — 자주 변하는 시스템(클라우드, SaaS, 애자일)을, 드문 재검증이 아니라 비례적이고 대체로 자동화된 보증으로 각 변경을 다시 증명함으로써 검증된 상태로 유지하려는 지향.
• SHACL 추적성 셰이프 — 요구사항 추적성 행을 RDF 트리플로 표현하고 SHACL(Shapes Constraint Language) 셰이프로 게이트하는 것으로, 추적되지 않거나 테스트되지 않은 요구사항이 사람이 알아차려야 할 빈틈이 아니라 검증 보고서가 되게 한다.
• 역량 질문(competency question) — 데이터가 답할 수 있어야 하는 평이한 언어의 질문으로, 통과/실패 SPARQL 점검으로 실행된다(예: "테스트가 없거나 PASS가 아닌 Critical 요구사항을 모두 나열하라").
• PROV-O 출처(provenance) — 어떤 활동으로부터 누가 또는 무엇이 사실을 만들어냈는지를 기록하는 W3C 표준. test_id 링크는 결과에서 그것을 만들어낸 CI 실행으로 거슬러 잇는 prov:wasGeneratedBy 엣지이다.
• 그룹(배치 단위 leave-one-batch-out) 교차검증 — 모델의 보류된 테스트를 행 단위가 아니라 배치 단위로 분할하여, 거의 동일한 이웃 행들이 학습과 테스트 양쪽으로 새어 들지 못하게 하는 것.
• 데이터 누수(data leakage) — 테스트 집합의 정보가 학습으로 새어 들어 보고된 모델 정확도를 부풀리며, 진정으로 새로운 배치에서 무너지는 수치를 만들어내는 것.
• 적용 범위(applicability domain) — 모델이 입증된 입력 영역(세포주, 규모, 원자재 로트, 운영 범위). 그 바깥에서 출력은 외삽이고 신뢰할 수 없으며, 방법의 검증된 범위에 해당하는 모델의 대응물이다.
• 잠그고-다시-학습 / PCCP(locked-then-relearn / PCCP) — 모델을 생산에서 동결하여 그 자리에서 결코 수정하지 않고, 모든 재학습이 미리 승인된 사전 결정 변경 관리 계획을 따라 변경 관리를 거쳐 승급되는 새로운 검증된 버전을 만들어내는 것.

이 다음은

검증은 단일 시스템이 신뢰할 수 있음을 증명하고, 데이터 무결성 통제는 각 기록을 정직하게 지킵니다. 그러나 어느 것도 그것만으로는 조직의 데이터를 대규모로 신뢰할 수 있게 만들지 못합니다. 그것은 모두가 따르는 정책과 역할, 정의를 필요로 합니다. 다음 장인 데이터 거버넌스, 데이터 품질, 마스터 데이터(Data Governance, Data Quality, and Master Data)가 그 조직적 척추를 제공합니다. 거버넌스란 무엇인지, 데이터를 "좋게" 만드는 차원들은 무엇인지, 메타데이터와 마스터 데이터가 시스템 전반에서 의미를 어떻게 일관되게 유지하는지, 그리고 누가 데이터를 소유(own)하고 관리(steward)하는지, 즉 Part III의 모든 기술적 통제를 실제로 자리 잡게 만드는 인적 구조를 제공합니다.