데이터 파이프라인

2026. 10. 12. 08:06ㆍ카테고리 없음

반응형


## 1. 시스템 분석 및 설계 방향

### 1.1 설계 범위

데이터를 이해하고, 업무를 판단하고, 필요한 시스템을 호출하며, 결과에 맞춰 사용자 인터페이스를 구성하는 AI Agent 플랫폼을 목표로 한다.

| 핵심 영역 | 주요 역할 | 구현 목표 |
|---|---|---|
| AI 기반 데이터 파이프라인 및 근거 데이터 | 상품·약관·규정 등 원천 데이터 정제 | 적용 시점과 출처를 추적할 수 있는 지식베이스 |
| AI Agent 워크플로우 및 LLM/RAG | 의도 분석, 검색, 계산, 업무 호출 | 근거 기반 추론과 통제 가능한 자동화 |
| AI Agent 기반 동적 UI | 실행 결과에 맞는 UI 조합 | 대화·비교표·차트·폼·승인 화면의 일체화 |

### 1.2 설계 원칙

1. **LLM과 업무 시스템의 책임 분리:** LLM은 의도 해석, 계획, 설명에 활용한다. 요금산출·가입조건 판정·금 계산은 공식 규칙 엔진과 기간계 API에서 처리한다.
2. **근거 중심:** 답변의 모든 도메인 관련 주요 주장에 적용 가능한 상품·약관 버전, 조항, 원문 위치를 연결한다.
3. **통제 가능한 실행:** 조회, 분석, 초안 생성, 확정·변경을 구분하고 위험도가 높은 행위에는 사용자 확인 및 업무 승인을 요구한다.
4. **선언형 UI:** 모델이 임의 코드를 실행하지 않고 승인된 컴포넌트와 구조화된 스키마를 선택하도록 한다.
5. **시간·권한·감사 가능성:** 데이터 유효기간, 계약 적용시점, 사용자 권한 및 실행 계보를 유지한다.

## 2. 전체 시스템 목표 아키텍처


**아키텍처 패턴:** Hybrid RAG(키워드+의미 검색), 선택적 Knowledge Graph(복합 관계), 상태 기반 Agent Workflow(실행 통제), Schema-driven Generative UI(선언형 화면 구성)를 결합한다. 그래프 탐색과 다중 Agent는 모든 질의에 강제하지 않는다.

---

## 3. AI 기반 데이터 파이프라인 및 근거 데이터 설계

### 3.1 도메인 데이터의 특성과 해결 과제

| 특성 | 주요 문제 | 설계 대응 |
|---|---|---|
| 약관의 복잡한 구조 | 본문·부칙·별표·면책의 상호 참조 | 계층형 파싱 및 조항 연결 |
| 비슷하지만 다른 담보 | 표면적 명칭 유사성으로 인한 오분류 | 온톨로지 및 표준 담보 매핑 |
| 계약별 적용 버전 상이 | 최신 약관을 과거 계약에 잘못 적용 | 유효시점 기반 버전 관리 |
| 정형·비정형 혼합 | 문서와 계약 시스템의 결합 필요 | RAG와 승인된 API 연계 |
| 높은 정확성 요구 | 면책 누락·금액 오산출 | 원문 근거 검증, 공식 계산 엔진 |
| 개인정보·민감정보 | 과도한 복제 및 무단 조회 위험 | 최소 수집, 동의·권한·감사 |

### 3.2 데이터 수집 및 전처리 파이프라인

```mermaid
flowchart LR
subgraph SOURCES["Sources"]
A["상품정보"]
B["도메인약관 PDF"]
C["업무 매뉴얼"]
D["계약 · 고객 DB"]
E["규정 · 공시"]
end
subgraph PROCESS["Processing"]
F["Connector / CDC"]
G["Parsing / OCR / Layout"]
H["Hierarchical Document Structure"]
I["Entity & Relation Extraction"]
J["Validation / Versioning / Approval"]
end
subgraph STORAGE["Stores"]
L[("Object Storage")]
M[("Relational DB")]
N[("Search Index")]
O[("Vector Index")]
Q[("Graph DB")]
end
A --> F
B --> F
C --> F
D --> F
E --> F
F --> G --> H --> I --> J
J --> L
J --> M
J --> N
J --> O
J --> Q
```

**수집 정책**

- 상품 및 약관 문서: 배치 + 문서 변경 이벤트, 원본 해시와 발행·개정 메타데이터 관리.
- 상품 마스터·담보 코드: API 또는 CDC로 정합성 확보.
- 고객 계약·보상 데이터: AI 지식베이스에 무차별 복제하지 않고 인증된 실시간 API 조회를 원칙으로 한다.
- 법령·규제: 공식 출처, 시행일, 개정 이력, 승인 상태를 기록한다.

### 3.3 문서 구조화와 약관 청킹

고정 토큰 길이로만 청킹하면 `지급 사유`와 `지급하지 않는 사유`가 분리되어 검색될 수 있다. 조·항·호·목 및 별표 연결을 보존하는 구조 기반 청킹을 적용한다.

```text
제12조 보험금 지급사유
├─ ① 보장 대상 사고
├─ ② 지급금액 산정 기준
└─ ③ 지급 제한 사항
제13조 보험금을 지급하지 않는 사유
├─ ① 고의에 의한 사고
└─ ② 기타 면책 사항
별표 2
└─ 상세 지급 제한 기준
```

```json
{
"document_id": "POLICY-EXAMPLE-001",
"product_id": "PRODUCT-EXAMPLE-001",
"document_version": "v3.2",
"section": "제12조",
"section_title": "보험금 지급사유",
"related_sections": ["제13조", "별표2"],
"valid_from": "2026-01-01",
"valid_to": null,
"source_page": 24,
"verification_status": "APPROVED"
}
```

> 모든 식별자·버전·조항 예시는 설명용 가상 값이다.

구현 단계는 PDF 레이아웃·표 추출 → 문서 계층 복원 → 보험 도메인 개체·관계 추출 → 원문 대조 → 승인된 지식베이스 게시 순서로 설계한다. 텍스트 기반 PDF는 직접 추출을 우선하고 스캔본에만 OCR을 사용한다. 금액·수치·면책 정보는 별도의 정확성 검사를 거친다.

### 3.4 보험 도메인 온톨로지와 지식 그래프

| 엔터티 | 핵심 속성 |
|---|---|
| InsuranceProduct | 상품코드·상품명·판매기간·유형 |
| Coverage | 담보코드·명칭·보장범위 |
| Rider | 특약코드·적용조건 |
| PolicyClause | 조항·유형·문서버전 |
| Exclusion | 면책사유·적용범위 |
| EligibilityRule | 가입조건·심사조건 |
| BenefitRule | 지급조건·한도·산정방식 |
| Regulation | 법령·규정 식별자·효력기간 |

```text
InsuranceProduct --HAS_COVERAGE--> Coverage
InsuranceProduct --HAS_RIDER----> Rider
InsuranceProduct --GOVERNED_BY--> PolicyClause
Coverage --DEFINED_IN---> PolicyClause
Coverage --HAS_EXCLUSION-> Exclusion
Coverage --HAS_BENEFIT---> BenefitRule
InsuranceProduct --SUBJECT_TO---> Regulation
```

예: `현재 계약 → 가입 담보 → 지급 조건 → 보장 공백 → 추가 가능한 특약` 관계를 탐색할 때 그래프 질의가 유용하다. 단순 조항 검색에는 BM25가 더 경제적이다. 그래프 내 모든 관계에 출처·버전·적용기간·검증 상태를 보존하고 모델이 추출한 미검증 관계를 확정 지식으로 배포하지 않는다.

### 3.5 Hybrid RAG 상세 흐름

| 검색 방식 | 대상 | 강점 |
|---|---|---|
| BM25 | 상품명, 코드, 조항번호, 정확한 전문용어 | 정확 일치 |
| Vector | 일상어 질문, 의미상 유사한 설명 | 의미 기반 후보 검색 |
| Graph | 담보·특약·약관 간 연결 | 다단계 관계 탐색 |
| Metadata Filter | 계약 시점, 적용 버전, 접근권한 | 유효한 근거로 제한 |
| Reranker | 통합 검색 후보 | 관련도 재평가 |

```text
질문 → 의도·상품·계약·기준일 분석
→ 접근권한 및 유효기간 사전 필터
→ BM25 + Vector (+ 필요 시 Graph)
→ 후보 병합·중복 제거·Reranker
→ 참조 조항·별표 확장
→ 출처·적용 가능성·면책 누락 검증
→ LLM 컨텍스트 구성
```

검색 점수가 높다고 적용 가능한 증거는 아니다. 검증된 원문인지, 현재 계약에 적용되는지, 사고/청구 기준일에 유효한지, 관련 예외 조항을 확인했는지 검증한다.

### 3.6 시간 기반 Evidence Versioning

- **Valid Time:** 약관이나 규정이 실제로 효력을 갖는 시점.
- **System Time:** 해당 데이터가 플랫폼에 기록·갱신된 시점.

이중 시간 모델(Bitemporal)을 통해 과거 판단을 재현한다. 2025년 가입 고객이 2026년 청구한 사건에는 무조건 최신 약관이 아니라 해당 계약과 사고에 적용되는 조항을 검색해야 한다.

### 3.7 품질 검증 및 게시

```text
Raw → Parsing → Structure Validation → Entity / Relation Validation
→ Business Rule Validation → Evidence Consistency Check
→ Human Approval(중요 변경) → Publish → Index / Graph Deploy
```

신상품 출시, 약관 개정, 면책 변경 시 회귀 평가셋을 재실행한다. 운영 지표는 문서 파싱 성공률, 계층 복원 정확도, 조항 관계 검증률, 약관 버전 정합성, 검색 근거 적중률, 개정 반영 지연시간 등으로 관리한다.

**기술 후보:** Airflow/Dagster, Kafka, Docling/Unstructured, Python/Pydantic, OpenSearch/Elasticsearch, pgvector, Neo4j, PostgreSQL, S3 호환 스토리지, OpenLineage. 최초 도입은 검색+관계형 메타DB+원문 스토리지를 우선하고 그래프는 복합 질의 평가를 거쳐 확장한다.

---

## 4. AI Agent 워크플로우 및 LLM/RAG 아키텍처 설계

### 4.1 실행 모델

`사용자 의도 분석 → 권한·맥락 확인 → 워크플로우 선택 → 데이터 검색·업무 API 조회 → 규칙/계산 → 근거 검증 → 사용자 확인 → 실행/결과 반환`

보험 업무는 단일 `질문→검색→생성` 체계보다 재시도, 중단·재개, 승인, 실패 복구가 가능한 상태 기반 실행 엔진을 요구한다.

```mermaid
flowchart TB
A["User Request"] --> B["Identity / Session Context"] --> C["Intent Classification"] --> D["Workflow Router"]
D --> E["Policy QA"]
D --> F["Coverage Analysis"]
D --> G["Product Comparison"]
D --> H["Business Action"]
E --> I["Evidence Retrieval"]
F --> I
G --> I
F --> J["Contract API"]
G --> K["Product / Calculation API"]
H --> L["Business Tool API"]
I --> M["Result Composer"]
J --> M
K --> M
L --> M
M --> N{"Validation"}
N -->|Pass| O["Structured Result"]
N -->|Need Evidence| I
N -->|Approval| P["Human Approval"]
P --> O
O --> Q["Dynamic UI"]
```

### 4.2 Intent & Context Analyzer

예시 요청: “현재 가입한 보험에서 암 관련 보장이 부족하면 보완 상품을 비교해줘.”

```json
{
"intent": "COVERAGE_GAP_ANALYSIS",
"customer_context_required": true,
"tasks": [
"GET_CUSTOMER_POLICIES",
"EXTRACT_COVERAGES",
"ANALYZE_COVERAGE_GAPS",
"SEARCH_ELIGIBLE_PRODUCTS",
"COMPARE_PRODUCTS"
],
"required_permissions": ["CONTRACT_READ", "PRODUCT_READ"],
"requires_customer_consent": true,
"response_type": "COVERAGE_ANALYSIS_UI"
}
```

이 JSON은 의도 해석 결과일 뿐 실제 권한 부여 수단이 아니다. 인증·인가 엔진이 매번 독립적으로 검증해야 한다.

### 4.3 상태 기반 Workflow Planner

```text
고객 식별·동의·조회 권한 확인
→ 계약정보 조회
→ 가입 담보 정규화
→ 보장 분석 기준 확인
→ 보장 공백 분석
→ 보완 상품 검색
→ 상품별 조건 검증
→ 상품 비교·설명 생성
→ 근거 검증
→ 사용자 결과 확인
```

핵심 보험 업무는 사전 정의한 상태 머신을 기반으로 수행하며 LLM은 검증 단계를 임의로 생략할 수 없다. LangGraph 또는 동등한 워크플로우 엔진을 사용할 수 있다.

### 4.4 전문 Agent 및 Tool 설계

| 역할 | 업무 | 연계 |
|---|---|---|
| Policy Knowledge | 조항·면책 설명 | RAG, Graph |
| Coverage Analysis | 담보·공백 분석 | 계약 API, 규칙 엔진 |
| Product Comparison | 상품 후보 비교 | 상품·요율·설계 API |
| Business Execution | 상담 저장·설계안 초안 | CRM, 기간계 API |
| Evidence Verification | 주장과 근거의 일치 점검 | 원문·버전DB·규칙 |

**초기 권장:** 다중 독립 Agent를 무조건 구성하기보다 Orchestrator 하나와 전문 Tool/Workflow 조합으로 시작한다.

| Tool | 입력 | 결과 |
|---|---|---|
| `getCustomerContracts` | 고객 참조 ID, 권한 | 계약 목록 |
| `getPolicyVersion` | 계약번호, 기준일 | 적용 약관 버전 |
| `searchPolicyClauses` | 상품·질의·시점 | 관련 조항 |
| `analyzeCoverage` | 담보·기준 | 분석 결과 |
| `checkEligibility` | 상품·조건 | 요건 판정 |
| `calculatePremium` | 상품·설계 조건 | 공식 산출 결과 |
| `createProposalDraft` | 고객·상품 구성 | 설계안 초안 ID |
| `saveConsultation` | 상담 정보 | 상담 기록 ID |

Tool Gateway는 MCP Adapter 또는 기존 REST API Adapter로 구성한다. 조회 Tool과 변경 Tool을 구분하며, 변경 시 사용자 확인·업무 승인·idempotency key·감사 로그를 적용한다.

### 4.5 Stateful Agent와 메모리

- **Conversation Memory:** 최근 대화의 의미와 조건.
- **Workflow State:** 완료·진행·대기 단계, 실행 재개 지점.
- **Evidence Memory:** 사용한 문서/계산 결과의 참조 및 버전.

```json
{
"session_id": "session-123",
"workflow": "COVERAGE_ANALYSIS",
"workflow_state": "PRODUCT_COMPARISON",
"customer_reference": "opaque-customer-token",
"filters": {"renewable": false, "monthly_premium_limit": null},
"completed_steps": ["CONTRACT_LOOKUP", "COVERAGE_ANALYSIS"],
"pending_steps": ["PRODUCT_COMPARISON"],
"evidence_snapshot_id": "evidence-456"
}
```

계약 원문이나 민감정보를 무분별하게 장기 메모리에 저장하지 않는다. 중단 후 재개 시에도 동의 및 권한을 재검증한다.

### 4.6 Evidence-bound Generation

답변의 중요한 보험 관련 주장마다 근거 조항을 연결한다.

```json
{
"claim": "해당 담보에는 지급 제한 조건이 존재합니다.",
"evidence": [{
"document_id": "POLICY-EXAMPLE-001",
"section_id": "CLAUSE-13",
"version": "v3.2",
"source_page": 25
}],
"verification": {
"source_exists": true,
"version_applicable": true,
"claim_supported": true,
"status": "PASS"
}
}
```

검증 플래그는 LLM의 자기 평가를 그대로 수용하지 않고 별도 검증 서비스에서 판정한다. 허위 조항, 적용 불가 약관, 누락된 면책 조건, 미확인 계약정보, 비공식 보험료 산출 등을 차단한다. 근거 부족 시 보완 질의 또는 담당자 검토로 분기한다.

### 4.7 Human-in-the-Loop 및 Guardrails

| 위험도 | 예시 | 실행 통제 |
|---|---|---|
| Low | 일반 약관 조회 | 자동 응답 + 출처 |
| Medium | 비교·추천·설계 초안 | 규칙 검증 + 사용자 확인 |
| High | 인수·지급 판단 지원 | 담당자 검토 및 정규 절차 |
| Critical | 계약 변경 확정·지급 승인 | 승인된 시스템·권한·승인 절차 |

입력 가드레일(인젝션·정보 노출·권한), 실행 가드레일(Tool allowlist·인자 검증·승인), 출력 가드레일(근거·개인정보·표현·스키마)을 분리한다. 강제 정책은 프롬프트가 아니라 서버·정책 엔진에서 집행한다.

---

## 5. AI Agent 기반 동적 UI 연동 설계

### 5.1 Schema-driven Generative UI

LLM이 HTML/JavaScript를 직접 생성·실행하지 않고 승인된 컴포넌트의 **타입, 데이터 참조, 레이아웃**을 선언하도록 한다. 보험 업무 결과(Business Result)와 화면 구성(Presentation Result)을 분리하면 웹·모바일·상담사 화면에서 동일 결과를 재사용할 수 있다.

```mermaid
flowchart TB
A["User Input<br/>Chat / UI Event"]
subgraph FRONT["React Workspace"]
B["Conversation Manager"]
C["Dynamic UI Renderer"]
D["Component Registry"]
E["UI State Manager"]
F["Action Dispatcher"]
end
subgraph BACK["Agent Runtime"]
G["Agent Gateway"]
H["Workflow Engine"]
I["Tool Execution"]
J["UI Response Composer"]
K["Schema / Policy Validator"]
end
subgraph CMP["Approved Components"]
L["Product Comparison"]
M["Coverage Chart"]
N["Evidence Viewer"]
O["Dynamic Form"]
P["Approval Panel"]
end
A --> B
B <-->|SSE / HTTPS| G
G --> H
H --> I
H --> J
I --> J
J --> K --> C
C --> D
D --> L
D --> M
D --> N
D --> O
D --> P
C <--> E
E --> F --> G
```

### 5.2 Agent UI Response Contract

```json
{
"schemaVersion": "1.0",
"responseId": "resp-001",
"workflowId": "wf-123",
"status": "COMPLETED",
"businessResult": {
"type": "COVERAGE_ANALYSIS",
"dataRef": "analysis-result-001",
"evidenceRef": "evidence-456"
},
"presentation": {
"layout": "DASHBOARD",
"components": [
{"id": "summary", "type": "SUMMARY_CARD", "dataRef": "analysis-result-001.summary"},
{"id": "coverage-chart", "type": "COVERAGE_CHART", "dataRef": "analysis-result-001.coverages"},
{"id": "comparison", "type": "PRODUCT_COMPARISON", "dataRef": "analysis-result-001.recommendations"},
{"id": "evidence", "type": "EVIDENCE_VIEWER", "dataRef": "evidence-456"}
]
}
}
```

모델은 승인된 컴포넌트 타입만 선택하며 서버 검증 후 UI로 전달한다. `dataRef` 해석 시에도 이용자 권한을 다시 검사한다.

### 5.3 React Component Registry

| 컴포넌트 | 목적 |
|---|---|
| `ProductCard` | 상품 요약 |
| `ProductComparisonTable` | 상품 비교 |
| `CoverageAnalysisChart` | 보장 현황 시각화 |
| `PolicyEvidenceViewer` | 약관 원문 및 조항 |
| `DynamicQuestionForm` | 누락 조건 추가 입력 |
| `PremiumSimulationPanel` | 공식 보험료 산출 결과 |
| `WorkflowProgress` | 실행 단계 표현 |
| `ApprovalRequestPanel` | 중요 업무의 승인 요청 |
| `CustomerContractSummary` | 현재 계약 요약 |
| `ActionResultCard` | 저장·등록 실행 결과 |

컴포넌트별 입력 JSON Schema, 접근 가능한 데이터 타입, 이벤트 목록을 정의한다. 미등록 타입은 렌더링하지 않는다.

### 5.4 양방향 UI 이벤트

예: 사용자가 갱신형 제외 및 월 보험료 조건을 적용한다.

```json
{
"eventType": "UI_ACTION",
"workflowId": "wf-123",
"componentId": "comparison",
"action": "UPDATE_FILTER",
"payload": {
"renewable": false,
"monthlyPremiumLimit": 150000
}
}
```

`UI 이벤트 → Action Dispatcher → 권한·입력 검증 → Workflow State 업데이트 → 관련 Tool만 재실행 → 결과 검증 → 화면 갱신` 흐름으로 처리한다. 단순 정렬·접기/펼치기는 프론트엔드에서 끝내고 보험료 재계산·가입 가능성 확인 등 업무 처리가 필요한 이벤트만 Agent/업무 API로 라우팅한다.

### 5.5 스트리밍과 장애 복구

```text
workflow.started → workflow.step.started → tool.execution.started
→ tool.execution.completed → evidence.ready → ui.component.ready
→ workflow.completed
```

```json
{
"event": "ui.component.ready",
"workflowId": "wf-123",
"sequence": 8,
"payload": {
"componentId": "coverage-chart",
"resultRef": "coverage-result-001"
}
}
```

SSE로 서버 진행 상황을 전달하고 UI 명령은 HTTPS API를 사용한다. 이벤트 ID·순서로 중복을 제거하고 끊김 시 상태를 복원한다. 장시간 워크플로우는 HTTP 연결과 독립적인 비동기 워커에서 처리한다. 꼭 필요한 경우에만 WebSocket을 추가한다.

### 5.6 UI 보안

- Component Allowlist 및 서버측 JSON Schema 검증.
- 외부 HTML/JavaScript 직접 렌더링 금지.
- UI 버튼 표시와 실제 업무 실행 권한을 분리.
- 개인정보 포함 `dataRef` 접근 시 재인가.
- 업무 변경은 명시적 확인·승인.
- 스키마 실패 시 안전한 기본 뷰로 전환.

---

## 6. E2E 업무 시나리오: 계약 보장 분석 및 보완 상품 비교

**사용자 요청:** “현재 가입한 보험을 분석해서 암 관련 보장이 부족한지 확인하고, 갱신형을 제외한 보완 상품을 비교해줘.”

| 단계 | Agent/시스템 작업 | 주요 산출물 |
|---|---|---|
| 1 | 사용자 식별·고객 접근 권한·동의 확인 | 실행 가능 여부 |
| 2 | 기간계 계약 조회, 적용 약관 버전 확인 | 계약·담보 구조 |
| 3 | 약관·담보 지식 검색 및 표준화 | 담보 정의·근거 |
| 4 | 승인된 분석 기준으로 보장 공백 판정 | 보장 분석 결과 |
| 5 | 갱신형 제외 후 상품 후보 검색 | 비교 대상 목록 |
| 6 | 공식 상품·보험료·가입 조건 검증 | 검증된 후보·계산 결과 |
| 7 | 관련 약관·면책·버전 검증 | Evidence Snapshot |
| 8 | UI Schema 생성·검증 및 렌더링 | 차트·표·근거 뷰어 |
| 9 | UI 조건 수정 시 관련 단계만 재실행 | 변경된 비교 결과 |
| 10 | 설계안 초안 요청 시 권한 확인 및 Tool 호출 | 설계안 초안 ID |

**예상 UI 구조**

```text
┌─────────────────────────────────────────┐
│ AI 보험 보장 분석 │
├─────────────────────────────────────────┤
│ 현재 계약 요약 │
├─────────────────────────────────────────┤
│ 보장 현황 차트: 현재 / 비교 기준 / 미확인 │
├─────────────────────────────────────────┤
│ 보완 상품 비교표 │
│ 상품 · 보장 · 조건 · 공식 보험료 결과 │
│ [갱신형 제외] [보험료 조건 변경] │
├─────────────────────────────────────────┤
│ 근거: 약관 조항 / 적용 버전 / 원문 위치 │
├─────────────────────────────────────────┤
│ [조건 변경] [설계안 초안 생성] │
└─────────────────────────────────────────┘
```

보장 공백은 절대적인 사실이 아니라 **분석 기준에 따라 달라지는 결과**다. 기준(목표 보장 수준, 사용자 조건, 사내 승인 규칙)을 명시하고 확정 가입 가능 여부 및 지급 판단과 구분한다.

---

## 7. 엔터프라이즈 운영 아키텍처 및 비기능 요구사항

### 7.1 기술 스택 후보

| 계층 | 권장 후보 | 목적 |
|---|---|---|
| Frontend | React, TypeScript, TanStack Query | 사용자 워크스페이스 |
| Dynamic UI | JSON Schema, Component Registry | 선언형 렌더링 |
| Streaming | SSE, Event ID | 진행 상태·복구 |
| API Gateway | Spring Boot 또는 FastAPI | 인증·API 정책 |
| Agent Runtime | LangGraph 또는 자체 상태 머신 | 워크플로우 관리 |
| LLM Serving | 승인된 모델, vLLM 등 | 추론·구조화 출력 |
| RAG | OpenSearch, Vector Index, Reranker | 근거 검색 |
| Knowledge Graph | Neo4j | 복합 관계 탐색 |
| State DB | PostgreSQL, Redis | 체크포인트·캐시 |
| Business Tool | MCP/REST Adapter | 기간계 연계 |
| 관측 | OpenTelemetry, Langfuse 등 | 실행 트레이스 |
| 보안 | IAM, RBAC/ABAC, KMS | 권한·암호화 |

### 7.2 모델 라우팅

- 의도 분류 및 검색 질의 생성: 검증된 경량 모델 활용 가능.
- 복잡한 약관 분석 및 계획: 한국어 보험 도메인 평가를 통과한 고성능 모델.
- UI 스키마 생성: 구조화 출력 및 JSON Schema 준수율 검증.
- 근거 검증: 규칙 기반 검사와 독립 검증 모델을 병행.

평가 항목은 보험 전문용어 이해, 면책·예외 해석, 시점 구분, Tool 선택, JSON 유효율, 불충분 근거의 보류 능력이다. 외부 모델에 개인정보를 전송하는 경우 사내 보안·법률 검토를 선행한다.

### 7.3 실행 감사와 계보

```text
Execution Trace
├─ 사용자 / 세션 참조 ID
├─ 요청·권한 검증 결과
├─ 선택된 워크플로우
├─ 모델·프롬프트 버전
├─ 검색 질의·근거 문서 ID / Index 버전
├─ Tool 호출·결과 참조
├─ 업무 규칙 버전
├─ 검증·승인 결과
├─ UI Schema 버전
└─ 최종 응답·실행 상태
```

감사 기록은 업무 판단의 재현성을 보장하되, 원문 개인정보의 무조건적 저장은 금지한다. 보관기간, 접근권한, 마스킹, 암호화 정책을 별도 정의한다.

### 7.4 AI 품질 평가

| 차원 | 지표 |
|---|---|
| Data | 파싱 정확도, 조항 연결 정확도, 버전 정합성 |
| Retrieval | Recall@K, nDCG, 근거 적중률 |
| Agent | 업무 완료율, Tool 정확도, 오류율 |
| Evidence | 인용 정확도, 지원되지 않은 주장 비율 |
| UI | Schema 유효율, 렌더 성공률, 상호작용 성공률 |
| Business | 계산·업무 규칙 정합성, 담당자 수정률 |
| Runtime | 지연시간, 비용, 가용성, 복구율 |

회귀 평가에 포함할 오류 사례: 동명이상품·서로 다른 약관 버전, 면책 누락, 존재하지 않는 특약, 무권한 고객 조회, 기간계 장애, 유효하지 않은 UI 스키마. 고위험 오류에는 평균 정확도와 별개로 **운영 차단 기준**을 정의한다.

---

## 8. 단계별 구축 전략

| 단계 | 데이터 | Agent | UI | 결과 |
|---|---|---|---|---|
| Phase 1: Foundation | 약관 수집·정규화·Hybrid RAG | 검색·근거 QA | 채팅·근거 뷰어 | 신뢰 가능한 검색 |
| Phase 2: Business Intelligence | 계약 API·담보 매핑·버전 | 보장 분석·상품 비교 | 차트·비교표 | 분석 업무 지원 |
| Phase 3: Agentic Workflow | 규칙 연계·필요시 Graph | 다단계 Tool·승인 | 동적 폼·진행·승인 | 업무 초안/실행 |
| Phase 4: Enterprise Scale | 자동 평가·데이터 계보 | 운영 정책·최적화 | 개인화·컴포넌트 확대 | 운영 확장 |

**1차 E2E 우선 범위:** `고객 계약 조회 → 담보 분석 → 약관 근거 검색 → 보장 비교 → 동적 UI 표시`.

계약 변경이나 지급 승인과 같은 고위험 실행보다 근거 정합성과 워크플로우·UI 연결 검증을 먼저 수행한다.

---

## 9. 핵심 기술 과제 및 난이도

| 과제 | 난이도 | 핵심 리스크 |
|---|---|---|
| 약관 구조화 | 매우 높음 | 표·별표·예외·상호참조 추출 |
| 시점 기반 근거 관리 | 매우 높음 | 계약·사고시점별 적용 약관 |
| 보험 지식 그래프 | 높음 | 온톨로지 설계·관계 검증 |
| Hybrid RAG | 중간~높음 | 적용 대상 필터·누락 없는 근거 |
| Agent Workflow | 높음 | 상태·실패 복구·승인 |
| 기간계 연계 | 높음 | 권한·감사·트랜잭션 |
| Dynamic UI | 높음 | 스키마 계약·상태 동기화 |
| AI 평가 체계 | 매우 높음 | 도메인 정답셋·경계 사례 |

가장 우선적인 선결 과제는 **약관 원문 구조화와 시점별 적용 정합성 확보**다. 잘못된 근거를 입력하면 이후 모델·워크플로우·UI가 정상이어도 업무 결과는 잘못된다.

---

## 10. 종합 결론 및 권고

보험 AI Agent는 단순 RAG 챗봇이 아니라 **근거 데이터 → 업무 추론 → 검증된 도구 실행 → 동적 업무 화면**으로 연결되는 실행 플랫폼이어야 한다.

| 영역 | 최종 전략 |
|---|---|
| Data | Insurance Ontology + Hybrid RAG + Temporal Evidence |
| Intelligence | Evidence-grounded LLM + Domain Rules |
| Orchestration | Stateful Workflow + Tool Gateway |
| Experience | Schema-driven Generative UI + React |
| Governance | Human-in-the-Loop + Execution Traceability + Policy Enforcement |

> **추가 확인 필요 사항:** 현행 Worker Space의 실제 메뉴·기능, 보험사 기간계 API와 데이터 접근권한, 고객 동의 및 규제 요건, 적용 모델·인프라 조건. 본 제안은 이 정보를 확보한 후 상세 구축 설계로 확정해야 한다.
반응형

티스토리툴바