MRM Thread The MRM Thread
Regulatory compliance and model risk management for AI recommendation systems, from a GARP FRM practitioner perspective.
[MRM 스레드] 에피소드 1 — MRM 은 검증이 아니라 아키텍처에 속한다
검증 우선의 MRM 체계는 모델이 LLM 에이전트 파이프라인으로 전환될 때 한계를 가진다. 다단계 실패 모드와 검증 주기 내 드리프트 등의 문제를 해결하기 위해, MRM 의무를 사후 검토 캘린더가 아니라 아키텍처 자체에 반영해야 하는 이유를 설명한다.
[MRM 스레드] 에피소드 2 — 관문으로서의 Champion-Challenger
월요일 새벽 3시 `_decide_promotion()` 안에서 일어나는 일 — 4단계 단락 평가 사다리(force-promote · bootstrap · fidelity floor · competition)가 2-4주짜리 MRM 위원회 주기를 수초로 대체하고, 모든 판정이 HMAC 서명 감사 엔트리를 남긴다.
[MRM 스레드] 에피소드 3 — 감사의 감사자들: Chain of Custody와 컨센서스 중재
7개 감사 테이블과 HMAC 해시 체인이 '기록의 연속성'을 보장한다면, 그 기록을 누가 검증하는가. 단일 LLM 판정의 함정과 다중 에이전트 컨센서스(α·β·γ) 구조, 소수 의견을 지우지 않는 설계, 그리고 AWS 병렬 투표와 온프렘 2-Round 심의가 서로 다른 방식을 택한 이유.
[MRM 스레드] 에피소드 4 — 설명이 아키텍처가 될 때: 내재적 XAI와 FD-TVS 스코어링
사후적 XAI(SHAP·LIME)는 운영 환경에서 불안정하며 모델과도 분리되어 있다. 우리는 PLE의 7개 이종 전문가 모델 위에서 게이트 가중치 자체를 설명으로 활용하는 방식을 택했다. 추론 경로의 자연스러운 결과물로 매 예측의 근거를 확보하는 구조다. FD-TVS는 그 위에 얹어진 운영 스코어링 철학이다.
[MRM 스레드] 에피소드 5 — RAG + LanceDB · 감사 인프라가 결국 검색 문제인 이유
감사 로그는 단순한 쓰기 전용 데이터가 아니다. 질의 가능한 지식 베이스다. 운영 및 감사 검색 인프라를 컬럼형, 버전 인식, 시간 여행 기능이 결합된 RAG와 LanceDB로 구성한 이유를 설명한다. 그리고 그 결과로 인적 감독, 운영 파이프라인 위에서의 공정성 모니터링, 분기별 집계 문제가 어떻게 해결되는지 살펴본다.
[MRM 스레드] 에피소드 6 — Modular Adaptability · 규제는 변해도 아키텍처는 변하지 않는다
한국 AI 기본법 시행령, EU AI Act 개정안, 미래의 미국 규제 프레임워크 — 이 모든 변화는 언젠가 현실이 될 것이다. 5개의 규제 산출물 생성기는 동일한 감사 로그 기반 위에서 동작하는 5개의 독립된 모듈이지, 매번 새로 작성해야 하는 5개의 문서가 아니다. 아키텍처의 모듈성이 왜 앞선 다섯 에피소드의 논의를 비로소 의미 있게 만드는 장기적인 베팅인지 살펴본다.