[MRM 스레드] 에피소드 1 — MRM 은 검증이 아니라 아키텍처에 속한다

시리즈 “MRM 스레드” 1편. AI 추천 시스템의 규제 준수와 모델 리스크 관리를 실무적 관점에서 다룬다.

표준적인 모델 리스크 관리의 한계

일반적인 모델 리스크 관리(MRM, Model Risk Management)의 과정은 보통 다음과 같이 이루어진다.

개발 팀이 모델을 구현한다.
완료된 모델은 제2선(2nd Line of Defense)인 독립적인 MRM 전담 조직이나 검증 팀으로 넘어간다.
검증 팀이 성능, 안정성, 공정성, 규제 준수 여부 등을 테스트한다.
테스트를 통과하면 프로덕션에 배포하고, 미달하면 개발 팀으로 반려한다.
배포 이후에는 검증 팀이 정기적으로 모니터링 지표를 확인한다.

이러한 검증 우선(validation-first) 접근법은 검증이 모델 구현 이후에 이루어지는 구조다. 바젤(Basel) 규제 체계를 따르는 리스크 관리에서 보편적으로 사용되어 왔으며, 전통적인 신용 및 시장 리스크 모델링에 적합하다.

하지만 별도의 MRM 전담 조직을 운영하기 어려운 다수의 중소·중견 금융기관에서는 이와 방식이 다를 수 있다. 모델 개발 팀이 자체적으로 검증 패킷(성능 지표, 샘플 결과, 요약 문서)을 구성해 리스크 관리 부서나 컴플라이언스 팀, 위원회에 정기적으로 서면 보고하는 형태다. 검토 부서는 제출된 자료를 기반으로 승인을 내린다. 모델 업데이트 주기가 길고 규제 환경이나 고객 데이터의 분포 변화가 완만한 전통적 로지스틱 회귀 모델의 경우, 이러한 정기 서면 보고 주기로도 적절한 관리가 가능하다.

그러나 ‘모델’의 구조가 단일 모델에서 복잡한 에이전트 파이프라인 형태로 변모하면서 기존 체계만으로는 한계가 나타난다.

모델이 LLM 에이전트 시스템일 때 나타나는 변화

구축된 금융 추천 시스템은 단일 모델이 아니라 5개의 에이전트로 구성된 파이프라인이다.

Feature Selector: 고객에게 설명할 수 있는 **주요 추천 요인(Feature Attribution)**을 선별한다.
Reason Generator: 선택된 피처를 바탕으로 고객에게 전달할 추천 사유 문구를 생성한다.
Safety Gate: 생성된 추천 사유를 규제, 적합성, 환각 여부, 어조, 사실성 등의 기준으로 검증한다.
OpsAgent: 시스템 모니터링 수치를 분석하고 드리프트(Drift) 리포트를 해석한다.
AuditAgent: 감사 로그의 보관 사슬(chain-of-custody)이 연속적으로 유지되고 있는지 정기적으로 확인한다.

이러한 다단계 파이프라인 시스템을 과거처럼 문서 중심의 사후 “검증”만으로 관리하려 할 때 다음과 같은 문제가 발생한다.

오류 발생 지점의 다단계화: 환각 현상은 Reason Generator에서 발생할 수 있고, Safety Gate가 이를 누락할 수도 있다. 따라서 에이전트 개별 단위 검증뿐만 아니라 파이프라인 전체의 상호작용 검증이 동시에 요구된다.
비전통적 실패 모드: 프롬프트 인젝션, 상황 변화에 따른 지시 수행 실패, 유효 질의에 대한 부당한 응답 거절 등 기존 지표(AUC 등)로 설명하기 어려운 리스크가 발생한다.
시간적 안정성 가정의 변화: 기존 MRM은 검증 주기 내 모델의 상태가 안정적일 것이라고 가정한다. 그러나 외부 LLM API를 사용하는 시스템은 공급자의 업데이트 시점에 영향을 받으므로, “검증 시점의 모델”과 “프로덕션 환경의 모델”이 예기치 않게 달라질 수 있다.

충분한 규모의 MRM 팀이 있다면 이러한 문제를 수작업으로 관리할 수 있으나, 규모가 작은 금융기관에서는 현실적으로 인력만으로 대처하기 어렵다.

아키텍처 중심의 대안

대안은 MRM의 주요 요구사항을 아키텍처 자체에 내재화하는 것이다. 사후 문서 점검이 아닌 시스템의 구조적 불변성(structural invariance)으로 규제 준수를 보장하는 접근법이다. 소프트웨어 엔지니어링의 “오류 상태를 코드 상에서 표현할 수 없게 설계한다”는 원칙과 맥락을 같이 한다.

적용된 주요 원칙은 다음과 같다.

아키텍처 구조로 제공되는 설명 가능성: 7개 전문가 네트워크의 게이트 가중치(Gate Weight) 자체가 비즈니스 설명이 된다. 기여도를 사후 분석 기법(SHAP 등)으로 추정하는 것이 아니라, 모델 연산 과정에서 직접 도출되는 값이다. 이를 통해 SR 11-7의 “효과적인 문제 제기(effective challenge)” 요건을 충족한다.

통제 관문으로서의 챔피언-챌린저 체계: ModelCompetition.evaluate()는 테스트 결과를 출력하는 것에 그치지 않고 배포 승인 여부를 프로그래밍 방식으로 제어한다. 후보 모델 등록 시 자동화된 관문이 작동하며, 결정 과정은 HMAC 서명과 함께 감사 로그로 즉시 기록된다.

무결성이 보장되는 감사 추적: 예측 결과, 에이전트 판단, 승격 결정은 위변조 방지가 적용된 해시 체인(Hash Chain) 로그로 보존된다. 특정 엔트리 수정 시 이후의 모든 서명을 다시 계산해야 하므로 무결성이 유지되며, AuditAgent가 이를 정기적으로 확인한다.

실시간 환경에 연동된 공정성 모니터링: 5가지 보호 속성에 대한 공정성 지표(DI, SPD, EOD)는 별도의 샘플이 아닌 실제 프로덕션 예측 스트림 위에서 계산된다. 임계값 위반 시 즉시 경고가 발생하며 예측 차단 등 후속 조치로 이어진다.

명시적 제어 수단으로서의 킬 스위치(Kill Switch): 시스템 개입이 필요한 비상 상황은 수동 결재 프로세스가 아니라 즉각적인 API 호출로 제어된다. 파이프라인 전체 또는 특정 태스크를 즉시 비활성화할 수 있어 운영자의 개입 지연을 줄인다.

이러한 접근법을 택한 과정

다섯 가지의 내재화 원칙은 프로젝트 초기의 계획에는 없었다. 초기에는 모델 구축 후 분기 단위의 검증 리포트를 관련 부서나 위원회에 제출하는 전통적 방식을 예상했다. 그러나 에이전트 파이프라인을 테스트하는 과정에서 현실적인 한계에 직면했다.

Reason Generator 테스트 중 잘못된 추천 설명이 생성되는 오류가 발견되었을 때, “사후 검토자가 이 오류를 보고서만으로 잡아낼 수 있을까?”를 검토했다. 시스템 내부 과정이 생략된 출력 결과물만으로는 판단하기 어렵다는 결론에 도달했다. 이로 인해 “구조적으로 보장되는 설명 가능성”의 필요성이 제기되었다.

나머지 속성들도 기존 템플릿으로는 검증하기 어려운 구체적 실패 사례를 마주하며 도입되었다. 문제가 문서나 사후 과정으로 넘어가기 전에 아키텍처 수준에서 방어하고 기록하도록 설계가 수정되었다.

아키텍처 중심 접근과 MRM 조직의 역할

“아키텍처가 모든 것을 처리하므로 관리·감독 조직의 역할이 축소된다”는 해석은 오해다. 자동화된 구조가 도입되더라도 제2선(리스크 관리 및 컴플라이언스) 담당자의 필수적인 역할은 유지된다.

시스템에 반영된 아키텍처 특성(게이트 가중치의 설명력, 해시 체인의 무결성, 킬 스위치의 동작 등)이 의도대로 유지되는지 지속적으로 확인한다.
Safety Gate의 검열 기준이 잠재적 리스크를 충분히 방어할 수 있는지 정기적으로 재평가한다.
자동화된 관리 범위를 벗어나는 예외적 사건이나 임계치 위반 사례를 검토한다.
거버넌스 관리, 모델 인벤토리 유지, 감독 당국과의 커뮤니케이션을 주도한다.
주요 아키텍처 결정 과정에서 잠재적 리스크에 대해 개발 팀과 협의한다.

이 접근법은 관리·감독의 책임을 없애는 것이 아니라 검토 대상과 방식을 전환한다. 학습된 모델의 출력값을 사후 확인하는 것에서 나아가, 규제 준수의 핵심이 되는 시스템 불변성이 아키텍처 상에서 견고하게 작동하는지를 검증하게 된다.

2026년 규제 환경의 변화

다음과 같은 규제적 흐름이 구체화되고 있다.

AI 기본법 (2026년 시행): 고객 재무 결정에 중대한 영향을 미치는 금융 AI는 제35조 ‘고영향 AI’로 분류될 가능성이 높으며, 분류 시 영향 평가, 투명성 확보, 인적 감독 의무가 구체화된다. 분류 여부는 사용 맥락과 위험의 영향·중대성·빈도를 종합하여 사업자가 자율적으로 판단하도록 되어 있다.
EU AI 법안(AI Act): 투명성(제13조), 인적 감독(제14조), 견고성(제15조) 및 리스크 관리(제9조) 조항이 포함되며, EU 고객에게 서비스되는 시스템에도 적용된다.
금융소비자보호법 (KFCPA): 적합성 원칙(제17조) 준수 여부가 AI 추천 시스템과 관련하여 더 엄격하게 평가되고 있다.

감독 당국은 규제 준수가 형식적인 사후 문서화에 머물지 않고, 시스템 구조와 로그를 통해 증명 가능하기를 기대하고 있다. 실시간으로 의사결정이 이루어지는 환경에서 주기적인 서면 검토만으로는 한계가 지적된다.

아키텍처 기반의 접근법은 이러한 변화에 대응하기 위한 방안이다. 대규모 검증 조직을 두기 어려운 상황에서, 시스템 구조 자체가 규제 요건을 반영하고 감사 가능한 로그를 남기도록 하여 감독 당국의 요구에 부응한다.

이후 에피소드 안내

이번 편에서는 전체적인 방향성과 프레임을 설명했다.

이어지는 에피소드 2에서는 동기적 통제 관문으로서의 ‘챔피언-챌린저(Champion-Challenger)’ 구조를 상세히 다룬다. 모델 승격 오버라이드 패턴과 관련된 의사결정이 SR 11-7 규제 요건하에 어떻게 서명된 감사 로그로 기록되는지 설명한다.

에피소드 3에서는 에이전트 파이프라인의 “보관 사슬(Chain of Custody)” 구현 방식을 다룬다. 분할된 감사 테이블, 해시 체인(Hash Chain) 구조, 그리고 EU AI 법안 및 금융소비자보호법 요구사항이 작동하는 코드 경로로 어떻게 반영되었는지 살펴본다.

관련 원문 자료는 Paper 2 (Zenodo)를 참고할 수 있다. 세부적인 규제 조항과 시스템 기능 간의 매핑은 해당 논문의 6장에 정리되어 있다.