[기초] Part 7. 배포가 끝이 아닙니다: 검증과 거버넌스, 모니터링

Part 6까지 오면서 우리는 좋은 모델을 만들고, 그 모델로 정책까지 설계하는 이야기를 했습니다. 그런데 금융에서는 여기서부터가 진짜 시작입니다.

Part 0에서 “모델은 배포하는 순간부터 노화가 시작된다”고, 그리고 “느린 데는 이유가 있다”고 짧게 말씀드렸는데, 이번 편이 바로 그 이유를 자세히 다루는 자리입니다. 다른 분야에서는 모델을 배포하면 결승선에 닿은 느낌이지만, 신용에서는 배포가 오히려 출발선에 가깝습니다. 만드는 데 몇 주가 걸렸다면, 그 뒤로 검증하고 감리하고 지켜보는 시간은 몇 개월, 혹은 몇 년입니다.

이 편에서 다룰 것은 이렇습니다. 배포 전에 다른 사람이 독립적으로 검증하는 일, 배포 자체를 조심스럽게 하는 일, 그리고 배포한 뒤에도 계속 지켜보다 노화하면 다시 학습시키는 일. 그리고 이 전부를 감싸는 문서와 거버넌스입니다.

만든 사람이 검증하면 안 됩니다

먼저 개념 하나. 모델 리스크입니다. 모델이 틀렸거나 잘못 쓰여서 생기는 손실과 평판 훼손, 규제 리스크를 통틀어 이렇게 부릅니다. 모델 하나가 충당금과 자본 계산까지 흘러가니(Part 0), 그게 틀리면 회사 전체가 흔들립니다. 그래서 금융에서는 모델을 리스크를 안고 있는 자산으로 취급하고, 이걸 관리하는 틀을 모델 리스크 관리(MRM)라고 부릅니다.

MRM의 원칙은 하나만 기억하시면 됩니다. 만든 사람과 검증하는 사람이 달라야 한다는 것입니다. 흔히 3선 방어라고 부르는데, 1선은 모델을 개발하고 운영하는 팀, 2선은 그와 독립된 검증과 리스크 관리, 3선은 내부감사입니다. “내가 만든 걸 내가 검증했더니 잘 나왔습니다”는 다른 분야에서는 통해도 금융에서는 통하지 않습니다. 만든 사람은 자기 모델의 약점을 보기 어렵거든요. 그래서 검증은 반드시 다른 눈이 합니다.

검증은 무엇을 보나

독립 검증자가 모델을 받으면 대략 다섯 가지를 봅니다.

첫째, 개념적 건전성입니다. 방법론과 가정과 변수가 애초에 말이 되는지를 봅니다. 성능이 좋게 나와도 “소득이 높을수록 부도 위험이 크다”처럼 상식에 어긋나는 관계가 들어 있으면, 그건 데이터의 우연이지 믿을 신호가 아닙니다.

둘째, 정량 검증입니다. 판별과 보정과 안정성을 숫자로 확인합니다. Part 5에서 본 그 세 축입니다. AUC만 좋고 PD는 틀리진 않았는지, 시간이 지나도 안정적인지.

셋째, 민감도와 스트레스 테스트입니다. 입력을 조금 흔들었을 때 점수가 출렁이지 않는지, 그리고 경기침체 같은 나쁜 시나리오에서 모델이 어떻게 거동하는지를 봅니다. 좋을 때만 잘 맞는 모델은 정작 필요할 때 무너집니다.

넷째, 벤치마킹입니다. 이 복잡한 모델이 더 단순한 모델이나 기존 모델보다 실제로 성능이 개선되는지 비교합니다. 복잡한데 성능도 크게 개선되지 않는다면, 그 복잡함은 그냥 리스크입니다.

다섯째, 재현성입니다. 같은 코드와 데이터로 다시 돌렸을 때 같은 결과가 나오는지. 재현이 안 되는 모델은 검증할 수도, 감사받을 수도 없습니다.

한 번에 켜지 않습니다: 섀도 모드

검증을 통과했다고 바로 실전에 투입하지도 않습니다. 신용 모델을 새로 도입할 때의 표준 안전장치가 섀도 모드입니다.

섀도 모드는 새 모델을 실제 의사결정에는 쓰지 않으면서 옆에서 점수만 같이 산출해보는 것입니다. 실제로는 기존 방식으로 승인하고 거절하되, 새 모델이라면 어떻게 판단했을지를 몇 달 동안 나란히 기록합니다. 그렇게 새 모델이 안정적으로 돌아가고 기존 결과와 크게 어긋나지 않는 걸 확인한 다음에야 진짜로 전환합니다.

비슷한 방식으로 챔피언과 챌린저를 병행 비교하기도 하고, 일부 고객에게만 먼저 켜보는 점진 롤아웃을 하기도 합니다. 어느 쪽이든 공통점은 하나입니다. 문제가 생기면 즉시 되돌릴 수 있게 롤백 계획을 미리 세워둔다는 것. “성능 좋은 모델을 빨리 켜자”가 아니라 “틀려도 안전하게 켜자”가 원칙입니다.

모델은 늙습니다: 모니터링과 재학습

배포하고 나면 끝이 아니라, 오히려 가장 긴 구간이 시작됩니다. Part 0에서 말씀드린 그 노화입니다. 2024년 데이터로 학습한 모델이 2026년 고객을 평가하는 동안 경기도, 금리도, 고객 행동도 바뀝니다. 분포가 이동하고, 모델은 서서히 낡습니다.

그래서 배포 후에는 여러 관점으로 계속 지켜봅니다. 먼저 입력이 학습 때와 얼마나 벌어졌는지를 PSI와 CSI로 봅니다. Part 5에서 본 그 안정성 지표입니다. 물론 성능도 추적합니다. 하지만 여기엔 신용 특유의 어려움이 있습니다. 부도 라벨이 12개월에서 24개월 뒤에야 확정되니(Part 0), 성능 저하를 실시간으로 알 수가 없습니다. 그래서 라벨이 쌓이는 대로 예측과 실제를 맞춰보는 백테스트를 늦게나마 돌리고, 그 사이에는 PSI 같은 선행지표로 이상 징후를 먼저 잡습니다. 예측 부도율과 실제 부도율이 맞는지, 특정 세그먼트만 유독 어긋나는지, 데이터 파이프라인이 조용히 깨지진 않았는지도 함께 봅니다.

그리고 모델이 노화했다고 판단되면 다시 학습시킵니다. 언제 재학습할지, 그 트리거도 미리 정해둡니다. 분포가 많이 이동했을 때, 성능이 떨어졌을 때, 정책이 바뀌었을 때, 새 상품이 나왔을 때. 중요한 건 재학습을 즉흥적으로 하는 게 아니라, 주기와 절차를 사전에 정의해두고 그 거버넌스를 따르는 것입니다. 모델을 바꾸는 것도 하나의 리스크이기 때문입니다.

문서가 곧 모델입니다

마지막으로, 모델에 관한 내용을 문서로 남기는 일입니다. 이게 의외로 핵심입니다.

모델 하나에는 개발 문서가 따라붙습니다. 무엇을 위해, 어떤 데이터로, 어떤 방법과 가정으로 만들었고, 한계는 무엇이며, 검증 결과와 모니터링 계획은 어떻게 되는지. 여기에 언제 무엇이 바뀌었는지 남기는 감사 추적과 버전 관리, 변경 관리가 더해집니다.

핵심은 이것입니다. 문서화는 모델을 다 만든 뒤에 하는 뒷정리가 아니라 개발 공정의 일부입니다. 감독당국이 “왜 이 모델입니까”라고 물었을 때, 내부감사가 “이 결정의 근거가 뭡니까”라고 물었을 때, 답이 되는 게 이 문서입니다. 문서로 설명되지 않는 모델은 성능이 아무리 좋아도 금융에서는 쓸 수 없습니다.

그래서, 느린 데는 이유가 있습니다

Part 0에서 스타트업식 “빨리 배포하자”가 여기서는 잘 안 통한다고, 느린 데는 이유가 있다고 했습니다. 그 이유에 대해 설명한 것이 이번 편입니다. 만든 사람과 다른 사람이 검증하고, 조심스럽게 켜고, 노화하는 걸 지켜보다 다시 학습시키고, 그 전부를 문서로 남기는 것. 번거로워 보이지만 이건 규제가 억지로 씌운 짐이 아니라 신뢰의 인프라입니다. 모델 하나가 한 사람의 신용을 판정하고 회사의 자본까지 흔드는 자리이기 때문입니다.

예측을 잘하는 것은 입장권이고(Part 5), 인과를 다루는 것이 실력이며(Part 6), 그렇게 만든 모델을 정직하게 검증하고 오래 지켜내는 것이 신뢰입니다. 다음 편에서는 이 신뢰의 또 다른 축, 왜 이렇게 판정했는지 설명할 수 있어야 한다는 해석가능성과 공정성, 규제로 이어가겠습니다.