본문으로 건너뛰기

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

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

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

쉽게 말하면

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

이 장에서 다루는 내용​

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

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

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

이것이 도대체 왜 요구될까요? 규제 대상 바이오 의약품 제조에서는 소프트웨어 자체가 제품 품질 시스템의 일부이기 때문입니다. 잘못 보정된 바이오리액터 컨트롤러나 잘못된 방향으로 반올림하는 스프레드시트는 환자의 약을 망가뜨릴 수 있고, 그 약이 안전하다는 것을 증명해야 할 기록까지 망가뜨릴 수 있습니다. 이 요구는 핵심 GMP 규정 그 자체에서 출발합니다. 21 CFR 211.68은 그러한 장비를 통제하고 그것이 만족스럽게 작동하도록 정기적으로 보정·점검·확인할 것을 제조사에 요구하며, FDA는 이를 전산화 시스템 검증의 GMP 근거로 해석합니다. 이후 Part 11과 Annex 11이 그러한 시스템이 생산하는 전자 기록과 서명으로 그 기대를 확장하여, 검증을 있으면 좋은 것이 아니라 법적 의무로 만듭니다 [8][7].

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

참고

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

GAMP 5: 위험 기반 지침서​

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

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

GAMP 5 V-모델: 왼쪽 내리막의 각 명세는 오른쪽 오르막의 짝이 되는 검증으로 증명됩니다. 저자 원본 도해, GAMP 5 프레임워크에 기반함 [1].

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

전통적인 검증 단계는 IQ / OQ / PQ, 즉 설치 적격성 평가(Installation Qualification), 운영 적격성 평가(Operational Qualification), 성능 적격성 평가(Performance Qualification)입니다. 시스템이 제대로 설치되었고, 제대로 작동하며, 실제 작업 부하에서 제대로 성능을 낸다는 증거입니다 [4]. **GAMP 5 제2판(2022)**은 이 모든 것을 오늘날 소프트웨어가 만들어지고 구매되는 방식에 맞게 현대화했습니다. 반복적인 애자일(Agile) 개발, 클라우드 서비스, 떠오르는 AI를 수용하고, 노력이 어디로 가야 하는지를 결정하는 명시적인 실로서 **비판적 사고(critical thinking)**를 끌어올렸습니다 [1].

컴퓨터 소프트웨어 보증: 스크립트보다 사고​

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

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

CSA의 위험 우선 논리: 비판적 사고가 각 기능을 여전히 확신을 주는 가장 가벼운 보증으로 안내합니다. 저자 원본 도해, FDA CSA 가이던스에 기반함 [2].

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

기능의 환자·제품·데이터에 대한 위험을 테스트 강도(비스크립트 대 스크립트)에 대응시켜 적절·위험·낭비 사분면으로 분류한 2x2 매트릭스. CSA는 시험 노력을 위험에 맞춥니다 — 환자를 보호하는 곳에는 엄격함을, 그렇지 않은 곳에는 절제를. 저자 원본 도해(AI 보조로 제작).

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

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

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

왜 중요한가​

데이터 관리에서 검증은 "시스템이 그렇게 말한다"를 "시스템이 그렇게 말한다고 신뢰할 수 있다"로 바꾸어 주는 것입니다. 데이터의 모든 하위 용도, 즉 배치 출하, 일탈 조사, 모델 훈련은 그 데이터를 생산하는 시스템이 목적에 적합함이 증명되었다는 가정 위에 놓여 있습니다. CSA로의 전환이 중요한 까닭은 그것이 위험이 가장 높은 곳, 즉 환자 안전과 데이터 품질을 직접 보호하는 기능에 보증 노력을 집중시키고, 모든 구성요소에 획일적인 정밀 검토를 똑같이 적용하지 않기 때문입니다 [2][9]. 잘만 하면 이는 더 적은 낭비된 문서 작업으로 더 많은 실질적 품질을 의미하며, 이 책의 나머지 부분이 의존하는 현대적이고 데이터가 풍부한 시스템을 더 빠르게 도입하는 길이 됩니다.

현실 세계에서는​

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

핵심 용어​

  • 전산화 시스템 검증(Computerized System Validation, CSV) — 컴퓨터 시스템이 의도된 일을 일관되게 수행하며 의도된 용도에 적합함을 보여주는 문서화된 증거를 만들어내는 것.
  • 검증 대 밸리데이션(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) — 시스템이 생애 전체에 걸쳐 검증된 상태를 유지함을 반복적으로 확인하는 것.

이 다음은​

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