오픈소스 스택 밸리데이션: GAMP 5와 CSA

📍 현재 위치: 5부 · 신뢰 — 우리는 감사 추적(audit trail)과 전자서명(e-signature)을 갖춘, 돌아가는 스택을 손에 넣었습니다. 이제 그것이 GxP 용도에 적합함을 증명해야 하는데, 뒤에 숨을 벤더(vendor)는 없습니다.

쉽게 말하면

밸리데이션된(validated) 소프트웨어를 사는 것은, 두툼한 서류철을 건네주고 지붕이 새면 책임을 지는 시공업자를 고용하는 것과 같습니다. 오픈소스(open source)는 데크를 직접 짓는 것과 같습니다. 아무도 서류철을 건네주지 않고, 아무도 대신 결재해 주지 않습니다. 그렇다고 그것이 치명적인 결격 사유는 아닙니다 — 잘 지은 데크라면 주택 검사관도 통과시킵니다 — 다만 여러분이 영수증과 사진, 그리고 사용한 모든 목재의 목록을 직접 챙겨야 합니다. 이 장은 검사관이 받아들일 방식으로 그 영수증을 챙기는 일에 관한 것이며, 그것을 다시 실행할 수 있는 코드로 해내는 일에 관한 것입니다.

지난 장들에서 여러분은 trust 프로파일을 켜고, 감사 트리거(audit trigger)를 활성화하고, 서명 서비스를 띄웠습니다. 모든 것이 돌아갑니다. 하지만 "내 노트북에서는 돌아간다"는 "밸리데이션되었다"가 아닙니다. 이 스택을 돌려 단일클론항체(monoclonal antibody, mAb)를 만드는 규제 제조사라면, 자신이 왜 그것을 신뢰하는지를 검사관에게 문서로 설명할 수 있어야 합니다 — 그리고 오픈소스에는 기댈 수 있는 공급자가 없습니다.

이 장이야말로 정직한 하이브리드(honest-hybrid) 명제가 가장 날카롭게 파고드는 곳입니다. 순수 오픈소스는 방어 가능한 밸리데이션 패키지로 가는 길의 약 80%까지 여러분을 데려다줄 수 있습니다. 마지막 한 구간 — 절차, 변경 관리(change control), 사람의 결재, 감사된 환경 — 은 여러분의 몫이며, 그 부담은 아래에 깔린 소프트웨어가 0달러였든 100만 달러였든 똑같습니다.

이 장에서 다루는 내용

• "밸리데이션된 소프트웨어"가 왜 신화이며 밸리데이션이 시스템 + 절차의 속성인지를, 21 CFR Part 11 §11.10(a), 21 CFR 820.70(i), 그리고 FDA의 *소프트웨어 밸리데이션 일반 원칙(General Principles of Software Validation)*의 틀로 살펴봅니다.
• 각 스택 구성 요소의 GAMP 5 범주화(categorization) — 인프라로서의 PostgreSQL, 카테고리 5로서의 우리 배치 모델 — 와, 문서에서 위험으로 무게중심을 옮기는 CSA(Computer Software Assurance, 컴퓨터 소프트웨어 보증)의 전환을 다룹니다.
• 공급자 품질 시스템이 없는 커뮤니티 프로젝트에 대한 공급자 및 출처(provenance) 평가를, 이미지 다이제스트(image digest)에 고정된 SBOM으로 뒷받침합니다.
• **URS → IQ/OQ/PQ 추적성 매트릭스(traceability matrix)**와, 이미지 다이제스트에 잠긴 **IQ 매니페스트(manifest)**를 살펴봅니다.
• pytest로 작성한 자동화 OQ — examples/tests/의 테스트들이 곧 밸리데이션 증거이며, 변경이 있을 때마다 CI가 다시 실행합니다.

"밸리데이션된 소프트웨어"는 존재하지 않는다

먼저 여러분의 어휘에서 한 표현을 지우는 것으로 시작합시다. "밸리데이션된 소프트웨어" 말입니다. 어떤 다운로드도 컴플라이언트(compliant)하지 않습니다. 법은 이 점에 대해 정확합니다. 21 CFR Part 11 §11.10(a)는 "정확성, 신뢰성, 일관되게 의도된 성능을 보장하기 위한 시스템의 밸리데이션"을 요구합니다 [1]. 의료기기와 품질 시스템에 대해서는 21 CFR 820.70(i)가 한층 더 직접적입니다. 생산 또는 품질 시스템의 일부로 사용되는 컴퓨터 소프트웨어는 "확립된 프로토콜에 따라 그 의도된 용도에 대해 밸리데이션되어야 한다"고 못 박습니다 [2]. 둘 다 의무를 벤더의 박스가 아니라 여러분이 사용하는 그대로의 시스템에 지웁니다.

FDA의 소프트웨어 밸리데이션 일반 원칙은 우리에게 동사들 — 설치, 운영, 성능 적격성 평가(IQ/OQ/PQ) — 을 제공하며, 밸리데이션을 일회성 시험이 아니라 라이프사이클 활동으로 규정합니다 [3]. 이 장의 나머지가 현금화하는 희소식은, 코드형 인프라(infrastructure-as-code) 스택에서는 그 동사들 각각이 여러분이 실행할 수 있는 무언가에 깔끔하게 매핑된다는 것입니다.

GAMP 5 제2판은 이를 비례적으로 해내기 위한 업계의 플레이북이며, 결정적으로 오픈소스를 금단의 열매로 취급하지 않습니다. 위험 기반의 비판적 사고 접근법과 함께, 소프트웨어 범주, 공급자, 심지어 오픈소스 소프트웨어에 대한 명시적 지침을 제공합니다 [4]. GAMP 실천 공동체(Community of Practice)가 펴낸 짝이 되는 Pharmaceutical Engineering 기사는 OSS 측면을 구체적으로 풀어냅니다. 오픈소스 구성 요소의 카탈로그를 유지하고, 프로젝트의 거버넌스(governance)와 지속 가능성을 평가하며, 설치된 사본이 평판 있는 출처의 의도된 버전과 일치하는지 검증하라는 것입니다 [5].

밸리데이션하기 전에 범주화하라

첫 번째 GAMP 5 수순은 각 구성 요소를 범주화하는 것인데, 범주가 노력의 크기를 좌우하기 때문입니다. 여러분은 PostgreSQL의 B-트리(B-tree) 구현을 밸리데이션하지 않습니다. 그 위에 여러분이 쌓아 올린 애플리케이션을 밸리데이션합니다. 우리 스택이 어떻게 나뉘는지 보겠습니다.

구성 요소	GAMP 범주	이유	밸리데이션 초점
PostgreSQL / TimescaleDB	1 (인프라)	확립된 플랫폼 소프트웨어	올바른 설치, 버전 고정, 명세에 따른 구성
Mosquitto, Grafana, Fuseki	1 (인프라)	수정 없이 사용하는 구성 가능한 플랫폼 도구	설치 + 구성 검증
Grafana 대시보드, OPA 정책, Telegraf TOML	4 (구성됨)	우리는 동작을 코딩하는 것이 아니라 구성한다	구성이 요구사항을 충족하는지 검증
bioproc_sim, ISA-88/95 모델, 감사 트리거, 소프트 센서(soft-sensor)	5 (커스텀)	이 의도된 용도를 위해 우리가 작성한 코드	전체 라이프사이클: 요구사항 → 설계 → 코드 리뷰 → 테스트

카테고리 1 대 5의 구분이 밸리데이션의 경제학 전부입니다. 스택의 대부분은 인프라이거나 구성이며, 카테고리 5로서 중량급 처리가 필요한 것은 우리가 직접 작성한 코드뿐입니다. 바로 거기에 우리는 OQ 테스트를 겨냥합니다.

CSA: 쓰기를 멈추고, 생각하기를 시작하라

수년간 CSV(Computer System Validation, 컴퓨터 시스템 밸리데이션)는 문서화 군비 경쟁으로 흘러갔습니다 — 버튼이 파란색이라는 것을 증명하는 스크린샷 수십 페이지 말입니다. FDA의 컴퓨터 소프트웨어 보증(Computer Software Assurance, CSA) 지침은 그 교정입니다. 2022년에 초안으로 발표되어 [6] 2025년에 확정되었고(2026년 초 행정적 업데이트와 함께) [7], CSA는 위험에 비례하여 노력을 쓰라고 말합니다. 환자에게 영향을 주는 고위험 기능은 엄격한 스크립트 테스트를 받고, 저위험 기능은 더 가벼운 비스크립트 또는 자동화 점검을 받습니다. 기록 관리는 그 반대가 아니라 위험에 따라 확장됩니다.

CSA는 OSS 스택에 주어진 선물입니다. 모든 것을 손으로 다시 도출하는 대신, 기존 증거 — 로그, 감사 추적, 자동화된 테스트 결과 — 를 활용하는 것을 명시적으로 축복합니다. 그것이 바로 pytest 실행과 CI 로그로 가득 찬 Git 저장소가 여러분에게 주는 것입니다. 보증 활동은 이렇게 됩니다. 의도된 용도를 식별하고, 위험을 판단하고, 확신을 세우는 가장 가벼운 테스트를 고르고, 자동화가 기록을 만들어 내게 둡니다.

그리고 이것은 이론이 아닙니다. IMPALA 컨소시엄 — 로슈(Roche), MSD, 베링거 인겔하임(Boehringer Ingelheim) — 은 커뮤니티가 개발한 오픈소스 R 패키지를 GxP/GCP 표준으로 독자적으로 밸리데이션했고, 그들이 정확히 어떻게 했는지를 공개했습니다 [8]. 규제 제약은 벤더 없는 소프트웨어를 방어 가능하게 밸리데이션할 수 있습니다. 그들이 사용한 패턴이 곧 여기서의 패턴입니다. 출처를 평가하고, 의도된 용도를 정의하고, 요구사항에 대해 테스트하고, 증거를 보관하는 것입니다.

공급자가 없을 때의 공급자 평가

GAMP 5는 공급자 평가(supplier assessment) — 보통 벤더 품질 시스템에 대한 설문이나 감사 — 를 기대합니다. 오픈소스에는 감사할 벤더가 없으므로, 대신 프로젝트와 *아티팩트(artifact)*를 평가합니다. 두 가지 질문입니다. 프로젝트가 신뢰할 만한 "공급자"인가, 그리고 여러분이 돌리고 있는 비트 단위로 똑같은 사본이 여러분이 생각하는 그것이 맞는가?

첫째에 대해서는, 프로젝트 건전성을 대리 지표로 평가합니다. 거버넌스, 릴리스 주기, 보안 대응, 커뮤니티 규모, 라이선스가 그것입니다 [5]. 둘째에 대해서는, 고정하고 검증합니다. 우리의 examples/platform/compose/compose.yaml은 모든 이미지를 사람이 읽을 수 있는 태그(tag)로 고정하고, 저장소의 examples/platform/versions.lock은 각 이미지에 대응하는 불변 매니페스트 다이제스트를 기록합니다(make lock으로 재생성).

# from examples/platform/compose/compose.yaml
postgres:
  image: timescale/timescaledb:2.17.2-pg17
  profiles: ["core"]

mosquitto:
  image: eclipse-mosquitto:2.0.22
  profiles: ["core"]

grafana:
  image: grafana/grafana-oss:11.4.0
  profiles: ["core"]

:2.17.2-pg17 같은 태그는 사람에게 친근한 라벨이라 다시 가리킬(re-point) 수 있습니다. 다이제스트(@sha256:…)는 콘텐츠 주소 지정(content-addressable) 방식이라 그럴 수 없습니다. 둘 다 고정하는 것이 "우리는 TimescaleDB 2.17을 돌렸다"와 "우리는 바로 이 TimescaleDB 2.17을 돌렸다"의 차이입니다. 그 구분이 설치를 재현 가능하게 만들며 — 재현성은 모든 IQ 주장의 토대입니다.

기계가 읽을 수 있는 공급자 도시에(dossier)가 **소프트웨어 자재 명세서(Software Bill of Materials, SBOM)**입니다. 우리는 컨테이너 이미지를 훑어 그 안의 모든 패키지를 나열하는 Apache-2.0 도구인 Syft로 하나를 생성합니다 [9]. 출력은 표준화된 포맷 — CycloneDX(이제 Ecma International ECMA-424) [10] 또는 SPDX(ISO/IEC 5962:2021로 비준) [11] — 이므로, 이 인벤토리는 손수 만든 스프레드시트가 아니라 형식을 갖춘, 검사에서 방어 가능한 기반을 가집니다. 다듬어진 CycloneDX 한 행은 다음과 같습니다.

// illustrative SBOM row (CycloneDX 1.6), produced by `make sbom` (Syft)
{
  "type": "container",
  "name": "timescale/timescaledb",
  "version": "2.17.2-pg17",
  "purl": "pkg:docker/timescale/timescaledb@2.17.2-pg17",
  "hashes": [{ "alg": "SHA-256", "content": "sha256:3324f81c…  (digest pinned in versions.lock)" }],
  "licenses": [
    { "license": { "name": "PostgreSQL License" } },
    { "license": { "name": "Timescale License (TSL)" } }
  ]
}

그 하나의 아티팩트가 검사관이 물을 세 가지 질문에 답합니다. 여기에 무엇이 들어 있는가, 어디서 왔는가, 어떤 라이선스인가. 그리고 그것은 산문만으로는 감출 수 있는 정직함을 강제합니다. 고정된 timescale/timescaledb:2.17.2-pg17은 커뮤니티(Community) 번들이며, PostgreSQL License(Apache-2.0 코어)와 소스 공개(source-available) 방식의 Timescale License(TSL)로 이중 라이선스되어 있습니다 — 그래서 SBOM 행은 깨끗한 Apache-2.0이 아니라 TSL을 싣고 있습니다(엄격하게 Apache 전용인 빌드는 -oss 태그입니다). 이 책은 이 함정에 대해 의도적입니다(히스토리언(historian) 장 참조). 무료 TSL 커뮤니티 자동화 — 연속 집계(continuous aggregate)와 add_retention_policy — 를 사용하되, 필요하지 않은 단 하나의 TSL 기능인 Hypercore 컬럼스토어/압축(columnstore/compression)에는 손대지 않습니다. InfluxDB v3 대신 VictoriaMetrics를 싣고, 재배포에 대해서는 Grafana의 AGPL을 표시합니다. 라이선스 열은 장식이 아닙니다 — 공급자 등록부와 SBOM이 하나의 소스(versions.lock)를 공유하므로, 기록된 라이선스는 고정된 이미지가 실제로 무엇이든 그것이며, 인벤토리는 돌아가는 스택에서 조용히 멀어질 수 없습니다.

추적성 매트릭스: URS → IQ/OQ/PQ

밸리데이션은 근본적으로 "우리가 필요하다고 말한 것을 우리가 만들었는가?"에 답하는 일입니다. 그것을 증명하는 아티팩트가 **추적성 매트릭스(traceability matrix)**입니다. 모든 사용자 요구사항(URS)은 앞으로 하나의 테스트에 매핑되고, 모든 테스트는 뒤로 하나의 요구사항에 매핑됩니다. 테스트되지 않은 것 없고, 추적되지 않은 것 없습니다.

다음은 우리 스택의 요구사항-대-테스트 매트릭스의 한 조각으로, 저장소가 compliance/ 아래에 실어 보낼 CSV로 표현한 것입니다.

# illustrative compliance/traceability.csv (URS -> test, generated from test IDs)
urs_id,requirement,gamp_cat,risk,verifies,test_id
URS-001,"Historian stores all bioreactor tags for a batch",1,High,test_historian_loaded,tests/test_db.py::test_historian_loaded
URS-002,"Every reading resolves to a named ISA-88 phase",5,High,test_contextualization_joins_phase,tests/test_db.py::test_contextualization_joins_phase
URS-003,"Record changes are attributable, reasoned, tamper-evident",5,Critical,test_audit_captures_update,tests/test_db.py::test_audit_captures_update
URS-004,"The audit hash chain has no broken links",5,Critical,test_alcoa_chain_intact,tests/test_db.py::test_alcoa_chain_intact
URS-005,"Generated process data is deterministic & reproducible",5,Medium,test_determinism_two_runs_identical,tests/test_simulator.py::test_determinism_two_runs_identical

test_id 열이 핵심입니다. 각 요구사항은 산문 한 단락이 아니라 실행되는 함수를 가리킵니다. 그것이 실전에서의 CSA입니다 — 증거는 옮겨 적는 것이 아니라 생성되는 것입니다.

작성된 요구사항에서 실행 가능한 테스트로: OSS 밸리데이션 라이프사이클은 GAMP 범주화와 위험을 각 구성 요소가 얼마만큼의 적격성 평가를 받을지 정하는 다이얼로 다루고, 그런 다음 IQ를 다이제스트로 고정된 매니페스트로, OQ를 자동화된 pytest로, PQ를 엔드투엔드 배치로 포착합니다 — 모든 단계가 URS로 거슬러 추적됩니다.

Original diagram by the authors, created with AI assistance.

IQ: 다이제스트에 고정된 설치 매니페스트

**설치 적격성 평가(Installation Qualification)**는 "올바른 것이, 올바르게 구성되어, 올바른 자리에 설치되었는가?"에 답합니다. 코드형 인프라에서는 설치 자체가 하나의 파일이므로 이것은 거의 공짜입니다. IQ 매니페스트는 돌아가는 스택의 구성 요소와 그 다이제스트의 스냅샷입니다 — 배포된 것이 명세된 것과 일치한다는 증거입니다.

// illustrative compliance/iq_manifest.json (captured from the running stack)
{
  "captured_utc": "2026-06-14T09:00:00Z",
  "compose_file_sha256": "…",
  "components": [
    { "service": "postgres",  "image": "timescale/timescaledb:2.17.2-pg17",
      "digest": "sha256:3324f81c…", "gamp_category": 1, "profile": "core" },
    { "service": "grafana",   "image": "grafana/grafana-oss:11.4.0",
      "digest": "sha256:d8ea3779…", "gamp_category": 1, "profile": "core" }
  ]
}

매니페스트가 SBOM과 공급자 등록부가 쓰는 것과 같은 versions.lock 다이제스트에서 생성되므로, 통과하는 IQ는 세 가지를 한꺼번에 증명합니다. 올바른 버전이 설치되어 있고, 그것이 라이선스 인벤토리와 일치하며, CI가 테스트한 것과 일치한다는 것입니다. 다이제스트가 어긋나면, 다음 절의 OQ 스위트는 요란하게 실패하도록 설계되어 있습니다 — 그것이 바로 핵심입니다.

OQ: 저장소의 테스트가 곧 증거다

**운영 적격성 평가(Operational Qualification)**는 "운영 범위 전반에서, 마땅히 해야 할 일을 해내는가?"에 답합니다. 이 책의 실습 지향적 성격이 보답하는 지점이 여기입니다. 우리는 이미 OQ를 작성해 두었습니다. examples/tests/의 pytest 스위트 [12]는 나중에 덧붙인 개발자 편의 도구가 아니라 운영 증거이며, 살아 있는 compose 스택에 대해 실행됩니다.

examples/tests/test_db.py를 보세요. 이 테스트들은 돌아가는 PostgreSQL+TimescaleDB에 연결하여 시스템이 요구사항대로 동작함을 단언합니다. 히스토리언 및 맥락화(contextualization) 점검은 URS-001과 URS-002를 검증합니다.

# from examples/tests/test_db.py
def test_historian_loaded(conn):
    n = _scalar(conn, "select count(*) from ts.sensor_reading where batch_id='BATCH-2026-001'")
    assert n > 300_000   # 16 tags x ~20160 minutes


def test_contextualization_joins_phase(conn):
    # every reading in the golden batch should resolve to a named phase
    rows = _scalar(conn, "select count(distinct phase_name) from s88.v_batch_sensor "
                         "where batch_id='BATCH-2026-001' and phase_name is not null")
    assert rows >= 4   # Inoculate, Growth, Production, Harvest

두 개의 데이터 무결성 테스트가 가장 중요한데, Critical 위험인 URS-003과 URS-004 — 검사관이 가장 신경 쓰는 ALCOA+ 통제 — 를 검증하기 때문입니다. test_audit_captures_update는 사용자와 사유를 제공하며 실제 UPDATE를 수행한 뒤, 변경이 포착되었는지 그리고 변조 감지 해시 체인(tamper-evident hash chain)이 여전히 온전한지를 단언합니다.

# from examples/tests/test_db.py
def test_audit_captures_update(conn):
    # an UPDATE must record old + new + who + why and keep the chain intact
    with conn.cursor() as cur:
        cur.execute("select set_config('app.user','pytest',false), "
                    "set_config('app.reason','test correction',false)")
        cur.execute("update lab.result set value = value where result_id = "
                    "(select result_id from lab.result limit 1)")
        conn.commit()
    last = _scalar(conn, "select action from audit.change_log "
                         "where app_user='pytest' order by seq desc limit 1")
    assert last == "UPDATE"
    assert _scalar(conn, "select count(*) from audit.verify_chain()") == 0

실행되고 로그로 남은 그 하나의 테스트가, 감사 추적을 처음부터 끝까지 가동하는 OQ 스크립트입니다. 스크린샷보다 더 나은 증거인데, 누구든 — 검사관까지 포함해 — 그것을 다시 실행하여 통과하는 것을 지켜볼 수 있기 때문입니다.

examples/tests/test_simulator.py의 시뮬레이터 테스트는 재현성 요구사항(URS-005)을 다룹니다. 결정론(determinism)은 그 자체로 하나의 밸리데이션 속성입니다. 같은 입력이 같은 출력을 내지 않는다면, 그 위에 쌓아 올린 어떤 것도 적격성을 평가할 수 없습니다.

# from examples/tests/test_simulator.py
def test_determinism_two_runs_identical():
    a = fed_batch.simulate("BATCH-2026-001").tags["value"].to_numpy()
    b = fed_batch.simulate("BATCH-2026-001").tags["value"].to_numpy()
    assert np.array_equal(a, b)

그리고 전체 스위트는 examples/Makefile의 단 하나의 명령으로 가려져 있는데, 이것이 밸리데이션 엔지니어(또는 CI)가 운영 증거를 만들어 내기 위해 입력하는 바로 그 한 줄입니다.

# from examples/Makefile
test: ## run the test suite (determinism + db + analytics)
	$(PY) -m pytest -q tests

make test가 OQ 실행입니다. 파일로 캡처된 콘솔 출력이 OQ 결과입니다. 깨끗한 머신에서 다시 실행하는 것 — CI가 모든 커밋마다 하는 일 — 은 여러분의 밸리데이션된 상태를 공짜로 회귀 테스트(regression-test)하는 것입니다.

PQ: 배치가 곧 증거다

**성능 적격성 평가(Performance Qualification)**는 "실제 작업에, 실제 조건 하에서, 제대로 작동하는가?"에 답합니다. 우리에게 그것은 정점입니다. 완전한 시뮬레이션 유가식(fed-batch) CHO 캠페인이 센서에서 출발해 히스토리언과 맥락화를 거쳐, 검토 가능하고 서명된 데이터셋과 감사 추적 검토 보고서까지 흘러가는 것 말입니다. PQ는 추상적인 요구사항이 실제 mAb 공정과 만나는 곳입니다. 이 정점 타깃은 바로 그 경로를 처음부터 끝까지 가동하며, CI는 검토 가능한 데이터셋이 존재하고 보고서가 비어 있지 않음을 단언합니다 — 책 전체에 대한 표제격 "구현은 가능하다" 증명입니다.

왜 중요한가

이 장이 없다면, 앞선 스무 개 장은 취미 프로젝트일 뿐입니다. 규제 시설은 방어할 수 없는 소프트웨어를 돌릴 수 없습니다. 이것이 유독 오픈소스에 그토록 중요한 이유는 부재하는 벤더에 있습니다. 밸리데이션된 LIMS를 살 때는 공급자의 품질 시스템이 여러분 부담의 일부를 흡수합니다. OSS에서는 그 부담이 전적으로 여러분에게 떨어집니다 — 하지만 사라지지는 않으며, CSA와 자동화 테스트는 그것을 옛 스크린샷 주도의 CSV가 했던 것보다 더 싸게, 정직하게 떨치도록 만들어 줍니다. 저장소는 밸리데이션을 문서화 프로젝트에서 엔지니어링 프로젝트로 바꾸어, 증거가 소프트웨어를 빌드하는 바로 그 CI에 의해 생성되게 합니다.

실제 현장에서는

정직한 평결: 이 접근법은 실재하며, 실제로 행해지고 있습니다. IMPALA 컨소시엄이 공개한 커뮤니티 R 패키지 밸리데이션은, 거대 제약사가 GxP 맥락에서 독립적으로 평가된 OSS를 뒷받침할 것이라는 증거입니다 [8]. GAMP 5 제2판의 오픈소스 부록과 GAMP CoP 지침은, 그 프레임워크가 이를 명시적으로 지원한다는 것을 뜻합니다 [4] [5]. 그리고 2025년의 CSA 확정은, 이 장이 취하는 위험 기반·증거 활용 자세가 이제 영리한 우회책이 아니라 기대되는 검사 대비 접근법이라는 것을 뜻합니다 [7].

하지만 한계에 대해서는 잔인하리만치 분명히 합시다. 자동화된 pytest는 훌륭한 OQ 증거입니다. 그것이 밸리데이션 패키지의 전부는 아닙니다. 여러분에게는 여전히 빚이 있습니다. 자격 있는 사람이 서명한 밸리데이션 계획서와 보고서, 변경 관리 절차(모든 다이제스트 변경은 평가를 재촉발합니다), 주기적 검토, 일탈(deviation) 프로세스, 그리고 — 이 책이 거듭 강조하는 정직함 — 어떤 OSS 구성 요소도 박스에서 꺼낸 채로는 Part 11을 준수하지 않는다는 인식 말입니다. 20장의 해시 체인은 변조를 불가능하게 하는 것이 아니라 감지 가능하게 만듭니다. 트리거를 비활성화하는 슈퍼유저는 여전히 그것을 우회할 수 있습니다. 빈약하게 유지되는 프로젝트에 대한 공급자 평가 노력은 지원되는 제품을 사는 비용을 넘어설 수 있으며, 그 절충은 실패가 아니라 정당한 사업적 결정입니다. NIIMBL — 바이오의약품 혁신을 위한 미국의 민관 합작 Manufacturing USA 연구소 — 과, 델라웨어 대학교(University of Delaware)에 있는 그 SABRE 파일럿 규모 cGMP(current Good Manufacturing Practice) 시설(데이터 프로그램이 아니라 건설 중인 건물) 같은 이니셔티브가 존재하는 이유는, 바로 작동하는 프로토타입에서 밸리데이션되고 검사 가능한 공정으로 가는 것이 어렵고 비싼 부분이기 때문입니다. 이 장은 오픈소스로 거기에 도달할 수 있음을 보여줍니다. 결코 마지막 한 구간이 공짜인 척하지 않습니다.

핵심 용어

• GAMP 5 — GxP 전산화 시스템을 밸리데이션하기 위한 ISPE의 위험 기반 프레임워크. 그 범주(1 인프라 → 5 커스텀)가 밸리데이션 노력을 확장한다.
• CSA(Computer Software Assurance, 컴퓨터 소프트웨어 보증) — 중량급 CSV에 대한 FDA의 위험 기반 후계자. 환자/데이터 위험에 비례하여 보증 노력을 쓰고, 기존 증거를 활용한다.
• CSV(Computer System Validation, 컴퓨터 시스템 밸리데이션) — CSA가 개혁하는, 흔히 문서 중심적이던 전통적 접근법.
• IQ / OQ / PQ — 설치, 운영, 성능 적격성 평가. 올바르게 설치되었는가, 올바르게 운영되는가, 실제 작업에 성능을 내는가.
• URS(User Requirement Specification, 사용자 요구사항 명세) — 시스템이 해야 할 일에 대한 진술. 추적성 매트릭스의 뿌리.
• 추적성 매트릭스(traceability matrix) — 각 URS에서 그것을 검증하는 테스트로(그리고 그 역으로)의 매핑.
• 공급자 평가(supplier assessment) — 소프트웨어 공급자의 품질을 평가하는 것. OSS의 경우, 대신 프로젝트의 건전성을 평가하고 아티팩트를 검증한다.
• SBOM — 소프트웨어 자재 명세서(Software Bill of Materials). 모든 구성 요소와 그 버전, 출처, 라이선스의 표준화된 인벤토리(CycloneDX/ECMA-424, SPDX/ISO 5962).
• 이미지 다이제스트(image digest) — 컨테이너 이미지의 콘텐츠 주소 지정 SHA-256. 다이제스트로 고정하면 설치가 비트 단위로 재현 가능해진다.

다음 이야기

밸리데이션은 "이 시스템은 신뢰할 만한가?"에 답합니다 — 하지만 신뢰는 전 지구적이지 않습니다. FDA의 Part 11을 만족하는 기록이라도 EU, 한국, 중국, 일본에서는 다른 거주(residency), 보존(retention), 감사 추적 기대치에 직면할 수 있습니다. 다음 장 여러 관할권에 걸친 데이터: FDA, EU, PIC/S, NMPA, PMDA, MFDS는 밸리데이션된 스택을 국경 너머로 데려가, 그 서로 다른 규칙들을 분기된 배포가 아니라 데이터와 정책으로 인코딩하는 방법을 보여줍니다.