[MRM 스레드] 에피소드 6 — Modular Adaptability · 규제는 변해도 아키텍처는 변하지 않는다

“MRM 스레드” 6편이자 시리즈의 마지막 에피소드다. 에피소드 1부터 5까지는 이 시스템의 기반을 탄탄하게 쌓아 올리는 과정이었다. 아키텍처에 내재화된 MRM(에피소드 1), 챔피언-챌린저 관문(에피소드 2), 감사 로그 계층(에피소드 3), 설명 컬럼으로서의 내재적 XAI(에피소드 4), 검색 계층으로서의 RAG와 LanceDB(에피소드 5)가 그것이다. 이 탄탄한 기반 위에 자리 잡은 5개의 규제 산출물 생성기 — KoreanFRIAAssessor, FRIAEvaluator, AnnexIVMapper, PIAEvaluator, PublicDisclosureGenerator — 의 세부 설계는 Paper 2에 기술되어 있다. 이번 에피소드에서는 전체 스택에 대한 장기적인 핵심 명제를 다룬다. 즉, 규제는 끊임없이 변할 것이며, 아키텍처의 핵심은 그 변화에 대응하는 비용을 극적으로 낮추는 데 있다. 변화에 대응하는 비용이 높다면, 앞선 다섯 에피소드의 치열한 노력은 모두 의미를 잃고 만다.

12개월 후의 어느 시나리오

2027년 5월. 2026년 1월 22일에 원본 법안이 발효된 후, 1년 이상의 유예 기간을 거쳐 한국 AI 기본법 시행령이 막 발표되었다고 가정해 보자. 이 시행령은 원본 법안에 없던 두 가지 구체적인 의무를 새롭게 추가한다.

§35 영향평가 기준에 국경 간 데이터 노출 차원을 신설한다. 원본 7차원 평가에서는 전혀 다루지 않던 새로운 영역이다.
보존 의무가 변경된다. 기존의 평가 기록 5년 보존 의무에 더해, 평가에 전달된 원본 데이터의 별도 3년 보존 의무 및 특정 저장 데이터 암호화 요구사항이 추가된다.

여기에 독립적으로, EU 측에서는 AI Office가 Annex IV Section 5(학습 데이터 속성)에 대한 해석 지침을 발행하여, 학습 데이터 셋의 인구통계학적 분포 공개를 단순한 통계 요약값이 아닌 구체적인 형태로 요구하기 시작한다.

컴플라이언스가 곧 ‘수동 문서 작업’인 전통적인 시스템에서 이는 최소 6주짜리 대형 프로젝트다. FRIA 템플릿을 새로 작성해야 하고, EU FRIA도 고쳐 써야 하며, Annex IV Section 5의 기술 문서 서사도 재작성해야 한다. 보존 정책의 변경을 클라우드 운영팀과 조율해야 하고, 데이터 처리 SOP(표준 운영 절차)를 업데이트해야 하며, 컴플라이언스 팀의 교육 일정도 잡아야 한다. 리스크 팀은 실무 여력이 부족하여 이 중 일부 검증 과정을 어쩔 수 없이 건너뛰게 될지도 모른다.

하지만 컴플라이언스가 ‘감사 로그 위에서 동작하는 쿼리’로 정의되는 우리 시스템에서는, 산출물 생성기당 하나의 PR과 한 번의 설정 파일 변경이면 충분하다. 그 아래를 묵묵히 받치는 기반 계층은 전혀 요동치지 않는다.

이것이 바로 모듈식 적응성이 실무에서 의미하는 바이며, 앞선 에피소드 1~5의 방대한 아키텍처를 그토록 공들여 설계한 사전 투자 비용이 결코 아깝지 않은 이유다.

왜 한 개가 아니라 5개의 생성기인가

규제 계층을 설계할 때 가장 빠지기 쉬운 유혹은 단일 ComplianceReporter 클래스로 모든 것을 묶는 것이었다. 규제 식별자를 인자로 받아 적합한 보고서를 반환하게 하고, 관할권에 따라 매개변수화하는 방식이다. 겉보기에는 코드 중복을 피하는 DRY 원칙에 충실한 아름다운 설계처럼 보인다.

하지만 우리는 이 접근을 일찌감치 거절했다. 에피소드 4에서 KoreanFRIAAssessor와 EU의 FRIAEvaluator가 표면적인 평가 차원이 비슷해 보임에도 별도의 클래스로 엄격히 분리해 둔 것과 같은 맥락이다. 서로 다른 법적 기반을 가진 규제들이, 하나의 개정안이 다른 규제의 컴플라이언스 대응에 연쇄적인 파급 효과를 일으키는 결합을 공유해서는 안 되기 때문이다.

따라서 5개의 규제 산출물 생성기는 의도적으로 독립적으로 분리된 5개의 모듈로 존재한다.

KoreanFRIAAssessor — 한국 AI 기본법 §35, 7차원 영향평가, 5년 보존 의무
FRIAEvaluator — EU AI Act Art. 9, 5차원 위험 관리 프로세스 기록
AnnexIVMapper — EU AI Act Art. 11 + Annex IV, 12개 섹션 기술문서 증거 매핑
PIAEvaluator — 한국 개인정보보호법(PIPA) + GDPR Art. 35, 6-도메인 개인정보 영향평가
PublicDisclosureGenerator — 금융위 AI 가이드라인, 5개 섹션 분기 공시

각 모듈은 자신만의 평가 차원, 보존 규칙, 출력 포맷, 업데이트 주기를 독자적으로 소유하고 관리한다. 이들이 유일하게 공유하는 것은 그 아래의 기반뿐이다. 즉, 동일한 감사 로그, 동일한 XAI 설명 컬럼, 동일한 RAG 검색 인터페이스만을 공유한다.

앞서 가정한 2027년 5월의 규제 변화 시나리오가 현실이 되었을 때, 변경의 범위는 철저히 제한된다.

새롭게 추가된 §35 국경 간 데이터 노출 차원 → KoreanFRIAAssessor 내부에만 평가 메서드를 추가하고, YAML 설정에 등록한 뒤, 감사 로그 위에서 동작할 대응 쿼리만 작성한다. 나머지 4개의 생성기는 전혀 변경되지 않는다.
새롭게 추가된 §35 원본 입력 데이터 보존 의무 → KoreanFRIAAssessor 실행 시 전달되는 데이터에 대해 감사 로그의 log_data_access 테이블에만 보존 정책을 업데이트한다. 나머지 4개의 생성기는 변경되지 않는다.
Annex IV Section 5 인구통계학적 공개 명확화 → AnnexIVMapper 모듈에 학습 데이터 스냅샷 테이블에서 인구통계 분포를 끌어오는 쿼리를 추가한다. KoreanFRIAAssessor나 FRIAEvaluator는 전혀 영향을 받지 않는다.

모든 변화는 기반 계층(에피소드 3~5)이 충격 없이 흡수한다. 그 위에 얹힌 규제 모듈은 오직 해당 모듈 내부에서만 변경된다. 총 두 번의 PR만이 필요할 뿐이며, 어떤 변경도 모델 그 자체나 추론 경로를 건드리지 않는다.

여기서 “모듈”이 의미하는 것

생성기 모듈의 구체적인 구조를 명확히 짚고 넘어갈 필요가 있다. 업계에서 ‘모듈’이라는 단어가 워낙 느슨하고 모호하게 쓰이기 때문이다.

각 생성기 모듈은 철저하게 분리된 4개의 구성 요소로 이루어진다.

1. 범위 선언: 감사 로그의 어느 부분을 질의할 것인지(어느 log_* 테이블, 어느 시간 윈도우, 어느 슬라이스 필터를 적용할지)를 정의한다. 이는 하드코딩된 코드가 아니라 YAML 설정 파일로 관리된다. 따라서 시스템 재배포 없이 변경이 가능하며, 변경 내역 자체가 안전하게 로깅된다.

2. 집계 명세: 질의가 실질적으로 무엇을 계산하는지 정의한다. KoreanFRIAAssessor의 경우 7개의 스칼라 차원 점수와 각각의 증거 포인터를 계산한다. AnnexIVMapper의 경우 12개의 증거 묶음을 생성하며, 각각은 특정 감사 로그의 행이나 설정 스냅샷 파일의 포인터로 구성된다. 명세는 철저히 버전 관리되며 런타임에 해시값으로 해시 스탬프가 찍힌다. 따라서 모든 평가 기록은 자신을 산출해 낸 정확한 명세 버전을 꼬리표처럼 달고 다니게 되어, 추후 재구성이 완벽히 보장된다.

3. 직렬화 포맷: 규제가 요구하는 최종 출력 형태다. AI 기본법 §35는 순수 JSON, Annex IV는 구조화된 PDF와 JSON의 결합, 금융위 분기 공시는 Excel 호환 CSV를 요구한다. 문서를 받는 당국과 목적이 다르니 포맷이 다른 것은 당연하다. 이 5가지를 억지로 하나의 공통된 형태로 강제하려는 시도는, 결국 가장 까다로운 포맷의 복잡성을 모두에게 짐 지우는 최악의 선택이 된다.

4. 보존과 접근 정책: AI 기본법 §35는 5년간 WORM 보존을, EU AI Act Art. 9는 명시적인 고정 보존 기간은 없으나 불변성 유지를 요구하므로 기본 10년을 유지한다. PIA 출력 결과는 3년간 감사 통제 기반의 제한적 접근을 허용하며, 금융위 공시는 대중에 공개 게시된다. 각 정책은 코드 내부에 얽힌 행동 로직이 아니라, 스토리지 계층의 명시적 설정으로 관리된다.

이 4개의 독립적인 구성 요소가 바로 모듈을 진정한 모듈로 만드는 핵심이다. 어느 하나도 다른 요소의 구현 세부 사항에 의존하지 않기 때문에, 시스템의 나머지를 전혀 건드리지 않고도 특정 요소 하나만을 깔끔하게 교체할 수 있다.

기반은 요동치지 않는다

이 전체 아키텍처 접근법의 핵심 논지는 모듈 아래를 받치는 기반이 특정 규제에 종속되지 않는 ‘규제 독립적’ 특성을 지닌다는 점이다. 스택을 아래로 내려가며 살펴보면 그 의미가 명확해진다.

감사 로그 (에피소드 3). 7개의 테이블, HMAC 해시 체인, 다중 에이전트 컨센서스 중재. 이 테이블들 중 어느 것도 특정 국가의 “컴플라이언스” 요건이 무엇인지 알지 못한다. 오직 어떤 이벤트가 발생했는지만을 묵묵히 기록할 뿐이다. 그러나 바로 이 동일한 로그가 한국의 §35, EU의 Art. 9 및 Annex IV, PIPA, 그리고 금융위 공시에 모두 훌륭하게 서비스된다. 규제 대응 자체가 별도의 이벤트를 발생시키는 것이 아니라, 이미 기록된 객관적인 이벤트 위에서 실행되는 쿼리에 불과하기 때문이다.

XAI 설명 컬럼 (에피소드 4). 전문가 게이트 가중치, CEH 피처 기여도, 마할라노비스 OOD 신뢰도 플래그. 이들 역시 특정 투명성 의무 조항을 의식하고 만들어지지 않았다. 매 예측마다 구조화된 추론 근거 데이터를 산출해 내는 것은 아키텍처가 원래 그렇게 설계되었기 때문이며, 규제 생성기가 그 데이터를 소비하는 이유는 그것이 마침 자신들의 쿼리 로직에 완벽하게 부합하는 훌륭한 기반이기 때문이다.

검색 계층 (에피소드 5). LanceDB 위에서 구동되는 RAG 계층 또한 특정 규제를 모른다. 벡터 유사도 검색과 시간 여행 쿼리라는 동일한 인프라가 실시간 인적 감독 큐, 공정성 모니터링, 반사실적 평가자, 분기별 집계 생성기에 모두 차별 없이 제공된다.

이것이 바로 앞선 다섯 에피소드를 관통하는 철학의 궁극적인 결실이다. 시스템의 각 컴포넌트는 특정 규제의 가정을 내부에 단단히 엮어 넣지 않은 채 독립적으로 구축되었다. 새로운 규제가 도입되더라도, 기존의 단단한 기반 위에 새로운 모듈로 부드럽게 안착할 뿐, 거대한 시스템의 재설계를 요구하지 않는다.

우리가 대비하고 있는 세 가지 규제 변화

향후 18개월 안에 도래할 것으로 예상하는 세 가지 큰 변화와, 우리의 아키텍처가 그것들을 어떻게 흔들림 없이 흡수할 것인지에 대한 시나리오다.

1. 한국 AI 기본법 시행령의 구체화. 법안은 2026년 1월 22일에 발효되었고, 1년 이상의 조정 기간이 주어졌다. 머지않아 시행령을 통해 §31 투명성 의무, §34 고영향 사업자 의무, §35 영향평가의 구체적인 세부 사항이 발표될 것이다. 우리의 관점: 이 새로운 요구사항들은 KoreanFRIAAssessor의 새로운 평가 차원이 되거나, PublicDisclosureGenerator(공시)의 새로운 필드로 번역되거나, 혹은 둘 다에 적용될 것이다. 만약 새로운 감사 로그 필드가 필요해지더라도, 스키마 확장 및 LanceDB의 버전 관리 기능(에피소드 5) 덕분에 기존 쿼리를 전혀 깨뜨리지 않고 우아하게 추가될 것이다.

2. EU AI Act의 단계적 시행과 개정. EU AI Act는 2025년부터 2027년에 걸쳐 단계적으로 시행되고 있다. 각 단계마다 해석 지침과 일부 개정안이 쏟아져 나온다. 특히 AI Office는 범용 AI 의무와 Annex IV 기술문서 요구사항과 관련하여 매우 적극적인 행보를 보이고 있다. 우리의 관점: FRIAEvaluator와 AnnexIVMapper 모듈이 이러한 개정안을 새로운 쿼리 패턴과 새로운 증거 포인터 매핑으로 즉각 흡수할 것이다. 두 가지 모두 단순한 YAML 설정 파일의 변경으로 해결된다.

3. 미국 연방 AI 규제 프레임워크 도입. 미국 트럼프 행정부의 2026년 3월 국가 정책 프레임워크가 7대 원칙과 선점 전략을 제시했지만, 현시점 기준으로 포괄적인 연방 AI 규제법은 아직 통과되지 않았다. 만약 통과된다면, 금융 서비스와 같은 고위험 AI 시스템에 대한 명시적인 정보 공개 및 리스크 관리 요구사항을 규정할 것이 확실시된다. 이는 EU나 한국의 요구사항과 실질적으로 상당히 겹치겠지만, 관할권의 경계는 명백히 다를 것이다. 우리의 관점: 6번째 생성기 모듈인 USComplianceGenerator를 새롭게 등록하기만 하면 된다. 기반 계층은 한 치도 요동치지 않을 것이다.

핵심은 우리가 다가올 구체적인 변화의 내용을 완벽하게 ‘예측’했다는 데 있지 않다. 미래에 어떤 형태의 규제가 들이닥치더라도, 거대한 재설계 없이 유연하게 흡수할 수 있는 능력을 갖추었다는 점이 핵심이다. 기반 계층(에피소드 3~5)이 규제 불가지론적으로, 상층부의 규제 계층(이번 에피소드)이 철저한 모듈식으로 분리되어 설계되었기 때문이다.

모듈성이 약속하지 않는 것

이 아키텍처 접근법이 해결할 수 없는, 혹은 의도적으로 약속하지 않는 몇 가지 한계점도 분명히 짚고 넘어가야 한다.

컴플라이언스의 본질적인 내용 해석을 대신해 주지 않는다. KoreanFRIAAssessor에 새로운 차원을 추가하는 것이 기술적으로 쉬워졌다고 해서, 그 차원이 법적으로 무엇을 의미하는지, 어떤 증거 데이터가 적법한지, 알고리즘적으로 어떻게 계산해야 하는지를 이해하는 과정까지 생략되는 것은 아니다. 이 아키텍처는 지루하고 반복적인 배관 작업을 극적으로 절약해 줄 뿐, 고도의 전문성이 요구되는 법적 해석 작업까지 대신해 주지는 않는다. 컴플라이언스 팀과 FRM (금융 리스크 관리) 팀의 전문성은 여전히 필수 불가결하다.

시스템의 컴플라이언스 대응력을 모델 자체의 품질과 분리시켜 주지 않는다. 만약 기저의 모델 자체가 불공정한 편향이 가득한 예측을 내놓거나 불안정한 설명을 산출한다면, 아무리 훌륭한 모듈러 보고 체계를 갖추고 멋진 보고서를 찍어낸다 한들 그 본질적인 문제를 고칠 수는 없다. 에피소드 4(XAI)와 Paper 2 시리즈의 운영 스트림 위 공정성 모니터링이 바로 그 실질적인 측면을 다룬다. 모듈식 적응성은 철저히 ‘보고 및 증명’ 계층의 유연성을 다루는 것이며, 모델의 실체적 성능 계층의 문제는 전혀 다른 영역이다.

거대한 아키텍처 패러다임의 전면적인 전환으로부터 보호해 주지 않는다. 만약 규제 당국이 갑자기 “모든 금융 AI는 특정 알고리즘 프레임워크만을 사용해야 한다”(가능성은 낮지만 불가능한 일은 아니다), 혹은 “설명 가능성은 반드시 국가가 공인한 특정 사후 설명기를 통해서만 도출되어야 한다”(마찬가지로 가능성은 낮다)라고 강제한다면, 우리의 모듈식 기반 계층은 아무런 도움이 되지 못한다. 우리는 에피소드 4에서 명시적으로 ‘내재적 XAI’라는 아키텍처 방향성에 깊게 베팅했고, 그 베팅이 틀렸을 때 감수해야 할 대가는 분명히 존재한다.

모든 규제의 발전 방향을 선제적으로 지원하지는 못한다. 특히 개인정보 보호법 분야는 입력 피처가 처리되는 방식 자체의 구조적 재설계를 요구하는 방향(예: 동형 암호화, 연합 학습, 민감 정보에 대한 기기 내 로컬 추론 등)으로 빠르게 진화하고 있다. 현재 우리의 기반 계층은 이러한 고도의 암호화 기술들을 네이티브로 지원하지 않는다. 만약 이러한 방향이 필수 규제로 법적 구속력을 가지게 된다면, 우리는 상위에 모듈을 얹는 수준을 넘어 기반 계층 자체를 뜯어고쳐 확장해야만 할 것이다.

6개의 에피소드, 1개의 핵심 아이디어

지금까지 달려온 MRM 스레드 시리즈는 본질적으로 단 하나의 핵심 아이디어를 명확히 표현(Articulate)하려는 긴 시도였다.

“아키텍처 자체에 깊게 뿌리내린 살아 숨 쉬는 MRM 체계가, 분기마다 한 번씩 작성되는 정적인 문서 속에 갇힌 전통적인 MRM 체계보다 운영 비용이 극적으로 낮으며, 어떤 규제 당국의 질문 앞에서도 논리적으로 완벽하게 방어 가능하고, 급변하는 환경 속에서도 훨씬 더 오래 생존한다.”

에피소드 1은 모델이 복잡한 LLM 에이전트 파이프라인으로 진화할 때 왜 문서 기반의 정기적인 사후 검증 모델은 무너질 수밖에 없는지, 왜 처음부터 MRM을 아키텍처 레벨에 녹여내야 하는지 그 당위성을 밝혔다. 에피소드 2는 챔피언-챌린저 승격 관문을 통해 모델의 통제권이 어떻게 코드 경로 내부로 편입되는지 보여주었다 (이제 모든 승격 결정은 그 자체로 완벽한 감사 엔트리다). 에피소드 3은 감사 로그 계층의 심연으로 들어가, 7개의 분할된 테이블과 HMAC 해시 체인, 다중 에이전트 합의 중재를 통해 *“누가 감시자를 감시하는가?”*라는 근본적인 질문에 구조적으로 답했다. 에피소드 4는 한 계층 더 내려가, 내재적 XAI 아키텍처가 감사 로그에 단순한 예측 이벤트가 아닌 예측의 구체적 추론 근거를 담게 만들고, 그 위에 FD-TVS 운영 스코어링 철학을 얹는 과정을 다루었다. 에피소드 5는 다시 한 계층 위로 올라와 검색 인터페이스를 조명했다. RAG와 LanceDB가 정적인 감사 로그를 실시간 질의 가능한 거대한 지식 베이스로 탈바꿈시키며, 실시간 인적 감독, 연속적인 공정성 모니터링, 분기별 집계 워크플로우를 어떻게 가능하게 하는지 증명했다.

그리고 마지막 에피소드 6이 전체 논의의 고리를 닫는다. 하부의 기반 계층이 규제 불가지론적으로 설계되고, 상부의 규제 대응 계층이 모듈화되어 있기 때문에, 불가피한 규제의 변화가 들이닥치더라도 시스템 전면 재설계라는 재앙을 피할 수 있다. 그저 생성기 모듈 하나당 PR 한 번, 설정 파일 수정 한 번이라는 극히 제한된 비용으로 변화를 여유롭게 흡수하게 된다. 이 대미를 장식하는 마지막 주장이 실무에서 유효할 때만, 앞선 다섯 에피소드에서 쏟아부은 치열한 아키텍처 설계와 구현의 노력이 비로소 온전한 의미를 갖게 된다.

다음에 올 것에 대한 메모

이 거대한 아키텍처 작업의 자연스러운 연장선상에 있으면서도 아직 다루지 못한 두 가지 주제가 남아 있다.

반사실적 설명 가능성 (CCP, Paper 2에 간단히 언급됨) — 인과적 교사(Causal Teacher) 모델이 구축한 증폭된 방향성 비순환 그래프(DAG) 위에서 수행되는 Pearl의 인과 계층 3단계(Rung 3) 추론 기법이다. 우리의 아키텍처는 이를 기술적으로 충분히 지원할 수 있으나, 반사실적 설명이 규제 환경에서 어떤 법적 지위를 가지게 될지는 아직 명확히 확립되지 않았다.
관할권 간 교차 조율 보고 — 동일한 예측 이벤트에 대해 한국 규제 당국과 EU 당국 양쪽에 서로 다른 프레이밍으로 보고서를 제출해야 할 때, 이 5개의 생성기 모듈 위에서 쿼리 결과를 어떻게 모순 없이 조율하고 집계할 것인지가 그 자체로 또 하나의 거대한 주제가 된다.

이 두 가지 주제는 기반을 이루는 근원적인 작업들이 좀 더 성숙해지면 미래의 새로운 MRM 스레드 에피소드로 돌아올 가능성이 높다. 하지만 현재 시점에서는 지금껏 다뤄온 이 6부작 시리즈가 우리의 핵심 논지를 완벽히 대변한다.

아키텍처가 곧 MRM이며, MRM이 곧 아키텍처다.

소스: Paper 2 Zenodo DOI의 §5–§6 섹션에서 모듈러 생성기 설계 원칙과 기반 계층이 보장하는 불변의 속성들을 상세히 다루고 있다. 실제 구현 코드는 오픈소스 저장소의 core/compliance/ 디렉터리에서 확인할 수 있다.