Repository navigation
Project Overview
develop
04c0e10(2026-10-27) 기준
AI가 만든 보상 분석 초안을 등록 손해사정사가 검수해 사용자에게 전달하고, 필요하면 그 손해사정사와 상담까지 연결하는 서비스다. 이 저장소는 Spring Boot 백엔드다. OCR과 초안 생성은 별도 저장소의 AI 워커가 맡고, 둘은 큐(SQS)와 공유 DB로만 이어진다.
보험금 청구는 보통 아래처럼 흘러간다. 문제는 넷째 칸, 결과에 불만이나 의문이 생겼을 때다.
기존 손해사정 과정 (기획 문서)
일반 사용자는 약관과 보상 기준을 이해하기 어렵다. 빠진 특약이 없는지, 후유장해가 어디까지 인정되는지, 과실비율이 맞는지 스스로 따지기 어렵고, 소액 사건은 손해사정 비용 때문에 상담을 포기하기도 한다. 결국 보험사가 제시한 금액에 그대로 합의하는 경우가 많다.
이 문제를 정보 비대칭 때문에 불리한 합의를 하게 되는 문제로 봤다. 손해보험 피해구제 신청은 해마다 87~90%가 보험금 관련이고, 신청 이유는 보험금 미지급(64.2%)과 보험금액 산정 불만(20.4%)이 대부분이다.
손해보험 피해구제 신청 현황 2022\~2025년 상반기 (자료: 손해보험협회). 빨간 칸이 보험금 관련 신청이고, 해마다 90% 가까이를 차지한다
분쟁도 줄지 않고 있다. 대형 손해보험사 다섯 곳의 분쟁조정 신청 건수는 2024년보다 2025년에 모두 늘었고, 가장 많이 늘어난 곳은 4,228건에서 6,239건이 됐다.
대형 손해보험사 분쟁조정 신청 건수 추이 (팀 중간 보고서에 정리한 공개 통계). 다섯 곳 모두 2025년에 늘었다
처음 구상은 사용자가 서류를 올리면 AI가 보상 가능성 리포트를 바로 보여주는 B2C 모델이었다. 그런데 보험업법상 손해사정은 등록한 자격자만 할 수 있고, 결과물도 자격 표시와 서명이 들어간 손해사정서여야 한다. AI 판단을 사용자에게 직접 전달하면 무자격 손해사정으로 해석될 위험이 있어 구조를 바꿨다.
- AI는 약관·판례·분쟁조정 사례를 바탕으로 초안만 만든다. 초안은 사용자에게 직접 보여주지 않는다.
- 등록 손해사정사가 초안을 검토·수정해 자기 이름으로 제안(검수본)을 보낸다.
- 사용자는 여러 제안을 비교해 손해사정사를 고르고 상담(채팅)으로 이어간다.
판단과 책임은 자격을 가진 손해사정사가 지고, AI는 그 업무를 돕는 도구로 둔다. 합의·협상 대리는 하지 않는다. 이 방향은 법률·손해사정 자문을 거쳐 정했고, AI 초안과 검수본을 테이블부터 나눈 백엔드 설계도 여기서 나왔다.
서비스 흐름 6단계. 2\~3단계(문서 처리·초안 생성)는 사람이 손대지 않는 AI 구간이고, 계약자는 4단계 검수를 거친 리포트만 받는다
사용자(보험 계약자)
- 소셜 로그인(카카오·네이버·Apple)으로 가입한다.
- 보험사·상품을 고르고 사고 상황을 입력한 뒤 진단서 같은 서류를 올린다.
- 리포트 접수는 비동기다. 분석 상태를 폴링하거나 푸시 알림을 기다린다.
- 손해사정사들의 제안이 도착하면 비교하고, 마음에 드는 제안으로 상담을 시작한다.
- 상담 뒤 그 손해사정사를 담당으로 확정하거나 거절한다. 거절하면 다른 제안을 고를 수 있다.
- 상담이 끝나면 후기와 평점을 남긴다.
손해사정사
- 가입 후 자격 신청을 한다. 관리자가 승인하기 전에는 검수 대기 목록만 볼 수 있다.
- 승인되면 검수 대기 목록에서 지역·사고 유형으로 사건을 골라 검수한다. 같은 사건을 다른 손해사정사도 따로 검수한다(경쟁 검수).
- 쟁점을 수락·수정·제외·추가하고 예상 보상 범위와 의견을 적어 제안을 보낸다. 당장 볼 수 없는 사건은 사유를 남겨 보류한다.
- 사용자가 상담을 요청하면 알림을 받고 채팅으로 상담한다.
 |
 |
 |
| 서류 업로드(사용자 2단계). 주민번호·계좌 같은 식별정보는 자동으로 가린다고 안내한다 | 검수 완료 리포트. 쟁점마다 손해사정사가 인정·수정·추가했는지가 보이고, 하단에 법률 자문이 아니라는 고지가 붙는다 | 손해사정사 검색. 전문 분야와 활동 지역으로 거른다 |
화면은 모두 데모 데이터다. 이름·금액·통계·사건번호는 실제가 아니다
| 영역 | Spring Boot (이 저장소) | AI 워커 (FastAPI) |
|---|---|---|
| 인증·회원 | JWT(HttpOnly 쿠키)·OAuth2·RBAC | — |
| 리포트 접수 | 사고 정보 수신, 첨부 저장, OCR 트리거 메시지 발행 | 메시지 소비 |
| 분석 | — | OCR, PII 마스킹, RAG, 멀티에이전트 초안 생성, 가드레일 |
| 검수·매칭 | 검수 대기 목록, 검수 제출, 보류, 제안 수락·거절 | — |
| 채팅 | 사용자↔손해사정사 1:1 채팅(STOMP) | AI 상담 챗봇 |
| 알림 | 인앱 알림, FCM 푸시 | — |
AI 워커는 백엔드를 호출하지 않는다. 결과와 상태는 공유 DB에 직접 쓰고, 백엔드는 그 값을 읽어 사용자에게 알린다. 그래서 DB에 쓰는 값의 계약과 배포 순서를 양쪽이 함께 지켜야 한다.
지금의 전체 구조. 무거운 작업(OCR·리포트 생성)은 SQS 뒤의 워커로 보내고, 워커와 API는 같은 RDS·S3를 쓴다. 약관 PDF는 오프라인 파이프라인이 미리 청킹해 pgvector에 넣어 둔다
그림에 드러나지 않는 백엔드 안쪽 구성은 다음과 같다.
- SQS 발행은 요청 스레드가 직접 하지 않는다. 리포트와 같은 트랜잭션으로 아웃박스 행을 쓰고, 아웃박스 릴레이가 폴링해 보낸다.
- 첨부 파일은 API를 거치지 않고 presigned URL로 S3에 바로 올린다.
- 사용자↔손해사정사 채팅은 메시지 전송을 REST로 받고 STOMP 구독으로 내려 준다. 인스턴스 사이 전달은 Redis pub/sub이 맡는다. AI 상담 챗봇은 별도 워커다.
- 워커가 DB에 남긴 실패·차단 상태는 스케줄러 스윕이 읽어 인앱 알림과 FCM 푸시로 바꾼다.
초기 설계(2026년 6월)의 전체 아키텍처. 관리형 Kubernetes·GPU 노드 그룹·Kafka(MSK)는 기획 단계 구상이라 지금 배포와 다르다. 외부 연동 영역은 잘라냈다
기획 단계에서는 관리형 Kubernetes 위에 앱 노드와 GPU 노드를 나누고, 문서 업로드와 리포트 접수까지 FastAPI가 받는 구조였다. 지금은 이렇게 바뀌었다.
- 리포트 접수는 Spring Boot가 받고, AI 워커는 큐 메시지만 소비한다.
- 브로커는 Kafka(MSK)에서 관리형 SQS로 바뀌었다. 경위는 OCR 트리거 브로커를 Kafka에서 MSK를 거쳐 SQS로 전환에 있다.
- dev는 직접 세운 Kubernetes, prod는 EC2 + docker compose다. 구성은 Kubernetes에 있다.
결정마다의 경위는 결정 로그에 모았다. 코드 구조·인증·API 같은 상세는 레포 README와 docs/를 본다.