[MRM 스레드] 에피소드 4 — 설명이 아키텍처가 될 때: 내재적 XAI와 FD-TVS 스코어링

“MRM 스레드” 4편. 에피소드 3까지는 7개의 테이블, HMAC 체인, 다중 에이전트 합의 등 감사 로그 계층의 이야기를 다뤘다. 그렇다면 그 로그에 ‘무엇’을 기록할지는 누가 정하는가. 매 예측에 대한 설명, 기여도, 신뢰도 플래그는 어디서 오는 것일까. 이번 편에서는 그보다 한 계층 아래로 내려가 본다. 추론이 끝난 뒤 사후적으로 덧붙이는 모듈이 아니라, 아키텍처 설계 단계에서의 XAI 선택이 그에 대한 해답이라는 이야기를 전한다.

SHAP 도입안이 흔들린 이유

PLE 아키텍처로 넘어가던 시점에, 우리에게도 SHAP을 도입하자는 제안은 무척 자연스러웠다. 기존 온프레미스 환경에서 쓰던 ALS 기반 추천 시스템에는 설명 가능성이라는 개념 자체가 없었으니, 새 모델에 scikit-learn 기반의 설명기 라이브러리를 하나 붙이는 것이 가장 빠른 길로 보였다. 하지만 두 가지 문제가 이 제안을 흔들었다.

첫째는 Salih 등(2023)이 지적한 SHAP의 불안정성이었다. background 분포 설정 하나만 바꿔도 같은 예측에 대한 상위 기여 피처가 달라진다는 점은, 1년 후 동일한 예측에 대해 동일한 근거를 제시해야 하는 규제 환경에서는 도저히 받아들일 수 없는 결과였다. 일회성 연구라면 감수할 수 있겠지만, 15개월 후 감독관이 “그때 이 고객에게 왜 이 상품을 추천했는가?” 라고 물어왔을 때 설명기를 돌릴 때마다 답이 달라진다면, 컴플라이언스 측면에서 이는 엄청난 기술적 부채다.

둘째는 운영 비용의 한계였다. CPU 기반 AWS Lambda 위에서 분당 수천 건의 추천을 서빙하면서 매 예측마다 SHAP 연산까지 수행하면 예산 범위를 크게 벗어났다. 비용을 줄이기 위해 샘플링 방식으로 타협하면 “모든 예측에 대한 설명 가능성 확보” 라는 원칙이 무너지고, 사전 계산 방식으로 선회하면 보편적인 상황에 대응할 수 없게 된다. 어느 쪽을 택하든 컴플라이언스 대응이 모호해지는 길이었다.

세 번째 문제는 더 깊은 곳에 있었다. SHAP과 LIME은 기본적으로 모델을 블랙박스로 취급한다. 기여도 산출 결과는 모델 자체가 아닌, 입력값 주변에서 모델의 행동을 추정하는 ‘별도의 근사기’가 내놓은 추측일 뿐이다. 모델과 설명기가 서로 다른 답을 내놓는 일이 생기면—실제로 종종 발생한다—규제 당국이나 고객, 감독 위원회에 제시되는 것은 설명기의 결과다. 불투명한 MLP 내부에 실제 추론 근거가 존재한다고 가정하더라도, 외부에서는 영영 그 진짜 이유를 알 수 없게 되는 셈이다.

이러한 문제들이 겹치자 결론은 명확해졌다. 수년이 지난 후에도 같은 질문에 안정적으로 답해야 하는 규제 AI 시스템의 입장에서, 사후적 XAI는 언제든 무너질 수 있는 불안한 기반이었다.

다른 길 — 게이트 가중치 자체를 설명으로

그래서 우리는 다른 길을 찾기로 했다. 설명 생성 작업을 ‘추론 이후’가 아니라 ‘추론 과정 내부’에 두면 어떨까. 예측값이 나온 후 별도의 모듈을 통해 설명을 만들어 내는 것이 아니라, 예측을 수행하는 forward pass 과정에서 설명도 함께 도출되도록 하는 방식이다.

Heterogeneous Expert PLE (Paper 1 참조) 아키텍처는 DeepFM, Temporal Ensemble, Hyperbolic GCN, PersLay, Causal, LightGCN, Optimal Transport 등 구조적으로 서로 다른 7개의 shared expert 모델을 기반으로 설계되었다. 핵심은 각 전문가 모델이 단순한 신경망이 아니라 ‘고유한 수학적 연산을 수행하는 명명된 주체’라는 점이다. 무작위 초기값을 갖는 7개의 일반적인 MLP가 아니라, 각기 다른 귀납적 편향을 인코딩한 7개의 특화 모델인 것이다. CGC(Customized Gate Control) 모듈은 각 태스크의 예측을 이 전문가 그룹에 라우팅하며, 이때 명시적인 전문가별 가중치를 부여한다.

여기서 얻은 깨달음은, 그 게이트 가중치 자체가 훌륭한 ‘설명’이 된다는 점이었다. 시스템이 “고객 X의 상품 P 교차 판매 확률 0.78” 이라는 예측을 내놓을 때, 그 예측에는 “최근 지출 패턴(Temporal) 35% + 상품 계층 적합성(HGCN) 28% + 개입 추론(Causal) 15% + …” 이라는 게이트 가중치가 따라붙는다. 같은 순전파 과정에서 예측이 일어나는 바로 그 순간에, 이 예측이 어떤 근거로 도출되었는지 알려주는 것이다. 별도의 설명기를 호출할 필요가 없다. 라우팅 결정 내역이 곧 설명이 되어 함께 기록되기 때문이다.

이것이 바로 우리가 부르기 시작한 ‘내재적 XAI(Inherent XAI)‘의 개념이다. 설명 가능성은 UI 계층에서 덧붙이는 기능이 아니라, 아키텍처 설계 단계에서 결정되어야 한다는 철학이다.

매 예측마다 생성되는 세 가지 수준의 설명

단 한 번의 순전파 연산으로 예측 결과와 함께 세 가지 수준의 설명이 자동으로 적립된다. 이 세 가지 요소는 처음부터 한 번에 기획된 것이 아니라, 각기 다른 시점에 서로 다른 필요에 의해 추가된 계층들이다.

1. 게이트 가중치 (전문가별 기여도) 각 전문가 모델이 고유한 귀납적 편향을 인코딩하므로, 게이트 가중치는 비즈니스 관점에서 이해할 수 있는 서사로 직접 연결된다. “Temporal 모델 35% 반영” 이라는 말은 “은닉 유닛 47번 활성화” 가 아니라 “최근 지출 패턴을 주요하게 고려함” 을 의미한다. 추천 사유 생성 계층(Paper 2 참조)에서는 이를 고객 대면 설명의 1차 근거로 활용한다.

2. CEH 기여도 (Causal Explainability Head) 이는 게이트 가중치만으로는 설명이 부족했던 사례들이 누적되면서 추가된 두 번째 계층이다. “Causal 모델이 38% 기여했습니다” 라고 보여주어도, 감독관은 종종 “그렇다면 Causal 모델 내부의 어떤 피처가 그런 결론을 이끌어냈는가?” 라고 되묻곤 했다. 초기 v1 에는 태스크 로짓을 타깃으로 하는 헤드를 시도했지만, 결과가 전역 중요도 패턴으로 붕괴하는 문제가 발생했다(이는 부정적 결과인 Finding 13으로 따로 정리해두었다). v2에서 타깃을 평균 중심화 (demeaned target) 방식으로 변경하자 샘플별 변동성이 회복되었고, 비로소 Causal 전문가 모델 내부의 피처 단위 기여도를 안정적으로 추출할 수 있게 되었다. 결과적으로 게이트 가중치보다 한 단계 더 깊숙이 들어가는 구조가 완성된 것이다.

3. 인과적 잠재 공간 위 마할라노비스 OOD (신뢰도 플래그) 매 예측의 신뢰도를 평가하는 플래그다. Causal 전문가 모델의 잠재 공간에서 분포 내 기준점 대비 마할라노비스 거리를 계산하여, 매 예측마다 이진 신뢰도 플래그를 산출한다. 합성 OOD probe 결과, 5%의 오탐률 기준으로 100%의 탐지율을 보였다. 이 계층을 추가한 이유는, 아무리 설명이 안정적이라 할지라도 ‘학습되지 않은 영역(OOD)에서 도출된 설명’이라면 그 의미가 퇴색되기 때문이다. 이 플래그가 켜지면 고객 대면 설명의 수위를 낮추거나 아예 노출을 보류한다.

이 세 가지 계층은 모두 추론 시점에 계산되며, 그대로 감사 로그에 기록된다. 어떤 단계에서도 사후적인 설명기 호출을 요구하지 않는다. 추론 경로 자체가 부산물로서 설명을 산출해 내는 구조다.

왜 이것이 규제 대응의 토대인가

이 지점에서 앞서 구축한 규제 대응 계층과 연결된다.

Paper 2에서 다룬 5가지 규제 산출물 — 한국 AI 기본법 §35에 따른 영향평가, EU AI Act Art. 9의 위험 기록, Annex IV 기술문서 증거 매핑, PIPA 및 GDPR Art. 35의 개인정보 영향평가, 금융위 AI 가이드라인 분기 공시 — 은 모두 매 예측마다 생성되는 ‘구조화된 로그’를 소비한다. 사람이 수기로 작성하는 문서가 아니라, 로그에 대한 집계 쿼리의 결과물이다.

이러한 패턴이 가능한 이유는 매 예측 로그가 단순히 입력값과 출력값만 담는 것이 아니라, ‘구조화된 추론 근거’를 함께 포함하고 있기 때문이다. 만약 예측 기록이 (입력 벡터, 출력 점수, 타임스탬프) 형태에 그쳤다면, 어떤 쿼리를 작성하더라도 “모델이 왜 고객 Y에게 상품 X를 추천했는가?” 라는 질문에 답할 수 없다. 데이터 안에 그 답이 없기 때문이다. 5가지 규제 산출물을 쿼리만으로 생성할 수 있는 것은 로그가 추론 근거를 담고 있기 때문이며, 로그가 추론 근거를 담을 수 있는 것은 아키텍처 자체가 추론의 부산물로 근거를 출력하도록 설계되었기 때문이다.

내재적 XAI가 그 토대다. 감사 로그가 2층이라면, 5개의 규제 generator는 지붕에 해당한다. 만약 이 토대를 사후적 모델인 SHAP으로 바꾼다면 2층과 지붕이 모두 무너져 내린다. 매 예측 로그에서 구조화된 설명 컬럼이 사라지고, 집계 쿼리가 작동할 기반을 잃게 되며, 결국 규제 산출물은 다시 사람이 일일이 작성해야 하는 문서 작업으로 퇴보할 것이다.

EU AI Act Art. 13 (투명성 의무)과 한국 AI 기본법 §31 (투명성)은 단순히 ‘설명기를 보유하고 있다’는 사실만으로 충족되지 않는다. ‘어떤 예측에 대해서든 요건이 주어지면 안정적이고 재구성 가능한 설명을 즉시 제시할 수 있는가’가 핵심이다. 우리가 아는 한, 모델 재학습 주기를 거치면서도 이 약속을 확실하게 지킬 수 있는 유일한 아키텍처는 내재적 XAI뿐이다.

FD-TVS — 온프레미스의 한계에서 출발한 스코어링 재설계

이 시스템의 온프레미스 선례는 스코어링 단계에서 개별 상품 단위의 가중치를 사용했다. 각 금융 상품마다 정적인 가중치가 수동으로 설정되어 있었고, 신상품이 출시될 때마다 설정 파일을 직접 업데이트해야 했다. 스코어링 계층이 단순한 평면적 룩업 테이블이었던 셈이다.

6개월간 운영하며 누적된 관찰 결과, 이는 세 가지 측면에서 매우 취약했다. 첫째, 신상품 출시마다 수동 재설정이 필요했고, 간혹 설정이 누락되면서 “새 상품이 추천되지 않는” 사고가 발생했다. 둘째, 25세의 첫 예금 가입자와 60세의 고액 자산가가 동일한 가중치 표를 적용받는 것은 논리적으로 맞지 않았다. 모델 예측 단계에서 세그먼트 차이가 반영되었기를 기대하며 스코어링 계층을 중립적으로 둔 것이었지만, 실제로는 모델 예측 위에 세그먼트별 보정이 한 번 더 들어가는 것이 훨씬 자연스러웠다. 셋째, 생애 주요 이벤트 같은 고객의 행동 변화(예: 오랫동안 비활성 상태이던 계좌에 갑자기 소액이 연속으로 입금되는 상황)가 스코어에 영향을 미칠 메커니즘이 없었다. 행동 자체가 중요한 시그널임에도, 그 시그널을 수용할 공간이 없었던 것이다.

FD-TVS(Financial DNA Targeted Value Scoring)는 이러한 스코어링 계층을 전면 재설계한 결과물이며, 다음 세 가지 핵심 결정을 담고 있다.

첫째, 가중치의 단위를 상품에서 태스크로 변경했다. 가중치가 개별 상품이 아닌 교차 판매 의향, 이탈 위험, 적합성 등 태스크 단위로 부여된다. 따라서 신상품이 추가되더라도 기존 태스크 구조를 상속받기만 하면 별도의 가중치 재설정이 필요 없다. 앞서 다룬 XAI 게이트 가중치가 이 과정에 직접 전달되며, 태스크 선택 자체가 각 전문가 모델의 예측 라우팅 정보에 기반하여 이루어진다.

둘째, 세그먼트 인식하도록 했다. segment_task_weights 설정이 각 고객 세그먼트마다 태스크 가중치 위에 배수를 곱해준다. 이때 적용 범위를 1.01.5로 제한한 것은 매우 의도적인 결정이다. 1.0 미만을 허용하면 세그먼트 휴리스틱이 태스크 고유의 시그널을 억누르게 되어 모델이 1차 시그널 소스 역할을 해야 한다는 원칙이 깨진다. 반면 1.5를 초과하게 두면 세그먼트에 따른 임의의 조정이 모델의 예측 자체를 지배해버린다. 1.01.5라는 범위는 “세그먼트는 가중치를 보정하는 배수일 뿐, 모델의 예측을 덮어쓰는 수단이 아니다” 라는 명확한 입장을 대변한다.

셋째, 행동 인식하도록 했다. 특정 피처의 임계값을 넘기면, dynamic_weight_rules가 스코어링 시점에 해당 태스크의 가중치를 동적으로 끌어올린다. 이탈과 관련된 피처 수치가 급증하면 이탈 방지 태스크의 가중치가 올라가고, 비활성 계좌에 소액 입금이 연속해서 발생하면 예금 상품 태스크의 가중치가 높아진다. 주기적인 모델 재조정을 기다리는 것이 아니라, 고객의 행동 자체가 즉각적인 가중치 조정 시그널이 되는 ‘반응적 스코어링’ 체계다.

이 세 가지 규칙은 모두 pipeline.yaml 내에서 관리된다. 운영팀은 코드를 수정할 필요 없이 세그먼트 표를 조정하거나 행동 규칙을 추가할 수 있다. 이것이 중요한 이유는 단순하다. 스코어링 정책의 변경은 주 단위가 아니라 시간 단위로 배포되어야 하기 때문이다. 모든 변경 사항은 설정 파일 버전과 함께 감사 로그에 기록되며, 시스템의 다른 MRM 스택과 동일하게 ‘15개월 내 재구성 가능’이라는 규제 윈도우 원칙을 철저히 준수한다.

이러한 구조는 XAI와의 연결을 더욱 직관적으로 만들어준다. XAI 계층은 시스템에게 예측이 도출된 ‘이유’ (게이트 가중치 × CEH × OOD)를 설명해 준다. 그리고 FD-TVS는 **‘이 고객이 누구이며 현재 어떻게 행동하고 있는지’**를 고려하여 그 예측이 최종 점수 산정에서 얼마나 큰 비중을 차지해야 하는지를 결정한다. 두 계층 모두 입력값을 꼼꼼히 기록한다. 결과적으로 고객 대면 설명은 “최근 지출 패턴(Temporal 35%)과 상품 계층 적합성(HGCN 28%)을 근거로 추천드렸으며, 고객님이 속한 세그먼트의 선호도를 반영하여 추천 가중치가 조정되었습니다” 와 같은 단일 문장으로 자연스럽게 정리된다. 각 구성 요소가 감사 로그로부터 독립적으로 복구될 수 있기에, 완벽하게 방어 가능한 구조가 완성되는 것이다.

XAI 토대가 가능하게 하는 것들

에피소드 5와 6으로 이어지는 여정은 다음과 같다.

**에피소드 5 (RAG + LanceDB)**에서는 매 예측에 대한 설명 로그가 어떻게 대규모 쿼리 가능한 시스템으로 발전하는지 다룬다. 설명 컬럼 위에서 벡터 검색을 수행하면 “지난 분기에 Temporal 모델의 비중이 지배적이었고 동시에 OOD 플래그가 켜졌던 예측들을 모두 찾아라” 와 같은 질의에 단 몇 초 만에 답할 수 있다. 이러한 검색이 의미를 가지려면, 근본적으로 구조화된 설명 컬럼이 먼저 존재해야만 한다.

에피소드 6에서는 규제 환경이 변할 때 이 아키텍처가 어떻게 유연하게 대응하는지 다룬다. 새로운 규제가 도입된다는 것은 곧 ‘동일한 설명 로그 위에서 실행되는 새로운 집계 쿼리’가 추가됨을 의미한다. XAI 토대는 특정 규제에 종속되지 않으며, 상층부의 규제 계층은 필요에 따라 얼마든지 교체하고 확장할 수 있다.

자동화되지 않는 것

아키텍처 관점에서의 XAI 도입이 모든 것을 해결해주지는 않는다. 다음은 시스템이 대신해 줄 수 없는 영역이다.

점수의 타당성 검증: “이 고객에게 상품을 추천할 때 Temporal 모델이 35% 기여했다는 것이 과연 비즈니스적으로 타당한 설명인가?” 라는 질문은 여전히 추천 검토 위원회나 고객을 직접 응대하는 RM의 판단 영역이다. 시스템이 자동화한 것은 그 기여도가 투명하게 기록되고 안정적으로 재구성 가능하다는 점이지, 그 설명이 실질적인 비즈니스 의미를 가지는지 판단하는 것은 오롯이 사람의 몫이다.

경계 케이스의 해석: 7개의 전문가 모델이 모두 엇비슷한 비율로 기여할 때(즉, 게이트 엔트로피가 최대치에 가까울 때), 게이트 가중치가 제시하는 설명은 사실상 “모든 모델이 조금씩 다 영향을 미쳤다” 가 되어버린다. 정직한 사실이긴 하지만, 원인을 파악해야 하는 입장에서는 결코 만족스럽지 않은 답이다. 그래서 우리는 이러한 고엔트로피 예측을 별도의 해석 카테고리로 분류한다. ‘신뢰도가 낮거나 엔트로피가 높은’ 예측은 OOD 플래그 발동 여부와 관계없이 감독 계층에서 사람이 직접 검토하도록 에스컬레이션 처리한다.

아키텍처 lock-in: 지금까지의 모든 논의는 ‘이종 expert 모델 구조가 안정적으로 유지된다’는 가정에 기반하고 있다. 만약 미래의 업데이트에서 7개의 전문가 모델을 단일 transformer 아키텍처로 전면 교체한다면, 게이트 가중치 기반의 설명 메커니즘은 사라지게 되고 결국 사후적 XAI로 회귀해야만 한다. 이는 단순한 단기 구현체의 선택이 아니라, 시스템의 장기적인 아키텍처 방향성에 대한 굳은 약속이다. 에피소드 6에서 다룰 5개의 규제 생성기 역시 이 약속이 변함없이 유지된다는 전제 위에서 설계되었다.

다음 이야기

에피소드 5에서는 한 계층 더 위로 올라가, 매 예측의 설명 로그를 질의 가능한 시스템으로 만드는 ‘검색 계층’을 살펴본다. 운영 및 감사 인프라의 핵심 엔진으로 RAG와 LanceDB를 선택한 이유, 컬럼 기반 검색과 버전 인식 검색이 공정성 모니터링·인적 감독 에스컬레이션·분기별 집계에 어떤 혁신을 가져다주는지, 그리고 왜 감사 로그가 단순한 쓰기 전용 데이터가 아닌지에 대해 심도 있게 다뤄볼 예정이다.

소스: Paper 1 (Zenodo)의 Heterogeneous Expert 아키텍처 및 게이트 가중치 설명 가능성, Paper 3 (Zenodo)의 CEH 및 Causal Guardrail (마할라노비스 OOD). FD-TVS 스코어링 설정은 configs/pipeline.yaml의 scoring.segment_task_weights 및 scoring.dynamic_weight_rules 경로에서 확인할 수 있다.