신용평가 시스템(CSS) 설계 — 스코어카드부터 ML 심사까지

들어가며
CSS의 역할 — 신청평점과 행동평점
스코어카드 개발 개요
전통 로지스틱 vs ML 모델
- 비교
- 규제 관점 — 설명가능성과 거절 사유
모델 서빙 아키텍처
- 실시간 심사 API와 피처 스토어
의사결정 엔진
- 전략 테이블
- 챔피언/챌린저
모델 모니터링
- PSI — 모집단 안정성
- 성능 모니터링과 조기 지표
기업여신과 내부등급법 — PD/LGD/EAD
공정성과 규제 준수
데이터 파이프라인
운영 사례 시나리오
설계 체크리스트
마치며
참고 자료

들어가며

앞선 글에서 LOS(Loan Origination System)의 파이프라인을 다루면서, 심사 단계의 핵심이 CSS라고 했습니다. CSS(Credit Scoring System)는 "이 차주에게 돈을 빌려주면 갚을 것인가"라는 질문에 확률로 답하는 시스템입니다. 수십 초 만에 끝나는 비대면 대출의 즉시 심사도, 기업여신의 등급 산정도, 결국 이 시스템이 내놓는 숫자 위에서 굴러갑니다.

CSS는 흥미로운 위치에 있는 시스템입니다. 통계학과 머신러닝이라는 모델링의 세계, 실시간 API와 피처 스토어라는 엔지니어링의 세계, 그리고 바젤 규제와 금융소비자보호라는 컴플라이언스의 세계가 한 지점에서 만나기 때문입니다. 모델을 잘 만들어도 서빙이 느리면 비대면 채널이 죽고, 서빙이 빨라도 설명가능성이 없으면 규제를 통과하지 못합니다.

이 글에서는 CSS의 역할 구분(신청평점/행동평점)부터 스코어카드 개발 방법론(WoE/IV), 전통 모델과 ML 모델의 비교, 서빙 아키텍처, 의사결정 엔진, 모니터링(PSI), 그리고 기업여신의 내부등급법까지 폭넓게 다룹니다. 본 글은 시스템과 방법론에 대한 기술 해설이며, 특정 금융상품 권유나 투자/법률 자문이 아닙니다. 규제 관련 내용은 일반론이므로 실제 적용 시 준법 부서 검토가 필요합니다.

CSS의 역할 — 신청평점과 행동평점

CSS가 산출하는 평점은 용도에 따라 크게 둘로 나뉩니다.

구분	신청평점 (Application Score)	행동평점 (Behavior Score)
시점	신규 신청 시점	계좌 보유 기간 중 주기적(월 단위 등)
입력	CB 정보, 신청서 정보, 소득/재직	자행 거래 이력, 상환 패턴, 한도 소진율
용도	승인/거절, 초기 한도/금리	한도 증액/감액, 갱신 심사, 조기경보
데이터 깊이	외부 정보 위주(자행 이력 없음)	내부 행동 데이터 풍부
모델 갱신 주기	상대적으로 김(1~2년)	짧음(분기~연 단위 재검증)

신청평점은 "처음 보는 고객"을 외부 정보만으로 판단해야 하므로 CB(신용정보기관) 데이터 의존도가 높고, 행동평점은 자행 거래 데이터가 쌓인 기존 고객을 다루므로 변별력이 훨씬 좋습니다. 시스템 관점에서는 신청평점이 실시간 API 호출형, 행동평점이 월배치 산출형이라는 워크로드 차이가 중요합니다. 이 둘을 하나의 서빙 인프라에 욱여넣으면 배치 부하가 실시간 심사 지연으로 번지는 사고가 나기 쉽습니다.

이 외에도 추심 우선순위를 위한 회수평점(Collection Score), 부정 사용 탐지를 위한 사기평점(Fraud Score) 등이 같은 인프라 위에서 운영되는 경우가 많습니다.

스코어카드 개발 개요

개발 파이프라인

전통적인 스코어카드 개발은 대략 다음 단계로 진행됩니다.

모집단 정의 -> 표본 추출 -> 불량 정의 -> 관찰/성과 기간 설정
   -> 특성(변수) 후보 도출 -> 구간화(Binning) -> WoE 변환
   -> IV 기반 변수 선정 -> 로지스틱 회귀 적합
   -> 점수 스케일링 -> 검증(KS, AUC, Gini) -> 전략 수립 -> 배포

먼저 불량(Bad)의 정의가 모든 것의 출발점입니다. 보통 "성과 기간 내 90일 이상 연체 발생"을 불량으로 정의하지만, 상품 특성에 따라 60일을 쓰기도 합니다. 관찰 기간(특성을 뽑는 과거 구간)과 성과 기간(불량 여부를 지켜보는 미래 구간)의 설정이 잘못되면 모델 전체가 무의미해집니다.

또 하나 중요한 것이 거절자 추론(Reject Inference)입니다. 학습 데이터는 "승인되어 실제 성과를 관찰한 고객"으로 편향되어 있습니다. 거절된 신청자들이 만약 승인되었다면 어떤 성과를 냈을지를 추정해 보정하지 않으면, 모델이 기존 승인 정책을 답습하는 순환 논리에 빠집니다.

구간화와 WoE/IV

연속형 변수(연소득, 부채비율 등)는 그대로 쓰지 않고 구간(bin)으로 나눈 뒤, 각 구간을 WoE(Weight of Evidence) 값으로 변환합니다. 수식은 다음과 같습니다.

WoE(i) = ln( (Good_i / Good_total) / (Bad_i / Bad_total) )

  Good_i     : i번째 구간의 우량(정상 상환) 건수
  Bad_i      : i번째 구간의 불량 건수
  Good_total : 전체 우량 건수
  Bad_total  : 전체 불량 건수

IV (Information Value)
  = SUM over i [ (Good_i/Good_total - Bad_i/Bad_total) * WoE(i) ]

IV 해석의 관례:
  0.02 미만      : 예측력 없음 (변수 제외)
  0.02 ~ 0.1     : 약한 예측력
  0.1  ~ 0.3     : 중간 예측력
  0.3  ~ 0.5     : 강한 예측력
  0.5 초과       : 과도하게 강함 -> 타깃 누수(leakage) 의심

WoE 변환의 실무적 이점은 분명합니다. 결측과 이상치를 별도 구간으로 흡수할 수 있고, 변수와 부도율의 비선형 관계를 단조(monotonic) 구간으로 정리할 수 있으며, 회귀 계수의 해석이 직관적이 됩니다. 구간화에서는 각 구간의 표본 수가 충분한지(통상 전체의 5% 이상), 구간별 불량률이 단조적으로 움직이는지를 확인합니다. 불량률이 들쭉날쭉한 구간화는 과적합 신호입니다.

IV가 비정상적으로 높은 변수는 기뻐할 일이 아니라 의심할 일입니다. 예를 들어 "현재 연체 여부" 같은 변수는 사실상 타깃의 동어반복이므로, 신청 시점에 알 수 있는 정보인지(time-of-decision availability)를 반드시 검증해야 합니다.

점수 스케일링

로지스틱 회귀의 출력(로그 오즈)을 사람이 다루기 쉬운 점수로 변환합니다.

Score = Offset + Factor * ln(odds)

  Factor = PDO / ln(2)
  Offset = BaseScore - Factor * ln(BaseOdds)

예: PDO(Points to Double Odds) = 40,
    기준점 600점에서 odds 50:1 이라면
  Factor = 40 / ln(2) = 57.7
  Offset = 600 - 57.7 * ln(50) = 374.3

  -> 점수가 40점 오를 때마다 우량:불량 오즈가 2배

이 스케일링 파라미터(PDO, 기준점, 기준 오즈)는 모델 버전과 함께 형상 관리해야 합니다. 점수 분포가 바뀌는 모델 교체 시, 전략 테이블의 컷오프를 함께 조정하지 않으면 승인율이 급변하는 사고가 납니다.

전통 로지스틱 vs ML 모델

비교

관점	로지스틱 + WoE 스코어카드	ML (XGBoost, LightGBM 등)
변별력 (AUC/KS)	기준선	통상 수 %p 우위 (데이터가 풍부할수록 격차 확대)
설명가능성	구간-배점표로 완전 투명	SHAP 등 사후 설명 기법 필요
거절 사유 산출	배점 차감 상위 항목으로 직접 도출	SHAP 기여도 기반 도출 (검증 필요)
단조성 제약	구간화 단계에서 자연 반영	단조 제약 옵션으로 강제 가능
운영/재학습	변경 영향 분석 용이	드리프트 민감, 재학습 거버넌스 필요
규제 수검	방법론이 정착되어 설명 부담 낮음	모델 리스크 관리 체계 입증 부담

규제 관점 — 설명가능성과 거절 사유

신용평가는 결과가 개인의 금융 접근성을 좌우하는 의사결정이므로, 규제는 "왜 그런 결정이 나왔는가"를 설명할 것을 요구합니다. 한국의 신용정보법 체계에서는 개인신용평가 결과에 대한 설명요구·이의제기 권리가 제도화되어 있고, 자동화 평가에 대한 설명 의무도 강화되는 추세입니다. 미국의 ECOA/Reg B처럼 거절 시 구체적 사유(adverse action reasons)를 통지해야 하는 법제도 같은 방향입니다.

실무적으로 이것이 의미하는 바는 명확합니다. 모델이 무엇이든, 신청 건 단위로 "점수를 깎은 상위 요인"을 일관되게 산출하는 파이프라인이 모델 서빙의 일부여야 한다는 것입니다. 스코어카드라면 배점표에서 바로 나오고, ML 모델이라면 SHAP 값 상위 음(-)의 기여 피처를 사유 코드로 매핑하는 레이어를 둡니다. 이때 사유 코드 매핑 테이블 자체도 버전 관리 대상입니다.

ML 도입 시 흔한 절충안은 하이브리드입니다. 승인/거절 경계의 의사결정에는 단조 제약을 건 해석 가능한 모델을 쓰고, ML 모델은 한도/금리 세분화나 챌린저(후보 모델)로 운영하면서 신뢰를 쌓는 방식입니다. 미국 연준의 SR 11-7로 대표되는 모델 리스크 관리 프레임워크 — 개발·검증·사용의 분리, 독립 검증, 문서화 — 는 어떤 모델을 쓰든 적용된다고 보는 것이 안전합니다.

모델 서빙 아키텍처

실시간 심사 API와 피처 스토어

                     +---------------------------+
 LOS 심사 요청 ----->|   스코어링 API 게이트웨이  |
 (고객ID, 신청정보)  +------+--------------------+
                            |
              +-------------+--------------+
              v                            v
     +----------------+          +------------------+
     | 피처 어셈블러   |          |  모델 서빙        |
     | - 온라인 스토어 |--피처-->|  - 모델 레지스트리 |
     |   조회 (ms)     |  벡터   |  - 버전 라우팅    |
     | - 실시간 CB 변환|          |  - 챔피언/챌린저  |
     +-------+--------+          +---------+--------+
             |                             |
             v                             v
     +----------------+          +------------------+
     | 온라인 피처     |          | 의사결정 엔진     |
     | 스토어 (KV)     |          | - 전략 테이블     |
     +-------+--------+          | - 컷오프/오버라이드|
             ^                   +---------+--------+
             | 동기화                       |
     +-------+--------+                    v
     | 오프라인 스토어 |          승인/조건부/거절 + 사유코드
     | (웨어하우스)    |          + 평점/피처 스냅샷 저장
     +----------------+

핵심 설계 포인트는 다음과 같습니다.

온라인/오프라인 피처 일관성: 학습은 웨어하우스(오프라인)에서, 서빙은 KV 스토어(온라인)에서 피처를 읽습니다. 같은 피처가 두 경로에서 다르게 계산되는 학습-서빙 왜곡(training-serving skew)이 CSS 품질 사고의 단골 원인입니다. 피처 정의를 코드로 일원화하고 두 스토어를 같은 정의에서 구체화(materialize)해야 합니다.
시점 정합성(Point-in-time correctness): 학습 데이터를 만들 때 "그 신청 시점에 알 수 있었던 값"만 써야 합니다. 피처 스토어가 시점 조회를 지원하지 않으면 미래 정보 누수가 발생합니다.
지연 예산: 비대면 심사의 전체 예산이 수 초라면, CB 조회가 대부분을 차지하므로 피처 조회와 추론에 허용되는 시간은 수백 ms 수준입니다. 피처 어셈블리는 병렬화하고, 모델은 추론 지연을 기준으로 선택합니다.
평점 스냅샷: 산출된 점수뿐 아니라 입력 피처 벡터 전체, 모델 버전, 전략 버전을 신청 건에 귀속시켜 저장합니다. 재현 가능성은 LOS와 마찬가지로 CSS에서도 제1원칙입니다.

의사결정 엔진

전략 테이블

점수는 확률일 뿐, 결정은 전략입니다. 의사결정 엔진은 점수와 정책 변수(DSR, 기존 부채, 소득 형태 등)를 조합해 승인/조건부/거절과 한도·금리를 결정합니다.

전략 테이블 예시 (개념):

  세그먼트: 급여소득자 / 신용대출

  점수구간    DSR 40% 이하       DSR 40~50%        DSR 50% 초과
  ---------  ----------------   ---------------   -------------
  720 이상    승인, 한도 1.0x    승인, 한도 0.7x    조건부(서류)
  650~719     승인, 한도 0.8x    조건부(서류)       거절
  600~649     조건부(보증부)     거절               거절
  600 미만    거절               거절               거절

  * 한도 배수는 소득 기반 산출 한도에 대한 곱
  * 모든 셀에 사유 코드와 전략 버전이 결합됨

전략 테이블은 룰 엔진에 외부화하고, 시행일자 버전 관리, 변경 전 시뮬레이션(과거 신청 재처리), 승인권자 결재를 거쳐 배포합니다. 모델 교체 없이 전략만 바꿔 승인율을 조정하는 경우가 실제 운영에서는 더 많습니다.

챔피언/챌린저

새 모델이나 새 전략은 전체 트래픽에 바로 태우지 않습니다.

섀도 모드: 챌린저는 점수만 산출해 기록하고 결정에는 관여하지 않습니다. 수개월 후 실제 성과와 비교해 변별력을 검증합니다.
트래픽 분할: 검증이 끝나면 무작위 일부(예: 10%)에 챌린저 전략을 적용해 승인율·부도율·수익성을 챔피언과 비교합니다. 금융 의사결정의 A/B 테스트는 소비자 보호 관점의 형평성 검토가 선행되어야 한다는 점이 일반 서비스와 다릅니다.
승격과 롤백: 챌린저 승격 시 전략 버전이 교체되며, 문제가 생기면 즉시 이전 버전으로 라우팅을 되돌릴 수 있어야 합니다. 모델/전략의 버전 라우팅 테이블이 이를 가능하게 합니다.

모델 모니터링

PSI — 모집단 안정성

모델은 배포되는 순간부터 늙기 시작합니다. 입력 분포가 개발 당시와 달라지는 것을 추적하는 대표 지표가 PSI(Population Stability Index)입니다.

import numpy as np

def psi(expected: np.ndarray, actual: np.ndarray,
        breakpoints: np.ndarray) -> float:
    """PSI = SUM (actual_pct - expected_pct) * ln(actual_pct / expected_pct)

    expected   : 개발(기준) 시점의 점수 표본
    actual     : 최근 운영 시점의 점수 표본
    breakpoints: 기준 표본의 십분위 등으로 만든 구간 경계
    """
    eps = 1e-6
    exp_pct = np.histogram(expected, bins=breakpoints)[0] / len(expected)
    act_pct = np.histogram(actual, bins=breakpoints)[0] / len(actual)
    exp_pct = np.clip(exp_pct, eps, None)
    act_pct = np.clip(act_pct, eps, None)
    return float(np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct)))

# 관례적 해석:
#   0.1 미만   : 안정
#   0.1 ~ 0.25 : 주의 (원인 분석)
#   0.25 초과  : 불안정 (재개발 검토)

PSI는 최종 점수뿐 아니라 주요 피처별로도 산출해야 원인을 추적할 수 있습니다. 점수 PSI가 튀었는데 특정 피처(예: 신규 유입 채널의 소득 분포)의 PSI가 같이 튀었다면, 모집단 변화의 진원지를 바로 짚을 수 있습니다.

성능 모니터링과 조기 지표

부도는 천천히 드러나므로(성과 기간 12개월 등), AUC/KS 같은 변별력 지표는 후행합니다. 운영에서는 다음을 조합합니다.

조기 연체율(early delinquency): 실행 후 3~6개월 내 30일 연체율을 빈티지(실행 월) 단위로 추적. 모델 열화의 가장 빠른 신호입니다.
등급별 부도율의 단조성: 등급이 나쁠수록 부도율이 높아야 합니다. 역전이 생기면 등급 체계가 무너진 것입니다.
오버라이드율: 심사역이 모델 결정을 뒤집는 비율이 높아지면 모델 신뢰가 깨졌다는 운영 신호입니다. 오버라이드 사유는 코드화해 모델 개선에 환류합니다.

기업여신과 내부등급법 — PD/LGD/EAD

가계 CSS가 점수를 내놓는다면, 기업여신과 규제자본의 세계는 세 가지 리스크 파라미터로 말합니다.

기대손실 EL = PD x LGD x EAD

  PD  (Probability of Default)   : 1년 내 부도 확률 (등급별)
  LGD (Loss Given Default)       : 부도 시 손실률 (회수율의 보수)
  EAD (Exposure At Default)      : 부도 시점 익스포저
                                   (미사용 한도 x CCF 포함)

규제자본(바젤 내부등급법)은 이 파라미터를 감독 공식에
대입해 위험가중자산(RWA)을 산출
  - FIRB(기초 내부등급법): PD만 자체 추정, LGD/EAD는 감독 값
  - AIRB(고급 내부등급법): PD/LGD/EAD 모두 자체 추정

시스템 관점에서 내부등급법(IRB)이 의미하는 것은 다음과 같습니다.

등급 시스템과 파라미터 추정 시스템의 분리: 차주 등급(부도 위험)과 거래 등급(회수 구조)을 분리해 관리하고, 각 등급에 장기 평균 기반의 PD/LGD를 캘리브레이션합니다.
부도 정의의 일원화: 바젤의 부도 정의(90일 연체 또는 상환 가능성 없음 판단)가 내부 시스템의 연체/기한이익상실 코드와 정확히 매핑되어야 합니다. 이 매핑이 어긋나면 추정치 전체가 흔들립니다.
데이터 이력 요건: 파라미터 추정에는 다년간(PD 5년 이상 등)의 부도·회수 이력이 필요하므로, 데이터 보존과 이력 무결성이 모델만큼 중요합니다.
CSS와의 관계: 가계 IRB에서는 리테일 풀(pool) 단위로 파라미터를 추정하는데, 풀 배정의 입력으로 행동평점이 쓰이는 식으로 CSS와 규제자본 체계가 연결됩니다. 또한 IFRS 9 기대신용손실 계산도 같은 파라미터 체계를 변형(12개월/전 생애, 경기 전망 반영)해 사용하므로, 파라미터 마트는 다목적 소비를 전제로 설계해야 합니다.

공정성과 규제 준수

신용평가 시스템 설계에서 컴플라이언스는 기능 요건입니다.

금지 변수: 성별, 출신 지역 같은 차별 소지가 있는 속성은 모델 입력에서 배제하는 것이 원칙이며, 더 까다로운 문제는 대리 변수(proxy) 입니다. 거주 지역 코드가 특정 집단의 대리 변수로 작동하지 않는지 상관 분석과 공정성 지표(집단별 승인율/오분류율 차이)로 점검합니다.
금융소비자보호 관점: 금소법 체계의 적합성·적정성 원칙과 설명의무는 판매 과정의 의무이지만, 심사 결과 고지(거절 사유, 금리 산정 근거)와 맞물려 CSS 출력의 설명 품질에 직접적인 요구를 만듭니다.
신용정보 관리: 신용정보법상 수집·이용 동의, 보유 기간, 파기 의무가 데이터 파이프라인의 설계 제약입니다. 특히 모델 학습 데이터셋에 들어간 개인신용정보의 보존 기한 관리가 자주 누락되는 지점입니다.
모델 거버넌스: 모델 인벤토리, 개발 문서, 독립 검증 보고서, 변경 이력, 정기 재검증 일정 — SR 11-7 류의 체계를 갖추면 국내외 어떤 수검에도 기본기가 됩니다.

데이터 파이프라인

원천                     수집/적재               가공/서빙
-----                    ---------               ---------
CB 조회 응답 ---------> 원천 보존 (불변)  ----> 피처 정의 코드
신청서/심사 결과 ------> 표준화 레이어    ----> 오프라인 스토어 (학습)
계정계 원장(상환이력) -> 일배치 ETL       ----> 온라인 스토어 (서빙)
행동 데이터(채널로그) -> 스트리밍 수집    ----> 평점/성과 마트
                                               (빈티지 분석, 모니터링)

원칙 몇 가지를 짚습니다.

원천 불변 보존: CB 응답 원문은 파싱 결과와 별도로 불변 저장합니다. 파싱 로직 버그가 발견됐을 때 원문이 없으면 복구가 불가능합니다.
성과 라벨 파이프라인: 모델 학습의 라벨(불량 여부)은 원장의 연체 이력에서 옵니다. 연체 코드 체계 변경, 채무조정 건의 처리 방식이 라벨 품질을 좌우하므로, 라벨 생성 로직 자체를 버전 관리합니다.
보존과 파기: 법정 보존 기한과 파기 의무를 데이터셋 단위 메타데이터로 관리하고, 학습 스냅샷에도 파기 정책을 전파합니다.

운영 사례 시나리오

가상의 사례 두 개로 운영 감각을 정리합니다.

사례 1 — 점수 분포의 갑작스러운 우상향. 월간 모니터링에서 신청평점 PSI가 0.31로 급등했습니다. 피처별 PSI를 보니 "최근 3개월 CB 조회 건수"의 분포가 크게 변했습니다. 원인은 대출비교 플랫폼 제휴 확대로 유입 모집단 자체가 바뀐 것이었습니다. 모델 자체의 결함은 아니지만, 새 모집단에서의 컷오프 적정성을 재검토하고, 빈티지 조기 연체율을 강화 관찰 대상으로 지정했습니다. 교훈: PSI 급등은 "모델 고장"이 아니라 "모집단 변화"의 신호인 경우가 많고, 대응은 전략 차원일 수 있습니다.

사례 2 — 챌린저 ML 모델의 함정. XGBoost 챌린저가 섀도 모드에서 챔피언 대비 KS 6%p 우위를 보여 승격을 검토했습니다. 그런데 거절 사유 산출 검증에서, SHAP 상위 음의 기여 피처가 "신청 시간대" 같은 설명 불가능한 변수로 잡히는 건이 다수 발견됐습니다. 해당 피처를 제거하고 단조 제약을 추가해 재학습하니 KS 우위는 4%p로 줄었지만 사유 코드 품질이 확보되어 승격했습니다. 교훈: 변별력 몇 %p와 설명가능성의 교환은 CSS에서 일상적인 의사결정입니다.

설계 체크리스트

마치며

CSS는 "좋은 모델"만으로 완성되지 않습니다. 시점 정합적인 피처 파이프라인, 재현 가능한 스냅샷, 설명 가능한 사유 산출, 안정성 모니터링, 그리고 전략과 거버넌스가 한 몸으로 움직여야 심사라는 의사결정이 신뢰를 얻습니다. 변별력 지표 몇 %p보다, 1년 뒤 감사 앞에서 "이 신청이 왜 거절되었는지"를 30초 안에 재현할 수 있는 체계가 CSS의 실력입니다.

다음 글에서는 대출 실행 이후의 세계 — 상환 스케줄, 연체 관리, 자산건전성 분류와 충당금, NPL — 를 다루는 사후관리 시스템을 살펴봅니다. 본 글은 기술 해설이며 금융상품 권유나 투자/법률 자문이 아님을 다시 밝힙니다.