🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 보험 FNOL 접수에서 사진·영상·문서·음성 메모 같은 비정형 증거를 자동으로 해석·태깅해, 손해사정인이 원자료 검증이 아니라 맥락이 정리된 청구 판단에서 출발하도록 만드는 에이전트 기반 접수 구조를 설명한다.

📌 핵심 요약

• 보험 FNOL 접수는 단순히 청구를 여는 절차가 아니라, 여러 형태의 비정형 증거를 해석·검증·상호 연결해야 하는 복잡한 초기 판단 단계다.
• 현재 손해사정인과 심사자는 포털 화면을 오가며 증거의 존재 여부, 품질, 관련성, 누락 여부를 반복적으로 확인하느라 전문 판단을 늦게 적용하게 된다.
• 제안된 접근은 Nova Act와 Amazon Bedrock AgentCore Browser Tool이 실제 포털 화면을 사람처럼 조작하고, Strands Agents가 보험 도메인 규칙을 적용해 증거를 해석·태깅·상관 분석하도록 역할을 분리한다.
• 증거가 접수 시점에 구조화된 태그로 정리되면 누락·불충분한 자료를 조기에 발견하고, 청구 복잡도와 후속 처리 방향을 더 일관되게 판단할 수 있다.
• 이 구조는 기존 포털을 수정하지 않고도 브라우저 수준 자동화를 적용할 수 있으며, 사람이 판단권과 감독을 유지한 채 반복적인 화면 작업을 줄이는 것을 목표로 한다.

🧩 주요 포인트

1. 보험 FNOL 접수는 단순히 청구를 여는 절차가 아니라, 여러 형태의 비정형 증거를 해석·검증·상호 연결해야 하는 복잡한 초기 판단 단계다.
2. 현재 손해사정인과 심사자는 포털 화면을 오가며 증거의 존재 여부, 품질, 관련성, 누락 여부를 반복적으로 확인하느라 전문 판단을 늦게 적용하게 된다.
3. 제안된 접근은 Nova Act와 Amazon Bedrock AgentCore Browser Tool이 실제 포털 화면을 사람처럼 조작하고, Strands Agents가 보험 도메인 규칙을 적용해 증거를 해석·태깅·상관 분석하도록 역할을 분리한다.
4. 증거가 접수 시점에 구조화된 태그로 정리되면 누락·불충분한 자료를 조기에 발견하고, 청구 복잡도와 후속 처리 방향을 더 일관되게 판단할 수 있다.
5. 이 구조는 기존 포털을 수정하지 않고도 브라우저 수준 자동화를 적용할 수 있으며, 사람이 판단권과 감독을 유지한 채 반복적인 화면 작업을 줄이는 것을 목표로 한다.

🧠 상세 정리

1. FNOL 접수가 단순한 청구 개시가 아닌 이유

원문은 FNOL, 즉 최초 손실 통지가 보험 업무에서 겉보기보다 훨씬 복잡한 단계라고 설명한다. 이 시점에는 현장에서 촬영한 사진, 차량 또는 현장 워크어라운드 영상, 스캔 문서, 받아쓰기나 녹음된 메모 등 다양한 형태의 비정형 자료가 한꺼번에 들어온다. 접수 단계에서 이 자료들을 해석하고 검증하며 서로 연결해야 이후 청구 주기, 후속 판단의 정확도, 고객 경험이 영향을 덜 받는다. 따라서 FNOL은 ‘청구를 하나 여는 일’이 아니라, 의미 있는 판단을 시작하기 전에 대량의 원자료를 의사결정 가능한 상태로 바꾸는 관문으로 제시된다.

2. 수작업 접수가 전문가 시간을 소모하는 구조

현재의 수작업 FNOL 처리는 전문가가 반복적인 검증 업무에 많은 시간을 쓰게 만든다. 손해사정인과 심사자는 포털을 탐색하고, 증거가 충분한지 확인하고, 각 자료가 실제 청구와 관련 있는지 눈으로 살펴본 뒤에야 본격적인 평가를 시작할 수 있다. 원문은 업계 관찰상 초기 청구 처리에서 접수 검증이 상당한 시간을 차지할 수 있으며, 일반적인 제출 건도 평가 전 의미 있는 화면 작업을 필요로 한다고 말한다. 특히 재난성 사건이나 계절적 청구 증가처럼 물량이 폭증할 때 이런 지연은 누적되어 백로그를 만들고, 청구 해결 속도와 고객 경험을 악화시킨다.

3. 전문성은 있지만 너무 늦게 쓰이는 문제

보험 전문가들은 어떤 사진 각도가 필요한지, 어떤 자료가 보통 누락되는지, 영상이 빠진 이미지를 대체할 수 있는지, 어떤 조합의 증거가 높은 복잡도를 시사하는지 잘 알고 있다. 그러나 오늘날 이 지식은 대개 느린 포털 조작과 개별 자료 확인을 거친 뒤에야 적용된다. 검토자는 필수 자료가 있는지, 사진과 영상이 쓸 만하고 관련성이 있는지, 음성 메모에 중요한 관찰 내용이 있는지, 제출 자료가 지연 없이 진행하기 충분한지를 일일이 판단해야 한다. 원문은 문제가 전문성의 부재가 아니라, 도메인 지식이 반복 검증 이후 너무 늦게 행사되는 구조에 있다고 본다.

4. 핵심 목표: 원자료를 태깅된 의사결정 자료로 전환

글이 제시하는 목표는 멀티모달 FNOL 증거를 태깅되고 의사결정 준비가 된 접수 자료로 바꾸는 것이다. 이렇게 하면 조정자는 사진, 영상, 문서, 오디오 같은 원자료 묶음에서 처음부터 출발하지 않고, 이미 맥락과 의미가 정리된 제출 건을 받아 판단할 수 있다. 자동 태깅은 현재 청구의 접수 완전성과 명확성을 높여 후속 단계가 시작되기 전에 기본 확인을 줄인다. 동시에 태그는 일회성 해석으로 사라지는 것이 아니라 이후 라우팅, 패턴 분석, 워크플로 개선에 재사용될 수 있는 운영 자산이 된다.

5. Strands Agents와 브라우저 자동화의 역할 분리

원문은 Strands Agents SDK로 만든 에이전트가 보험 도메인 추론을 담당하고, Amazon Bedrock AgentCore Browser Tool과 Nova Act가 실제 포털 상호작용을 담당하는 구조를 설명한다. Strands Agents는 모델 중심 방식의 오픈소스 SDK로, 이 아키텍처에서는 증거 해석, 모달 간 상관 분석, 청구 복잡도 평가 같은 보험 업무 규칙을 적용한다. 반면 Nova Act는 ‘다음 미처리 청구 열기’나 ‘이미지 분석 실행’ 같은 자연어 지시를 화면상의 실제 UI 행동으로 바꾸는 클라이언트 SDK로 제시된다. AgentCore Browser Tool은 Nova Act가 연결해 조작할 수 있는 관리형 격리 Chrome 세션을 제공하고, 세션 기록과 라이브 뷰로 관찰 가능성을 지원한다.

6. 업무 흐름: 화면 조작은 자동화하고 판단 논리는 배경에서 실행

이 워크플로에서는 Nova Act가 AgentCore Browser 세션을 통해 화면에 보이는 내용을 해석하고 접수 과정을 진행한다. Nova Act는 언제 증거 분석이 필요한지 판단하고 포털 상호작용을 오케스트레이션하며, Strands 기반 도메인 에이전트는 그 증거가 무엇을 의미하는지 판단한다. 즉 화면을 클릭하고 청구를 열고 분석을 실행하는 기계적 업무와, 보험 전문가가 수행하던 규칙 기반 해석 업무가 분리된다. 결과적으로 수작업 화면 조작은 줄어들지만, 인간의 감독과 감사 가능성은 유지되며, 손해사정인은 검증 대상 원자료가 아니라 맥락이 풍부한 사전 분석 제출 건을 받게 된다.

7. 태깅이 만드는 운영상 효과

접수 시점에 증거가 태깅되면 누락되었거나 불충분한 자료를 초기에 찾아낼 수 있고, 자료의 관련성도 암묵적 판단이 아니라 명시적 신호가 된다. 청구는 실제로 제출된 자료를 기준으로 더 일관되게 분류되고, 검토자는 기본 확인에 쓰는 시간을 줄여 판단이 필요한 지점에 더 집중할 수 있다. 원문은 태깅된 증거가 축적되면 이미지, 영상, 오디오가 고립된 파일이 아니라 검색 가능하고 분석 가능한 신호로 바뀐다고 설명한다. 이는 공통 누락이 감지될 때 선제적으로 연락하거나, 전문 팀을 위해 청구를 미리 준비하거나, 유사한 미래 청구의 처리 시간을 줄이는 워크플로로 이어질 수 있다.

8. 기존 포털을 바꾸지 않는 프로토타입 구조

원문은 이 접근이 기존 포털을 수정하지 않고도 구현될 수 있음을 강조한다. 프로토타입은 실제 운영 환경을 모사하도록 구성되어 있으며, FNOL 포털과 백엔드 서비스는 컨테이너화된 애플리케이션으로 실행되고, 에이전트 기반 브라우저 자동화는 사람이 하듯 라이브 포털과 상호작용한다. 전통적인 RPA처럼 미리 녹화된 스크립트나 하드코딩된 흐름을 재생하는 방식이 아니라, UI 상태를 보고 추론해 동작하는 방식으로 설명된다. 이 분리는 도메인 추론과 UI 제어가 독립적으로 발전할 수 있게 하면서도, 운영 안전성과 감사 가능성을 유지하는 장점으로 제시된다.

9. 배포와 데이터 저장의 기본 구성

솔루션은 AWS 계정과 표준 개발 환경의 AWS CLI 자격 증명을 전제로 하며, AWS CDK, Amazon ECS on AWS Fargate, Amazon S3, Amazon DynamoDB, Application Load Balancer, Amazon CloudFront, IAM 역할과 정책 같은 리소스 권한을 필요로 한다. FNOL 접수 UI와 백엔드 서비스는 Docker 컨테이너로 패키징되어 ECS와 Fargate에 배포되고, CDK가 컨테이너 이미지 빌드와 컴퓨트·스토리지·네트워킹 리소스 생성을 하나의 배포 흐름으로 처리한다. 이미지, 영상, 전사문 같은 비정형 증거는 S3에 저장되고, 청구 메타데이터와 증거 참조, 에이전트가 생성한 분석 결과는 DynamoDB에 저장된다. 이를 통해 에이전트는 접수 과정 전반에서 증거를 검색하고 연결하며 추론할 수 있다.

10. 외부 브라우저 제어 환경과 운영 경계

브라우저 자동화는 애플리케이션 런타임 내부가 아니라 별도의 제어 환경, 예를 들어 워크스테이션이나 자동화 호스트에서 실행된다. 이 제어 환경은 AgentCore Browser 세션을 통해 배포된 FNOL 애플리케이션에 연결되며, Nova Act는 Chrome DevTools Protocol을 WebSocket으로 사용해 관리형 Chrome 세션에 접속한다. 자동화 계층은 이 브라우저를 통해 라이브 포털을 관찰하고 조작하지만, 백엔드 서비스는 별도로 호스팅되고 격리된 상태를 유지한다. 원문은 이렇게 브라우저 제어를 애플리케이션 런타임 바깥에 둠으로써, 사람이 보는 것과 같은 화면을 에이전트가 보면서도 운영 경계를 명확히 유지할 수 있다고 설명한다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 사람을 의사결정에서 제거하는 자동화가 아니라, 사람이 판단하기 전 반드시 거쳐야 했던 반복적 화면 검증을 앞단에서 구조화해 전문성이 더 일찍 발휘되게 하는 데 있다.
• 태깅된 증거는 단일 청구 처리 속도를 높이는 데 그치지 않고, 시간이 지날수록 누락 패턴·복잡도 신호·전문 팀 라우팅 기준을 개선하는 데이터 자산으로 축적될 수 있다.
• 기존 포털을 직접 수정하지 않고 브라우저 수준에서 상호작용하는 구조는 레거시 업무 환경에 에이전트 기반 자동화를 적용하려는 조직에 현실적인 전환 경로를 제시한다.

✅ 액션 아이템

• FNOL 접수 과정에서 사진, 영상, 문서, 음성 메모가 어떤 순서로 구조화·검증·태깅되는지 현재 보험 청구 워크플로와 비교한다.
• Strands Agents가 담당하는 도메인 추론과 Nova Act 기반 브라우저 조작을 분리해, 사람 검토가 필요한 경계 지점을 정의한다.
• Amazon S3, DynamoDB, SageMaker 모델, legacy claims portal 사이의 데이터 흐름을 기준으로 감사 로그·권한·개인정보 보호 요구사항을 점검한다.
• low-confidence tagging, escalated claim, missing evidence처럼 adjuster가 개입해야 하는 예외 케이스를 먼저 파일럿 범위로 정한다.

❓ 열린 질문

• FNOL 자동화에서 “decision-ready intake”의 품질을 측정하려면 cycle time, evidence completeness, adjuster override rate 중 어떤 지표를 우선해야 할까?
• Nova Act 기반 브라우저 조작이 legacy claims portal에 의존할 때 UI 변경·세션 만료·권한 오류를 어떻게 탐지하고 복구해야 할까?
• Strands Agents의 도메인 추론 결과를 adjuster가 신뢰하려면 어떤 근거·원본 링크·confidence 설명이 함께 제공되어야 할까?
• 보험 청구 자동화가 고객 경험을 높이면서도 과소 지급·오분류·개인정보 노출 리스크를 키우지 않으려면 어떤 사람 검토 단계가 남아야 할까?