제8장
프로토콜 레코드가 가리키는 승인은 누가 발급하는가, 규제 참조 체계는 어떻게 소프트웨어의 승인 게이트가 되는가, 이중용도 거버넌스는 어떤 메타데이터로 남는가, 그리고 WIA-BIO-014 v1.0이 다음 판에서 고쳐야 할 결함은 무엇인가를 다룬다.
앞의 일곱 장은 하나의 기계를 만들었다. 제2장과 제3장이 레코드 모델·직렬화·스키마를 세우고, 제4장이 레코드를 생산하고 검증하는 API 표면을 붙였으며, 제5장이 상태와 승인 게이트와 추가 전용 감사 추적을 정의하고, 제6장이 그 기계를 기관의 시스템 안과 기관 사이에 놓았으며, 제7장이 그 동작을 제3자가 확인할 수 있는 증거로 바꾸었다. 그러나 어느 장도 준법 담당자가 가장 먼저 묻는 질문에는 답하지 않았다. 이 모든 일은 누구의 권한으로 진행되는가. 프로토콜 레코드의 값은 그것이 가리키는 허가만큼이며, 그 허가는 소프트웨어 밖의 위원회와 관계 기관이 발급한다.
이 장은 그 고리를 닫는다. 승인을 발급하는 주체와 그들이 만들어 내는 레코드 산출물을 정리하고, 규제 참조 체계를 소프트웨어가 실제로 집행하는 게이트에 대응시키며, 체세포 편집과 생식세포 편집의 구분을 산문이 아니라 실패 시 차단(fail-closed)되는 정책 게이트로 구현한다. 이어서 이중용도와 공개 결정을 출처가 붙은 메타데이터로 다루고, 표준 자체의 유지관리 — 버전과 폐기 절차 — 를 살핀 뒤, v1.0에서 명백히 비어 있는 부분을 목록화하고 독자가 월요일 아침에 할 일을 짧게 제시한다.
제1장 §1.3에서 선언한 경계는 이 장에서도 예외 없이 유지된다. 이 책이 다루는 WIA-BIO-014는 관리·데이터 표준이다. 누가 무엇을 어떤 범위로 언제까지 승인했고, 이후 무엇이 실행되고 검증되었는지를 기록한다. 과학적으로 무엇이 바람직한지, 실험실이 물리적으로 무엇을 해야 하는지, 특정 관할에서 무엇이 법적으로 허용되는지는 정하지 않는다. 아래에서 법적 의무를 언급할 때는 언제나 그 의무를 정한 규범이나 기관에 귀속시키며, 이 책의 주장으로 서술하지 않는다.
유전자편집 과제에서 결정적인 문서는 연구팀이 만들지 않는다. 기관생물안전위원회(IBC)가 기관 차원의 생물안전 측면을 심의하여 결정을 내리고, 기관생명윤리위원회(IRB)나 윤리위원회가 인체유래물·동의 측면을 심의하여 별도의 결정을 내리며, 생물안전관리책임자와 품질보증(QA)·연구행정 기능이 그 이후의 레코드를 보관한다. 소프트웨어의 역할은 이들의 판단을 재현하는 것이 아니라 각 결정을 지시 가능하게 만드는 것이다. 곧 식별자, 발급 주체, 범위, 유효기간, 그리고 프로토콜 레코드에서 그 결정으로 이어지는 연결이다.
v1.0 스키마는 이 요구를 절반만 충족한다. SafetyChecks.ethicsApproval은 불리언이고 SafetyChecks.regulatory는 문자열 배열이며, SafetyChecks.biosafety는 BSL1~BSL4 네 값을 갖는 라벨로서 허가가 아니라 저장된 표시일 뿐이다. 불리언은 발급 주체도 만료일도 담지 못한다. 제5장 §5.2가 이 확인값이 승인 레코드를 참조하도록 요구하고, 이 장 §8.6이 승인 참조 구조의 부재를 결함으로 올린 이유가 여기에 있다. 그 결함이 고쳐지기 전까지 구현체는 승인 참조를 자기 구조 — 프로파일 확장 필드나 레코드 저장소의 외래키 — 에 보관하고, 표준의 불리언은 그로부터 파생된 값으로만 취급해야 한다. 결코 1차 출처로 삼지 않는다.
다음 표는 참여자와 그 레코드 산출물을 정리한다. 의도적으로 좁게 썼다. 역할과 산출물만 적고, 어떤 주체가 기술적으로 무엇을 심의하는지는 서술하지 않는다.
| 참여자 | 산출물 | 레코드상의 위치 | 시간 의미 |
|---|---|---|---|
| 기관생물안전위원회(IBC) | 범위가 명시된 기관 생물안전 심의 결정 | SafetyChecks.regulatory[]의 기관 준수 항목이 가리키는 승인 참조. biosafety는 라벨로만 남는다 | 유효 개시일·만료일. 변경 시 재심의 |
| 기관생명윤리위원회(IRB)·윤리위원회 | 윤리 심의 결정, 동의 문서 구비 확인(명세 §9.2.2) | SafetyChecks.ethicsApproval이 가리키는 승인 참조 | 만료일 존재. 만료 시 in_execution 전이를 차단 |
| 생물안전관리책임자 | 레코드 부서(副署), 철회·정지 통지 | 제5장 §5.3의 권한 표기가 포함된 감사 이벤트 | 기록 시점에 즉시 효력 |
| 품질보증·연구행정 | 보존 기간 지정, 정기 완결성 점검 | 보관된 레코드에 결속되는 보존 정책 | 보존 시계는 archived 시점에 시작 |
| 연구책임자·제출자 | 제출·변경 요청, 실행 확인 | 프로토콜 레코드 본체와 실행 기록 | 각 전이에서 필드별로 동결 |
| 국가·부문 관계 기관 | 시설 등록, 허가, 신고 접수증, 임상 신청 접수 확인 | SafetyChecks.regulatory[]의 외부 참조 항목 | 해당 기관의 유효기간 규칙에 따름 |
여기서 두 가지 결론이 나온다. 첫째, 승인은 소유자가 있는 레코드이므로 제출자가 스스로 ethicsApproval을 true로 바꿀 수 있는 시스템에는 승인이 없다. 그것은 자기 주장일 뿐이며, 제6장 §6.3은 그 쓰기 권한을 생물안전관리책임자 역할에 배정한다. 검토자가 기록하는 것은 심의 결정이지 승인 참조가 아니다. 둘째, 승인은 만료되지만 프로토콜은 계속 살아 있으므로 제5장 §5.6의 기관 대시보드는 편의 기능이 아니라 거버넌스 장치다. 다음 보고 주기 안에 만료되는 승인 목록만이 프로토콜이 조용히 허가 밖으로 밀려나는 일을 막는다.
구현자는 어떤 외부 규범이 소프트웨어의 어떤 동작을 규정하는지 알아야 하고, 그 대응이 규칙 하나 바뀔 때마다 무너지지 않는 형태로 적혀 있어야 한다. 이 책이 택한 원칙은 단순하다. 규범의 이름을 적고, 그것이 구동하는 게이트를 적고, 해석은 소관 기관에 남긴다. 레코드 저장소는 자신이 집행하는 모든 게이트에 대해 기관 정책이 인용하는 근거를 출력할 수 있어야 하며, 그 이상은 말하지 않아야 한다.
유전자편집 과제 레코드에 관련되는 규범은 네 부류다. 첫째는 유전자변형생물체 취급을 규율하는 국가 체계다. 한국에서는 카르타헤나 바이오안전성의정서를 이행하는 「유전자변형생물체의 국가간 이동 등에 관한 법률」(LMO법) 체계가 이에 해당하며, 소관 부처와 질병관리청(KDCA)이 운영한다. 기관 위원회와 연구시설에 관한 의무를 두고 있고, 그 적용 기준과 신고 의무의 구체적 내용은 기관 자신이 고시한다. 소프트웨어 측 귀결은 명확하다. 일부 허가는 프로토콜 단위가 아니라 기관 단위이며, 따라서 시설 등록·허가 식별자는 프로토콜 레코드가 아니라 프로토콜이 참조하는 기관 컨텍스트에 속한다.
둘째는 재조합·합성 핵산 연구에 대한 기관 심의 전통이다. 미국 NIH의 Guidelines for Research Involving Recombinant or Synthetic Nucleic Acid Molecules가 널리 인용되는 예이며, 이 책에 주는 기여는 상설 기관 위원회의 등록·심의 결정이 연구에 선행한다는 개념이다. 셋째는 국제 지침이며, 특히 인간 유전체 편집의 거버넌스와 감독에 관한 세계보건기구(WHO)의 권고가 투명성과 등록 가시성이라는 요구의 출처다. 넷째는 임상 경로다. 편집 과제가 사람에 대한 적용으로 향할 때에는 국가 규제 신청 — 미국에서는 임상시험용신약(IND) 신청, 다른 관할에서는 그에 상응하는 임상시험 승인 — 이 허가 게이트가 되며, 레코드는 그 신청에 대한 참조를 담을 수 있어야 한다. 이 책은 임상 단계별 대상자 수, 승인 확률, 관할별 허용 여부를 서술하지 않는다. 원자료의 그 수치들은 출처가 없어 제외되었다(§8.5의 편집상 주기 참조).
| 참조 | 시스템상의 레코드 또는 게이트 | 집행 지점 |
|---|---|---|
| 국가 LMO 체계(한국의 경우 카르타헤나 의정서를 이행하는 LMO법 체계, 소관 부처와 질병관리청) | 기관 컨텍스트의 시설 등록·허가 참조, 신고 접수증의 외부 참조 | 프로토콜이 under_review로 들어갈 때 확인하는 기관 단위 전제조건 |
| 기관 위원회 심의(예: NIH Guidelines의 IBC 개념, 기관 자체 정책) | SafetyChecks.regulatory[]가 가리키는 생물안전 결정 참조 | in_execution 이전의 승인 게이트(제5장 §5.2) |
| IRB·윤리 심의와 사전 동의(명세 §9.2.2) | SafetyChecks.ethicsApproval이 가리키는 윤리 결정 참조, 동의 문서 구비 확인 | 승인 게이트. 실패 시 C006(§8.3) |
| 인간 유전체 편집 거버넌스에 관한 WHO 권고 | 투명성·등록 가시성 확인값, 유전 가능 의도 선언 | 정책 검증 계층(제3장 §3.4) |
| 임상 신청 경로(예: IND 신청, 그에 상응하는 국가 승인) | 선언된 목적이 임상일 때 요구되는 외부 신청 참조 | 정책 검증. 참조가 없으면 전이 차단 |
| 이중용도·책임 있는 공개 정책(명세 §9.2.2 항목) | 공개 검토 확인값, 공유·수출 플래그(§8.4) | 기관 간 교환 번들 생성 이전의 교환 게이트(제6장 §6.5) |
| ISO/IEC 17065:2012 감사 기대치(Annex E가 인용) | 보관 레코드와 감사 이벤트의 보존 기간 | 보존 설정(제5장 §5.4). 더 엄격한 국내 규정이 우선한다 |
| Semantic Versioning 2.0.0(Annex H) | 스키마·프로파일 매니페스트·SDK 빌드의 버전 문자열 | 릴리스 절차(§8.5) |
| 거버넌스 참조로만 인용하는 개인정보 법제(국내 개인정보보호법, 해외 GDPR·HIPAA) | 가명 처리된 대상자 식별자만 보관, 필드 단위 제한 | 통제 수단은 이 장이 아니라 제6장 §6.3이 규정한다 |
이 표는 의도된 형태를 갖는다. 모든 행이 게이트, 필드, 설정값 중 하나에서 끝난다. 어떤 거버넌스 참조를 이 셋 중 어느 것과도 연결할 수 없다면 그것은 소프트웨어에 들어갈 내용이 아니라 사람이 읽는 기관 정책 문서에 남을 내용이다. 반대로 참조 칸이 빈 게이트는 누군가 임의로 만든 게이트이며, 기관 정책에서 근거를 얻거나 제거되어야 한다.
명세가 그은 구분 하나는 반드시 실행 가능해야 한다. §9.2.1은 연구와 치료 목적의 통상적 경우로서의 체세포 편집과, 제한되며 특별한 승인을 요구하고 국제 지침을 따라야 하는 생식세포 편집을 나눈다. 다만 관할별 법적 지위에 관한 명세의 부수적 진술은 출처가 없고 관할에 따라 달라지므로, 이 책은 전 세계에 통하는 법적 판단을 코드에 넣지 않는다. 대신 더 좁고 방어 가능한 것을 넣는다. 유전 가능 의도가 선언된 경우에는 실행을 허용하는 어떤 생애주기 전이보다 먼저 명시적이고 참조 가능한 승인이 있어야 하며, 선언 자체가 없는 상태는 위험이 없는 상태가 아니라 미확인 상태로 취급한다.
오류 코드로는 SDK CRISPRErrorCode의 C006 ETHICS_VIOLATION이 여기에 해당하고, 명세의 오류 표는 C006에 "중단하고 재검토"라는 조치를 대응시킨다. 그 대응은 옳으며, 이 게이트를 권고성 코드와 구분해 준다. C003 계열이 계획에 대한 경고라면 C006은 레코드의 진행을 거부하는 코드다. 파이프라인이 자꾸 실패한다는 이유로 C006을 경고로 낮춘 검증기는 파이프라인을 개선한 것이 아니다. 검토자가 설득으로 치울 수 없는 유일한 게이트를 없앤 것이다.
v1.0은 이 게이트가 읽을 필드를 제공하지 않는다. CRISPRProtocol 어디에도 유전 가능 의도를 표시하는 필드가 없어, 이 점검은 표준 자체의 구조만으로는 기계 판정이 불가능하다(§8.6의 결함 항목). 수정되기 전까지 기관은 프로파일 확장에 세 값의 통제 어휘를 두어 선언하고 — 두 판본 모두 영문으로 저장하는 none | declared | unknown — 검증기는 unknown에서 차단한다. 실패 시 차단이 핵심이다. 레코드 시스템에서 흔한 실패는 잘못된 선언이 아니라 빠진 선언이며, 값이 없을 때 통과하는 게이트는 장식이다.
심의를 위해 제출된 프로토콜 레코드
|
+-------------+-------------+
| 유전 가능 의도가 선언됐나? |
+-------------+-------------+
none | declared | unknown
| | |
v v v
통상 게이트로 승인 참조가 차단
(8.2 표) 있나? C006
| / \ "선언 필요"
| 예 / \ 아니오
| v v
| 범위·유효기간 차단 C006
| 확인 "승인 필요"
| |
| 범위 내인가? --아니오--> 차단 C006
| | 예
+--------+--------+
v
전이 허용. 허용이든 차단이든
게이트 판정은 감사 추적에 기록된다이 도식에서 두 가지 성질을 강조할 필요가 있다. 첫째, 차단도 레코드다. 허용과 차단 두 결과 모두 제5장 §5.3의 추가 전용 로그에 기록해야 한다. 감사인이 찾는 패턴은 차단되었다가 4분 뒤 아무 문서도 없이 승인된 프로토콜이기 때문이다. 둘째, 예외 경로는 정확히 하나이며 설정 플래그가 아니다. 예외는 발급 주체·범위·만료일을 갖는 승인 참조와 그것을 적용한 사람의 신원으로 구성되고, 제출자는 그 사람이 될 수 없다. 이보다 약한 장치는 누군가 급한 날 게이트를 조용히 끄는 환경변수에 지나지 않는다.
게이트 판정은 평범한 증거 객체로 저장한다. 아래 값은 모두 자리표시자이며, 그대로 복사할 설정으로 오해되지 않도록 표기했다.
{
"record_type": "gate_decision",
"gate": "heritable_intent",
"protocol_id": "<자리표시자-프로토콜-ID>",
"protocol_version": "<자리표시자-버전>",
"evaluated_at": "<ISO-8601 타임스탬프, 서버 시계>",
"evaluated_by": "validator@<자리표시자-서비스>",
"validator_build": "<자리표시자-SDK-빌드-ID>",
"declared_value": "unknown",
"outcome": "blocked",
"error": { "code": "C006", "name": "ETHICS_VIOLATION",
"message": "heritable intent must be declared before execution" },
"override": null,
"audit_event_id": "<자리표시자-이벤트-ID>"
}예외가 실제로 존재할 때 override는 불리언이 아니라 승인 참조를 담는다. 발급 주체, 결정 식별자, 적용 범위, 만료일, 적용한 사람, 적용 시각이다. 그러면 1년 뒤 보관된 레코드를 읽는 검토자가 정작 중요한 질문 — 누가 어떤 범위로 이를 허용했고, 작업이 수행된 날에 그 허가가 유효했는가 — 에 레코드 저장소를 떠나지 않고 답할 수 있다.
명세의 연구윤리 절은 이중용도 고려를 책임 있는 공개와 접근 제한과 함께 나열한다. 이것들은 거버넌스 결정이며, 이 책은 어디까지 다루는지를 분명히 한다. 결정과 그 출처를 담는 메타데이터를 설명하되, 평가 방법론이나 위험 분류 체계, 특정 과제를 민감하게 만드는 기술적 내용은 담지 않는다. 그 판단은 기관의 이중용도 정책과 위원회, 그리고 소관 기관의 몫이며, 이는 모든 장 말미의 안내와 같다.
레코드 표면은 셋으로 충분하다. 접근 제한 라벨은 기관 내부에서 누가 레코드를 읽을 수 있는지를 통제하며 제6장 §6.3의 역할이 집행한다. 공개 검토 확인값은 공개 관련 검토가 있었음을 기록하며, 검토 주체와 결정 식별자를 참조한다. 검토의 논거는 담지 않는다. 공유 결정은 레코드가 기관 밖으로 나갈 수 있는지를 통제하며, 제6장 §6.5에서 교환 번들을 만드는 가림 단계의 입력이 된다.
| 필드(프로파일 확장) | 형 | 설정 권한 | 값이 없을 때 |
|---|---|---|---|
disclosure.accessClass | 통제 어휘, 영문 저장 | 생물안전관리책임자 또는 위임받은 레코드 관리자 | 가장 제한적인 등급을 적용. 열람은 소관 부서로 한정 |
disclosure.publicationReview | 참조 객체: 주체, 결정 ID, 결정일, 결과 | 검토자 역할을 통한 검토 주체 | 외부 번들에 포함할 수 없는 레코드로 취급 |
disclosure.shareable | 열거형: no | partner_only | open | 생물안전관리책임자, 감사 이벤트 동반 | no로 간주(실패 시 차단) |
disclosure.exportControl | 참조 객체: 판정 ID, 판정 기능, 만료일 | 해당 판정을 내리는 기관 내 기능 | 수출 경로 비활성. 기본 가정을 기록하지 않는다 |
disclosure.notes | 짧은 자유 텍스트 | 레코드를 쓰는 모든 주체 | 비움. 위원회의 논거나 대상자 식별 정보를 결코 담지 않는다 |
이 영역의 실패는 모두 텍스트가 엉뚱한 곳으로 새는 문제다. 자유 텍스트 사유 칸은 검토자가 위원회 회의록에서 어떤 과제를 민감하다고 본 이유가 적힌 문단을 그대로 붙여 넣게 만들고, 그 문단은 이후 모든 교환 번들과 모든 백업에 함께 실려 나간다. 시스템을 정직하게 유지하는 규칙은, 레코드는 결정 식별자만 저장하고 자격을 갖춘 열람자에게만 저장소가 그것을 해석해 준다는 것이다. 논거는 위원회가 회의록을 두는 곳에 남는다. 두 번째 실패는 기본값이다. 시범 통합이 편하다는 이유로 공유 플래그의 기본값을 open으로 두면 언젠가 아무도 승인하지 않은 레코드가 밖으로 나간다. 세 번째는 낡은 판정이다. 만료일 없는 수출 판정은 이미 퇴사한 사람이 부여한 영구 허가다.
10년 뒤에도 읽히는 레코드는 변하는 표준을 인용한다. PHASE 문서의 Annex들은 작업반의 유지관리 정책을 진술하며, 비규범적이긴 하지만 내용이 일관되므로 구현자가 계획의 전제로 삼을 만하다. Annex F는 자료를 세 안정성 등급으로 나눈다. Stable은 MUST·MUST NOT로 표현된 규범 요구사항이며 시맨틱 버저닝이 적용된다. Provisional은 Annex 자료로서 메이저 상승 없이 규범으로 승격될 수 있다. Reference는 시험 벡터, 참조 SDK, 시뮬레이터로서 문서와 독립적으로 버전이 붙어 참조 자료의 오류를 문서 개정 없이 고칠 수 있게 한다. 구현자가 가장 자주 오해하는 것이 마지막 등급이다. 참조 구현 빌드를 고정하는 일은 문서 버전을 주장하는 일과 같지 않다.
Annex H는 그 기계 장치를 정한다. 버전 번호는 Semantic Versioning 2.0.0을 따르며, 규범 요구사항의 하위호환 불가 변경은 메이저, 기존 구현을 깨지 않는 새 요구사항은 마이너, 편집상 변경만은 패치다. 제거되거나 하위호환 불가로 바뀐 요구사항은 이전 메이저 버전을 최소 180일간 병행 유지하며 그 기간에는 어느 버전이든 인용할 수 있고, 이후 폐기된 메이저 버전은 레지스트리에서 12개월의 일몰 기간에 들어가며 변경 이유와 이행 안내가 함께 표시된다. 패치 수준의 정오표는 동작을 바꾸지 않으므로 유예 기간 없이 발행되며 각 항목에 서명이 붙는다. 마지막으로 구현체는 자신이 지원하는 각 문서 버전을 그것을 충족하는 구체적 빌드·컨테이너 다이제스트·SDK 버전에 대응시킨 변경 이력을 공개하도록 권고된다. 제7장 §7.5가 적합성 주장의 정기 의무로 꼽는 바로 그 대응표다.
레코드 저장소에 주는 실무 규칙은 둘이다. 첫째, 표준 버전을 프로토콜 버전과 분리해 저장한다. CRISPRProtocol.version은 프로토콜 레코드의 버전이지 WIA-BIO-014의 버전이 아니며, v1.0에는 후자를 담을 필드가 없다. 그 필드가 없으면 오늘 보관한 레코드가 5년 뒤의 독자에게 어느 문서 버전에 적합성을 주장했는지 말해 줄 수 없다. 추가 필드가 생기기 전까지는 프로파일 확장(제3장 §3.1이 권하는 schema 멤버)에 두고 교환 매니페스트에 포함한다. 둘째, 식별자와 상태에 관해서는 문서 꼬리말이 아니라 레지스트리 항목을 근거로 삼는다. 이 점이 중요한 까닭은 공개된 원자료들이 서로 어긋나 있기 때문이다. README와 명세는 표준을 WIA-BIO-014로 식별하지만 네 PHASE 문서는 WIA-BIO-013을 제목으로 달고 다른 주제 이름을 갖고 있으며, 두 묶음의 발행일이 일치하지 않고, 라이선스 표기도 README와 PHASE 꼬리말 사이에서 다르다. 그래서 이 책은 전체에서 WIA-BIO-014와 v1.0을 쓰고, 제1장 §1.6에서 처음 밝힌 그 불일치를 편집상의 유지보수 사안으로 다루며(적합성 주장 산출물의 처리 방식은 제7장 §7.1), 발행일과 라이선스를 지나가듯 주장하지 않는다. 같은 이유로 PHASE 문서에서는 Annex E~J 자료만 인용한다. 그 문서들의 본문은 다른 주제에서 옮겨 온 템플릿 텍스트여서 이 주제의 규범 내용이 아니며, 본문에 실린 품질관리 수치들은 진단 분야 표준의 것으로 프로토콜 레코드에는 아무 의미가 없다.
이 책을 쓰기 위해 공개된 모든 원자료를 읽어야 했고, 그 과정에서 결함 목록이 나왔다. 아래 항목들은 미관 문제가 아니라 구조 문제다. 각 항목은 구현자가 무언가를 사적으로 발명하게 만들며, 그것은 표준이 막으려는 결과 그 자체다. 제안 칸은 Annex H의 어휘를 쓴다. 편집상 수정은 패치 정오표, 추가적 규범 변경은 마이너, 기존 구현이 깨지는 경우는 메이저다.
| 결함 | 운영상 영향 | 제안 |
|---|---|---|
| 네 PHASE 문서가 다른 표준 식별자를 제목에 달고 다른 주제 이름을 가진 템플릿 텍스트다 | 시험할 주제별 규범 요구사항이 없어 적합성 주장이 Annex에만 기댄다 | 마이너: PHASE 본문을 재작성하거나 철회하고, 일관된 Annex E~J는 유지 |
Annex E가 인용하는 Annex A 적합성 등급이 어느 공개 문서에도 없다 | 등급 기반 주장은 근거가 없다. 과거 홍보용 "레벨" 명칭도 명세에 근거가 없었다 | 패치 정오표: 해당 Annex를 발행하거나 참조를 삭제하고, 제7장의 증거 기반 주장을 쓴다 |
| 규범적 생애주기 상태 기계가 없다 | 업체마다 전이를 달리 정의해 교환한 레코드의 상태를 서로 비교할 수 없다 | 마이너: 제5장 §5.1의 상태 모델을 규범 프로파일로 채택 |
승인이 불리언(ethicsApproval)과 자유 문자열(regulatory[])뿐이고 참조 구조가 없다 | 문서 없이도 확인값을 세울 수 있고 만료를 점검할 수 없다 | 마이너: 승인 참조 객체를 추가하고, 불리언은 호환을 위한 읽기전용 파생값으로 남긴다 |
| 유전 가능 의도를 표시하는 필드가 레코드에 없다 | §8.3의 C006 게이트를 표준 자체 구조로 판정할 수 없다 | 마이너: 세 값의 통제 어휘를 추가하고, 미확인 값에서 검증기가 차단하게 한다 |
프로토콜 레코드 하나에 guideRNA와 casSystem이 정확히 하나씩만 허용된다 | 여러 가이드를 쓰는 프로젝트는 가이드마다 레코드를 만들어 문서 밖에서 연결하거나, 이식성을 깨는 지역 스키마 확장을 해야 한다(제2장 §2.3) | 마이너: 기존 멤버 옆에 선택적 추가 가이드 컬렉션을 두어 현행 문서의 유효성을 유지 |
| 레코드가 주장하는 표준 버전을 담을 필드가 없다 | 보관된 레코드가 어느 문서 버전에 적합했는지 말할 수 없다 | 마이너: 추가 필드. 그 전까지는 교환 매니페스트에 담는다 |
| 기관 간 교환 프로파일이 없다 | 제휴마다 가림 방식과 식별자 대응을 양자 협상으로 정한다 | 마이너: 제6장 §6.5가 제시한 교환 프로파일을 발행 |
| 설계 계산과 레코드 관리가 섞여 있고, 참조 SDK가 수치 상수를 권고처럼 제공한다 | 출처 없는 소프트웨어 기본값이 과학적 임계값으로 읽힌다. 명세의 과학 문헌 절은 비어 있다 | 메이저 또는 동반 문서: 계산을 레코드 계층에서 분리하고, 모든 상수를 설정 가능·출처 없음으로 표기 |
| README·명세·PHASE 꼬리말 사이에 식별자·발행일·라이선스 표기가 어긋난다 | 도구가 잘못된 식별자를 키로 쓰고, 독자는 어느 진술이 유효한지 알 수 없다 | 패치 정오표: 하나의 식별자, 하나의 날짜, 하나의 라이선스를 레지스트리 항목에서 확정 |
| 프로토콜 JSON의 예시 값이 권장 설정처럼 읽힌다 | 구현자가 자리표시자 수치를 운영 템플릿에 복사한다 | 패치 정오표: 이 책이 한 것처럼 모든 예시 값을 자리표시자로 재표기 |
이 결함들 가운데 어느 것도 기관이 오늘 레코드 계층을 도입하는 것을 막지 않는다. 그래서 이 책은 버티는 부분 — 필드 표, 식별자와 직렬화 규칙, API 계약, 생애주기, 증거 패키지 — 을 중심으로 쓰였다. 다만 이 목록은 다음 마이너 버전의 의제를 정하며, 위에 적은 우회책을 이미 구축한 구현자는 그 버전이 나올 때 적은 비용으로 이행할 수 있다.
이 책에서 작동하는 시스템까지 가는 가장 짧은 경로는 장의 순서와 같다. 각 단계가 다음 단계가 늦어져도 남는 결과를 만들기 때문이다.
명세는 홍익인간(弘益人間), 곧 널리 인간을 이롭게 한다는 말로 시작한다. 레코드 표준에서 이 원칙은 소박하고 구체적인 뜻을 가진다. 사람에게 도움이 되는 유전자편집 연구란 허가가 실재하고, 이력을 재구성할 수 있으며, 그 자리에 없던 사람이 결과를 확인할 수 있는 연구다. 이 책이 설명한 레코드는 편집 과제를 안전하게 만들지 않는다. 책임을 물을 수 있게 만들며, 그것이 소프트웨어가 정직하게 주장할 수 있는 유일한 기여다. 그 너머 — 무엇을 시도해도 되는지, 어떤 조건에서, 어떤 감독 아래에서 — 는 이 장에서 이름을 적은 위원회와 관계 기관이 결정하고, 잘 만든 레코드 저장소는 그 결정을 필요한 만큼 오래 읽을 수 있게 남기기 위해 존재한다.
과학·실험실 안전 내용은 소속 IBC/IRB와 공식 생물안전·규제 기관에 문의할 것(국내에서는 질병관리청과 LMO법을 운영하는 관계 기관, 국제적으로는 WHO, NIH Guidelines, 해당 국가 규제기관). 이 장은 거버넌스 메타데이터, 레코드 게이트, 표준 유지관리만을 다룬다. 실험 절차, 봉쇄나 대상별 특성, 법률 자문은 제공하지 않는다.