제8장
어떤 시스템이 WIA-BIO-018을 실제로 구현했다는 것을 어떻게 보일 것인가, 가동 중인 시스템을 어떻게 감사할 것인가, 표준의 숫자는 어디까지 쓸모가 있는가, 그리고 연구윤리를 앞으로 바꿀 변화는 무엇인가를 다룬다.
앞의 일곱 장은 용어, 데이터 모델, SDK, 구현 아키텍처를 차례로 쌓아 올렸다. 마지막 장은 스폰서나 규제 실사관, 혹은 의심 많은 IRB 위원장이 결국 던지게 될 질문을 다룬다. 그것이 제대로 작동한다는 것을 어떻게 아는가? 윤리 시스템에서 이 질문은 두 층으로 나뉜다. 첫째는 기술적 층위다. 소프트웨어가 표준의 규칙을, 동의가 유효에서 무효로 뒤집히는 바로 그 경계값에서까지 정확히 적용하는가. 둘째는 제도적 층위다. 소프트웨어가 남긴 기록만으로 감사자가 누가, 어떤 문서의 어떤 버전을 근거로, 무엇을, 왜 결정했는지 재구성할 수 있는가.
이 장의 내용은 명세서의 서술을 그대로 옮기지 않고 참조 코드로 직접 확인한 것이다. 아래의 모든 테스트 벡터는 api/typescript/src에 배포된 WIA-BIO-018 TypeScript SDK(v1.0.0)로 실행했으며, 결함을 드러내는 결과까지 관찰된 그대로 적는다. 명세서를 넘어서는 권고는 이 책의 권고임을 밝힌다.
WIA-BIO-018 v1.0.0은 적합성을 §8.1의 한 문장으로 정의한다. 적합한 시스템은 여섯 개 구성요소를 "반드시 포함해야" 한다. 이어서 인터페이스(§8.2), 하나의 데이터 형식(§8.3.1 동의 기록), 오류 코드 표(§8.4)를 규정한다. 규범적 내용은 이것이 전부다. 따라서 적합성 주장은 정확히 이 요소들로 구성해야 하며, 그 이상을 덧붙여서는 안 된다.
| 적합성 영역 | 표준의 근거 | 주장이 입증해야 하는 것 |
|---|---|---|
| 동의 관리(Consent Management) | §8.1 (1), §3 | 모든 설명 요소, 이해도 점수, 의사결정 능력, 입회인과 서명을 포함한 전자 동의 수집, 그리고 SDK 규칙을 재현하는 검증 |
| IRB 제출(IRB Submission) | §8.1 (2), §4.3, §8.2.3 | exempt·expedited·full-board로 배정된 프로토콜 기록과 상태 추적 |
| 위험 평가(Risk Assessment) | §8.1 (3), §2.1.2, §8.2.2 | 위험-이익 기록, 그리고 자문용임이 분명히 드러나는 자동 권고 |
| 개인정보 보호(Privacy Protection) | §8.1 (4), §6.1 | 데이터셋별 보호 수준, 비식별화, 유전 데이터의 암호화와 접근 통제 |
| 감사 추적(Audit Trail) | §8.1 (5) | 모든 윤리적 결정에 대한 완전하고 변조가 드러나는 기록 |
| 보고(Reporting) | §8.1 (6), §4.5 | IRB와, 해당하는 경우 규제기관에 대한 이상사례·프로토콜 이탈·진행 보고 |
| 데이터 형식 | §8.3.1 | §8.3.1 JSON 형태로 내보낼 수 있는 동의 기록(제4장의 정합화 적용) |
| 오류 코드 | §8.4, BioEthicsErrorCode | 실패한 모든 검사를 E001–E006(명세서) 또는 E001–E010(SDK 열거형)에 대응 |
표준에는 눈에 띄게 빠진 것이 두 가지 있으며, 적합성 프로그램이 이를 지어내서는 안 된다. 첫째, 인증 등급이 없다. 명세서는 브론즈·실버·골드 같은 등급도, 합격률 기준도, 인증 기관도 정의하지 않는다. 프로젝트 README가 인증 사이트로 링크를 걸고 있지만 그 사이트의 존재와 절차는 표준의 일부가 아니며, 이 책은 그것을 확립된 제도로 다루지 않는다. 둘째, 성능이나 정확도 목표가 없다. 윤리 심의는 민감도와 특이도를 따지는 분류 문제가 아니다. BIO-018에 대해 그런 수치를 인용하는 문서가 있다면 그것은 다른 무언가를 인용하고 있는 것이다.
구현자가 정직하게 만들어 낼 수 있는 것은 적합성 선언서(conformance statement)다. 구현한 BIO-018 버전, 여섯 구성요소 각각과 그것을 담당하는 모듈, 시스템이 내보내는 오류 코드, 참조 SDK와 달라진 모든 점(제5장과 아래 8.3절에서 설명하는 결함을 의도적으로 고친 부분 포함)을 적고 테스트 보고서를 첨부한 짧은 버전 관리 문서다. 이는 명세서의 요구사항이 아니라 이 책의 권고이지만, IRB나 스폰서가 주장을 실제로 평가할 수 있는 형태가 바로 이것이다.
BioEthicsErrorCode 열거형(E001–E010)과 BioEthicsError 클래스는 types.ts에 정의되어 있고 index.ts가 이를 가져오지만, 어떤 SDK 메서드도 코드를 반환하거나 던지지 않는다. validateInformedConsent는 문제를 violations[]에 영어 문장으로만 보고한다. 따라서 적합한 시스템은 위반 사항을 코드로 바꾸는 대응 계층을 따로 가져야 한다. 또한 참조 SDK는 E003(강압 감지)을 만들어 낼 방법이 아예 없다. InformedConsent에는 voluntarinessScore가 있지만 ConsentValidation에는 자발성 입력이 없기 때문이다.
윤리 소프트웨어는 전형적으로 두 가지 방식으로 실패한다. 거부해야 할 동의를 받아들이는 것이 위험한 오류이고, 받아들여야 할 동의를 거부하는 것이 비용이 큰 오류다. 후자가 쌓이면 참여자에게 다시 연락해야 하고 등록이 지연되며, 직원들은 시스템을 무시하는 법을 배우게 된다. 테스트 스위트는 둘 다 잡아야 하며, 가장 효과적으로 살펴볼 곳은 경계값이다. BIO-018에는 경계값이 많다. 이해도 0.80, 입회인이 필요해지는 0.85, 입회인 서명이 요구되는 0.90, 네 단계의 능력 구간, 준수 점수 0.8, 유전자 편집의 평균 위험 0.5, 그리고 위험-이익 비의 2.0 / 1.5 / 1.0 / 0.7 구간이 그것이다.
각 경계값마다 바로 아래, 정확히 그 값, 바로 위의 벡터를 하나씩 둔다. 범주형 규칙(능력, 입회인, 법정대리인, 서명)마다 적합한 경우와, 규칙이 위반될 수 있는 서로 다른 방식을 각각 넣는다. 결정 트리(심의 배정, 유전자 편집)는 모든 말단 노드를 거쳐야 한다. 아래 표는 이 원칙에 따라 만든 동의 검증 벡터 세트다. 기준 벡터는 ConsentFormElements 10개가 모두 true이고, 능력은 온전하며, 참여자 서명이 있고, 이해도가 0.92인 동의다. 각 행은 설명에 적힌 부분만 바꾼다.
| ID | 입력(기준 대비 변경) | 기대 isValid | 관찰된 complianceScore | 오류 코드(이 책의 대응) |
|---|---|---|---|---|
| C01 | 기준, 입회인 없음 | true | 0.976 | — |
| C02 | 이해도 0.80, 입회인 참석·서명 | true | 0.940 | — |
| C03 | 이해도 0.79, 입회인 참석·서명 | false | 0.937 | E002 |
| C04 | 이해도 0.84, 입회인 없음 | false | 0.927 | E001(입회인 누락) |
| C05 | 이해도 0.85, 입회인 없음 | true | 0.955 | — |
| C06 | futureUseDisclosed: false | false | 0.946 | E001 |
| C07 | 능력 borderline, 이해도 0.90, 입회인 서명 | true(경고 포함) | 0.940 | — |
| C08 | 능력 diminished, 이해도 0.90, 법정대리인 없음, 입회인 서명 | false | 0.900 | E004 |
| C09 | 능력 diminished, 이해도 0.90, 법정대리인과 입회인 서명 | true | 0.900 | — |
| C10 | 능력 severely-impaired, 이해도 0.90, 법정대리인과 입회인 서명 | true | 0.850 | — |
| C11 | 참여자·법정대리인 서명 모두 없음, 이해도 0.95 | false | 0.835 | E001 |
| C12 | 이해도 0.88, 입회인은 참석했으나 서명 없음 | false | 0.939 | E001 |
| C13 | consentForm: {}(빈 객체) | false | NaN | 발생하지 않음(결함) |
| C14 | §8.2.1의 6개 키 양식, 모두 true | false여야 함 | 0.976(유효로 보고됨) | 발생하지 않음(결함) |
몇몇 행은 설명이 필요하다. C02와 C03은 이해도 경계를 사이에 둔다. SDK는 comprehensionScore < 0.8을 검사하므로 0.80은 통과하고 0.79는 실패한다. 이는 10문항 중 8문항을 맞히면 통과인 부록 A.2의 사례와 일치한다. C04와 C05는 입회인 요건의 경계다. 이해도가 0.85 미만이면 입회인이 필수가 되므로, 입회인이 없는 같은 동의가 0.84에서는 무효, 0.85에서는 유효가 된다. 표에서 가장 교훈적인 행은 C08이다. 준수 점수는 0.900으로 기준선 0.8을 넉넉히 넘지만 동의는 무효다. 의사결정 능력이 저하된 참여자가 법정대리인 없이 서명했기 때문이다. 준수 점수는 유효성의 대용 지표가 아니다. 점수만으로 걸러내는 대시보드, 보고서, 후속 규칙은 C08을 좋은 동의로 취급하게 된다. 테스트는 반드시 isValid와 위반 목록을 검증해야 하며, 점수만 단독으로 검증해서는 안 된다.
C09·C10을 C01과 비교해 보라. 정당하게 받은 법정대리인 동의가 일반 동의(0.976)보다 낮은 점수(0.900, 0.850)를 받는다. 능력 항이 0.2 × 1.0 대신 0.2 × 0.65 또는 0.2 × 0.40을 기여하기 때문일 뿐이다. 점수는 절차의 품질이 아니라 참여자의 상태를 깎는다. 판정 옆에 참고로 표시하는 한 해가 없지만, 예컨대 기관별 동의 품질 순위를 매기는 데 쓰는 것은 잘못이다. 감사용 동의 품질 지표(8.4절)는 이 점수가 아니라 지적 사항에서 산출해야 한다.
§8.3.1의 예시 동의 기록에는 "complianceScore": 0.98이라고 적혀 있다. SDK 가중치로 다시 계산하면(모든 요소 충족, 이해도 0.92, 온전한 능력, 입회인 참석·서명) 0.976이 나온다. 차이는 반올림 때문이며, 점수는 정확한 일치가 아니라 허용 오차(예: 소수점 셋째 자리)를 두고 비교해야 하는 이유이기도 하다.
submitIRBProtocol에는 관찰 가능한 결과가 네 가지이며 테스트 세트는 그 모두에 도달해야 한다. 면제 분기는 부분 문자열 비교에 의존하므로 특히 주의해야 한다. isExemptEligible은 studyType을 소문자로 바꾼 뒤 네 문구("educational research", "anonymous surveys", "observation of public behavior", "existing de-identified data") 중 하나를 포함하는지 본다.
| 위험 수준 | 취약 집단 | studyType | 관찰된 reviewLevel |
|---|---|---|---|
| minimal | 없음 | "Anonymous Surveys of staff" | exempt |
| minimal | 없음 | "chart review" | expedited |
| minimal | children | "anonymous surveys" | full-board |
| minor-increase | 없음 | 임의 | expedited |
| minor-increase | prisoners | 임의 | full-board |
| greater-than-minimal | 없음 | 임의 | full-board |
자유 텍스트를 비교하므로 부정 테스트도 똑같이 중요하다. "identifiable follow-up of anonymous surveys"(익명 설문의 식별 가능한 추적 조사) 같은 연구 유형도 면제로 배정된다. 미국 공통규칙(45 CFR 46.104)의 실제 면제 범주는 제목의 단어가 아니라 식별 가능성과 절차에 관한 사실에 달려 있다. 따라서 구현은 부분 문자열 검사를 명시적인 범주 필드로 대체하고, 부분 문자열 논리는 IRB 행정 담당자에게 보여 주는 제안으로만 남겨야 한다.
evaluateGeneEditingEthics에서는 유형(somatic, germline)과 목적(therapeutic, enhancement, research)의 여섯 조합이 첫 여섯 벡터가 된다. 전임상 근거, 안전성 자료, 동의가 모두 갖춰진 경우 관찰된 결정은 다음과 같다. 체세포 치료 → approve, 체세포 향상 → reject, 체세포 연구 → approve-research-only, 생식세포 치료 → defer, 생식세포 향상 → reject, 생식세포 연구 → defer. 경계 벡터는 네 위험 값의 평균이다. 넷 모두 0.5(평균 0.5)이면 체세포 치료가 승인되고, 하나를 0.6으로 올리면(평균 0.525) defer로 바뀐다. 0.5라는 한계는 임상 기준이 아니라 SDK의 설계 선택이며, 테스트는 이를 검증한다기보다 기록한다.
performRiskBenefitAnalysis에 부록 A.1의 겸상적혈구병 수치(이익 28, 위험 3.3, 정의 계수 1.0)를 넣으면 조정 비율 8.48과 approve가 나온다. 예상대로다. 더 흥미로운 벡터는 비율은 높지만 정의 계수가 낮은 경우다. 이익 5, 위험 1, 정의 계수 0.75이면 조정 비율은 3.75인데도 권고는 defer이고 isEthicallyAcceptable은 false다. 모든 승인 구간이 정의 계수 0.8 이상을 요구하기 때문이다. 이것은 의도된 기능이다. 부담이 불공정하게 분배된 연구를 큰 이익으로 상쇄할 수는 없다. 테스트로 이 동작을 고정해 두어야 이후 리팩터링이 이를 조용히 없애지 못한다.
제5장은 참조 SDK의 결함을 나열했다. 위의 벡터를 실행하자 결함이 더 드러났다. 적합성 스위트는 각 결함에 대한 회귀 테스트를 두 가지 방식 중 하나로 갖추어야 한다. SDK를 감싸서 결함을 고친 시스템(제7장의 서비스처럼)에서는 테스트가 수정된 동작을 검증한다. SDK를 그대로 쓰는 시스템에서는 테스트가 결함 있는 동작을 고정(pin)한다. 지금은 통과하지만 상위 코드가 바뀌면 실패하므로, 누군가가 이 목록을 다시 읽도록 강제한다.
| ID | 결함(관찰 결과) | 영향 | 수정 후 테스트 기대값 |
|---|---|---|---|
| KD-1 | targetPopulation: 'adults'(§8.2.2와 CLI가 쓰는 값)로 assessEthicalRisk를 호출하면 TypeError: Cannot read properties of undefined (reading 'protections')가 발생 | 명세서를 따르는 호출자는 모두 비정상 종료 | 'adults'를 'general-adults'로 정규화, 가중 배수 없음, 예외 없음 |
| KD-2 | 생식세포 research가 conditions 없이 defer를 반환, 착상 금지를 포함한 세 연구 조건이 버려짐 | 가장 중요한 안전장치가 기록에 남지 않음 | 실험실 연구 한정·착상 금지 조건이 결정에 포함 |
| KD-3 | 체세포 경로에서 benefitsOutweighRisks: false이면 GeneEditingDecision.decision에 없는 값 'revise'를 반환 | 후속 코드의 전수 switch 문이 어느 분기에도 걸리지 않음 | defer로 대응(또는 타입을 의도적으로 확장) |
| KD-4 | 빈 consentForm이면 완결성이 0/0: 점수 NaN, isValid false, violations 비어 있음 | 이유도 오류 코드도 없이 거부된 동의 | "설명 요소가 제공되지 않음"과 함께 E001 발생 |
| KD-5 | 완결성을 제공된 키 기준으로 계산하므로 §8.2.1의 6개 키 양식이 futureUseDisclosed, compensationExplained, contactProvided 없이도 1.0을 받음 | 불완전한 설명이 통과 | 고정된 10개 표준 요소 목록을 기준으로 완결성 계산 |
| KD-6 | assessEthicalRisk의 위험·이익 점수가 내용이 아니라 목록 항목 수를 셈 | 이익 목록을 부풀리면 점수가 오름 | 문서화하고 고정, 아래 속성 테스트 참조 |
| KD-7 | index.ts와 types.ts가 같은 이름을 두 번 내보냄. Node.js 22가 모듈 적재를 거부("Duplicate export of 'BioEthicsSDK'", 이어서 "'BioEthicsError'") | 배포된 상태로는 패키지를 적재할 수 없음 | 빌드된 패키지를 가져오는 스모크 테스트 |
| KD-8 | CLI validate-consent가 준수 점수를 0.9로 하드코딩하여, 이해도 실패를 보고한 뒤에도 "Consent is VALID"를 출력 | CLI는 테스트 기준(oracle)이 될 수 없음 | 테스트의 기준으로는 CLI가 아니라 라이브러리를 사용 |
KD-7은 테스트 스위트가 가장 재미없는 테스트, 곧 모듈을 가져와 getVersion()을 호출하는 것부터 시작해야 하는 이유를 보여 준다. 이 장의 벡터는 중복 내보내기 줄만 지운 로컬 사본에서 얻었다. 수정은 사소하지만, 스모크 테스트가 없으면 이 문제는 통합 단계에 가서야 드러난다.
다음 테스트 파일은 세 종류의 테스트를 한곳에 보여 준다. 표로 구동하는 경계 벡터, 이 책이 권고하는 오류 코드 대응, 그리고 고정된 결함이다. SDK 소스가 로컬에 있다고 가정하며(이 책은 npm 패키지가 공개되어 있다고 주장하지 않는다), 구현자가 위반 메시지를 코드로 바꾸는 작은 toErrorCodes 함수를 작성했다고 가정한다.
import { BioEthicsSDK } from '../src/index';
import type { ConsentFormElements, ConsentValidation } from '../src/types';
import { toErrorCodes } from '../src/error-mapping'; // 구현자가 직접 작성한 모듈
const sdk = new BioEthicsSDK();
const at = new Date('2025-12-26T10:30:00Z');
const ALL: ConsentFormElements = {
purposeDisclosed: true, durationExplained: true, risksDisclosed: true,
benefitsExplained: true, alternativesProvided: true, withdrawalRights: true,
privacyProtection: true, compensationExplained: true, contactProvided: true,
futureUseDisclosed: true,
};
function consent(over: Partial<ConsentValidation> = {}): ConsentValidation {
return {
participantId: 'P-TEST-001', studyId: 'STUDY-TEST',
consentForm: { ...ALL }, participantCapacity: 'full',
comprehensionScore: 0.92, witnessPresent: false,
signature: { participant: true, date: at },
...over,
};
}
const witnessed = { participant: true, witness: true, date: at };
describe('validateInformedConsent: 경계 벡터', () => {
test.each([
['C01', {}, true, 0.976, []],
['C02', { comprehensionScore: 0.80, witnessPresent: true, signature: witnessed }, true, 0.940, []],
['C03', { comprehensionScore: 0.79, witnessPresent: true, signature: witnessed }, false, 0.937, ['E002']],
['C04', { comprehensionScore: 0.84 }, false, 0.927, ['E001']],
['C05', { comprehensionScore: 0.85 }, true, 0.955, []],
['C08', { participantCapacity: 'diminished', comprehensionScore: 0.90,
witnessPresent: true, signature: witnessed }, false, 0.900, ['E004']],
] as const)('%s', (_id, over, valid, score, codes) => {
const r = sdk.validateInformedConsent(consent(over as Partial<ConsentValidation>));
expect(r.isValid).toBe(valid);
expect(r.complianceScore).toBeCloseTo(score, 3);
expect(toErrorCodes(r)).toEqual(codes);
});
test('점수가 0.8 이상이어도 유효하다는 뜻은 아니다 (C08)', () => {
const r = sdk.validateInformedConsent(consent({
participantCapacity: 'diminished', comprehensionScore: 0.90,
witnessPresent: true, signature: witnessed }));
expect(r.complianceScore).toBeGreaterThanOrEqual(0.8);
expect(r.isValid).toBe(false);
});
});
describe('SDK v1.0.0의 알려진 결함 (고정)', () => {
test('KD-1: "adults"가 assessEthicalRisk를 중단시킨다', () => {
expect(() => sdk.assessEthicalRisk({
studyType: 'drug trial', targetPopulation: 'adults' as never,
interventionType: 'drug', potentialBenefits: ['b'], potentialRisks: ['r'],
riskLevel: 'minor-increase',
})).toThrow(TypeError);
});
test('KD-4: 빈 양식은 NaN을 내고 위반 사항을 남기지 않는다', () => {
const r = sdk.validateInformedConsent(
consent({ consentForm: {} as ConsentFormElements }));
expect(Number.isNaN(r.complianceScore)).toBe(true);
expect(r.isValid).toBe(false);
expect(r.violations).toHaveLength(0);
});
});
감싸는 서비스에서 결함을 고치면 KD 테스트는 다른 방식으로 옮겨 간다. KD-1은 'adults'가 'general-adults'와 같은 결과를 내는지를, KD-4는 E001이 발생하는지를 검증하게 된다. 두 버전을 모두 버전 관리에 남기고 전환 이유를 주석으로 적어 두면 그 자체가 쓸모 있는 감사 증거가 된다.
경계 벡터는 특정 지점을 확인하고, 속성 테스트는 규칙이 범위 전체에서 성립하는지를 확인한다. BIO-018 코드에서는 세 가지 속성을 시험할 만하다. 첫째, 이해도에 대한 준수 점수의 단조성이다. 다른 조건이 같다면 이해도 점수가 높아질 때 complianceScore가 낮아져서는 안 된다. 참조 SDK는 입회인 항이 0.5에서 1.0으로 뛰는 0.85 지점을 포함해 이 속성을 만족한다. 둘째, 위험 개수에 대한 ethicalScore의 단조성이다. 위험을 하나 추가했을 때 점수가 올라가서는 안 된다. 이 역시 성립한다(이익 셋, 위험 하나이면 0.545, 위험 둘이면 0.500). 셋째는 참조 SDK가 명백히 실패하는 속성, 곧 내용 민감성이다. potentialBenefits에 빈 문자열을 하나 더해도 결과가 바뀌지 않아야 하지만, 실제로는 ethicalScore가 0.545에서 0.727로 오른다. 이 세 번째 테스트를 작성하고 KD-6을 가리키는 예상 실패로 표시해 두는 것이, 이 점수가 판단이 아니라 개수라는 사실을 코드베이스에 가장 분명하게 기록하는 방법이다.
테스트는 소프트웨어가 규칙을 적용한다는 것을 보여 준다. 감사는 조직이 그 소프트웨어와 그것이 만든 기록을 올바르게 사용했다는 것을 보여 준다. BIO-018 §9.3은 내부 감사 주기(분기별)와 외부 감사 주기(매년, 또는 스폰서·규제기관이 요구할 때)를 정하고 감사 범위 여섯 가지를 나열한다. §9.2는 매월 동의서 표본 검토와 분기별 프로토콜 준수 감사를 포함한 지속 모니터링 주기를 덧붙인다. 이는 표준의 기본 운영값이며, 스폰서 계약, 실사 지적, 국가 규정이 더 많은 것을 요구할 수 있다.
| 감사 범위(§9.3) | 표본 추출 대상 기록 | 대표적 점검 사항 |
|---|---|---|
| 사전 동의 문서 | InformedConsent 기록과 서명된 동의서 | 동의 일자 기준으로 IRB 승인 양식 버전과 일치하는가, 10개 요소 전부, 필요한 경우 입회인·법정대리인, 참여자에게 사본 제공 |
| IRB 교신 | IRBSubmission 이력, 결정, 수정 사항 | 승인 전 등록 없음, 수정 사항은 사용 전 승인, 승인 기간 미만료 |
| 프로토콜 준수 | ProtocolDeviation 기록, 원자료 | 이탈이 기록·분류되었는가, 중대한 이탈은 보고되었는가 |
| 데이터 무결성 | 감사 추적 체인, 데이터베이스 추출본 | 해시 체인 검증, 감사 항목 없는 수정 없음, UTC 타임스탬프 |
| 안전성 보고 | AdverseEvent 기록 | 중증도·인과관계·예상 여부 평가, 적용 규정의 기한 내 보고 |
| 규제 준수 | 적합성 선언서, 규제 대응표(제7장) | 적용되는 규정마다 담당자와 증거가 있는가 |
감사 결과는 SDK의 AuditResult 타입에 담긴다. auditId, studyId, auditDate, auditor, 그리고 각각 category, description, critical·major·minor 중 하나인 severity를 갖는 findings 배열, 전체 complianceScore, recommendations, followUpRequired 플래그로 구성된다. 명세서는 중요도 단계의 의미를 정의하지 않으므로, 조직은 첫 감사 전에 이를 문서로 정해 두어야 한다. 이 책은 임상시험 품질관리에서 쓰는 논리를 따른 정의를 제안한다. critical은 참여자의 권리·안전·안녕이 침해되었거나 침해될 수 있었던 경우, 또는 데이터를 신뢰할 수 없는 경우다(예: 유효한 동의 없는 등록, 보고되지 않은 중대한 이상사례). major는 고치지 않으면 critical로 이어질 수 있는 중대하고 체계적인 약점이다(예: 한 기관이 폐기된 동의서 버전을 계속 사용). minor는 그런 결과로 이어지지 않는 단발성 누락이다.
AuditResult 기록의 신뢰성을 높이는 일관성 규칙이 두 가지 있으며, 둘 다 코드로 강제하기 쉽다. 첫째, critical 또는 major 지적이 하나라도 있으면 followUpRequired는 true여야 한다. 타입이 이를 강제하지 않으므로 감사 결과를 기록하는 서비스가 강제해야 한다. 둘째, 타입이 0에서 1 사이의 숫자라고만 설명하는 감사의 complianceScore는 사람이 손으로 입력하지 말고 문서화된 규칙에 따라 지적 사항에서 산출해야 한다. 그렇지 않으면 두 감사자가 같은 지적 사항에 서로 다른 점수를 매기고, 분기별 추세선은 아무 의미가 없어진다.
동의 품질 표본 검토는 감사가 동의 데이터 모델과 가장 직접적으로 만나는 지점이다. 표준은 매월 동의서 표본을 검토하라고 하지만 표본 크기나 추출 방법은 정하지 않는다. 그 선택은 기관의 몫이며 모니터링 계획에 적어 두어야 한다. 표본 크기와 무관하게 적용되는 실무 지침이 두 가지 있다. 첫째, 위험이 높은 기록이 과대 대표되도록 층화 추출한다. 법정대리인 서명, 경계 수준의 능력, 0.80 경계에 가까운 이해도, 재교육 주기(E002)를 거친 동의에 오류가 몰린다. 둘째, 표본으로 뽑힌 각 기록을 그 동의 일자에 유효했던 IRB 승인 양식 버전과 대조한다. 버전 불일치(기관이 옛 PDF를 인쇄해 쓰는 경우)는 가장 흔한 동의 문제 중 하나이며, 양식 본문을 보지 않는 validateInformedConsent로는 드러나지 않는다.
감사 증거는 실사관이 도착했을 때 남아 있어야 쓸모가 있다. BIO-018 §3.2.2는 연구 종료 후 최소 7년을 제시하지만, 보존 기간은 이 표준이 아니라 법률과 계약이 정하며 편차가 크다. 미국 공통규칙은 IRB 기록을 연구 종료 후 최소 3년간 보관하도록 한다(45 CFR 46.115(b)). EU 임상시험규정(Regulation (EU) No 536/2014)은 스폰서와 시험책임자가 임상시험 기본문서(trial master file)를 시험 종료 후 최소 25년간 보관하도록 한다(제58조). 다른 관할권과 스폰서도 각자의 기간을 둔다. 적합한 시스템은 연구마다 적용 규칙에서 계산한 보존 기간을 저장하고, 그 날짜 전의 삭제를 막아야 한다. 7년은 내부 하한선으로는 쓸 수 있지만 보편적 규칙은 아니다.
WIA-BIO-018은 연구윤리를 기계로 점검할 수 있게 만들려는 시도이며, 이 책의 상당 부분은 그 시도를 실제로 작동시키는 데 할애되었다. 그만큼 그 숫자들이 무엇인지 분명히 하는 일도 중요하다. SDK의 점수는 거의 모두 표준 작성자가 고른 가중치를 쓰는 경험적 규칙(heuristic)이다. 동의 준수에는 0.30 / 0.30 / 0.20 / 0.15 / 0.05, 개입 위험에는 0.1(관찰 연구)부터 0.9(유전자 치료)까지, 취약 집단에는 일괄 1.5배, 이익은 항목당 0.2(상한 1.0), 위험은 항목당 0.05를 더한다. 이 값들 가운데 동의 품질이나 연구 위해에 관한 실증 연구에서 나온 것은 없으며, 명세서도 그렇다고 주장하지 않는다. 선별용 기본값으로는 합리적이지만 그 이상은 아니다.
문제는 가중치가 자의적이라는 데 있지 않다. 모든 점수 체계는 어딘가에서 출발해야 한다. 문제는 점수가 보지 못하는 것이다. assessEthicalRisk는 문자열 개수를 세기 때문에 "가벼운 두통 가능성"과 "사망 가능성"을 같은 단위의 위험으로 취급한다. 추측에 불과한 이익을 다섯 개 나열한 연구에 최대 이익 점수를 준다. 건강한 수감자 연구와 중증 소아 환자 연구에 똑같이 1.5배를 적용한다. 부록 A.1의 비율 8.5는 예시를 위해 고른 이익 가중치에 기대고 있다. "윤리 점수 0.73, 권고: 승인"만 보는 심의자에게는 이 가운데 어느 것도 보이지 않는다.
미국 공통규칙의 승인 기준(45 CFR 46.111)은 위험이 예상 이익에 비추어 합리적이라는 것을 IRB가 판단하도록 요구한다. 이 판단은 과학 분야와 비과학 분야 위원으로 구성된 위원회의 숙의에 따른 판단이며, 규정도 BIO-018도 이를 소프트웨어에 위임하지 않는다. 시스템 설계에 주는 실무적 결론은, 모든 자동 권고를 자문용으로 제시해야 하고, 권고와 다른 사람의 결정은 모두 독립된 정식 기록으로 남겨야 한다는 것이다.
IRBDecision 값), 심의자 자신의 말로 쓴 근거, 결정 주체(소집된 위원회 또는 지정 심의자)와 일자, 부과한 조건. 재정의는 오류가 아니다. IRB가 점수에 한 번도 이의를 달지 않는 시스템은 가끔 이의를 다는 시스템보다 더 걱정스럽다. 점수가 형식적으로 추인되고 있다는 신호이기 때문이다.
§2.1.1의 자율성 점수는 정량화가 눈에 띄지 않게 어긋날 수 있음을 보여 주는 작지만 분명한 예다. 인쇄된 대로 (V × I × C × Comp) / 4를 계산하면 각 요인이 0과 1 사이일 때 0.25를 넘을 수 없으므로, 어떤 참여자도 의미 있는 자율성 기준에 도달할 수 없다. 제1장은 수정된 해석(네 요인의 곱 또는 평균)을 제시했다. 이 오류가 공개된 명세서에 남은 것은 아무도 현실적인 사례로 공식을 계산해 보지 않았기 때문이다. KD-7이나 C08과 같은 교훈이다. 테스트를 작성하고, 숫자를 돌려 보고, 결과를 읽어야 한다.
BIO-018 v1.0.0은 작성 당시의 연구윤리 지형을 묘사한다. 몇 가지 변화가 이미 그 지형을 바꾸고 있으며, 표준 위에 세운 시스템은 이를 흡수할 수 있도록 설계되어야 한다.
언어 모델은 이미 동의서 초안을 쓰고, 필수 요소 목록과 대조하고, 읽기 난이도를 추정하고, 심의자를 위해 프로토콜을 요약할 수 있다. 이렇게 쓰면 특히 문해력이 낮거나 여러 언어를 쓰는 집단에서 동의 품질의 하한선을 끌어올릴 수 있다. 동시에 그럴듯하지만 부정확한 요약, 실행마다 달라지는 결과, 모델이 심의자를 대신하게 두려는 유혹도 따라온다. 8.5절의 원칙은 여기서 더 강하게 적용된다. AI의 출력은 모델과 버전을 밝혀 숙의의 입력으로 기록에 남겨야 하며, 결코 결정이 되어서는 안 된다. EU에서 운영하는 기관은 도입하는 도구에 인공지능법(Regulation (EU) 2024/1689)이 어떻게 적용되는지도 살펴야 한다.
BIO-018의 동의 모델은 본질적으로 버전 번호가 붙은 단일 사건이다. 바이오뱅크와 장기 유전체 코호트는 참여자가 향후 이용의 범주를 골라 선택하는 계층형(tiered) 동의, 그리고 디지털 인터페이스로 그 선택을 시간에 걸쳐 관리하고 새 이용이 생길 때 재연락을 받는 동적(dynamic) 동의를 점점 더 많이 쓴다. 2018년 개정된 미국 공통규칙도 식별 가능한 정보와 인체유래물의 보관 및 2차 연구 이용을 위한 "포괄 동의(broad consent)"를 도입했다. 이 가운데 어느 것도 futureUseDisclosed: true 플래그 하나에 들어맞지 않는다. 앞을 내다본 구현이라면 동의를 각자 타임스탬프와 버전을 가진 범위별 허가의 연속으로 모델링하고, 거기서 BIO-018 기록을 여전히 도출할 수 있게 해야 한다.
BIO-018 §7은 핵산분해효소 기반 CRISPR 편집을 전제로 쓰였다. 이중가닥 절단 없이 DNA를 바꾸는 염기 편집(base editing)과 프라임 편집(prime editing), 그리고 편집 도구를 체외의 세포가 아니라 환자에게 직접 투여하는 생체 내(in vivo) 전달은 표준의 네 위험 필드가 담으려는 위험 양상을 바꾼다. 표적 이탈 위험이 사라지지는 않으며, 생체 내 전달에서는 편집된 세포가 환자에게 닿기 전에 확인할 기회가 없어진다. 한편 체세포 유전자 편집은 연구에서 승인된 치료로 넘어왔다. 겸상적혈구병에 대한 체외(ex vivo) CRISPR 기반 치료가 2023년 말 영국과 미국에서 규제 승인을 받았다. §7.2가 요구하는 장기 추적은 이제 가정이 아니라 시판 후의 현실이다. 규제기관은 일부 유전자 치료 제품에 최장 15년의 추적을 권고해 왔으므로, SDK의 "최소 5년"은 대부분의 프로그램이 넘어서게 될 하한선으로 읽어야 한다.
일부 클리닉은 다유전자 위험 점수로 체외수정 배아의 순위를 매겨 주는 서비스를 제공한다. 이는 편집을 전혀 하지 않으면서도 BIO-018 §7.3이 생식세포 편집에 대해 던지는 것과 같은 질문(비의료적 형질 선택, 접근의 정의, 예비 부모에 대한 압력)을 제기한다. 여러 유전학 전문 학회는 개별 배아에 대한 이 점수의 예측력이 제한적이며 임상에 쓸 단계가 아니라고 공개적으로 경고했다. BIO-018의 유전자 편집 결정 트리는 이 문제에 닿지 않으며, 향후 개정에서 메워야 할 공백이다.
2021년 세계보건기구(WHO)는 인간 유전체 편집에 관한 권고와 거버넌스 프레임워크를 발표하면서 유전체 편집 임상시험의 국제 등록부 구축을 촉구했다. 2023년 런던에서 열린 제3차 인간 유전체 편집 국제 정상회의의 조직위원회는 유전 가능한 인간 유전체 편집은 현 시점에서 여전히 용인될 수 없다고 결론지었다. 이러한 입장은 SDK가 생식세포 치료 제안을 defer로 처리하는 것과 일치한다. SDK가 생식세포 연구에 부여하는 배아 배양 14일 한계는 여러 나라의 법에 널리 반영되어 있지만, 국제줄기세포학회(ISSCR)의 2021년 지침은 이를 더 이상 절대적 한계로 다루지 않는다. 시스템은 이런 한계를 하드코딩하지 말고 관할권에 연결된 설정값으로 두어야 한다.
유럽에서는 데이터 거버넌스법(Regulation (EU) 2022/868)이 "데이터 이타주의(data altruism)"의 틀을 만들었다. 개인과 조직이 과학 연구 같은 공익 목적으로 인정받은 기관을 통해, 유럽 공통 동의 양식을 사용해 자발적으로 데이터를 제공하는 제도다. 보건의료 데이터의 2차 이용에 관한 병행 노력도 진행 중이다. BIO-018 구현자에게 이는 동의 기록이 연구기관 밖에서 정의된 동의 도구와 상호운용되어야 할 수 있다는 뜻이다. 제4장의 10개 요소 표준 모델은 합리적인 핵심이지만 확장 지점이 필요할 것이다.
표준이 인용하는 참고 문헌 가운데 두 개는 이미 개정되었다. 헬싱키 선언은 2024년 10월에 개정되었고 ICH E6(R3) 임상시험 관리기준은 2025년 1월에 채택되었지만, 명세서는 2013년판과 E6(R2)를 인용한다. 적합성 선언서에는 명세서가 나열한 판본과 별개로, 조직이 실제로 따르는 외부 규범의 판본을 기록해야 한다.
아래 점검표는 BIO-018 §9.1의 연구 개시 전 8개 항목과 이 책이 주장해 온 시스템 차원의 항목을 합친 것이다. 첫 묶음은 표준이 모든 연구에 요구하는 것이고, 두 번째 묶음은 실사에서도 버틸 적합성 주장을 원하는 팀을 위한 이 책의 권고다.
| # | 항목 | 근거 | 증거 |
|---|---|---|---|
| 1 | IRB 승인 취득 | §9.1 | IRBSubmission.status = 'approved', 기간 미만료 |
| 2 | 사전 동의서 승인 | §9.1 | 제출 기록에 연결된 승인 양식 버전 |
| 3 | 동의 절차 문서화 | §9.1 | 이해도 평가 방법, 입회인·법정대리인 규칙을 포함한 서면 절차 |
| 4 | 데이터 보안 계획 시행 | §9.1, §6.1 | 데이터셋별 보호 수준, 암호화, 접근 역할 |
| 5 | 이상사례 보고 계획 수립 | §9.1, §4.5 | 기본값이 아니라 적용 규정에서 가져온 보고 기한 |
| 6 | 직원 교육 완료 | §9.1 | 동의를 받는 모든 인력의 교육 기록 |
| 7 | 취약 집단 보호 조치 마련 | §9.1, §5 | 등록하는 집단별 강화 보호 계획 |
| 8 | 위험-이익 분석 문서화 | §9.1, §2.1.2 | RiskBenefitAnalysis 기록과 IRB 자체의 판단 |
| 9 | 필수 구성요소 6개 모두 식별 | §8.1(이 책) | 적합성 선언서 |
| 10 | 알려진 SDK 결함 수정 또는 고정 | 제5장, 8.3절(이 책) | KD-1~KD-8 회귀 테스트 |
| 11 | 위반 사항을 E001–E010에 대응 | §8.4, 제5장(이 책) | 대응표와 테스트 |
| 12 | 경계·속성 테스트 통과 | 8.2절(이 책) | 릴리스에 첨부한 CI 보고서 |
| 13 | 감사 추적 검증 가능 | §8.1 (5), 제7장 | 감사 전마다 해시 체인 검증 실행 |
| 14 | 사람의 재정의 기록 | 8.5절(이 책) | 사유가 적힌 재정의 기록 |
| 15 | 연구별 보존 기간 설정 | 8.4절(이 책) | 적용 법률과 계약에서 계산 |
| 16 | 외부 참고 규범 최신화 | 8.6절(이 책) | 적합성 선언서에 헬싱키 선언·ICH-GCP·국내 법령의 판본 기재 |
이 목록을 충족하는 시스템이 그 자체로 연구를 윤리적으로 만들지는 않는다. 그것은 여전히 공정한 연구를 설계하는 연구자, 자유롭게 선택하는 참여자, 정직하게 숙의하는 심의위원회의 몫이다. 이런 시스템이 할 수 있는 일은 그 노력을 보이게 하고, 일관되게 하고, 점검할 수 있게 만드는 것이다. 그래서 훗날 누군가가 한 사람이 제대로 설명을 듣고, 제대로 보호받고, 제대로 존중받았는지 물을 때, 그 답을 기억에서 재구성하는 대신 기록에서 찾을 수 있게 한다. WIA-BIO-018 같은 표준이 줄 수 있는 것은 거기까지이며, 그것만으로도 잘 해낼 가치가 있다.