법 조항에서 AI 위험 원인까지 EU AI Act 고위험 요구사항을 다시 읽는 법

오늘 살펴볼 논문은 From Legal Text to AI-specific Risk Sources: A Systematic Analysis of the EU AI Act's High-Risk Requirements라는 제목의 arXiv 프리프린트(arXiv:2609.13535)로, 제4회 International Conference on Frontiers of Artificial Intelligence, Ethics, and Multidisciplinary Applications에서 발표된 연구입니다. 이 논문은 EU AI Act의 고위험 요구사항 가운데 소수만이 AI 특유의 위험 원인을 직접 다루고 나머지는 조직의 절차와 문서화 의무에 가깝다는 진단을 내놓습니다. 원문 링크는 제목 아래에 걸어 두었습니다.

법을 읽다가 멈칫한 지점이 있었습니다

제가 이 논문에서 가장 흥미롭게 본 부분은 법을 읽는 태도였습니다. 보통 EU AI Act를 이야기하면 고위험 AI 시스템이라는 말이 먼저 나오고, 이어서 준수해야 할 요구사항이 많다는 말이 따라오는데, 이 논문은 거기서 한 걸음 물러나 요구사항 자체를 분류하는 것부터 시작합니다. 법에 적힌 문장을 하나씩 떼어내어 이것이 AI 때문에 생기는 위험을 직접 겨냥한 것인지, 아니면 조직이 갖춰야 할 절차와 기록에 가까운 것인지를 가려보자는 시도인데요. 생각해보면 사람도 비슷하게 배웁니다. 처음에는 두꺼운 설명서를 통째로 외우려다가, 어느 순간 목차를 다시 보고 이것은 동작 원리에 대한 설명이고 저것은 점검 기록 양식이라는 사실을 깨닫는 식이죠. 이 논문은 EU AI Act의 Section 2에 담긴 고위험 요구사항을 대상으로 바로 그 목차 읽기를 수행합니다.

여기서 재미있는 질문이 생깁니다. 법이 요구하는 일이 많다는 사실은 알겠는데, 그 많은 요구사항이 정말 AI의 위험한 성질과 연결되어 있을까요. 아니면 상당수가 어떤 기술을 쓰든 필요했을 일반적인 품질 관리와 기록 관리에 가까울까요. 저자는 이 질문을 그냥 던지지 않고 요구사항을 직접 손으로 분류하면서 답을 찾습니다. 그래서 이 논문은 법 해석서가 아니라 분류 작업의 기록에 가깝습니다. 분류가 끝나면 법 문장에서 AI 위험과 관련된 요구사항만을 추려내고, 거기에서 다시 서로 겹치지 않는 AI 특유의 위험 원인들을 추려 EU AI Act Risk Source List라는 목록으로 묶습니다. 이 목록이 법적인 의무와 실제 위험 관리 실무 사이를 잇는 다리가 되기를 바란다는 점도 분명히 밝히고 있습니다.

저는 이 출발점이 마음에 들었습니다. 법을 읽을 때 흔히 빠지는 함정이 조항마다 무엇인가 대단한 기술적 통찰이 숨어 있을 것이라는 기대인데, 실제로는 상당수가 누가 무엇을 기록하고 누가 승인했는지를 묻는 절차이기 때문입니다. 그렇다면 그 절차를 걷어내고 남는 것이 무엇인지 아는 일이 먼저겠죠. 오늘 글에서는 그 분류가 어떻게 이루어졌는지, 분류 뒤에 남은 AI 특유의 위험 원인이라는 말이 무엇을 뜻하는지, 그리고 이 목록이 실무에서 어떤 쓰임새를 가질 수 있는지를 차례로 따라가 보겠습니다.

고위험 요구사항은 왜 절차처럼 들릴까

EU AI Act가 고위험 AI 시스템에 의무를 부과한다는 말은 자주 듣지만, 막상 조항을 펼치면 문장이 꽤 행정적으로 느껴집니다. 무엇을 문서화하고, 어떤 품질 관리 체계를 갖추고, 기록을 얼마나 보관하고, 사람에 의한 감독을 어떻게 배치할 것인지를 묻기 때문입니다. 그런데 이런 문장을 읽으면서 드는 의문이 있습니다. 이것은 AI라서 필요한 것일까, 아니면 의료기기나 자동차 부품을 만들 때도 필요했을 일일까. 제조업을 오래 본 분이라면 후자에 가깝다는 느낌을 받을 때가 많을 텐데요. 품질 문서, 로그 보관, 책임자 지정 같은 장치는 특정 기술에만 속하지 않기 때문입니다.

이 논문이 짚은 지점도 바로 여기입니다. 고위험 요구사항 전체를 놓고 보면 AI 특유의 위험 원인을 직접 겨냥한 요구사항은 소수에 불과하고, 나머지는 조직의 절차와 문서화 의무에 가깝다는 것입니다. 이 진단은 언뜻 실망스럽게 들릴 수 있습니다. AI 법인데 AI 이야기가 적다니요. 하지만 달리 보면 꽤 현실적인 관찰입니다. 법이라는 도구가 다루기 쉬운 것은 측정 가능한 절차이기 때문입니다. 문서가 있는가, 기록이 남는가, 감독자가 지정되어 있는가는 감사(audit)에서 확인하기 쉽습니다. 반면 학습 데이터의 편향이 어느 수준에서 위험해지는가 같은 질문은 현장마다 답이 달라서 법 문장 하나로 못 박기 어렵죠.

문제는 그다음입니다. 절차가 중요하지 않다는 말이 아니라, 절차를 다 지켰다는 사실이 곧 AI의 위험한 성질을 통제했다는 뜻은 아니라는 점입니다. 제가 예전에 배포 체크리스트를 보면서 느낀 것도 비슷했습니다. 체크리스트의 칸이 모두 채워지면 마음이 놓이는데, 정작 모델이 낯선 입력 앞에서 어떻게 흔들리는지는 체크리스트가 묻지 않는 경우가 많았습니다. 법을 준수하는 팀이 바로 이 지점에서 헷갈릴 수 있습니다. 서류는 완벽한데 위험은 그대로인 상태가 생길 수 있기 때문입니다. 그래서 요구사항을 AI 위험 관련 요구사항과 절차 의무로 가르는 일은 단순한 학술적 정리가 아니라, 준수 작업의 초점을 어디에 둘 것인지를 묻는 실무적인 질문이 됩니다.

그렇다면 AI 특유의 위험이란 무엇일까

그렇다면 AI 특유의 위험 원인이라는 말은 무엇을 가리킬까요. 이 표현은 언뜻 추상적으로 들리지만, 논문의 문제의식을 따라가면 꽤 분명해집니다. 어떤 요구사항은 AI가 아니라 다른 시스템이어도 똑같이 적용될 수 있고, 어떤 요구사항은 학습 데이터나 모델의 동작 방식 때문에만 생기는 문제를 다룹니다. 후자가 바로 AI 특유의 위험과 연결된 부분인데요. 예를 들어 기록 보관 의무는 은행 창구 업무에도 있을 수 있는 요구이지만, 학습 과정에서 스며든 편향이나 운영 중에 마주치는 낯선 입력에 대한 취약함 같은 문제는 AI 시스템이라는 특정한 구성에서 비롯됩니다.

저는 이 구분을 건축 허가에 비유해서 이해했습니다. 건축 허가를 받을 때는 구조 계산서도 내고, 시공사 등록증도 내고, 감리 일지도 제출합니다. 그런데 시공사 등록증은 누가 짓든 필요한 서류이고, 지반의 특성에 맞춘 구조 계산은 그 땅과 그 건물에서만 생기는 문제입니다. 두 서류가 모두 필요하지만, 건물이 무너지지 않게 하는 데 직접 연결되는 것은 후자에 가깝죠. AI 시스템에서도 문서화와 품질 체계는 등록증과 감리 일지에 가깝고, 데이터와 모델의 성질에서 비롯되는 위험 원인은 그 땅의 지반에 가깝습니다. 법은 두 종류를 같은 장에 넣어두기 때문에 읽는 사람이 직접 가려내야 합니다.

여기서 한 가지 조심할 점이 있습니다. AI 특유의 위험이라는 말을 들으면 곧바로 거대한 모델의 자의식 같은 장면을 떠올리기 쉽지만, 이 논문이 말하는 방향은 그쪽이 아닙니다. 법 문장에서 실제로 길어 올릴 수 있는, 데이터와 모델과 운영 조건에 묶인 위험의 출처를 가리킵니다. 다시 말해 철학적인 논쟁이 아니라 조항 속에 숨어 있는 기술적 단서에 가깝습니다. 그렇다면 다음 질문은 자연스럽게 이어집니다. 수많은 조항 중에서 그 단서를 어떻게 골라내고, 겹치는 표현을 어떻게 하나의 목록으로 다듬을 수 있을까. 그 이야기는 분류 방법에서 이어집니다.

문서화 의무를 위험 관리로 착각하면 생기는 일

화요일 아침에 채용 심사 모델을 운영하는 팀을 떠올려 보겠습니다. 감사 대응 폴더에는 문서가 가지런히 들어 있습니다. 위험 관리 계획서도 있고, 로그 보관 정책도 있고, 사람 감독 절차도 문서로 정리되어 있습니다. 팀장은 점심 전에 감사관과 미팅이 있는데, 서류상으로는 준비가 끝난 상태입니다. 그런데 오후에 현장 면접관 한 명이 묻습니다. 최근 지원자 분포가 바뀌었는데 모델 점수의 기준이 그대로 괜찮은가요. 이 질문에는 폴더 속 문서가 바로 답하지 못합니다. 문서는 절차가 있다는 것을 보여주지만, 분포 변화라는 기술적 조건이 위험을 키웠는지는 따로 살펴봐야 하기 때문입니다.

제가 이 장면을 길게 꺼낸 이유는 절차와 위험 관리의 간극이 문서상으로는 잘 보이지 않기 때문입니다. 절차는 과거의 결정을 고정하는 데 능숙하고, 위험 관리는 변하는 조건에 반응해야 하는 일이라서 둘의 시간 감각이 다릅니다. 법이 요구하는 문서화 의무는 대개 전자를 돕고, AI 특유의 위험 원인을 다루는 일은 후자에 가깝습니다. 전자가 부실하면 조직은 흔들리지만, 후자가 비어 있으면 모델이 흔들립니다. 두 흔들림은 종류가 달라서 한쪽을 채웠다고 다른 쪽이 자동으로 채워지지 않습니다.

그래서 논문이多数 요구사항이 절차와 문서화에 가깝다고 지적한 대목은 비판이라기보다 주의사항에 가깝게 읽힙니다. 법에서 요구하는 대로 서류를 갖추는 일은 필요하지만, 그것만으로 AI 위험을 다뤘다고 생각하면 놓치는 부분이 생긴다는 것이죠. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 우리 팀의 점검표에는 일반 품질 항목과 AI 특유의 위험 항목이 섞여 있지 않은가. 섞여 있다면 둘을 같은 방식으로 점검하고 있지는 않은가. 저는 이 논문이 던지는 가장 실용적인 질문이 바로 이것이라고 봅니다. 목록을 만드는 일보다 목록이 필요하다는 사실을 보여준 점이 더 중요하게 느껴지기도 합니다.

분류 작업은 어떻게 이루어졌을까

이제 분류 작업 자체를 들여다볼 차례입니다. 논문은 EU AI Act의 Section 2에 담긴 고위험 요구사항을 추출한 뒤, 그것들을 체계적으로 분류합니다. 분류의 기준은 겉으로 드러난 장의 제목이 아니라 각 요구사항이 겨냥하는 대상이 AI 특유의 위험 원인인지, 아니면 조직이 갖춰야 할 절차와 문서화인지에 있습니다. 이 방식은 언뜻 단순해 보이지만 막상 해보면 까다로운 작업입니다. 법 문장은 한 문장 안에 여러 의무를 함께 담는 경우가 많고, 같은 의무도 장마다 다른 말로 반복되기 때문입니다.

저는 이 과정을 도서관 서가를 정리하는 일로 상상했습니다. 책등에 적힌 제목만 보고 꽂으면 금방 끝나지만, 실제로 필요한 정리는 주제별 분류라서 한 권씩 펼쳐서 봐야 합니다. 어떤 책은 제목과 내용이 다르고, 어떤 책은 두 주제에 걸쳐 있어서 별도의 기준이 필요합니다. 법 조항 분류도 마찬가지입니다. 문장 표면에 적힌 말을 그대로 믿기보다 그 문장이 실제 현장에서 무엇을 바꾸는지를 물어야 합니다. 기록을 남기라는 요구는 현장의 파일 하나를 바꾸고, 데이터의 문제를 살피라는 요구는 현장의 실험 하나를 바꿉니다. 바꾸는 대상이 다르면 다른 서가에 꽂아야겠죠.

이 과정에서 눈여겨볼 점은 분류가 곧 해석이라는 사실입니다. 어디까지를 AI 특유하다고 볼 것인지는 사람마다 조금씩 다를 수 있기 때문입니다. 예를 들어 사람에 의한 감독이라는 요구는 언뜻 일반적인 절차처럼 보이지만, 모델의 판단이 불투명하다는 성질 때문에 더 무거워지는 측면도 있습니다. 이런 경계에 있는 항목을 어느 쪽에 둘 것인지는 분류자의 판단에 달려 있습니다. 논문이 체계적 분석을 내세운 이유도 여기에 있습니다. 한두 개의 인상적인 조항을 골라 주장하는 대신 전체를 같은 잣대로 훑어야 경계에 있는 항목들의 위치가 드러나기 때문입니다. 그렇다면 분류가 끝난 뒤에는 무엇이 남을까요. 절차를 걷어낸 자리에 남는 문장들이 바로 다음 이야기의 재료가 됩니다.

법 조항에서 위험 원인 목록이 나오는 순간

분류에서 AI 위험과 관련된 요구사항만을 추려냈다고 해서 일이 끝나는 것은 아닙니다. 추려낸 문장들은 여전히 법의 말투로 적혀 있어서 서로 겹치고, 같은 위험을 다른 장에서 다르게 표현한 경우도 많습니다. 논문은 이 문장들에서 서로 겹치지 않는 AI 특유의 위험 원인들을 추려 하나의 목록으로 묶습니다. 이 지점이 이 연구에서 가장 손이 많이 가는 대목일 텐데요. 겹치는 표현을 합치고, 수준이 다른 말을 같은 층위로 맞추고, 절차의 잔재가 섞여 들어오지 않았는지 다시 확인해야 하기 때문입니다.

이 작업을 요리 레시피를 정리하는 일에 비유하면 이해가 쉽습니다. 여러 집의 김치 레시피를 모아 공통 조리 원리를 뽑는다고 할 때, 소금의 양은 집마다 다르지만 소금이 하는 역할은 같습니다. 반대로 같은 소금이라도 절이는 단계에서 쓰는지 간을 맞출 때 쓰는지Order에 따라 역할이 달라집니다. 법 문장도 비슷합니다. 같은 말을 해도 어느 단계의 무엇을 바꾸려는 것인지에 따라 가리키는 위험이 달라집니다. 그래서 목록을 만드는 일은 문장을 세는 일이 아니라 역할을 가려내는 일에 가깝습니다. 겹치는 말을 합치는 과정에서 연구자의 판단이 들어갈 수밖에 없는 이유이기도 합니다.

개인적으로 인상 깊었던 점은, 이 목록이 법을 대신하겠다는 야심이 아니라 법과 실무 사이를 잇겠다는 자세로 제시되었다는 것입니다. 법 문장은 준수 여부를 따지는 말투로 적혀 있고, 위험 관리 문서는 원인을 찾고 대책을 세우는 말투로 적혀 있습니다. 두 말투는 자연스럽게 이어지지 않기 때문에 중간에 번역기가 필요합니다. EU AI Act Risk Source List라는 이름의 목록은 바로 그 번역기를 자처합니다. 법에서 출발했지만 도착지는 실무의 점검표와 설계 검토에 있다는 점에서, 이 목록의 가치는 항목 하나하나의 새로움보다 전체를 한 장으로 볼 수 있게 했다는 데 있습니다. 그렇다면 이 목록은 기존에 알려진 위험 분류표와 어떤 관계에 있을까요. 그 비교가 다음 대목입니다.

기존 위험 분류표와 맞춰보면 무엇이 보일까

AI 위험을 정리한 분류표는 이미 여러 종류가 알려져 있습니다. 연구 공동체와 표준화 기구에서 만든 목록들이 각자의 관점에서 위험의 종류를 나누고 있죠. 그런데 자연스럽게 이런 의문이 생깁니다. 법이 겨냥하는 위험과 기존 분류표가 말하는 위험은 같은 것일까. 두 목록이 모두 AI로 인한 위험을 다룬다고 말하지만, 실제로는 서로 다른 층위를 보고 있을 수도 있기 때문입니다. 논문은 바로 이 정렬 문제를 정면으로 다룹니다. 법의 고위험 요구사항이 암묵적으로 가리키는 위험과 기존 분류표 사이의 분명한 대응 관계가 아직 없었다는 점을 출발점으로 삼습니다.

이 대목을 읽으면서 저는 서로 다른 지도를 겹쳐보는 장면을 떠올렸습니다. 하나는 행정구역 지도이고 다른 하나는 지질도인데, 두 지도 모두 같은 땅을 그리고 있습니다. 행정구역 지도는 어디까지가 어느 구청의 관할인지를 보여주고, 지질도는 어디에 단층이 있는지를 보여줍니다. 두 지도를 겹치면 관할 경계 안에 어떤 지질 위험이 들어 있는지가 보이기 시작하죠. 법과 기존 분류표의 관계도 비슷합니다. 법은 누가 무엇을 해야 하는지를 그리고, 분류표는 어떤 성질이 위험해질 수 있는지를 그립니다. 두 그림을 나란히 놓고 겹치는 부분과 어긋나는 부분을 확인하는 일은 그래서 단순한 대조표 만들기가 아니라, 법의 빈틈과 분류표의 빈틈을 동시에 드러내는 작업이 됩니다.

여기서 한 가지 짚고 넘어갈 점이 있습니다. 대응 관계가 없다는 지적은 법이 잘못되었다는 말이 아닙니다. 법과 분류표는 애초에 용도가 다르기 때문입니다. 법은 강제할 수 있어야 하므로 확인할 수 있는 의무 중심으로 적히고, 분류표는 놓치기 쉬운 위험을 상기시키는 데 목적이 있습니다. 문제는 두 도구를 함께 써야 하는 실무자가 그 사이를 스스로 메워야 한다는 점입니다. 논문이 목록을 기존 분류표와 연결하려는 시도는 바로 그 메우기 작업을 돕겠다는 뜻으로 읽힙니다. 법을 읽고 나서 그러면 우리 시스템의 어떤 성질을 봐야 하는가라는 질문으로 넘어갈 수 있게 해주기 때문입니다.

실무자 관점에서 이 목록을 어떻게 써야 할까

그렇다면 이 목록은 현장에서 어떻게 쓰일 수 있을까요. 저는 이 질문을 받을 때 저희가 새로운 AI 아키텍처를 볼 때의 습관을 떠올립니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 법을 볼 때도 비슷하게 물을 수 있습니다. 요구사항의 개수가 아니라 그 요구사항이 현장의 무엇을 바꾸는지, 그리고 그 바꿈이 절차의 완성인지 위험의 감소인지를 함께 보는 것이죠. 이 목록은 후자를 보는 눈을 제공합니다.

구체적인 장면을 하나 더 들어보겠습니다. 금요일 오후에 고위험 AI 시스템을 담당하는 팀이 분기 점검을 합니다. 기존에는 법 조항 번호 순서대로 문서를 확인했습니다. 몇 조의 무엇을 갖췄는지를 묻는 방식이죠. 이 목록이 있다면 순서를 바꿀 수 있습니다. 문서 확인을 먼저 끝낸 뒤 위험 원인별로 시스템을 다시 훑는 것입니다. 학습 데이터의 출처와 편향 점검은 어떻게 했는지, 운영 중에 들어오는 입력의 범위를 어떻게 정의했는지, 사람이 개입하는 지점이 실제로 작동하는지를 묻는 식입니다. 같은 시간을 쓰더라도 후반부의 질문이 팀의 대화를 절차 점검에서 위험 점검으로 옮겨줍니다. (참고로 이런 점검은 한 번으로 끝나지 않고 분기마다 반복해야 하는데, 그 반복이야말로 절차와 위험 관리가 만나는 지점이기도 합니다.)

물론 목록이 있다고 해서 위험이 자동으로 줄어드는 것은 아닙니다. 목록은 어디를 볼 것인지를 알려줄 뿐, 각 항목을どの 수준까지 다뤄야 하는지는 현장의 판단에 남기 때문입니다. 이 점에서 이 목록은 답안지가 아니라 질문지에 가깝습니다. 좋은 질문지는 답을 대신해주지 않지만, 놓치기 쉬운 질문을 빠뜨리지 않게 해줍니다. 실무자 입장에서 보면 그 기능만으로도 충분한 가치가 있습니다. 특히 여러 팀이 각자 다른 말로 위험을 이야기할 때 공통의 항목 이름이 있다는 것은 회의 시간을 크게 줄여줍니다. 같은 위험을 같은 이름으로 부를 수 있다는 것만으로도 설계 검토와 감사 대응이 훨씬 수월해지기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 연구가 보여주는 것은 법 문장의 분류와 그로부터 길어 올린 목록이지, 특정 시스템이 얼마나 위험한지를 측정한 결과가 아니기 때문입니다. 분류가 체계적이라고 해서 그 결과가 유일한 정답이 되는 것은 아닙니다. 앞서 말했듯이 경계에 있는 항목은 분류자의 판단에 따라 위치가 달라질 수 있고, 법 문장 자체도 개정과 해석에 따라 얼굴을 바꿉니다. 그래서 이 목록을 고정된 표준처럼 읽기보다 특정 시점의 법 문장을 같은 잣대로 정리한 스냅사진으로 읽는 편이 정확합니다.

또 하나 짚을 점은 절차 의무를 가볍게 보면 안 된다는 사실입니다. 이 논문의 진단을 접하면 절차는 형식적이고 위험 원인만이 실질적이라는 인상을 받기 쉬운데, 실제 운영에서는 절차가 위험을 붙잡는 그릇이 되기도 합니다. 기록이 남아 있어야 사후 분석이 가능하고, 책임자가 있어야 문제가 생겼을 때 대응이 빨라집니다. 절차가 위험 자체를 줄이지 못하더라도 위험이 터졌을 때의 피해를 줄이는 역할을 하는 것이죠. 저는 그래서 절차와 위험 원인을 우열로 읽기보다 역할로 읽는 편이 좋다고 봅니다. 하나는 터지기 전에 보는 일이고 다른 하나는 터진 뒤에도 수습할 수 있게 하는 일이라서 둘 다 필요합니다.

마지막으로 확인해야 할 것은 증거의 범위입니다. 이 글에서 다룬 내용은 공급된 연구 자료에 담긴 발견에 기대고 있습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 소수와 다수라는 표현 자체보다 무엇을 소수로 묶고 무엇을 다수로 묶었는지가 논의를 만들기 때문입니다. 그 구조를 이해하면 법이 바뀌거나 새로운 분류표가 나와도 같은 방법으로 다시 물을 수 있습니다. 이번에는 무엇이 절차이고 무엇이 위험 원인인가. 이 질문을 던질 수 있다는 점이야말로 이 논문이 남기는 방법론적 선물에 가깝습니다.

법을 지킨다는 말의 뜻이 바뀌는 지점

이제 처음으로 돌아와 볼까요. 처음에는 법 조항이 많다는 사실이 부담으로 느껴졌는데, 분류를 거치고 나면 부담의 성격이 달라집니다. 부담이 줄어드는 것이 아니라 부담이 어디에 있는지가 분명해지는 것이죠. 서류 작업의 부담과 기술적 검토의 부담은 종류가 다르고, 두 부담을 같은 일정표에 넣어 처리하면 둘 다 반쪽이 되기 쉽습니다. 이 논문은 두 부담을 다른 트랙에 올려놓자고 제안합니다. 법을 지켰다는 말이 서류를 갖췄다는 뜻에서 멈추지 않고, AI 특유의 위험 원인을 점검했다는 뜻까지 포함하도록 말이죠.

제가 앞으로 보고 싶은 것은 이 목록이 현장의 설계 검토와 어떻게 만나는지입니다. 목록이 문서의 한 장으로 머무르면 아쉽고, 모델을 고르고 데이터를 고르고 운영 조건을 정하는 회의에서 실제로 불려 나오면 좋겠습니다. 예를 들어 새로운 데이터셋을 도입할 때 목록의 특정 항목을 펼쳐서 이번 도입이 어떤 원인과 연결되는지를 묻는 식입니다. 그런 사용법이 쌓이면 목록은 점점 현장의 말로 다듬어질 것이고, 반대로 현장의 경험이 목록을 갱신하는 재료가 될 것입니다. 법에서 출발한 목록이 실무에서 다시 쓰이면서 법의 다음 개정에 영향을 주는 순환이 생긴다면 꽤 이상적인 그림이겠죠.

다 읽고 나면 남는 문장은 하나입니다. 법을 읽는 일과 위험을 보는 일은 같은 일이 아니지만, 분류라는 다리를 놓으면 두 일을 함께 할 수 있다는 것입니다. 이 다리 위에서는 감사관과 엔지니어가 같은 목록을 보고도 각자의 질문을 던질 수 있습니다. 감사관은 이 항목에 대한 기록이 있는지를 묻고, 엔지니어는 이 항목이 우리 시스템에서 어떤 조건일 때 커지는지를 묻습니다. 같은 목록에서 출발한 두 질문이 만나면 준수는 종이 위의 도장이 아니라 시스템의 상태에 대한 대화가 됩니다. 저는 그 대화가 늘어나는 모습을 보고 싶습니다. 그것이 이 논문을 읽은 뒤에 제가 갖게 된 가장 구체적인 기대입니다.