40년 된 보험 관리 시스템(policy admin system) 위에 온톨로지(Ontology)와 에이전틱 AI(Agentic AI)를 계층화하여, COBOL 코드를 단 한 줄도 건드리지 않고 심사 분류(triage) 시간을 며칠에서 몇 시간으로 단축한 방법.

모든 보험 개발자가 마주하는 벽

보험 엔지니어링 분야 근처에서 일해 보셨다면, 어떤 대화가 오가는지 잘 아실 겁니다. 대화는 "보험 관리 시스템을 현대화해야 합니다"로 시작해서, 누군가 "5년짜리 프로젝트, 9자릿수 예산, 세 명의 커리어가 끝장나는 일"이라고 속삭이며 끝납니다.

대부분의 보험사에서 사용하는 보험 관리 플랫폼은 설계자가 은퇴하기 전에 작성되었습니다. 그 주변은 데이터 추출 작업(extract jobs), 엑셀 시트, 그리고 매주 월요일 아침마다 수동으로 데이터를 대조하는 영웅적인 계리사들로 둘러싸여 있습니다.

저는 예전에 유일한 전진 방법은 완전히 뜯어내고 교체하는(rip-and-replace) 것이라고 생각했습니다. 그러다 Palantir의 보험 배포 사례에 대한 BD Emerson의 분석—특히 Swiss Re의 독립적으로 측정된 ROI와 AIG의 Lloyd's 신디케이트 구축 사례—을 읽고, 선두 팀들은 핵심 시스템을 완전히 교체하려는 시도를 중단했다는 사실을 깨달았습니다.

대신 그들은 기존 자산 위에 운영 계층(operational layer)을 구축했습니다.

그리고 그 수치는 반박하기 어렵습니다: 170%의 ROI, 7.3개월의 회수 기간, 70~80%의 보고 시간 단축(Nucleus Research, 독립 측정).

그래서 저는 그 철학을 바탕으로 무언가를 만들었습니다. 제가 배운 것들을 공유합니다.

문제점: 심사 분류(Submission Triage)는 병목 구간이다

기업 보험(commercial insurance)에서 브로커는 PDF 형태의 심사 요청(submission)을 이메일로 보냅니다. 여기에는 다음 내용이 포함됩니다:

• 피보험자(Named insured) 상세 정보
• 위험 노출(Exposure) 설명
• 과거 손실 기록
• 담보 요청(Coverage requests)

그다음 시계가 돌아가기 시작합니다.

언더라이터(underwriter)는 다음을 수행해야 합니다:

1. PDF(또는 더 최악인 경우 20슬라이드 분량의 PowerPoint)를 읽기
2. 보험사의 인수 성향(appetite)(그들이 실제로 원하는 위험이 무엇인지)과 대조 확인
3. 재보험 계약(treaty) 용량 확인
4. 유사한 과거 손실 사례 탐색
5. 결정: 견적 제공(quote), 거절(decline), 또는 참조(refer)

이 과정은 며칠이 걸립니다. 때로는 몇 주가 걸리기도 합니다. 성수기에는 언더라이터에게 인지적 여유(cognitive bandwidth)가 생길 때까지 심사 요청이 편지함 대기열에 쌓여 있게 됩니다.

기존 레거시 시스템(legacy system)은 도움이 되지 않습니다. 그 시스템은 오직 체결된(bound) 보험 증권만을 저장할 뿐입니다. 체결 _이전(before)_의 모든 과정은 이메일, SharePoint, 그리고 Excel에 머물러 있습니다.

통찰: 교체하지 말고, 계층을 쌓으세요 (Don't Replace. Layer.)

BD Emerson의 기사는 제가 보험 아키텍처(insurance architecture)를 생각하는 방식을 바꾼 중요한 지점을 짚어줍니다.

"기록 시스템(system of record)을 먼저 교체하는 대신, 그 상단에서 통합하십시오. 레거시 플랫폼들을 연결하고, 보유 계약(book)을 한 번 모델링한 뒤, 그 계층 위에서 언더라이팅(underwriting), 포트폴리오, 리포팅 워크플로우를 실행하십시오. 그러면 궁극적인 코어 교체는 이미 작동하고 있는 모델로 데이터를 마이그레이션(migration)하는 과정이 될 것입니다."

이는 다음을 의미합니다:

• 1980년대의 보험 관리 시스템(policy admin system)은 그대로 유지됩니다.
• 1990년대의 보상(claims) 데이터베이스는 그대로 유지됩니다.
• 계리(actuarial) Excel 모델들도 그대로 유지됩니다.
• 하지만 이 시스템들 상단에, **통합 운영 계층(unified operational layer)**을 구축하는 것입니다.

Palantir는 이를 **온톨로지 (Ontology)**라고 부릅니다. 이는 객체(objects), 관계(relations), 그리고 관리되는 액션(governed actions)을 가진 비즈니스의 라이브 그래프(live graph)입니다. 저는 심사 분류(submission triage)를 위해 이 아키텍처의 경량화된 버전을 구축했습니다.

아키텍처: 3개의 계층

┌─────────────────────────────────────────────────────────────┐
│  LAYER 3: AGENTIC AI (AIP)                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
...

계층 1: 커넥터 (코어는 건드리지 마세요)

저는 레거시 데이터베이스를 위한 마이그레이션 스크립트를 단 하나도 작성하지 않았습니다. 대신, **읽기 전용 커넥터(read-only connectors)**를 구축했습니다.

• 체결된 보험 증권 이력을 위한 보험 관리 시스템용 JDBC
• 손실 이력(loss runs)을 위한 보상 시스템용 API
• 브로커 이메일 및 PDF를 위한 IMAP 리스너 + OCR 파이프라인(pipeline)

핵심 규칙은 다음과 같습니다: 레거시 시스템은 체결된 비즈니스에 대한 기록 시스템(system of record)으로 남습니다. 우리는 오직 거기서 읽기만 합니다. 시스템에 변경을 요구하지 않습니다.

계층 2: 온톨로지 (체결 전 단계의 진실의 원천)

여기가 마법이 일어나는 곳입니다. 심사 요청(submissions)을 폴더 안의 파일로 저장하는 대신, 그래프 내의 **객체(objects)**로 모델링합니다.

# ontology/schema.py
from dataclasses import dataclass
from typing import List, Optional
...

온톨로지 (Ontology)는 단순한 데이터베이스 스키마 (database schema)가 아닙니다. 이는 다음과 같은 **살아있는 모델 (living model)**입니다:

• Submission (심사 청구)은 과거의 Loss (손실) 객체와 _관계 (relates to)_를 맺습니다.
• Exposure (위험 노출)는 AppetiteRule (인수 성향 규칙)을 _트리거 (triggers)_합니다.
• Decision (결정)은 전체 계보 (lineage)를 포함하는 Action (조치)을 _생성 (creates)_합니다.

레이어 3: 트리아지 에이전트 (The Triage Agent, Agentic AI)

이 단계에서 LLM (대규모 언어 모델)이 투입됩니다. 하지만 결정적으로, LLM은 가공되지 않은 PDF를 바탕으로 추론하지 않습니다. 대신 온톨로지 (Ontology)를 바탕으로 추론합니다.

# agents/triage_agent.py
from typing import Literal
import json
...

핵심적인 설계 선택: 에이전트는 인간 언더라이터 (underwriter)와 동일한 권한을 상속받습니다. 만약 언더라이터가 Syndicate X에 대한 특약 (treaty) 데이터를 볼 수 없다면, 에이전트 또한 볼 수 없습니다. 이는 사후에 덧붙여진 보안이 아니라, 온톨로지 레이어 (Ontology layer)에 내장된 (native) 보안입니다.

거버넌스 레이어 (The Governance Layer): 이것이 블랙박스가 아닌 이유

보험 산업은 규제를 받습니다. 재보험 파트너들은 귀사를 감사 (audit)합니다.

만약 당신이 이를 구축하려는 개발자라면, 제가 제안하는 범위(scope)는 다음과 같습니다:

1개월 차: 데이터 수집(Ingestion) 및 온톨로지(Ontology) v0.1

• 1-2주 차: PDF/OCR 데이터 수집 파이프라인 구축 (AWS Textract, Azure DI, 또는 오픈 소스인 Tesseract + layoutLM 사용)
• 3-4주 차: 핵심 객체 정의: Submission (심사 신청), Exposure (위험 노출), Insured (피보험자), AppetiteRule (인수 규칙). 그래프 데이터베이스 (Neo4j)를 사용하거나, 접근 권한이 있다면 Palantir Foundry를 사용하세요.

2개월 차: 심사 에이전트 (The Triage Agent)

• 5-6주 차: LLM이 가공되지 않은 텍스트(raw text)가 아닌, 구조화된 온톨로지 컨텍스트를 바탕으로 추론할 수 있도록 프롬프트 엔지니어링 (Prompt engineering) 수행. Claude 3.5 Sonnet 또는 GPT-4를 사용하세요.
• 7-8주 차: 액션 레이어 (Action Layer) 구축: AUTO_APPROVE (자동 승인)는 보험 증권 발행 API로 경로를 지정하고, REFER (검토 요청)는 모든 컨텍스트가 사전 로드된 언더라이터 워크벤치(underwriter workbench)를 엽니다.

3개월 차: 거버넌스(Governance) 및 피드백 루프 (Feedback Loop)

• 9-10주 차: 리니지 추적 (Lineage tracking) 구현. 모든 결정은 반드시 소스 데이터로 추적 가능해야 합니다.
• 11-12주 차: A/B 테스트: 심사 신청의 20%는 기존 프로세스로, 20%는 새로운 엔진을 통해 처리합니다. 심사 소요 시간(time-to-triage), 전환율(conversion rate), 그리고 언더라이터 만족도를 측정하세요.

"골든 레이어(Golden Layer)": 신뢰도 점수(Confidence Scoring) + 피드백

하지만 보험 산업 — 그리고 대부분의 규제 산업 기업들 — 에서 레거시 시스템(legacy system)은 사라지지 않습니다. 비즈니스는 5년이 걸리는 마이그레이션(migration)을 견딜 수 없습니다. 데이터는 너무나 무질서하고, 통합(integration)은 너무 깊게 박혀 있으며, 리스크는 너무 높습니다.

Palantir의 접근 방식 — 그리고 제가 구축 과정에서 검증한 방식 — 은 우리에게 다른 기술을 가르쳐 줍니다:

제어할 수 없는 시스템 위에 실시간 지능형 레이어(intelligent layer)를 구축하고, 몇 년이 아닌 몇 주 만에 가치를 창출하는 능력.

이것은 단순한 아키텍처 패턴이 아닙니다. 커리어를 결정짓는 핵심 역량입니다.

핵심 요약 (Key Takeaways)

1. 레거시를 교체하지 말고, 그 위에서 통합하세요. 보험 관리 시스템(policy admin system)은 그대로 유지됩니다. 여러분의 온톨로지(Ontology)가 계약 체결 전(pre-bind)의 진실의 원천(source of truth)이 됩니다.
2. LLM은 PDF가 아닌 온톨로지(Ontology)를 기반으로 추론해야 합니다. 가공되지 않은 문서 기반의 RAG(Retrieval-Augmented Generation)는 취약합니다. 구조화된 객체 추론(structured object reasoning)은 거버넌스(governance)가 가능합니다.
3. 거버넌스는 선택적인 장식이 아닙니다. 목적 기반 액세스(purpose-based access), 결정 이력(decision lineage), 그리고 인간의 체크포인트(human checkpoints)는 아키텍처에 내장되어 있어야 합니다.
4. Swiss Re의 수치는 실제입니다. 7.3개월 만에 170%의 ROI(투자 대비 수익)를 달성한 것은 마케팅 용어가 아닙니다. 언더라이터(underwriter)들이 추출된 데이터를 대조하는 일을 멈추고 의사결정을 시작할 때 실제로 일어나는 일입니다.

Seyed Alireza Alhosseini Almodarresieh