2026년 모델 위험 관리: 개정된 기관 간 지침에 대한 은행가 가이드

2026년 4월 MRM 가이드라인 변경 사항

2026년 4월 17일, 연방준비제도, FDIC, OCC는 모델 위험 관리를 위한 보다 명시적으로 위험 기반의 원칙 중심 프레임워크로 SR 11-7, OCC 2011-12, FIL-22-2017 및 관련 BSA/AML 발행물을 폐지했습니다.

이것은 단순한 기술적 업데이트가 아닙니다. 이는 모델이 은행의 의사 결정에 중심적인 역할을 하며, 모델 위험은 신용 또는 시장 위험과 동일한 심각성으로 관리되어야 한다는 더 넓은 관점을 반영합니다.

은행 내부 실무자에게 이는 구체적인 기대치 세트로 전환됩니다. 즉, 인벤토리는 중요도에 따라 계층화되고, 통제는 비례적으로 적용되며, 수명 주기는 처음부터 끝까지 방어 가능해야 합니다.

기존 스택에서는 인벤토리 마이그레이션, 검증 템플릿 재작성, 새 모니터링 파이프라인, 문서 새로 고침, 공급업체 모델 온보딩, 감독 기관이 이제 원칙적으로 범위 내로 취급하는 GenAI 및 에이전트 시스템에 대한 병렬 작업 흐름 등 2~3분기 스프린트 작업에 해당합니다. 모든 작업 흐름은 프로젝트, 변경 티켓, 감사 노출입니다.

진정한 질문은 "이 가이드라인에 대한 규정 준수를 어떻게 구축할 것인가?"가 아닙니다. "다음 가이드라인 변경과 그 다음 변경을 프로그램이 아닌 구성 작업으로 만드는 플랫폼 결정은 무엇인가?"입니다.

새로운 MRM 프레임워크가 실제로 요구하는 것

2026년 개정은 통제 재작성이라기보다는 통제 적용 방식의 재분할입니다. 실무자에게 중요한 다섯 가지 변화가 있습니다.

1. 위험 기반 맞춤 설정 — 모든 모델은 내재된 위험, 노출 및 목적을 반영하는 계층에 속해야 합니다. Tier-1 중요 모델은 전체 수명 주기 감독을 받습니다. 하위 계층은 비례적이고 가벼운 통제를 받지만, 이는 계층화 자체를 입증할 수 있는 경우에만 해당됩니다.
2. 수명 주기 사고 — 개발, 검증, 배포, 모니터링 및 폐기는 하나의 관리 체인입니다. 감독 기관은 핸드오프 지점에서의 스냅샷이 아닌, 모든 링크에 걸쳐 계보를 기대합니다.
3. 효과적인 도전 — 도전 모델, 결과 분석, 벤치마킹 및 민감도 테스트는 일회성 메모가 아닌 버전 관리되고 재현 가능해야 합니다.
4. 지속적인 모니터링 — 성능 드리프트, 데이터 드리프트 및 안정성은 중요도에 따라 매핑된 임계값으로 지속적으로 추적되어야 합니다.
5. AI에 대한 원칙 확장 — GenAI 및 에이전트 시스템은 공식적으로 범위 외이지만 원칙을 상속합니다. 감독 기관 및 내부 감사는 이미 LLM 기반 인수 심사 보조원, AML 분류 에이전트 및 고객 대면 공동 작업자에 MRM 기대치를 유추하여 적용하고 있습니다.

공통된 흐름: 증거는 사후에 재구성하는 것이 아니라 모델 구축 방식의 부산물로 생성되어야 합니다. 이는 정책 문제가 아니라 플랫폼 문제입니다.

우리의 접근 방식

우리는 규제 의도를 당연하게 받아들입니다. 가이드라인을 논쟁하기보다는 그것이 암시하는 운영 모델에 집중합니다.

• 은행은 위험 계층화, 비례성, 효과적인 도전을 수동이 아닌 시스템적으로 어떻게 만들 수 있을까요?
• 우수한 거버넌스 증거는 일상적인 모델 작업에서 자동으로 어떻게 생성될 수 있을까요?
• 어떤 종류의 플랫폼 결정이 다음 가이드라인 업데이트를 다분기 프로그램에서 구성 변경으로 바꿀까요?

이 기사의 나머지 부분에서는 Databricks의 참조 아키텍처를 설명합니다. 이는 단일 관리형 하위 시스템에서 이러한 요구 사항을 충족하도록 설계되었습니다. 실제로는 MRM이 제거하려는 단편화를 다시 생성하지 않고는 이러한 요구 사항을 포인트 솔루션 모음에서 안정적으로 구성할 수 없기 때문입니다.

은행이 Lakehouse에서 이러한 원칙을 운영하는 방법을 볼 수 있도록 개정된 MRM 기대치를 구체적인 Databricks 기능에 매핑합니다.

MRM을 위한 Databricks 참조 아키텍처

아래 아키텍처는 "하나의 계보 그래프"를 슬로건 이상으로 만드는 것입니다. 모든 수명 주기 단계는 Unity Catalog의 관리형 객체로 해결됩니다. 동일한 기본 요소가 클래식 ML과 GenAI에 사용되므로 MRM 팀은 두 개가 아닌 하나의 프레임워크를 운영합니다.

네 개의 계층, 하나의 하위 시스템

아키텍처 앵커

거버넌스 계층은 마지막에 추가되는 것이 아니라 다른 모든 계층이 기록하는 것입니다. 이것이 등급 변경이 마이그레이션이 아닌 메타데이터 업데이트가 되는 이유이며, 검사관이 단일 시스템에서 단일 답변을 얻는 이유입니다.

ML 수명 주기를 MRM 증거에 매핑

각 수명 주기 단계는 새로운 가이드라인이 기대하는 특정 종류의 증거를 생성합니다. Databricks 아키텍처는 이러한 증거를 일반 작업의 구조화된 부산물로 전환합니다. 마지막에 별도의 규정 준수 패스가 아닙니다.

개별 기능은 포인트 도구로 조립할 수 있습니다. 아키텍처의 핵심은 Databricks에서 이들이 하나의 계보 그래프라는 것입니다. 심사관은 "이 모델을 훈련시킨 데이터는 무엇이며, 누가 검증했고, 어떻게 드리프트되었으며, 어떤 프로덕션 결정에 사용되었는가?"라는 질문이 단일 탐색으로 해결된다는 점을 의문을 제기했습니다. 이는 팀 간 증거 수집 연습이 아닙니다.

주요 거버넌스 패턴

5.1 메타데이터로서의 중요도 티어링, 마이그레이션이 아님

레지스트리의 모든 모델은 중요도 티어, 비즈니스 라인, 지침 버전, 할당된 검증자, 마지막 검증 날짜와 같은 구조화된 태그를 가집니다. 이 태그는 장식이 아니라 액세스 정책, 모니터링 임계값 및 포트폴리오 수준 MRM 대시보드에서 읽습니다.

감독관이 중요도 정의를 개선하거나 내부 정책이 변경될 때 티어가 변경됩니다. 이 아키텍처에서는 티어 변경이 태그 업데이트이며, 몇 분 안에 적용되어 모든 다운스트림 제어에 표시됩니다. 재플랫폼화, 파이프라인 재작성, 문서 재작성은 필요하지 않습니다.

5.2 ABAC를 통한 비례성 강제 적용

비례성은 지침의 핵심 원칙이며 역사적으로 증명하기 가장 어려운 부분입니다. Databricks에서는 티어 태그에 연결된 속성 기반 액세스 규칙이 됩니다.

실제로는 Unity Catalog 객체에 대한 간단한 ABAC 정책과 유사합니다. 예를 들어:

• Tier-1 중요 모델: 프로덕션으로 승격하려면 독립적인 MRM 검증자 그룹의 승인이 필요합니다. 이중 통제가 강제되며 권장되지 않습니다.

• Tier-2 표준 모델: 팀 리더와 검증자가 승인할 수 있습니다. 감독이 덜하지만 감사 가능합니다.

• Tier-3 저중요도 모델: 모델 소유자가 자신의 워크스페이스 내에서 승격할 수 있습니다. 모니터링 임계값이 완화되고 문서 요구 사항이 줄어듭니다.

은행은 비례성이 어떻게 작동하는지 설명하는 정책 문서가 필요하지 않습니다. 액세스 제어 로그가 모든 모델, 모든 승격에 대해 감사 보존 기간 동안 이를 설명합니다.

실제로는 Unity Catalog 객체에 대한 ABAC 정책 로직으로 직접 변환됩니다:

IF model.tier = 'Tier1'

THEN require_approver_role IN ('MRM_Validator', 'Model_Risk_Committee')

AND require_dual_control = TRUE

동일한 티어 태그는 사용자 정의 코드 없이도 더 엄격한 모니터링 임계값과 더 짧은 검증 주기를 유도할 수 있습니다. 은행은 비례성을 설명하기 위해 별도의 정책 문서가 필요하지 않습니다. 액세스 제어 로그와 구성이 이를 모델별, 승격별로 입증합니다.

5.3 정보 아키텍처로서의 MRM 카탈로그

깔끔한 카탈로그 계층 구조는 가장 과소평가된 거버넌스 결정입니다. 작동 가능한 패턴은 인벤토리와 증거를 모델 자체와 분리합니다:

• 인벤토리 카탈로그 — 모델 메타데이터, 검증자 승인, 인벤토리 오버레이, 검증자 큐 테이블을 보유합니다.

이 카탈로그의 주요 테이블은 간단한 패턴을 따릅니다:

• models.inventory — 티어, 소유자, 지침 버전, 의도된 사용 및 종속 프로세스와 같은 필드를 가진 모델 버전당 한 행.

• models.validation_log — 검증자 ID, 검증 범위, 발견된 문제 및 잔여 위험 등급과 함께 model_version_id로 키 지정된 검증 이벤트당 한 행.

• 클래식 ML 카탈로그 — 신용, AML, 사기, 자본 모델에 대한 비즈니스 라인별 스키마.

• GenAI 카탈로그 — LLM 엔드포인트 및 에이전트, 1급 모델로 등록되고 도구 레지스트리가 포함됩니다.

• 모니터링 카탈로그 — Lakehouse Monitoring에서 생성된 드리프트, 성능 및 공정성 메트릭 테이블.

• 증거 카탈로그 — 챌린저 실행, 검증 아티팩트, 모델 카드, 폐기된 모델 아카이브.

이 분리를 통해 MRM 리더십은 기본 학습 데이터에 대한 액세스를 노출하지 않고도 증거 및 모니터링에 대한 읽기 전용 액세스를 부여할 수 있습니다. 이는 시험 준비에서 흔히 발생하는 문제입니다.

단일 프레임워크 하의 클래식 ML 및 GenAI

은행은 두 가지를 동시에 실행합니다. 수십 년간의 MRM 관행에 의해 관리되는 PD 모델과 아직 아무도 관리 방법을 파악하지 못한 LLM 기반 AML 분류 보조 도구입니다. 전통적인 본능은 두 번째 유형의 모델에 대해 두 번째 프레임워크를 구축하는 것입니다. 이는 비용을 두 배로 늘리고, 감사 범위를 두 배로 늘리며, 불일치를 보장합니다.

Databricks에서는 클래식 ML과 GenAI가 동일한 레지스트리, 동일한 수명 주기 단계, 동일한 증거 패턴을 공유합니다. 모델 유형에 따라 필요한 경우 계층별 기능이 추가됩니다.

감독관이 GenAI에 MRM 원칙을 확장할 때(이미 하고 있는 일), 우리는 두 번째 프레임워크를 구축하지 않습니다. 첫 번째 프레임워크를 적용합니다.

세 가지 구성 요소, 하나의 플랫폼

데이터 과학자 및 모델 개발자 — 무단으로 코너를 자르지 않는 속도

• 추적, 계보 및 기능 등록이 자동화된 거버넌스 노트북 환경에서 작업합니다. 규정 준수 체크박스가 나중에 추가되는 것이 아닙니다.

• AutoML 및 Agent Bricks를 사용하여 기준선 및 에이전트 패턴을 빠르게 반복합니다. 모든 반복은 기록되고 재현 가능합니다.

• 승격, 모니터링 및 문서화가 동일한 워크플로에 내장되어 있어 별도의 팀에 인계할 필요 없이 더 빠르게 출시할 수 있습니다.

MRM 및 독립 검증자 — 전체 컨텍스트로 검토

• 모델을 생성한 정확한 학습 데이터, 기능 버전 및 코드에 대한 읽기 전용 액세스 — 데이터 복사본 없음, 최신 상태 유지.

• 챌린저 및 벤치마크 실행이 챔피언과 함께 버전 관리됩니다. 민감도 분석은 요청 시 재현 가능합니다.

• 승인 자체는 모델 버전에 연결된 레지스트리의 1급 아티팩트입니다. 이메일 스레드에 첨부된 메모가 아닙니다.

• Databricks 앱은 큐, 댓글, 승인, 에스컬레이션 등 구조화된 검토 워크플로를 제공하며 모두 감사 가능합니다.

리스크 및 규정 준수 리더십 — 포트폴리오 규모에서 방어 가능한 감독

• 인벤토리 전체의 단일 대시보드: 티어 분포, 검증 상태, 모니터링 상태, 미해결 문제 — 5개의 GRC 내보내기를 엮은 것이 아닙니다.

• 계층 및 소유권은 ABAC 정책으로 시행됩니다. 비례성은 정책 문서가 아니라 감사 로그가 있는 액세스 규칙입니다.

• 타사 및 GenAI 모델은 내부 모델과 동일한 방식으로 등록됩니다. 검사관이 발견하기 전에 적용 범위 격차가 표시됩니다.

검사관 RFI, 엔드 투 엔드

감독 검토의 대표적인 질문을 고려해 보십시오. "지난 12개월 동안 신용 PD 모델에 대한 검증 증거, 프로덕션 성능 및 드리프트 기록을 비즈니스 라인별로 슬라이스하여 보여주십시오."

단편화된 스택에서는 레지스트리, 데이터 레이크, BI 도구 및 GRC 시스템 전반에 걸쳐 2주간의 증거 수집 작업이 필요합니다. 각 시스템은 자체 ID 모델과 데이터 최신 상태를 가집니다. Databricks 참조 아키텍처에서는 다음과 같습니다.

• 검증 증거는 모델 버전에 연결된 인벤토리 카탈로그에 있습니다.

• 프로덕션 성능 및 드리프트 기록은 Lakehouse Monitoring에서 지속적으로 기록되는 모니터링 카탈로그에 있습니다.

• 비즈니스 라인은 모델의 태그이며 모니터의 슬라이싱 차원입니다.

• MRM 카탈로그의 Genie 공간은 행 수준 액세스 필터링을 통해 검사관이 권한이 있는 것만 볼 수 있도록 하여 자연어로 질문에 답합니다.

처리 시간이 몇 주에서 몇 시간으로 단축됩니다. 더 중요한 것은, 증거가 은행 자체 MRM 팀이 사용하는 것과 동일한 증거이므로 은행이 내부적으로 보고하는 내용과 검사관에게 보여주는 내용 사이에 불일치가 없다는 것입니다.

Databricks를 선택하는 이유 — 은행가의 다섯 가지 이유

1. 정책 변경은 메타데이터 변경이 됩니다 — 중요도 정의, 계층 임계값 또는 검증자 역할이 변경되면 Unity Catalog에서 태그 및 액세스 정책이 업데이트됩니다. 재플랫폼화, 파이프라인 재작성, 문서 새로 고침이 필요 없습니다.
2. 하나의 감사 추적, 일곱 개가 아님 — 데이터, 피처, 모델, 모니터링 및 문서는 하나의 서브스트레이트에 있습니다. 검사관 질문은 한 시스템에서 추적됩니다. 창고, 피처 스토어, 레지스트리, BI 도구 및 GRC 플랫폼을 넘나들지 않습니다.
3. 비례성은 시행 가능합니다 — Tier-1 모델에는 강력한 제어가 적용되고 Tier-3 모델에는 경미한 제어가 적용됩니다. 둘 다 동일한 ABAC 정책으로 시행됩니다. 비례성은 방어 가능하고 감사 가능한 사실이 됩니다.
4. GenAI는 평행 우주가 아닙니다 — 클래식 신용, AML, 사기, LLM 엔드포인트 및 에이전트 시스템은 동일한 평가, 모니터링 및 문서화 하네스를 갖춘 단일 레지스트리를 공유합니다. 적용 범위 격차는 숨겨진 것이 아니라 두 번째 도구 체인에서 볼 수 있습니다.
5. 커밋하기 전에 리허설할 수 있는 용량 — 빠른 프로토타입은 새로운 제어 패턴을 몇 주 안에 Tier-1 모델 하나에 테스트하고 MRM으로 개선한 다음 확장할 수 있음을 의미합니다. 규제 대응은 반복적인 엔지니어링이 됩니다. 이는 은행이 이미 다른 모든 것을 실행하는 방식입니다.

위험 관리 왼쪽으로 전환

2026년 지침은 은행에 "왼쪽으로 전환"하여 모델 수명 주기의 아주 초기에 위험 통제를 이동하도록 요구합니다. Spark Declarative Pipelines (SDP)를 사용하면 거버넌스가 수동 장애물이 아니라 데이터 흐름의 자동화된 부분이 됩니다. 모델이 구축된 후 감사하는 대신 SDP는 내장된 품질 기대치를 사용하여 규정을 준수하지 않는 데이터나 불안정한 피처가 모델 레지스트리에 도달하기 전에 차단합니다. 이를 통해 Medallion 아키텍처의 모든 자산이 설계상 규정을 준수하도록 보장하며, 개발의 자연스러운 부산물로 완전한 감사 추적이 생성됩니다. 이러한 파이프라인을 통해 "효과적인 도전"을 자동화함으로써 MRM 팀은 수동 데이터 수집에 소비하는 시간을 줄이고 고수준 감독에 더 많은 시간을 할애할 수 있습니다.

용량 논증

모든 규제 대응은 MRM 분석가, 모델 개발자 및 검증자의 유한한 풀에서 나옵니다. 해당 용량이 어떻게 사용되는지가 도움이 되는 플랫폼과 방해가 되는 플랫폼의 차이입니다. 통합된 서브스트레이트에서 세 가지 구조적 이점이 따릅니다.

• 통합으로 인한 용량 소모 중단 — 단편화된 스택에서는 부족한 MRM 용량이 통합 작업에 소모됩니다. 도구 간 인벤토리 조정, 모니터링 재구축, 도구가 이미 알고 있는 내용 재문서화 등이 포함됩니다.
• 사람들은 배관이 아닌 판단에 집중합니다 — 통합 플랫폼에서는 용량이 인간만이 할 수 있는 작업, 즉 중요도에 대한 판단, 모델 설계에 대한 효과적인 도전, 검사관과의 대화에 사용될 수 있습니다.
• 거버넌스는 프로젝트가 아닌 부산물이 됩니다 — 계보, 문서화, 모니터링 및 액세스 제어는 모델이 구축되고 배포되는 방식의 부산물로 생성됩니다. 마지막에 별도의 규정 준수 단계로 생성되는 것이 아닙니다.

Databricks에 대한 구조적 주장은 이 지침 변경을 더 빨리 처리한다는 것이 아니라(물론 처리하지만) 다음 지침과 그 다음 지침을 프로그램이 아닌 구성으로 전환한다는 것입니다.

조직적 가치 동인

은행의 AI 로드맵에 대한 주목할 만한 제약은 컴퓨팅이나 데이터뿐만 아니라 모델 위험 팀과 COE(Center of Excellence)의 인간적 역량입니다. 현재 지침이 "모델과 유사한" 시스템의 정의를 GenAI 및 에이전트 워크플로를 포함하도록 확장함에 따라 검증 요청의 양이 숙련된 실무자의 인력 부족을 초과할 것입니다.

"첫 번째 패스" 자동화 계층

모든 LLM 프로토타입에 맞춤형 수동 검토가 필요한 대신 Databricks를 사용하면 COE는 은행의 표준을 첫 번째 패스 자동화 계층으로 코딩할 수 있습니다.

• 셀프 서비스 분류 — 개발자는 MLflow 평가 레시피(독성, 근거, PII 누출)를 사용하며 자동으로 실행됩니다. 첫 번째 패스를 통과하지 못하는 모델은 COE 데스크에 도달하지 못합니다.
• 표준화된 증거 — 플랫폼이 공통 계보 및 문서화 스키마를 시행하므로 COE는 증거를 정리하는 데 몇 주를 소비하지 않습니다. 몇 시간 동안 검토하는 데 시간을 보냅니다.

실질적인 문제는 익숙합니다. 비즈니스 단위는 4주 안에 LLM 도우미를 출시하고 싶어하지만 COE는 6개월의 백로그가 있습니다.

Databricks는 COE가 제어권을 유지하면서 실행을 위임할 수 있도록 하여 이를 해결합니다. COE는 감독을 반복 가능하게 만드는 모니터링, 모델 카드 및 메트릭인 자동화 하네스를 제공합니다. 비즈니스는 GenAI 속도로 이동합니다. 2026년 지침은 병목 현상에서 가드레일로 전환됩니다.

요점

2026년 4월 지침은 이번 주기에 우리가 보게 될 마지막 감독 변화가 아닙니다. 에이전트 AI 원칙, 타사 모델 감독 및 기후 위험 모델링이 모두 진행 중입니다. 문제는 우리 플랫폼이 이러한 각 변화를 3분기 프로젝트 또는 4주 프로토타입으로 만드는지 여부입니다. 그 선택은 한 번 이루어집니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)