정확도보다 이유 코드 우선: Python으로 설명 가능한 클레임 분류(Claims-Triage) 스코어러 구축하기

대부분의 머신러닝 튜토리얼은 정확도 수치로 끝납니다. 보험 청구(claims) 분야에서 이 수치가 모델이 실제로 운영되는지 여부를 결정하는 경우는 드뭅니다. 클레임 관리자, 감사관 또는 규제 기관이 가장 먼저 던지는 질문은 더 간단합니다. 바로 '왜 이 청구가 이런 식으로 라우팅되었나요?'입니다.

만약 시스템이 청구 건당 한 문장으로 그 답을 제시할 수 없다면, 파일럿 단계를 벗어나기 어려울 것입니다. 본 글에서는 설명 가능성을 최우선으로 하는 클레임 분류(claims-triage) 스코어러의 의도적으로 단순한 설계를 안내합니다. 이 코드는 교육 목적으로만 작성되었으며, 실제 운영 환경에 적합하지 않습니다. 또한, 기능과 가중치 값은 오직 교육 목적을 위해 임의로 만들어진 것입니다.

분류(Triage)란 무엇이며, 무엇이 아닌가

클레임 분류는 '결정'하는 것이 아니라 '라우팅(routing)'하는 것에 관한 것입니다. 새로운 청구가 들어오면 시스템은 다음과 같은 경로를 제안합니다:

패스트 트랙 (Fast track): 단순하고 복잡도가 낮은 청구로, 즉시 정산 검사 단계로 이동할 수 있습니다.
표준 검토 (Standard review): 기본 처리 대기열입니다.
전문가 검토 (Specialist review): 경험 많은 조정관(adjuster)의 시선이 필요한 신호를 가진 청구입니다.

모델은 절대 청구를 거부하지 않습니다. 최종 결과는 항상 사람이 책임집니다. 이러한 관점은 설계에 중요합니다. 즉, 당신은 '우선순위 지정 보조 도구(prioritisation aid)'를 구축하고 있으므로, 예측력을 짜내는 것보다 투명성이 더 큰 가치를 지닙니다.

설계 원칙 1: 점수 기반 스코어카드부터 시작하라

그래디언트 부스팅(gradient boosting)을 찾기 전에, 스코어카드를 시도해 보세요. 각 기능(feature)이 점수를 추가하거나 차감하며, 총점이 하나의 경로에 매핑됩니다. 보험 계리사 및 신용 위험 팀은 이 스타일의 모델을 수십 년 동안 사용해 왔는데, 그 이유는 누구나 이해할 수 있기 때문입니다.

from dataclasses import dataclass, field

# 예시일 뿐인 규칙: 기능, 임계값, 점수는 이 예시를 위해 만들어졌습니다...
...

출력 결과는 처리 담당자에게 정확히 무슨 일이 일어났는지 알려줍니다. 어떤 규칙이 발동되었고, 각 규칙이 몇 점을 추가했으며, 총점이 어느 경로에 도달했는지 말입니다. 유지해야 할 사후 설명 계층(post-hoc explanation layer) 자체가 없는데, 그 이유는 모델 자체가 설명이기 때문입니다.

설계 원칙 2: 이유 코드(Reason Codes)는 제품 기능이다

이유 코드를 디버깅 보조 도구가 아니라 일급 출력물(first-class output)로 취급하세요:

안정적인 식별자(Stable identifiers). R01은 내년에도 같은 의미여야 합니다. 로직이 변경되면 새로운 코드를 발행하고 이전 코드는 폐기해야 합니다. 다운스트림 보고서와 감사 추적(audit trails)에 의존하기 때문입니다.
일반 언어 텍스트(Plain-language text). 데이터 과학자가 아닌 클레임 처리 담당자에게 설명문을 작성하십시오. “Policy started shortly before the loss”가 policy_age_days_lt_60보다 좋습니다.
Top-N만 보여주기. 가장 강력한 동인(driver) 두세 개만 보여줍니다. 14가지 기여 요인 목록은 설명이 아닙니다.
중립적인 표현(Neutral wording). 이유 코드는 확인해 볼 가치가 있는 무언가를 지적할 뿐입니다. 누구를 비난하는 것이 아닙니다. 사용자 인터페이스(user-facing) 텍스트에서 “suspicious” 같은 단어는 피해야 합니다.

설계 원칙 3: 단조성(monotonic) 동작 강제하기

이해관계자들은 직관을 가지고 있으며, 모델은 그 합리적인 직관을 존중해야 합니다. 만약 클레임을 나중에 보고하는 것이 항상 점수를 증가시킨다면, 처리 담당자는 이를 근거로 판단할 수 있습니다. 하지만 점수가 31일째에 오르고, 50일째에 내렸다가, 다시 90일째에 오르는 식이라면 신뢰는 빠르게 무너집니다.

스코어카드를 사용하면 이를 쉽게 보장할 수 있습니다. 나중에 트리 기반 모델(tree-based model)로 전환하더라도 XGBoost나 LightGBM 같은 라이브러리는 피처별(per feature) 단조성 제약 조건(monotonic constraints)을 지원합니다. 어느 쪽이든 테스트를 작성하십시오:

def test_reporting_delay_is_monotonic():
    base = {"id": "T", "claim_amount": 5000, "sum_insured": 10000,
            "policy_age_days": 400, "docs_complete": True}
...

이러한 테스트는 비즈니스 기대치를 CI 파이프라인(CI pipeline)에서 모든 변경 사항에 대해 검사하는 무언가로 만듭니다.

설계 원칙 4: 검토자가 요청할 모든 것을 기록하기

각 트리아지 결정(triage decision)마다 입력 스냅샷, 규칙 세트 버전, 점수, 레인(lane), 이유 코드, 그리고 최종 인간의 결정 사항을 저장해야 합니다. 마지막 필드가 가장 가치가 높습니다. 시간이 지남에 따라 제안된 레인과 실제 조정 담당자가 수행한 작업을 비교하면 어떤 규칙이 도움이 되고 어떤 규칙은 단순히 노이즈를 추가하는지 알 수 있습니다. 첫날부터 기록하지 않으면 배울 수 없습니다.

설계 원칙 5: 인간의 재정의(human override) 기능을 유지하고 측정하기

모든 레인(lane) 제안은 짧은 이유를 들어 쉽게 재정의(override)할 수 있어야 합니다. 규칙별, 레인별 오버라이드율을 추적하세요. 자주 재정의되는 규칙은 무언가를 알려주고 있습니다. 아마도 임계값(threshold)이 잘못되었거나, 데이터를 공급하는 과정이 신뢰할 수 없거나, 혹은 그 규칙이 숙련된 담당자가 실제로 일하는 방식을 전혀 반영하지 못했을 수도 있습니다.

스코어카드를 넘어서야 할 때 (When to graduate beyond a scorecard)

스코어카드에는 한계가 있습니다. 이는 피처(feature) 간의 상호작용이나 조정사 노트 또는 사진과 같은 비정형 입력 데이터와는 다루기 어렵습니다. 이를 초과하게 되면, 합리적인 경로는 다음과 같습니다:

스코어카드를 **기준선(baseline) 및 폴백(fallback)**으로 유지합니다.
사용자가 기존의 어휘를 유지할 수 있도록 SHAP 같은 설명 도구를 **기존 이유 코드(existing reason codes)**에 매핑한, 더 유연한 모델을 도입합니다.
두 가지 모두를 **섀도우 모드(shadow mode)**로 실행하고 전환하기 전에 제안 내용을 비교 분석합니다.
**의도치 않은 편향(unintended bias)**이 있는지 고객 세그먼트 전반에 걸쳐 결과를 확인하고, 무엇을 검토했는지 문서화합니다.

목표는 설명하는 것을 더 어렵게 만들지 않으면서 시스템의 역량을 높이는 것입니다.

실용적인 체크리스트 (Practical checklist)

모델이 클레임을 라우팅(routes)하며 최종 결정을 내리지 않습니다.
모든 출력물에 안정적이고 평이한 언어의 이유 코드가 포함됩니다.
단조성 기대치(monotonic expectations)는 자동화 테스트로 작성되어야 합니다.
규칙 세트 버전은 각 결정과 함께 기록됩니다.
사람의 재정의(human overrides)는 캡처되고 정기적으로 검토됩니다.
복잡한 모델을 배포하기 전에 간단한 기준선이 존재합니다.

마무리 생각 (Closing thought)

규제 산업에서는 설명 가능성(explainability)이 마지막에 붙이는 레이어가 아닙니다. 그것은 로깅하는 데이터, 작성하는 테스트, 그리고 인터페이스 핸들러가 보는 모든 것을 형성합니다. 클레임 관리자가 한 줄씩 읽을 수 있는 것부터 시작하세요. 나중에 복잡성을 추가할 권리를 얻으세요.

Yeshwanth Vepachadu는 20년 이상의 경험과 보험 계리 과학 석사 학위를 가진 두바이 기반의 보험 및 AI 전략가입니다. 그는 Substack와 WordPress에서 글을 씁니다.