통과를 거부한 ISO 42001 코스

통과를 거부한 ISO 42001 코스

잘못된 확신, 감사 사각지대, 그리고 탐지(detection)와 현실의 차이에 관한 기술적 사후 분석(post-mortem)입니다. 여기에는 AI가 포함되어 있지만, 이것은 AI 이야기가 아닙니다. 이는 컴플라이언스(compliance)의 탈을 쓴 관측성(observability) 이야기입니다.

버그가 아니었던 버그 리포트

이런 일들은 항상 그렇듯, 우리가 스스로에게 말하던 이야기와 맞지 않는 결과가 나오면서 시작되었습니다.

우리는 구조화된 컴플라이언스 교육 프로그램 — 자격 증명을 뒷받침하는 데 필요한 인증 기관(awarding body)의 코스, 평가, 그리고 전체 장치 — 을 생성하는 플랫폼을 운영합니다. 그 프로그램 중 하나가 ISO 42001 선임 심사원 (ISO 42001 Lead Auditor) 코스였습니다 (ISO 42001은 AI를 위한 경영 시스템 표준입니다). 이 프로그램은 우리가 _표준 제품군 일관성 (standard-family consistency)_이라고 부르는 기준에서 내부 품질 검사(quality checks)를 계속 통과하지 못했습니다. 대략적으로 말하자면, "이 자료가 가르친다고 주장하는 표준에 대해 이야기하고 있는가, 아니면 은밀하게 다른 표준으로 흘러가고 있는가?"를 확인하는 기준입니다.

괜찮습니다. QA 검사 실패는 흔한 일입니다. 우리는 당연한 조치들을 취했습니다:

• 생성기를 다시 실행했습니다.
• 프롬프트(prompt)를 강화했습니다.
• "다른 ISO 표준을 규제 기준으로 참조하지 마시오"라는 명시적인 지침을 추가했습니다.
• 감사를 다시 실행했습니다.
• 다시 실패하는 것을 지켜보았습니다.
• 우리의 인생 선택에 의문을 품었습니다.
• 반복했습니다.

프로그램은 계속 실패했습니다. 극적으로 실패한 것은 아니었습니다. 말도 안 되는 내용을 만들어내는 것도 아니었습니다. 그것은 AI 경영 (AI management) (ISO 42001)에 관한 프로그램 내에서, 과제를 환경 경영 (environmental management) 통제 항목(ISO 14001)을 중심으로 미묘하게 구성하곤 했습니다. 한 검토자는 초안 중 하나를 "GreenTech Energy가 AI 거버넌스를 수행하는 것 같다"라고 묘사했는데, 이는 학습자가 잘못된 표준을 기준으로 평가받을 뻔했다는 사실을 깨닫기 전까지는 웃기는 이야기였습니다.

우리는 이 프로그램이 유독 고장 났다고 확신하며 당혹스러울 정도로 많은 시간을 허비했습니다. 돌파구는 우리가 첫날부터 물었어야 했던 질문이었습니다:

우리는 _"왜 이 프로그램이 실패하는가?"_라고 묻는 것을 멈추고, _"왜 다른 모든 것들은 통과하는가?"_라고 묻기 시작했습니다.

그러한 관점의 전환이 이 글의 핵심입니다. 아래의 모든 내용은 우리가 그 질문을 진지하게 받아들였을 때 일어난 일들입니다.

아키텍처 맵 (The Architecture Map)

무언가 고장 났다고 의심될 때는 그 부분을 디버깅(debug)합니다. 하지만 '고장'에 대한 정의 자체가 틀렸다고 의심될 때는 시스템을 매핑(map)해야 합니다. 그래서 우리는 머릿속에 있는 지도 대신 실제 생성 토폴로지(generation topology)를 그렸습니다.

우리는 아마 6개 또는 7개 정도의 "생성기(generators)"가 있을 것이라고 예상했습니다. 하지만 우리는 **22개의 별개 생성 경로(generation pathways)**를 발견했습니다. 각 경로는 학습자 대상 콘텐츠를 생성할 수 있었고, 저마다의 프롬프트 조립(prompt assembly) 방식과 컨텍스트(context)를 가지고 있었으며, 결정적으로 — 우리의 거버넌스(governance) 규칙과 각각의 관계(또는 관계 없음)를 맺고 있었습니다:

 1  Blueprint (청사진)              8  Applied exercises (응용 연습)     15  Rubric generation (루브릭 생성)
 2  Outline / refine (개요 / 정교화) 9  Capstone (캡스톤)              16  Smart hotspots (스마트 핫스팟)
 3  Course generation (코스 생성)     10  Module exams (모듈 시험)        17  Cover image (커버 이미지)
...

그 누구도 22개의 경로를 설계하지 않았습니다. 그것이 핵심입니다. 그것들은 **점진적으로 축적(accreted)**되었습니다. 버전 1에는 레슨과 퀴즈가 있었습니다. 그러다 누군가 진단(diagnostics) 기능을 추가했습니다. 그다음에는 자격 인증을 위해 총괄 평가(summative assessment)가 필요했기에 캡스톤(capstones)이 추가되었습니다. 그다음에는 인증 기관들이 채점된 결과물을 원했기에 과제 설명서(assignment briefs)와 루브릭(rubrics)이 추가되었습니다. 그다음에는 소유자들이 "이 부분 다시 하기" 버튼을 원했기에 재생성 엔드포인트(regeneration endpoints)가 추가되었습니다. 그다음에는 첫 번째 경로가 새로운 워크플로우(workflow)에 맞지 않았기에 두 번째 재생성 경로가 추가되었습니다.

각각의 추가 사항은 합리적이었습니다. 각각은 테스트와 함께 배포되었습니다. 그리고 각각은 작성된 당시에 존재하던 거버넌스 규칙에 연결되어 있었습니다. 즉, 드리프트(drift, 괴리)는 재앙처럼 갑자기 찾아온 것이 아니었습니다. 그것은 18번의 합리적인 화요일을 거쳐 찾아왔습니다.

우리는 거버넌스 커버리지(governance coverage)에 따라 맵에 색상을 입혔습니다:

• 🟢 녹색 (8개): 생성이 거버넌스 통제를 받으며, 출력이 감사(audited)되고, 결함이 수정 가능함.
• 🟠 황색 (9개): 생성이 대략적으로 거버넌스 통제를 받지만, 결과물을 감사하는 장치가 없음.
• 🔴 적색 (5개): 완전히 고립됨 — 응용 연습, 과제 설명서, 과제 재생성, 루브릭 생성. 공유된 거버넌스 컨텍스트가 입력되지 않으며, 출력을 검토하는 감사도 없음.

ISO 42001의 미스터리가 풀리게 된 지점은 바로 여기입니다. 표준 패밀리 심사원(standard-family auditor)은 오직 녹색 경로(green pathways)인 강의, 퀴즈, 시험, 진단, 캡스톤 프로젝트만을 검사했습니다. 결함은 과제 설명서(assignment brief) — 즉, 적색 경로(red pathway)에 존재했습니다. 심사원은 엄격하면서도 동시에 눈이 멀어 있었습니다. 즉, 보이는 곳에서 누출이 발생하는 것은 지적할 만큼 엄격했지만, 누출이 실제로 시작되는 더 넓은 표면(surface)에 대해서는 눈이 멀어 있었습니다.

ISO 42001 프로그램이 유독 망가져 있었던 것은 아닙니다. 그것은 유독 정밀하게 측정되었을 뿐입니다. 프로그램이 매우 엄격하게 기반을 두고 있었기에, 심사원이 볼 수 있는 어딘가에서 오염이 표면화되었고, 결과적으로 다른 모든 프로그램도 가지고 있지만 아무도 찾지 않았던 구조적 약점을 드러내게 된 것입니다.

신뢰의 문제: 통과(PASS) ≠ 깨끗함

모든 대시보드에 문신처럼 새겨져야 할 사실을 말씀드리겠습니다.

시스템은 오직 측정하는 것만을 탐지할 수 있습니다. PASS(통과)는 단지 "우리가 검사한 표면에서 결함이 발견되지 않았다"는 것을 의미할 뿐입니다. 우리가 검사하지 않은 표면에 대해서는 아무것도 말해주지 않습니다.

우리의 포트폴리오 뷰는 자랑스럽게 녹색을 표시했습니다. 대부분의 프로그램이 "통과"했습니다. 하지만 "통과"는 오직 심사된 경로(전체 22개 중 약 9개)만을 참조하는 QA 함수(qa.passed)를 통해 계산되었습니다. 모든 적색 경로를 포함한 나머지 13개는 판정에 전혀 기여하지 않았습니다. 따라서 우리의 PASS는 기술적으로 정직하게 말하자면 다음과 같았습니다.

PASS  ≡  "생성 표면의 약 40%에서 차단 요소(blocker)가 발견되지 않음"

이것은 품질 신호가 아닙니다. 그것은 **녹색 체크 표시를 달고 있는 샘플링 아티팩트(sampling artefact)**일 뿐입니다. 가장 위험한 종류의 녹색입니다. 즉, 기술적으로는 참이지만 실질적으로는 무의미한 종류의 녹색 말입니다.

만약 여러분이 관측성 (Observability) 관련 작업을 해본 적이 있다면, 이 상황이 뼈아플 정도로 익숙할 것입니다. 이는 본문(body)에 에러 페이지를 담아 반환하는 200 OK와 같습니다. 이는 단언(assertion)이 assert True로 되어 있는 100% 테스트 커버리지 (test coverage)와 같습니다. 이는 데이터베이스 대신 로드 밸런서 (load balancer)에 핑을 보내는 헬스 체크 (health check)와 같습니다. 지표 (metric)는 실제였습니다. 하지만 그 지표가 암시하는 바는 허구였습니다. 우리에게는 콘텐츠 문제가 있었던 것이 아닙니다. 우리에게는 측정 (measurement) 문제가 있었던 것이며, 측정 문제는 다른 문제가 있다는 사실조차 알 수 없게 만들기 때문에 훨씬 더 심각합니다.

감사 신뢰도 보고서 (The Audit Confidence Report)

이 모든 과정에서 가장 유용한 결과물은 코드가 아니었습니다. 그것은 질문 자체를 바꾼 문서였습니다.

우리는 그동안 다음과 같이 물어왔습니다: "결함이 있는가?" 이는 탐지기가 신뢰할 수 있다고 가정하는, 이진법적이고 결함을 찾아내는 데 급급한 질문이었습니다.

우리는 질문을 다음과 같이 전환했습니다: "우리는 시스템의 얼마만큼을 실제로 측정하고 있는가, 그리고 '통과 (PASS)'라는 결과값을 얼마나 신뢰해야 하는가?"

이것이 말장난처럼 들릴 수도 있습니다. 하지만 그렇지 않습니다. 이것은 연기 감지기와, 배터리가 들어있는지 확인된 연기 감지기 사이의 차이와 같습니다. 구체적으로, 우리는 모든 감사 판정 (audit verdict)이 이전에는 결코 갖지 못했던 두 가지 요소를 동반하도록 만들어야 했습니다:

1. 커버리지 (Coverage) — 이 감사가 실제로 어떤 경로들을 점검했는가?
2. 신뢰도 (Confidence) — 해당 커버리지를 고려할 때, 사람이 이 판정에 어느 정도의 비중을 두어야 하는가?

40% 커버리지에서의 '통과' 판정과 100% 커버리지에서의 '통과' 판정이 동일한 초록색 픽셀로 나타나서는 안 됩니다. 이 둘이 똑같이 보이지 않게 되기 전까지, 다른 모든 개선 사항은 보여주기식 행위 (theatre)에 불과했습니다.

거버넌스 프로그램 구축 (Building a Governance Programme)

우리는 "고립된 생성기 (orphaned generators)들을 그냥 패치하자"라는 유혹적인 방식을 거부했습니다. 패치(Patching)야말로 애초에 22개의 경로가 생겨나게 만든 원인이었기 때문입니다. 대신 우리는 단계별로 진행했습니다. 각 단계는 배포 가능해야 했고, 명확한 범위 경계 (scope boundary)를 가져야 했으며, 무엇보다도 — 중요하게도 — 다음 단계의 역할을 수행하는 것이 금지되었습니다.

0단계 — 거버넌스 스파인 (The governance spine)

무엇인가를 수정하기 전에, 우리는 모든 경로가 처음부터 공유해야 했던 요소를 구축했습니다. 바로 시나리오, 도메인, 승인된 동반 표준 (companion standards), 로케일 (locale), 그리고 근거 (grounding)를 담고 있는 단일 불변 컨텍스트 객체인 ProgrammeGenerationContext입니다. 규칙은 간단합니다. 모든 생성기 (generator)는 이를 전달받으며, 어떤 생성기도 이를 재발명하지 않습니다.

0단계는 출력물(output)을 전혀 바꾸지 않았습니다. 우리는 바이트 패리티 테스트 (byte-parity tests)를 통해 이를 증명했습니다. 0단계는 컨텍스트가 전달되는 _방식_을 재라우팅했을 뿐, 컨텍스트가 포함하는 _내용_을 바꾸지 않았기에 생성된 산출물 (artefacts)은 전후가 동일했습니다. 의도적으로 지루하게 만든 것입니다. 불활성 (inert) 상태라고 신뢰할 수 없는 중추 (spine)는, 기존 버그를 수정하는 동안 새로운 버그를 유입시키는 중추가 될 뿐입니다.

우리는 또한 출처 (provenance)를 추가했습니다. 이제 모든 생성된 산출물은 다음을 포함합니다:

"generation_meta": { "route": "assignment_brief", "governance_version": "gv1", "at": "..." }

이 작은 도장 하나가 나중에 엄청난 양의 작업을 대신해 줍니다. 이는 "이 산출물은 깨끗하다"와 "이 산출물은 gv1 거버넌스 버전 하에, assignment-brief 경로를 통해, 이 시점에 _탄생_했다"의 차이입니다. 출처는 의견을 사실로 바꿉니다.

1단계 — 생성 정렬 (Generation alignment)

이제 우리는 5개의 레드 경로 (red pathways)를 중추 (spine) 위로 끌어올렸습니다. 고립되어 있던 생성기들 — 적용된 연습 문제 (applied exercises), 과제 요약 (assignment brief), 두 가지 재생성 경로 (regeneration paths), 루브릭 (rubric) — 은 녹색 경로들과 마찬가지로 동일한 공유 거버넌스 지침을 소비하기 시작했습니다.

여기서 발견된 가장 고약한 문제는 **피드백 루프 (feedback loop)**였습니다. 과제 재생성 (assignment-regeneration) 경로가 기존의 (오염된) 요약 (brief)으로부터 스스로를 다시 시딩 (re-seed)하고 있었기에, "수정을 위해 재생성하라"는 명령은 방금 저지른 실수와 같은 확신을 가지고 결함을 충실히 재현해냈습니다. 우리는 그 루프를 끊어냈습니다. 레드 경로는 앰버 (amber) 경로가 되었습니다. 아직 아무것도 그것들을 감사 (audit)하지 않았음에도 불구하고, 생성 시점에 거버넌스가 적용된 것입니다. 그 "아직"이 바로 2단계입니다.

2단계 — 탐지 확장 (Detection expansion)

생성 시점의 커버리지(Generation coverage)가 이제 감사(audit) 커버리지를 앞질렀는데, 이는 그 자체로 일종의 거짓말입니다 (콘텐츠에 거버넌스가 적용되었지만, 이를 증명할 수 없는 상태). 그래서 우리는 이전에는 보이지 않았던 표면들 — 적용된(applied), 요약된(brief), 루브릭(rubric), 핫스팟(hotspots) — 으로 탐지기(detector)를 확장하고, 타협할 수 없는 요소 하나를 추가했습니다: 자가 테스트(self-test) 기능이 포함된 경로 레지스트리 (pathway registry) 입니다.

def test_all_22_pathways_registered():
    assert set(PATHWAY_REGISTRY) == set(range(1, 23))
# 탐지 결정 없이 23번째 경로를 추가하면 → 테스트 스위트가 빨간색(실패)으로 변합니다.

이 테스트는 우리가 올해 구매한 가장 저렴한 보험입니다. 이 테스트 덕분에 "새로운 생성기에 대한 감사를 잊었다"는 상황이 운영 환경에서 발견되는 사고가 아니라, 컴파일 타임(compile-time)에 가까운 단계에서 발생하는 실패가 됩니다.

새로운 탐지기보다 더 중요했던 두 가지가 있습니다:

속성 (Attribution). 이제 모든 발견 사항은 _무엇이 실패했는지 / 어떤 아티팩트(artefact)인지 / 어떤 경로(pathway)인지 / 어떤 루트(route)인지 / 어떤 거버넌스 버전인지 / 레거시(legacy)인지_에 대해 답합니다. 위치를 특정할 수 없는 발견 사항은 버그 리포트가 아니라 불평에 불과합니다.

신뢰도 분리 (The confidence split). 우리는 (아래 참조) 신뢰도를 하나의 숫자로 통합하지 말아야 한다는 것을 고통스러운 경험을 통해 배웠습니다. 그래서 우리는 두 개의 축을 보고합니다:

• coverage_confidence — 우리가 얼마나 많이 측정했는가?
• content_confidence — 우리가 측정한 것이 얼마나 깨끗한가?

어떤 프로그램은 coverage: High, content: Low일 수 있습니다. 이는 "모든 곳을 살펴보았고 실제 문제를 발견했다"는 뜻이며, 이는 coverage: Low, content: High — "우리가 살펴본 모든 것은 괜찮았지만, 많이 살펴보지는 못했다" — 와는 완전히 다릅니다. 하나의 숫자로는 이 두 가지를 결코 동시에 나타낼 수 없습니다.

우리는 또한 오탐 (false positives) 에 대해서도 엄격했습니다. 왜냐하면 원래의 실패는 날카로운 경계선을 가지고 있었기 때문입니다. 정당한 표준 간의 교육적 비교 ("ISO 9001과 비교했을 때, Annex SL은 공유 구조를 제공하며...")는 결함이 아닙니다. 우리는 세 가지 버킷을 가진 분류기(classifier)를 재사용했습니다 — A (거버넌스 역할을 하는 것으로 제시된 다른 표준: 실제 결함), B (제목/구조가 인코딩됨), C (비교/맥락적 내용). 오직 A만이 경고를 울릴 수 있습니다. 이를 잘못 처리하면 엔지니어들이 탐지기를 무시하도록 훈련하게 되는데, 이는 탐지기가 없는 것보다 더 나쁩니다.

Phase 3 — Remediation expansion

Phase 3 — Remediation expansion (Remediation 확장)

Remediation(교정) 없는 탐지는 그저 기분만 더 나쁘게 만드는 정교한 방법일 뿐입니다. 우리는 각 발견 사항(finding)을 Phase 1의 스파인(spine)을 통해 재생성되는 원클릭, 거버넌스 인식(governance-aware) 수정 사항과 연결했습니다. 따라서 수정 사항은 설계 단계부터(by construction) 깔끔하게 유지되며 gv1으로 재인증(re-stamped)되어, is_legacy 플래그를 false로 전환합니다. 탐지(Detect) → 수정(fix) → 재탐지-정화(re-detect-clean)로 이어지는 폐쇄 루프(closed loop)입니다.

이 단계는 또한 미묘한 구분을 강제했습니다. 응용 연습(Applied exercises)은 연습용일 뿐이며, 과제 지침(assignment briefs)과 루브릭(rubrics)은 자격 증명(credential-bearing)을 포함합니다. 따라서 응용 교정(applied remediation)은 각 연습 항목별로 제자리에서 재생성되며, 버전 업데이트(version bump)나 SME(전문가)의 승인(sign-off)이 필요하지 않습니다. 이는 성적 산출물(graded artefacts)보다 의도적으로 가볍게 설정된 정책입니다. 엔진은 동일하지만, 영향 범위(blast radius)가 다릅니다. "균일하게 만들자"는 요구에 저항한 것은 옳은 결정이었습니다. 영향 범위를 무시하는 균일함은 그저 중앙 집중화된 리스크일 뿐입니다.

그리고 우리는 Phase 2의 부채를 상환했습니다. 이제 교정 사항은 캐시된 감사 보고서(cached audit report)에 **직접 기록(writes through)**됩니다. 왜냐하면 포트폴리오가 오래된 캐시(stale cache)를 읽고 있다는 사실을 발견했기 때문입니다(한 프로그램에서 캐시된 행에는 3개의 발견 사항이 표시되었으나, 새로운 감사에서는 9개가 표시되었습니다. 이는 대시보드가 거짓을 말하게 만드는 정확한 괴리입니다).

Phase 4 — Enforcement (강제 적용)

이 단계는 게시(publish) 동작을 변경할 수 있는 유일한 단계이며, 의도적으로 매우 좁게 설정되었습니다. 도메인 외 표준(off-domain standard)을 **지배적(governing)**인 것(Category-A 발견 사항)으로 제시하는 학습자 대상 산출물은 게시를 차단하는 강력한 차단 요소(hard publish blocker)가 되었습니다:

_BLOCKER_KEYS = {"courses", "qa", "signoff", "assignment",
                 "module_exams", "final_exam", "governance"}  # ← 신규

경계 조건(boundary conditions)은 엔지니어링적 판단이 살아있는 지점입니다: