간단한 답변: 제출 패킷당 접수 검토 시간(접수부터 견적 준비 완료까지)을 측정하고, 직접 작업 시간(touch time)과 경과 시간(elapsed time)을 모두 기록해야 합니다. 파일럿 진행 전에 패킷 복잡도에 맞춰 기준선(baseline)을 구축한 후, 통제된 방식으로 비교하세요. 사람이 추출된 필드를 확인하고 수정하는 데 쓰는 시간을 검토 시간으로 계산하지 않으면, 보고되는 모든 절감액은 측정하지 않기로 선택한 것의 인공적인 결과물일 뿐입니다. 모델 변경 시 클럭을 바꿀 필요 없이 Superlinked Inference Engine에서 해당 파일럿의 추출 기능을 실행하세요.
파일럿 팀에 따르면 AI 추출 기능이 제출 검토 시간을 절반으로 줄였다고 보고합니다. 측정은 간단했습니다. 파일럿 이전에는 인수 심사 보조원이 패킷을 시스템에 입력하는 데 약 40분이 걸렸지만, 이후에는 필드가 미리 채워져 있어 입력 시간이 20분으로 단축되었습니다. 하지만 다음에 무슨 일이 일어났는지는 아무도 시간을 재지 않았습니다. 사전 채우기된 제한 사항을 신뢰하지 않게 된 인수 심사원들은 원본 문서를 열어 모든 것을 확인했습니다. 일부 패킷은 브로커에게 두 번이나 반송되었습니다. 입력 시간 기록계에는 절감액이 표시되었고, 견적서 발송 시간도 이전과 다름없이 걸렸습니다. 위의 수치들은 모두 예시적인 것이며, 문제의 형태를 보여주기 위해 만들어진 것입니다. 스톱워치는 정확했지만, 잘못된 지점에서 시작하고 멈췄습니다.
이 가이드는 문서 AI가 상업 인수 심사 제출에 대한 검토 시간을 실제로 단축하는지 측정하는 방법을 제시합니다. 단위는 패킷이며, 주의해야 할 실패 사례는 재작업(rework)과 브로커 간의 왕복 과정입니다. 마지막 근처에는 Superlinked가 파일럿 기능에서 추출 모델을 호스팅할 수 있는 방법에 대한 짧은 섹션이 포함되어 있습니다.
1. 단위와 시간을 정의하기
단위는 하나의 제출 패킷, 즉 브로커의 이메일과 그에 첨부된 모든 것을 의미합니다. 문서를 기준으로 측정하면 숫자가 더 좋아 보이지만, 인수 심사원이 신경 쓰는 것은 아무것도 설명하지 못합니다.
두 가지 시간을 정의하고 모두 기록하세요:
- 경과 시간(Elapsed time): 서류 묶음(packet)을 접수한 순간부터 견적 산출 준비가 완료되거나 거절되기 직전까지 걸리는 시간을 의미합니다. 이는 브로커와 비즈니스 측면에서 체감하는 시간입니다.
- 접촉 시간(Touch time): 사람들이 실제로 서류 묶음을 처리하며 보내는 시간을 모두 합산한 것입니다. 이 시간은 인력 배치 비용에 영향을 미칩니다.
각 시계가 시작하고 멈추는 정확한 이벤트를 기록하고, 기억이 아닌 시스템에서 로그를 남겨야 합니다. '견적 산출 준비 완료(Ready to quote)'에는 "필수 필드가 모두 확인되었고 브로커의 미해결 질문이 없는 상태"와 같이 모두가 동의하는 정의가 필요합니다.
경과 시간은 대기 시간을 포함하며, AI는 사전에 누락된 문서를 발견함으로써 간접적으로 이 시간을 단축할 수 있습니다. 반면, 접촉 시간은 정보 추출(extraction)을 통해 직접적인 도움을 받습니다. 어떤 효과를 보고 있는지 알려면 두 가지 지표 모두가 필요합니다.
2. 파일럿 시작 전의 기준선 설정 (Baseline)
파일럿이 시작된 후에 측정하는 기준선은 오염되어 있습니다. 정상적인 물량 변동을 포괄할 수 있도록 충분한 기간 동안, 즉 파일럿 이전에 데이터를 확보해야 합니다.
서류 묶음마다 복잡도가 엄청나게 다르기 때문에, 복잡도별로 나누어 분석해야 합니다. 예시적인 분류는 다음과 같습니다:
- 단순(Simple): 하나의 사업 부문(line of business), 디지털 신청 양식, 그리고 한두 개의 손실 기록(loss runs)으로 구성됩니다.
- 표준(Standard): 두세 개의 사업 부문, 소규모 가치 목록(schedule of values), 여러 보험사로부터의 손실 기록 등으로 구성됩니다.
- 복잡(Complex): 여러 위치를 포함하거나, 대형 가치 목록(SOV)이 필요하고, 스캔 또는 팩스된 문서가 있거나, 여러 명의 피보험자(named insureds)가 관련된 경우입니다.
서류 묶음의 혼합 비율을 기록해야 합니다. 만약 파일럿 기간 동안 단순한 서류 묶음만 많이 접수된다면, 어떤 모델의 도움 없이도 평균치가 하락할 수 있습니다. 따라서 각 세그먼트 내에서 비교하는 것이 중요합니다.
또한 이미 존재하는 재작업(rework) 비율도 기록해야 합니다. 즉, 서류 묶음이 브로커에게 되돌아가는 빈도나 검토자가 키 입력된 데이터를 수정하는 빈도 등입니다. 이러한 수치들은 기준선의 일부이며, 5단계는 이 데이터에 의존합니다.
3. 통제된 비교 수행 (Controlled comparison)
가장 깨끗한 설계 방식은 서류 묶음 단위의 A/B 분할(A/B split)입니다. 접수되는 서류 묶음을 현재 프로세스 또는 AI 지원 프로세스 중 하나에 무작위로 할당하고, 두 시스템을 동일한 직원들로 같은 주 동안 운영해야 합니다. 무작위 할당은 계절성, 인력 변동, 그리고 제출물 혼합 비율의 영향을 통제할 수 있게 해줍니다.
만약 분할(split)이 실용적이지 않다면, 매칭된 혼합군을 사용한 전후 비교를 실행하십시오. 각 복잡성 세그먼트를 자체 기준선과 비교하고, 파일럿 과정에서 도착하는 결과물에 의존하기보다는 고정된 비율로 결과를 가중치 부여해야 합니다.
패킷 단위 분할은 한 가지 약점, 즉 파급 효과(spillover)가 있습니다. 오전에 미리 채워진 패킷을 본 보험 인수 담당자들은 오후에 통제 패킷을 읽는 방식이 달라지며, 어느 그룹의 패킷인지 눈가림 처리를 할 수 없습니다. 만약 책상이 충분히 넓다면, 대신 팀이나 책상 단위로 분할하고 각 측면에 유사한 업무 포트폴리오를 배치하십시오. 그리고 더 깨끗한 비교 결과를 얻기 위해 더 넓은 범위(wider range)를 감수하는 것이 좋습니다.
어떤 경우든 검토자는 동일하게 유지하고 학습 곡선(learning curve)을 예상해야 합니다. 새로운 도구를 사용하는 첫 몇 주는 속도가 느립니다. 이를 보고하되, 어느 방향으로도 결과가 결정하도록 내버려 두지 마십시오.
4. 검증 및 수정 시간을 검토 시간에 포함하기
이 단계는 대부분의 파일럿에서 건너뛰는 부분이며, 앞서 언급된 예시가 잘못된 지점입니다. 추출된 필드가 미리 채워진 상태로 도착하더라도 작업 자체가 사라지는 것은 아닙니다. 키 입력(keying) 방식에서 확인(checking) 방식으로 변화하는 것입니다.
AI 지원 그룹에서는 세 가지 종류의 시간을 기록해야 합니다:
- 검증 (Verification): 추출된 값을 확인하기 위해 원본 페이지를 열어보는 시간.
- 수정 (Correction): 잘못된 값을 고치는 데 걸리는 시간.
- 복구 (Recovery): 오분류된 문서나 추측으로 채워져 패킷을 잘못된 경로로 보내는 필드 등 추출 과정이 야기한 문제들을 처리하는 시간.
검토자가 모든 필드를 검증한다면, 절감되는 시간은 읽기와 타이핑의 차이에 국한됩니다. 절감액은 검토자가 충분히 많은 필드를 신뢰하여 확인 과정을 건너뛸 때만 증가하며, 이러한 신뢰는 정확도(accuracy)를 통해 얻어져야 합니다. 이것이 추출 평가가 이 측정보다 선행되어야 하는 이유입니다. 유효한 JSON 형식의 추출 결과물이라 하더라도 잘못된 제한값(wrong limit)을 포함할 수 있으며, 이를 아는 검토자는 반드시 확인하게 됩니다.
5. 시간과 함께 가드레일 품질 측정하기
검토 속도가 빨라지는 것은 결과물의 품질이 유지될 때만 이득입니다. 양쪽 그룹 모두에서 가드레일(guardrail) 측정을 추적해야 합니다.
- 오류 발생 사례(Error escapes): 패킷이 준비됨으로 표시된 후, 예를 들어 요율 산정이나 견적 검토 과정에서 잘못된 값이 발견되는 경우.
- 중개인 재검토 요청(Broker follow-ups): 각 패킷이 중개인에게 되돌아가는 횟수와 그 이유.
- 결정 변경(Decision changes): 나중에 수정되거나 취소되어 견적 또는 거절 결정이 변경된 경우.
만약 검토 시간이 줄어들고 오류 발생 사례가 증가한다면, 프로세스가 작업을 제거한 것이 아니라 위험을 하류(downstream)로 이동시켰다는 의미일 수 있습니다. 따라서 시간 수치만을 보고 결정을 내리기 전에, 어느 정도의 품질 변화를 허용할지 미리 결정해야 합니다.
6. 범위와 표본 크기를 포함하여 보고하고 결정하기
결과를 복잡성 세그먼트별로, 각 세그먼트에 포함된 패킷 수와 단일 수치가 아닌 범위를 제시하며 보고해야 합니다. 가상의 숫자를 사용한 예시 보고서는 다음과 같습니다:
| 세그먼트 | 패킷 수 (A / B) | 현재 중앙값 터치 시간 | AI 지원 중앙값 터치 시간 | 오류 발생 사례, 현재 / AI |
|---|
| Simple | 120 / 118 | 25분 | 15분 | 2 / 2 |
| ... | | | | |
30개의 패킷은 너무 적은 표본이며, 이처럼 작은 복잡한 세그먼트는 결론이 아닌 질문을 뒷받침할 뿐입니다. 모양을 이해하기 위해 예시를 읽어보십시오. 이 가상의 결과는 해당 도구가 간단하고 표준적인 패킷에는 도움이 되지만, 수정 및 오류 발생 사례가 증가한 복잡한 패킷에는 해로울 수 있음을 시사합니다. 현명한 결정은 복잡한 케이스가 개선될 때까지 첫 두 세그먼트만 AI 추출을 통해 처리하는 것일 수 있습니다. 단일 혼합 백분율(blended percentage)은 이 모든 것을 숨겨버릴 것입니다.
파일럿 단계에서 측정하지 않은 내용과 다음에 다시 측정할 시점을 명시해야 합니다.
SIE가 적용되는 곳
Superlinked Inference Engine
SIE는 파일럿 암(pilot arm)에서 추출 모델을 위한 추론 엔진(inference engine)입니다. SIE는 단일 SDK를 통해 OCR 및 필드 추출 모델에 서비스를 제공하므로, AI 지원 암은 모델 ID를 변경함으로써 한 모델에서 다른 모델로 전환할 수 있으며, 이 과정에서 클럭(clocks), 기준선(baseline), 가드레일(guardrails)은 정의된 상태를 유지합니다. 이를 통해 여러 개의 암을 실행할 수 있습니다. 예를 들어, 하나의 페이지 모델과 또 다른 모델을 비교하거나, 작은 필드 모델을 SIE Cloud의 문서 필드 추출 작업에 사용되는 Qwen3.8-27B (FP8) 모델과 비교할 수 있으며, 이 모든 측정은 동일한 클럭과 동일한 패킷 혼합(packet mix)으로 이루어집니다.
SIE Cloud는 제품 페이지에서 모델별 가격을 공개합니다. 동일한 엔진은 배포 문서에 설명된 바와 같이 Apache 2.0 하에 자체 클러스터에 호스팅할 수 있으며, 소규모 파일럿을 위해 단일 머신에서 로컬로 실행됩니다. 측정 방식이 모드(mode)가 바뀌어도 변화하지 않습니다.
솔직한 평가: SIE는 다중 암 파일럿을 실용적으로 만드는 핵심 요소입니다. OCR, 추출(extraction), 임베딩(embeddings), 재순위 지정(reranking) 기능을 단일 API 뒤에서 실행하므로, 추출 단계는 모델 ID를 통해 한 모델에서 다른 모델로 전환되며, 동일한 클럭과 동일한 패킷 혼합으로 측정됩니다. SIE Cloud가 관리형 경로(managed path)입니다. Apache 2.0 기반의 자체 호스팅 SIE는 고객 VPC 또는 자체 클러스터 내부에 동일한 엔진을 단일 코드베이스로부터 실행하며, 로컬 모드는 단일 머신에서 소규모 파일럿을 실행합니다. 세 번째 암은 두 번째 암과 오직 하나의 모델 ID만 다릅니다. 이것이 바로 단일 추론 계층(inference layer)으로 어떤 모델이 패킷 검토 시간을 단축하는지 테스트할 수 있는 방법입니다.
FAQ
예상되는 절감액은 어느 정도인가요?
본 가이드에서는 구체적인 숫자를 제시하지 않으며, 이를 주장하는 사람에게는 경계심을 가져야 합니다. 절감액은 패킷 혼합(packet mix), 인수자(underwriters)가 확인해야 하는 필드의 개수, 문서 추출의 정확도, 그리고 투입 시간 중 작업이 아닌 대기 시간이 얼마나 되는지에 따라 달라집니다. 다른 사업 분야의 공급업체 수치는 자신들의 패킷과 프로세스를 측정하여 제시합니다. 몇 주 동안 통제된 비교를 실행해 보시면 귀하에게 적용되는 숫자를 갖게 될 것입니다.
절약된 시간이 단순히 검토(checking)로 이동할까요?
정확도가 낮다면 그럴 것입니다. 그리고 이를 알 수 있는 유일한 방법은 측정하는 것입니다. 파일럿 단계에서 검증 및 수정 시간을 분리하여 로깅해야 합니다. 리뷰어들이 모든 필드를 확인한다면, 절약되는 시간은 적으며 다음 투자는 추출 정확도(extraction accuracy) 향상이나 각 필드 옆에 출처 페이지를 표시하는 데 할애되어야 합니다. 리뷰어들이 어떤 필드가 신뢰할 수 있는지 학습함에 따라 검토 시간이 줄어들어야 합니다. 만약 그렇지 않다면, 모델이 귀하의 문서에 대해 충분히 정확하지 않다는 의미입니다.
정확히 무엇을 로깅해야 하며, 어디서 가져와야 할까요?
지속 시간(duration)이 아닌 이벤트를 로깅하고 나중에 클럭을 계산하세요. 이메일 게이트웨이 또는 제출 포털은 수신 패킷(packet received) 정보를 제공합니다. 워크플로우 또는 언더라이팅 시스템은 배정됨(assigned), 열림(opened), 견적 준비 완료(ready to quote), 거부됨(declined), 그리고 각 브로커 요청과 그 이유를 제공합니다. 검토 화면은 조회된 필드(field viewed), 열린 출처 페이지(source page opened), 그리고 수정된 필드(field corrected)와 함께 이전 및 새 값을 제공합니다. 추출 서비스는 필드별 모델 ID 및 버전을 제공하므로, 결과가 생성한 모델과 연결될 수 있습니다. SIE docs에는 각 호출이 반환하는 내용이 설명되어 있습니다. 모든 이벤트에 패킷 ID와 암(arm)을 저장하세요.
전체 작업 시간
검토 시간은 사람이 패킷을 견적 준비 완료 상태(ready-to-quote)로 만드는 데 소비하는 시간을 의미하며, 여기에는 검토, 수정, 그리고 브로커 이메일이 포함됩니다. 모든 것을 측정하고, 일치하는 기준선(matched baseline)과 품질 가드레일(quality guardrails)을 옆에 두고 결과를 내면, 그 결과는 면밀한 심사를 통과할 것입니다. 2차 또는 3차 파일럿 단계의 추출 모델은 클럭을 연결하는 동안 SIE Cloud에서 실행될 수 있습니다.
