Skip to content
Published on

여신 사후관리 시스템 — 연체, 충당금, NPL의 데이터 흐름

Authors

들어가며

앞선 글에서 LOS(대출의 탄생)와 CSS(심사의 두뇌)를 다뤘습니다. 그런데 여신 시스템에서 코드 줄 수가 가장 많고, 배치가 가장 복잡하고, 감사가 가장 자주 들여다보는 곳은 사실 실행 이후의 세계 — 사후관리(LMS, Loan Management System) 영역입니다. 대출은 실행되는 순간부터 수년간 매일 이자가 붙고, 매달 상환이 들어오고, 일부는 연체되고, 그중 일부는 부실채권(NPL)이 되어 상각되거나 매각됩니다. 이 모든 흐름이 원장, 회계, 충당금, 감독 보고와 정합성을 유지해야 합니다.

사후관리 시스템이 어려운 이유는 "시간"이 일급 시민이기 때문입니다. 모든 금액은 기준일자에 종속되고, 어제의 처리 결과가 오늘의 입력이 되며, 과거를 소급해서 고치는 순간 그 위에 쌓인 모든 계산이 무너집니다. 이 글에서는 상환 스케줄 생성부터 연체 관리, 자산건전성 분류와 충당금, 추심, NPL 처리, 채무조정, 감독 보고까지 — 대출의 "그 이후"를 시스템 관점에서 끝까지 따라가 봅니다.

미리 밝혀두면, 이 글은 시스템 아키텍처와 도메인에 대한 기술 해설이며 특정 금융상품 권유나 투자/법률 자문이 아닙니다. 규제·회계 관련 내용은 작성 시점의 일반적인 이해를 바탕으로 하므로, 실제 적용 시에는 반드시 준법감시·회계·법무 부서의 검토를 거치시기 바랍니다.

사후관리 도메인 지형도

대출 계좌가 실행된 뒤 관여하는 시스템들을 한눈에 보면 다음과 같습니다.

                  +--------------------------------------+
                  |        여신 원장 (Loan Ledger)        |
                  |  계좌 마스터 / 상환 스케줄 / 거래내역 |
                  +---+--------+--------+--------+-------+
                      |        |        |        |
        +-------------+        |        |        +--------------+
        v                      v        v                       v
+---------------+  +----------------+  +-----------+  +----------------+
| 이자/상환 처리 |  | 연체 관리      |  | 건전성    |  | 충당금 엔진     |
| - 일이자 계상  |  | - 버킷 전이    |  | 분류      |  | - IFRS 9 ECL   |
| - 수납/충당    |  | - 연체이자     |  | - 5단계   |  | - Stage 판정   |
| - 중도상환     |  | - 기한이익상실 |  | - FLC     |  | - 회계 연동    |
+---------------+  +-------+--------+  +-----------+  +----------------+
                           |
              +------------+-------------+
              v                          v
       +--------------+         +----------------+
       | 추심 시스템   |         | NPL 처리       |
       | - 콜 배분     |         | - 상각(write-off)
       | - 약속(PTP)   |         | - 매각(Pool 구성)
       | - 행위 규제   |         | - 채무조정 반영 |
       +--------------+         +----------------+
              |                          |
              +------------+-------------+
                           v
              +--------------------------+
              | 감독 보고 / 정보계        |
              | - 업무보고서, 연체율      |
              | - 신용정보 집중기관 등록  |
              +--------------------------+

각 박스가 별도 시스템일 수도, 하나의 LMS 안의 모듈일 수도 있지만, 데이터 흐름의 방향은 같습니다. 원장이 사실(facts)의 원천이고, 연체·분류·충당금·추심·보고는 모두 원장에서 파생됩니다. 파생 시스템이 원장과 다른 숫자를 들고 있는 순간부터 사고가 시작됩니다.

상환 스케줄 생성

실행(기표) 시점에 가장 먼저 만들어지는 산출물이 상환 스케줄입니다. 상환 방식은 크게 세 가지입니다.

방식매월 납입액원금 상환 패턴총이자주 용도
원리금균등일정초기엔 적고 후기에 증가중간주택담보, 가계신용
원금균등점차 감소매월 동일가장 적음기업 시설자금 등
만기일시이자만 납입만기에 전액가장 많음한도성, 단기, 전세자금

세 방식의 계산을 코드로 보면 다음과 같습니다. 금액 계산에는 반드시 decimal을 쓰고, 절사·반올림 규칙을 상품 조건으로 명시해야 합니다.

from decimal import Decimal, ROUND_DOWN, ROUND_HALF_UP

WON = Decimal("1")  # 원 단위 절사용

def round_won(amount: Decimal, mode=ROUND_DOWN) -> Decimal:
    """원 단위 처리. 절사/반올림은 상품 조건에 따름."""
    return amount.quantize(WON, rounding=mode)

def equal_installment(principal: Decimal, annual_rate: Decimal,
                      months: int) -> list[dict]:
    """원리금균등: 매월 납입액이 동일.
    납입액 = P * r * (1+r)^n / ((1+r)^n - 1), r = 월이율
    """
    r = annual_rate / Decimal("12")
    factor = (Decimal("1") + r) ** months
    payment = round_won(principal * r * factor / (factor - Decimal("1")),
                        ROUND_HALF_UP)
    schedule, balance = [], principal
    for seq in range(1, months + 1):
        interest = round_won(balance * r)
        principal_due = payment - interest
        if seq == months:               # 마지막 회차에서 끝수 조정
            principal_due = balance
            payment = principal_due + interest
        balance -= principal_due
        schedule.append({"seq": seq, "payment": payment,
                         "principal": principal_due,
                         "interest": interest, "balance": balance})
    return schedule

def equal_principal(principal: Decimal, annual_rate: Decimal,
                    months: int) -> list[dict]:
    """원금균등: 매월 원금 상환액이 동일, 이자는 잔액 기준."""
    r = annual_rate / Decimal("12")
    base_principal = round_won(principal / Decimal(months))
    schedule, balance = [], principal
    for seq in range(1, months + 1):
        interest = round_won(balance * r)
        principal_due = base_principal if seq < months else balance
        balance -= principal_due
        schedule.append({"seq": seq,
                         "payment": principal_due + interest,
                         "principal": principal_due,
                         "interest": interest, "balance": balance})
    return schedule

def bullet(principal: Decimal, annual_rate: Decimal,
           months: int) -> list[dict]:
    """만기일시: 매월 이자만, 만기에 원금 전액."""
    r = annual_rate / Decimal("12")
    schedule = []
    for seq in range(1, months + 1):
        interest = round_won(principal * r)
        principal_due = principal if seq == months else Decimal("0")
        schedule.append({"seq": seq,
                         "payment": principal_due + interest,
                         "principal": principal_due,
                         "interest": interest,
                         "balance": principal - principal_due})
    return schedule

실무에서 챙겨야 할 디테일이 몇 가지 있습니다.

  • 끝수 조정: 회차별 절사 오차가 누적되므로, 마지막 회차에서 잔액 기준으로 조정합니다. "마지막 회차 납입액이 다른 회차와 몇십 원 다른" 것은 정상이며, 이를 숨기려고 중간 회차를 건드리면 안 됩니다.
  • 일할 계산 규칙: 위 예시는 월 단위지만, 실제로는 납입일 사이의 일수(365/366, 윤년 처리)로 이자를 일할 계산하는 상품이 많습니다. 일수 계산 컨벤션(actual/365 등)을 상품 마스터의 속성으로 두어야 합니다.
  • 거치기간: 거치기간 중에는 이자만 납입하고 거치 종료 후 원금 분할이 시작됩니다. 스케줄 생성기는 거치 구간과 상환 구간을 별도 파라미터로 받아야 합니다.
  • 변동금리 재산정: 금리가 바뀌면 남은 회차의 스케줄만 재생성합니다. 이미 지나간 회차는 절대 다시 계산하지 않습니다 — 이 원칙은 뒤의 "함정" 절에서 다시 강조합니다.

상환 처리 — 정상, 중도, 일부

수납과 충당 순서

상환 처리의 핵심은 들어온 돈을 어디에 먼저 꽂을 것인가, 즉 충당 순서(appropriation order) 입니다. 일반적인 순서는 비용(법적 비용 등), 이자(연체이자 포함), 원금 순이지만, 약정과 내부 정책에 따라 달라질 수 있으므로 코드에 하드코딩하지 말고 상품/계좌 속성으로 외부화해야 합니다.

from decimal import Decimal

def apply_payment(received: Decimal, dues: dict) -> dict:
    """수납액을 충당 순서대로 배분. dues는 기준일 현재 미수 항목."""
    order = ["fees", "overdue_interest", "interest", "principal"]
    applied = {}
    remaining = received
    for bucket in order:
        due = dues.get(bucket, Decimal("0"))
        take = min(remaining, due)
        applied[bucket] = take
        remaining -= take
        if remaining <= Decimal("0"):
            break
    applied["unapplied"] = remaining   # 잔여액은 선수금 처리
    return applied

배분 결과는 회계 분개와 1:1로 대응되어야 하며(이자 수익, 원금 회수, 가수금 등), 잔여액(선수금)의 처리는 다음 회차 자동 충당인지 즉시 반환인지 정책으로 정해 둡니다.

중도상환

만기 전에 원금의 전부 또는 일부를 갚는 것이 중도상환입니다. 시스템 관점의 처리는 다음과 같습니다.

  • 전액 중도상환(상환 해지): 기준일까지의 일할 이자 + 원금 잔액 + 중도상환수수료를 산출해 수납하고, 계좌를 해지 상태로 전이합니다. 담보가 있다면 담보 해지(근저당 말소) 프로세스가 후속으로 연결됩니다.
  • 일부 중도상환: 원금 잔액이 줄어든 뒤 남은 스케줄을 어떻게 할지 고객이 선택합니다 — 회차당 납입액을 줄이고 만기 유지, 또는 납입액 유지하고 만기 단축. 어느 쪽이든 미래 회차만 재생성합니다.
  • 중도상환수수료: 통상 "중도상환 원금 x 수수료율 x 잔존기간/총기간" 형태의 슬라이딩 방식이 쓰이며, 면제 기간(예: 실행 후 3년 경과)과 면제 조건이 상품 속성으로 들어갑니다.
중도상환수수료 (예시 구조)

수수료 = 중도상환원금 x 요율 x (만기까지 잔여일수 / 대출 총일수)

예: 잔액 1억 원 중 5천만 원 상환, 요율 1.2%,
    총기간 1,095일 중 365일 경과 (잔여 730일)
  수수료 = 50,000,000 x 0.012 x (730 / 1,095)
         = 400,000원

자동이체와 수납 채널

상환 수납은 자동이체(CMS), 가상계좌, 창구, 앱 즉시출금 등 여러 채널로 들어옵니다. 채널마다 수납 확정 시점이 다르므로(자동이체는 출금 결과 파일이 도착해야 확정), "수납 접수"와 "수납 확정"을 상태로 분리하고, 확정 전 금액이 연체 판정에 잘못 반영되지 않도록 기준일 처리에 주의해야 합니다. 납입일이 휴일이면 다음 영업일로 이연되는데, 이연된 날까지는 연체로 보지 않는 휴일 규칙도 스케줄 엔진이 알아야 합니다.

연체 관리

연체 버킷과 단계 전이

납입일에 돈이 들어오지 않으면 연체가 시작됩니다. 운영은 연체 일수를 버킷으로 끊어 관리합니다.

연체 버킷 전이 (일배치가 매일 판정)

 정상(Current) --미납 발생--> 1~29일 (Bucket 1, 초기 연체)
      ^                          |
      | 전액 정상화              v
      +<----------- 30~59일 (Bucket 2)
      |                          |
      |                          v
      +<----------- 60~89일 (Bucket 3)
      |                          |
      |                          v
      +<-----?----- 90일 이상 (부도/Default 인식 구간)
                                 |
                                 v
                        기한이익상실(EOD: Event of Default)
                                 |
                                 v
                  전액 즉시 상환 의무 / 추심 강화 / NPL 트랙

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

  • 연체 일수의 단일 정의: 연체 일수 계산기는 시스템 전체에 하나만 존재해야 합니다. 추심 시스템과 충당금 엔진이 각자 일수를 계산하면 반드시 어긋납니다.
  • 부분 납부와 버킷: 3회차가 밀린 상태에서 1회차분만 납부하면 연체 기산일이 2회차 납입일로 이동합니다. "가장 오래된 미납 회차 기준"이라는 기산 규칙을 명확히 구현해야 합니다.
  • 버킷 전이 이력: 버킷의 현재값만 갱신하지 말고, 전이 이력(어느 날짜에 어느 버킷으로)을 append-only로 남깁니다. 빈티지 분석(roll rate: 버킷 간 이동률)이 리스크 관리의 핵심 입력이기 때문입니다.

연체이자 계산

연체가 발생하면 약정이자 대신(또는 더해서) 연체이자가 붙습니다. 한국 실무에서 일반적인 구조는 "약정금리 + 연체가산금리(상한 규제 있음)"이며, 연체이자율은 법정 최고금리를 넘을 수 없습니다.

연체이자 계산 (일반적 구조의 예시)

연체이자율 = MIN(약정금리 + 연체가산금리, 법정 상한)

(1) 기한이익상실 전: 연체된 "그 회차의 미납액" 기준
    연체이자 = 미납 약정 납입액 x 연체이자율 x 연체일수 / 365

(2) 기한이익상실 후: "원금 잔액 전체" 기준
    연체이자 = 원금 잔액 x 연체이자율 x 경과일수 / 365

예: 미납 납입액 100만 원, 약정금리 5%, 가산 3% -> 연체이자율 8%
    연체 40일이면
  연체이자 = 1,000,000 x 0.08 x 40 / 365 = 8,767원 (절사 규칙 적용)

기한이익상실 전후로 계산 모수 자체가 바뀐다는 점이 시스템 구현의 핵심입니다. 전이 시점이 하루 어긋나면 연체이자가 통째로 달라지므로, 기한이익상실 처리일은 배치 산출이 아니라 명시적 이벤트 레코드로 박제해야 합니다.

기한이익상실

기한이익상실은 "남은 기간 동안 나눠 갚을 권리(기한의 이익)"를 차주가 잃고 전액 즉시 상환 의무가 생기는 법적 이벤트입니다. 일반적으로 일정 기간 이상의 연체(약정상 통지 요건 포함), 담보 가치의 현저한 하락, 차주의 신용 악화 사유 등으로 발생하며, 발생 전 고객 통지(예고 통지, 도래 통지) 의무가 있습니다.

시스템 관점의 처리는 다음과 같습니다.

  1. 대상 추출 배치: 연체 일수·사유 조건을 만족하는 계좌를 후보로 추출
  2. 통지 발송과 회신 대기: 통지 이력을 법적 증빙 수준으로 보관(발송 일시, 수단, 반송 여부)
  3. 기한이익상실 확정: 이벤트 레코드 생성, 계좌 상태 전이, 연체이자 계산 모수 전환
  4. 후속 연동: 신용정보 집중기관 등록, 보증기관 사고 통지(보증부 대출), 추심 강화 트랙 진입

기한이익상실 이후 고객이 연체금을 전액 정상화하면 기한이익이 부활하는 경우가 있는데, 이 부활 처리(계산 모수의 원복, 스케줄 복원)는 상실 처리보다 구현 난도가 높고 버그도 많은 지점입니다. 부활 가능 조건과 횟수 제한을 정책으로 명확히 해 두어야 합니다.

자산건전성 분류 — 5단계

감독 규정상 금융회사는 보유 여신을 차주의 상환 능력과 연체 상태에 따라 5단계로 분류합니다. 이른바 자산건전성 분류이며, 한국 감독 체계의 전통적인 분류는 다음과 같습니다.

단계명칭통상적 기준(개략)의미
1정상연체 없음, 상환 능력 양호회수 확실
2요주의1개월 이상 3개월 미만 연체 등잠재 위험
3고정3개월 이상 연체, 회수 의문이나 담보 범위 내회수에 상당한 위험
4회수의문고정 중 담보 초과 부분 등회수 불확실
5추정손실사실상 회수 불능손실 확정적

두 가지를 주의해야 합니다.

  • 연체 일수는 출발점일 뿐: 분류는 연체 일수만으로 기계적으로 끝나지 않습니다. FLC(Forward Looking Criteria) 관점에서 차주의 미래 상환 능력(산업 전망, 재무 상태)을 반영해 하향 조정할 수 있고, 동일 차주의 다른 여신이 부실하면 함께 하향되는 교차 부실(cross-default 성격의 차주 단위 분류) 규칙도 있습니다.
  • 담보의 분할 분류: 같은 계좌라도 유효담보가액 이내 부분은 "고정", 초과 부분은 "회수의문"으로 쪼개어 분류하는 식의 금액 분할이 일어납니다. 분류 테이블은 계좌 단위가 아니라 계좌-구간(금액 단편) 단위로 설계해야 합니다.

분류 결과는 최저 적립률 기반의 감독 목적 충당금과 연결되고(정상 일정 비율, 요주의·고정·회수의문·추정손실로 갈수록 높은 비율), 회계 목적의 IFRS 9 기대신용손실과는 별도의 체계로 병행 운영됩니다. 시스템은 두 체계를 모두 산출하고, 통상 둘 중 보수적인(큰) 쪽이 재무에 반영되는 구조를 지원해야 합니다.

충당금 — IFRS 9 기대신용손실

3단계 모델

IFRS 9의 기대신용손실(ECL, Expected Credit Loss)은 "손실이 발생한 뒤 적립"하던 과거 발생손실 모형을 "미래 손실을 미리 추정해 적립"하는 모형으로 바꿨습니다. 핵심은 Stage 구분입니다.

IFRS 9 ECL 3단계

 Stage 1                Stage 2                  Stage 3
 (정상)                 (신용위험 유의적 증가)    (신용 손상)
 12개월 ECL 적립        전 생애(Lifetime) ECL     전 생애 ECL
 이자수익: 총장부금액    이자수익: 총장부금액      이자수익: 순장부금액
 기준                   기준                      (장부금액 - 충당금) 기준

 전이 트리거(예):
  Stage 1 -> 2 : 30일 이상 연체(반증 가능 추정),
                 신용등급의 유의적 하락, 워치리스트 등재 등 (SICR)
  Stage 2 -> 3 : 90일 이상 연체, 기한이익상실,
                 채무조정(신용 손상 인식) 등
  회복 방향    : 치유 기간(probation) 경과 후 상향
ECL 계산의 뼈대

ECL = SUM over t [ PD(t) x LGD(t) x EAD(t) x 할인계수(t) ]

  - Stage 1: t = 향후 12개월
  - Stage 2/3: t = 잔존 만기 전체 (Lifetime)
  - 거시경제 시나리오(낙관/기준/비관)별로 산출해 확률 가중
  - PD/LGD/EAD는 CSS·IRB 체계의 파라미터를 회계 목적으로 변형

시스템 구현 관점

  • SICR(신용위험의 유의적 증가) 판정 엔진: 30일 연체라는 양적 기준 외에 등급 하락 폭, 워치리스트, 업종 위험 같은 질적 기준을 룰로 운영합니다. 판정 근거(어떤 룰에 걸렸는지)를 계좌-기준일 단위로 저장해야 감사 대응이 됩니다.
  • Stage 전이의 비대칭: 하향(1에서 2, 2에서 3)은 즉시, 상향(치유)은 일정 기간 연체 없이 유지된 뒤에만 허용하는 비대칭 규칙이 일반적입니다. 전이 이력은 역시 append-only입니다.
  • 시나리오 가중 인프라: 거시 시나리오별 파라미터 세트를 받아 ECL을 여러 번 계산하고 확률 가중하는 구조이므로, 충당금 엔진은 "파라미터 세트 x 계좌"의 곱으로 계산량이 늘어납니다. 월마감 윈도 안에 끝나도록 파티셔닝과 병렬화를 설계 초기부터 고려해야 합니다.
  • 감사 추적: 충당금 숫자 하나에 대해 "어느 모델 버전, 어느 시나리오, 어느 파라미터, 어느 Stage 판정"이 쓰였는지 풀 추적이 가능해야 합니다. 회계 감사에서 가장 깊이 파는 지점입니다.

추심 시스템

콜 배분과 작업 큐

연체가 발생하면 추심(컬렉션) 시스템이 회수 활동을 조직합니다. 구조는 본질적으로 "우선순위가 있는 작업 큐 + 행위 규제 엔진"입니다.

연체 계좌 인입 (일배치)
   |
   v
세그먼테이션
  - 연체 버킷, 회수평점(Collection Score), 금액, 상품
  - 자체 추심 / 위탁 추심 / 법적 절차 트랙 분리
   |
   v
캠페인/큐 배분
  - 초기(1~29일): 문자/앱 알림 중심, 저비용 채널
  - 중기(30~89일): 상담원 콜 배분, 약속 관리
  - 후기(90일~): 전담 조직, 법적 절차 검토
   |
   v
상담원 워크리스트
  - 통화 결과 코드, 약속(PTP) 등록, 다음 액션 일정
  • 회수평점 기반 차등화: 자가 치유(self-cure) 확률이 높은 계좌에 콜을 낭비하지 않도록, 회수 가능성 점수로 접촉 강도를 차등화합니다. CSS 인프라에서 다룬 행동평점·회수평점이 여기에 쓰입니다.
  • 약속 관리(PTP, Promise to Pay): 상담에서 "며칠까지 얼마를 내겠다"는 약속을 구조화해 등록하고, 약속일에 수납을 자동 대사해 이행/불이행을 판정합니다. 약속 이행률은 상담 품질과 전략의 핵심 지표입니다.
  • 수납과의 실시간 동기화: 고객이 방금 입금했는데 독촉 콜이 나가는 것이 최악의 시나리오입니다. 수납 확정 이벤트가 추심 큐에서 해당 계좌를 즉시 제외하도록 이벤트 연동을 설계합니다.

추심 행위 규제 준수

채권 추심은 채권의 공정한 추심에 관한 법률 등으로 행위가 강하게 규제되는 영역입니다. 시스템이 규제를 코드로 강제해야 사람의 실수를 막을 수 있습니다.

  • 접촉 제한: 야간(통상 오후 9시부터 오전 8시) 접촉 금지, 1일 접촉 횟수 제한 등을 다이얼러와 발송 엔진 레벨에서 차단합니다. "걸지 말라"는 가이드가 아니라 "걸 수 없게" 만드는 것이 포인트입니다.
  • 제3자 고지 금지: 가족·직장에 채무 사실을 알리는 행위는 금지됩니다. 연락처 관리에서 차주 본인 확인이 안 된 번호로의 자동 발송을 막아야 합니다.
  • 채무조정·소송 중 계좌 보호: 신용회복위원회 채무조정 신청, 개인회생·파산 절차가 개시된 계좌는 추심 행위가 제한됩니다. 외부 기관 연동으로 해당 상태를 수신하면 추심 큐에서 즉시 동결(hold)하는 자동화가 필수입니다.
  • 전체 이력 보존: 모든 접촉 시도와 결과(녹취 포함)를 보존합니다. 민원·분쟁에서 금융회사가 입증 책임을 지는 경우가 많기 때문입니다.

채무조정의 시스템 반영

연체 차주의 재기를 지원하는 채무조정은 외부 제도(신용회복위원회의 채무조정, 법원의 개인회생·파산)와 금융회사 자체 프로그램(만기 연장, 금리 감면, 분할상환 전환 등)으로 나뉩니다. 시스템 관점에서는 공통적으로 다음 처리가 필요합니다.

  1. 원 채권의 동결과 조정 조건의 신규 스케줄 생성: 감면된 금리, 연장된 만기로 새 상환 스케줄을 만들되, 원 약정 조건과 조정 이력을 모두 보존합니다. 원 레코드를 덮어쓰면 안 됩니다.
  2. 회계·충당금 연동: 채무조정은 통상 신용 손상(Stage 3) 인식 사유이며, 조건 변경으로 인한 장부금액 조정(현재가치 재계산)이 발생할 수 있습니다. 조정 유형별 회계 처리 룰을 충당금 엔진과 공유해야 합니다.
  3. 건전성 분류와 치유 기간: 조정 후 일정 기간 성실 상환하면 분류를 상향할 수 있는데, 이 치유 기간 동안의 상환 이행 추적이 시스템 요건이 됩니다.
  4. 추심 동결과 신용정보 처리: 조정 확정 시 추심을 중단하고, 신용정보 집중기관에 약정 변경·연체 해제 정보를 등록 기한 내에 반영합니다.

NPL 상각과 매각

회수 가능성이 사실상 없는 채권은 두 가지 출구로 나갑니다.

상각(Write-off)

상각은 회계 장부에서 채권을 제거하는 처리입니다(통상 충당금과 상계). 중요한 것은 상각이 채권의 소멸이 아니라는 점입니다. 법적 청구권은 살아 있으므로, 상각 후에도 "상각채권 관리 원장"에서 잔액·시효·회수 활동을 계속 추적합니다. 상각 후 회수가 발생하면 수익(상각채권 회수이익)으로 인식하는 별도 분개 경로가 필요합니다. 소멸시효(통상 상사채권 5년) 관리와 시효 중단 사유(가압류, 소송, 일부 변제 등) 추적도 이 원장의 몫입니다.

매각(NPL Sale)

부실채권을 묶어 NPL 전문 투자자나 유동화 구조에 파는 것이 매각입니다.

NPL 매각 파이프라인

풀(Pool) 구성        실사(Due Diligence)      낙찰/양도 실행
  - 대상 채권 추출      - 데이터 테이프 제공      - 채권양도 계약
  - 제외 조건 필터        (차주/담보/연체 이력)   - 양도 통지 (대항요건)
    (조정 중, 소송 중,  - 입찰가 산정             - 원장 제각 처리
     보증부 등)         - Q&A 대응                - 사후 정산
                                                   (기준일 이후 회수금)

시스템 요건은 다음과 같습니다.

  • 데이터 테이프 품질: 매수자에게 제공하는 채권 명세(원금·이자·연체 이력·담보·법적 진행 상태)의 정확성이 곧 매각가입니다. 정보계에서 일회성 추출로 만들지 말고, 표준 테이프 생성 기능을 시스템화하는 것이 반복 매각에 유리합니다.
  • 기준일 정산: 입찰 기준일과 양도 실행일 사이에 들어온 회수금은 매수자 몫입니다. 이 구간의 수납을 분리 집계하는 정산 로직이 필요합니다.
  • 양도 후 이벤트 처리: 양도된 채권에 대한 수납이 착오로 들어오면 매수자에게 전달해야 하고, 고객 문의는 양수인 안내로 라우팅됩니다. 계좌에 "양도됨" 상태와 양수인 정보를 보존해야 가능한 일입니다.
  • 신용정보 등록: 양도 사실의 신용정보 집중기관 반영도 기한 내 처리 대상입니다.

감독 보고와 정보계 연동

사후관리 데이터는 다양한 감독 보고의 원천입니다.

  • 연체율 보고: 연체율의 분자·분모 정의(1개월 이상 연체 원리금 기준 등)는 보고서마다 다를 수 있습니다. 정의별 산출 로직을 코드로 명세화하고, 원장 마감 데이터와의 정합성 체크를 자동화합니다.
  • 건전성 분류·충당금 보고: 업무보고서의 분류별 잔액·충당금 적립 내역은 월·분기 마감 스냅샷에서 산출합니다. 마감 후 소급 수정이 생기면 보고 재제출 이슈가 되므로, 마감 컷오프와 수정 절차를 엄격히 관리합니다.
  • 신용정보 집중기관 등록: 연체 발생·해제, 기한이익상실, 채무조정, 양도 등 이벤트는 등록 기한이 있습니다. 이벤트 발생과 등록 전문 발송을 잇는 큐에 미발송 감시 알람을 둡니다.

데이터 모델

핵심 엔티티를 ERD로 요약하면 다음과 같습니다.

+---------------+       +--------------------+       +-------------------+
| LOAN_ACCOUNT  |1-----N| REPAY_SCHEDULE     |       | RATE_HISTORY      |
|---------------|       |--------------------|       |-------------------|
| account_id PK |       | account_id FK      |       | account_id FK     |
| product_cd    |       | seq, due_date      |       | from_date, rate   |
| principal     |       | principal_due      |       | reason_cd         |
| open_date     |       | interest_due       |       +-------------------+
| maturity_date |       | status (예정/완납/  |
| status        |       |   부분납/연체)      |       +-------------------+
| repay_method  |       | version_no         |1-----N| TXN_HISTORY       |
+------+--------+       +--------------------+       |-------------------|
       |                                             | txn_id PK         |
       |1                                            | account_id FK     |
       |                                             | txn_date, type    |
       N                                             | amount, applied_to|
+---------------+       +--------------------+       | (비용/이자/원금)   |
| DELINQ_EPISODE|1-----N| BUCKET_TRANSITION  |       +-------------------+
|---------------|       |--------------------|
| episode_id PK |       | episode_id FK      |       +-------------------+
| account_id FK |       | trans_date         |       | CLASSIFICATION    |
| start_date    |       | from_bucket        |       |-------------------|
| end_date      |       | to_bucket          |       | account_id FK     |
| eod_flag      |       +--------------------+       | base_date         |
| eod_date      |                                    | class_cd (5단계)   |
+------+--------+       +--------------------+       | split_amount      |
       |1               | COLLECTION_ACTION  |       | reason_cd         |
       |                |--------------------|       +-------------------+
       N                | action_id PK       |
+---------------+       | episode_id FK      |       +-------------------+
| PTP_PROMISE   |       | channel, result_cd |       | ECL_RESULT        |
|---------------|       | action_ts, agent   |       |-------------------|
| promise_id PK |       +--------------------+       | account_id FK     |
| episode_id FK |                                    | base_date, stage  |
| promise_date  |                                    | ecl_amount        |
| promise_amt   |                                    | model_ver         |
| kept_yn       |                                    | scenario_set_id   |
+---------------+                                    +-------------------+

모델링 원칙 몇 가지를 덧붙입니다.

  • 연체는 에피소드 단위: 한 계좌가 연체와 정상화를 반복하므로, "연체 시작부터 해소까지"를 하나의 에피소드 엔티티로 묶어야 추심 이력·버킷 전이가 깔끔하게 귀속됩니다.
  • 스케줄은 버전 관리: 금리 재산정·중도상환·채무조정으로 스케줄이 재생성될 때마다 version_no를 올리고 이전 버전을 보존합니다. "그 시점에 유효했던 스케줄"을 재현할 수 있어야 합니다.
  • 분류·ECL은 기준일 스냅샷: 현재값 갱신이 아니라 기준일별 적재입니다. 시계열이 곧 감사 증적이고 분석 원천입니다.

배치 설계 — 일배치와 월배치

사후관리는 배치의 세계입니다. 의존 관계가 생명입니다.

일배치 (EOD) — 순서가 곧 정합성

  01 수납 확정 처리 (자동이체 결과 반영)
  02 일이자 계상 (미수이자 적수)
  03 연체 판정 / 버킷 전이      <- 02 이후 (당일 수납 반영 후)
  04 연체이자 계산              <- 03 이후 (버킷/EOD 상태 확정 후)
  05 기한이익상실 후보 추출/통지
  06 추심 큐 적재/회수          <- 03, 05 이후
  07 신용정보 등록 전문 생성
  08 원장-회계 대사 (일마감)
  09 정보계 적재

월배치 (월마감)

  M1 우대금리 조건 재판정        <- 다음 이자 주기 전
  M2 행동평점/회수평점 산출
  M3 자산건전성 분류             <- 연체/담보 데이터 확정 후
  M4 IFRS 9 Stage 판정 / ECL 산출 <- M2, M3 이후
  M5 충당금 회계 분개 / 결산 연동
  M6 감독 보고서 산출            <- M3, M4, M5 이후
  M7 빈티지/롤레이트 분석 마트 적재

배치 설계에서 반복적으로 강조할 점은 세 가지입니다.

  • 재기동 가능성(restartability): 04번이 실패했을 때 01부터 다시 돌리는 설계는 마감 시간을 지킬 수 없습니다. 잡 단위 체크포인트와 부분 재처리를 처음부터 설계합니다.
  • 기준일 파라미터화: 모든 잡은 "오늘"이 아니라 명시적 기준일을 입력받아야 합니다. 장애로 다음 날 재실행해도 전일 기준으로 정확히 돌 수 있어야 하기 때문입니다.
  • 휴일 캘린더의 단일 원천: 납입일 이연, 연체 기산, 이자 일수 모두 영업일 캘린더에 의존합니다. 캘린더 마스터는 하나여야 하고, 연 단위 등록 시점에 검증 절차를 둡니다.

함정 — 소급 재계산의 유혹

사후관리 시스템에서 가장 위험한 안티패턴을 모았습니다.

  1. 소급 재계산: "금리 적용이 잘못됐으니 과거 6개월 이자를 다시 계산해서 덮어쓰자"는 요구는 반드시 옵니다. 절대 과거 레코드를 덮어쓰면 안 됩니다. 과거 거래는 그대로 두고, 차액을 별도 정산 거래(환급 또는 추가 청구)로 일으키는 조정 거래 패턴을 표준으로 삼아야 합니다. 덮어쓰는 순간 회계 마감, 보고서, 신용정보 등록, 고객 명세가 전부 어긋납니다.
  2. 연체 일수 계산기의 중복: 원장, 추심, 충당금이 각자 연체 일수를 계산하다 하루씩 어긋나는 사고가 흔합니다. 단일 모듈로 강제하고, 파생 시스템은 결과를 구독만 하게 합니다.
  3. 기한이익상실 상태의 암묵 관리: "연체 90일 넘으면 상실로 간주" 같은 유도 로직으로 처리하면, 통지 요건·부활 처리와 어긋납니다. 명시적 이벤트와 상태로 관리해야 합니다.
  4. 수납 확정 전 금액의 선반영: 자동이체 출금 결과가 오기 전에 수납으로 간주하면, 출금 실패 시 연체 판정·추심 제외가 전부 뒤집힙니다. 접수와 확정의 분리가 답입니다.
  5. 버킷 전이의 시계열 미보존: 현재 버킷만 갱신하면 롤레이트 분석이 불가능해지고, 충당금 모델의 입력 데이터도 사라집니다.
  6. 마감 후 데이터 수정: 월마감 스냅샷이 나간 뒤 원천을 고치면 보고서와 원장이 다른 숫자를 갖게 됩니다. 수정은 다음 기수의 조정으로 반영하고, 예외적 소급은 재제출 절차와 함께 통제합니다.
  7. 시효 관리 누락: 상각채권의 소멸시효를 시스템이 추적하지 않으면, 시효 완성 채권에 대한 추심으로 법적 리스크가 발생합니다. 시효 기산일·중단 사유를 데이터로 관리해야 합니다.

설계 체크리스트

  • 상환 스케줄 생성기가 거치기간, 일수 컨벤션, 끝수 조정, 휴일 이연을 모두 파라미터로 받는가
  • 금액 계산이 decimal 기반이고 절사/반올림 규칙이 상품 속성으로 명세되어 있는가
  • 충당 순서가 외부화되어 있고 수납 배분 결과가 회계 분개와 1:1 대응되는가
  • 스케줄 재생성이 미래 회차만 건드리고 버전 이력을 보존하는가
  • 연체 일수 계산이 단일 모듈이며 부분 납부 시 기산 규칙이 명확한가
  • 연체 에피소드·버킷 전이가 append-only로 보존되는가
  • 기한이익상실이 명시적 이벤트로 관리되고 통지 이력이 증빙 수준으로 남는가
  • 건전성 분류가 금액 분할(담보 범위)을 지원하고 기준일 스냅샷으로 적재되는가
  • ECL 산출의 모델 버전·시나리오·Stage 판정 근거가 풀 추적 가능한가
  • 추심 행위 규제(시간대, 횟수, 제3자 고지 금지)가 시스템 레벨에서 강제되는가
  • 수납 확정 이벤트가 추심 큐와 실시간 동기화되는가
  • 채무조정·회생 개시 정보 수신 시 추심 동결이 자동화되어 있는가
  • 상각채권 원장이 별도로 존재하고 소멸시효를 추적하는가
  • NPL 매각의 데이터 테이프 생성과 기준일 정산 로직이 시스템화되어 있는가
  • 일배치·월배치의 의존 순서가 명세되어 있고 잡 단위 재기동이 가능한가
  • 소급 수정 대신 조정 거래 패턴이 표준으로 강제되는가

마치며

사후관리 시스템은 화려하지 않습니다. 신규 가입자 수 같은 지표도 없고, 잘 돌아갈수록 조용합니다. 그러나 대출이라는 비즈니스의 손익은 결국 여기서 결정됩니다 — 연체를 얼마나 빨리 정확하게 식별하는가, 충당금을 얼마나 신뢰성 있게 산출하는가, 회수를 얼마나 규제 안에서 효율적으로 하는가. 이 글의 핵심을 한 줄로 줄이면 이렇습니다. 시간을 명시적으로 다루고(기준일, 버전, 에피소드), 과거를 절대 덮어쓰지 말고(조정 거래), 파생 숫자는 단일 원천에서만 흘러나오게 하라(원장 중심).

이것으로 여신 시리즈 — LOS(탄생), CSS(심사), 사후관리(그 이후) — 가 한 바퀴 돌았습니다. 다시 한번, 본 글은 기술 아키텍처 해설이며 금융상품 권유나 투자/법률/회계 자문이 아닙니다.

참고 자료