현재 보험업계에는 이상한 패턴이 존재합니다. 모든 보험사가 AI 로드맵을 가지고 있습니다. 이사회는 이를 요구하고, 공급업체들은 시연하며, 헤드라인 수치는 정말 놀라울 정도입니다. 인수(underwriting) 처리 시간이 3일에서 3분으로 단축되고, 클레임 처리가 최대 75% 더 빨라지며, 사기 탐지(fraud detection)가 30% 이상 개선됩니다.

하지만 실제로 이 시스템을 구축하는 사람들과 이야기해 보면, 같은 조용한 인정이 반복적으로 들려옵니다. 바로 '대부분의 프로젝트는 프로덕션 단계에 도달하기도 전에 중단된다'는 것입니다.

본능적으로 모델 탓을 하려는 경향이 있습니다. 아마도 충분히 정확하지 않았기 때문일 수도 있고, 공급업체가 과장 광고를 했기 때문일 수도 있습니다. 하지만 거의 항상 문제는 모델 자체가 아닙니다.

슬라이드에 아무도 언급하지 않는 80/20 법칙

보험 AI 프로젝트가 성공할 때, 노력의 약 20%는 모델에 투입되고 나머지 80%는 데이터를 모델이 사용할 수 있는 상태로 만드는 데 쓰입니다. 반면 프로젝트가 '실패'할 때는 보통 누군가가 이 비율을 거꾸로 예산 책정했기 때문인 경우가 많습니다.

클레임 분류(claims triage), 위험 점수화(risk scoring), 사기 탐지 등 현대의 모델들은 대부분 범용화되어 있습니다. 오후만 지나면 구축할 수 있는 수준입니다. 하지만 정책 보유자, 그들의 이력, 클레임 기록, 그리고 좋은 모델이 소비하고 싶어 하는 수백 가지 외부 신호들을 담은 깨끗하고 통합되며 거버넌스(governed)가 적용된 실시간 뷰를 오후만 지나서 구축할 수는 없습니다.

그것이 조용히 시간표를 잡아먹는 부분입니다. 그리고 이것은 AI와 전혀 관련이 없습니다. 데이터 엔지니어링 문제입니다.

보험 데이터가 실제로 존재하는 곳 (그리고 그것이 문제인 이유)

일반적인 중견 규모의 보험사 데이터 환경은 다음과 같습니다:

• 팀원 대부분보다 오래된 메인프레임 또는 Oracle/Teradata 스택 기반의 정책 관리 시스템(policy administration system).
• 직접 구축한 것이 아니라 구매하여 도입했으며 자체 스키마를 사용하는 별도의 클레임 시스템.
• 서로 다른 10년 동안 서로 다른 공급업체에 의해 통합된 청구 플랫폼, CRM, 문서 저장소.
• 모두가 사용하고 싶어 하지만 아무도 통합하지 못한 신용, 원격 측정(telematics), IoT, 날씨 등의 제3자 피드들이 쌓여가는 더미.

각 시스템 자체는 개별적으로는 문제가 없습니다. 하지만 이들을 종합하면 간단한 질문—“이 고객에 대해 우리가 아는 모든 것을 보여줘”—에 놀라울 정도로 답하기 어렵게 만듭니다. 그리고 AI 모델은 본질적으로 그 질문을 매우 까다롭게 요구하는 형태입니다.

네 가지 실패 모드

1. 파편화(Fragmentation). 동일한 보험 가입자가 신뢰할 수 있는 키로 연결할 방법 없이 네 개의 시스템에 걸쳐 네 개의 기록으로 존재합니다. 모델은 결코 전체 사람을 볼 수 없습니다.

2. 품질(Quality). 누락된 필드, 일관성 없는 코드, 구조화되어야 할 곳의 자유 텍스트가 문제입니다. 이러한 데이터로 학습한 언더라이팅 모델(Underwriting models)은 눈에 띄게 작동하지 않는 모델보다 훨씬 더 비싸게 위험을 잘못 책정합니다.

3. 지연 시간(Latency). 사기 탐지 및 실시간 처리(straight-through processing)에는 청구 또는 견적 시점에 신호가 필요하며, 어젯밤 배치 데이터로 충분하지 않습니다. 만약 데이터가 24시간 지연되어 도착한다면, 당신의 “실시간” AI는 설계상 하루가 늦습니다.

4. 거버넌스(Governance). NAIC 모델 게시물(Model Bulletin)이 현재 23개 미국 관할 구역에서 채택되었고 EU AI Act가 대부분의 보험 AI를 “고위험(high-risk)”으로 분류함에 따라, 당신은 의사 결정이 어떻게 이루어졌는지 _증명_해야 하는 경우가 점점 늘어납니다. 이러한 출처 추적성(lineage)을 그 목적에 맞게 구축되지 않은 파이프라인에 덧붙일 수는 없습니다.

이 중 어느 것도 더 나은 알고리즘으로 해결되지 않습니다.

‘기반 시설 개선’이 실제로 의미하는 것

• 보험, 청구, 결제 및 문서 사일로(silos)를 단일 클라우드 데이터 플랫폼—일반적으로 Snowflake 또는 Databricks 레이크하우스(lakehouse)—으로 통합합니다.
• 레거시 코어 시스템을 단계적으로 폐기하고 병행 운영(parallel run)을 진행하여, 전환 과정에서 비즈니스가 중단되지 않도록 합니다.
• 변환(transformation), 중복 제거(deduplication), 안정적인 고객 키를 갖춘 실제 파이프라인을 구축하여, “고객 360도(customer 360)”가 슬라이드가 아닌 조회 가능한 테이블이 되게 합니다.
• 실시간으로 필요한 신호—FNOL(First Notice of Loss), 원격 측정 데이터, 사기 신호—를 배치 데이터와 함께 스트리밍합니다.
• 출처 추적성(lineage), 접근 제어(access controls), PII 처리, 감사 추적(audit trails) 등 거버넌스를 처음부터 내재화합니다.

이렇게 하면 AI 부분은 거의 지루해집니다. 이전에 '멈춰 있던' 모델들이 갑자기 작동하는 이유는, 처음으로 실제로 학습할 수 있는 것을 공급받기 때문입니다.

프로젝트를 살리는 관점 전환(The reframe that saves the project)

대부분의 AI 로드맵에서 던지는 질문은 ‘어떤 모델을 배포할까?’입니다. 하지만 실제 성공을 결정하는 질문은 ‘우리의 데이터가 어떤 모델에도 준비되어 있는가?’입니다. 이 두 번째 질문부터 하는 보험사들이 프로젝트를 진행합니다. 이를 건너뛰는 보험사들은 비싼 비용으로 2년 동안, 애초에 그 질문부터 했어야 했다는 것을 깨닫게 됩니다.

모델이 어려운 부분이 아니었습니다. 데이터가 어려웠습니다. 항상 그랬습니다.

저희는 200개 이상의 클라우드 마이그레이션을 수행해 온 데이터 엔지니어링 팀이며, 보험 AI가 구동되는 데이터 기반 시설도 포함합니다. 더 많은 정보는 IntelliBooks에서 확인하세요.