월요일 아침, 지급심사 한 건은 이렇게 흘러간다. 청구서와 진단서를 펼치고, 해당 담보가 어느 약관 조항에 걸리는지 찾고, 면책 사유와 대조하고, 비슷한 분쟁조정례까지 떠올려 본다. 베테랑이 머릿속 지도로 5분에 끝내던 길에서, 신입은 "어느 조항부터 봐야 하나"에서 멈춘다. 약관 조항 하나 짚는 데 40분, 그 사이 청구는 계속 쌓인다.
진짜 문제는 사람이 빠져나가는 속도다. 숙련 심사역은 은퇴·이직으로 줄어드는데 언더라이팅(인수심사)과 지급심사 청구 물량은 줄지 않는다. 1인당 처리 건수는 이미 한계선에 닿아 있다. 약관·청구·시책 같은 비정형 문서를 사람의 기억에만 의존하던 방식이 버티지 못하는 지점이다. 그래서 약관 RAG 지식 엔진을 검토하는 회사가 늘었다. 다만 결정은 "도입하느냐"가 아니라 "온프레미스냐 SaaS냐"에서 갈린다.
도입 형태부터 정해야 하는 이유
같은 엔진이라도 온프레미스로 들이느냐 구독형(SaaS)으로 쓰느냐에 따라 비용 구조, 데이터 동선, 운영 책임이 통째로 달라진다. 알티스(RT'S) 보험 도메인 팩 — RAG 지식 엔진이 원수·대형 보험사용 온프레미스형과 GA(법인보험대리점)·중소형·디지털 보험사용 SaaS형을 모두 제공하는 것도 이 때문이다. 중요한 건 "어느 쪽이 더 좋은가"가 아니라 "우리 회사 상황에서 어느 쪽이 답인가"다. 답을 가르는 변수는 다섯 개다.
온프레미스냐 SaaS냐를 가르는 5가지 판단 변수
| 판단 변수 | 온프레미스가 맞는 회사 | SaaS가 맞는 회사 |
|---|---|---|
| ① 문서 민감도·폐쇄망 | 주민번호·진단서·내부 인수지침이 망 밖으로 못 나가고 망분리·폐쇄망이 의무 | 다루는 문서가 공시·공개 자료 위주이거나 민감정보를 비식별·동의 범위로 처리 가능 |
| ② 월 물량·트래픽 변동성 | 심사·청구 물량이 크고 꾸준해 자원을 상시 점유 | 물량이 작거나 시책·계절에 따라 변동이 커 상시 인프라가 비효율 |
| ③ 내부 인프라·MLOps 인력 | 자체 데이터센터와 운영·MLOps 인력 보유 | 운영 인력이 없거나 핵심 심사 업무에 집중하고 싶음 |
| ④ TCO·도입 속도 | 장기 보유로 감가상각이 유리하고 구축 기간을 감수 가능 | 초기 구축비를 최소화하고 빠르게 시작하는 것이 우선 |
| ⑤ 약관·시책 업데이트·재학습 책임 | 개정이 잦아 내부 규정 변경을 직접 통제하려 함 | 업데이트와 재학습을 공급사 SLA로 위임하려 함 |
자가진단은 단순하다. 다섯 줄 중 왼쪽이 셋 이상이면 온프레미스, 오른쪽이 셋 이상이면 SaaS에 무게가 실린다. 단, ①번 폐쇄망 요건은 가중치가 다르다. 망 밖 반출이 원천 금지라면 나머지가 어느 쪽이든 온프레미스가 출발점이고, 폐쇄망 요건만 충족된다면 온프레미스 엔드포인트로 푸는 절충도 검토할 수 있다.
출처를 함께 내놓는 RAG가 심사에서 결정적인 이유
범용 LLM은 그럴듯한 답을 내지만 근거를 묻기 어렵다. 심사는 다르다. 답이 맞느냐만큼 "왜 그렇게 판단했는가"가 중요하다. 알티스 RAG 지식 엔진이 답변과 함께 근거가 된 약관 조항·법령 출처(예: 약관 제15조, 상법 제651조의2)를 제시하는 이유가 여기에 있다. 이 한 줄의 출처가 세 군데서 일한다. 첫째 감사 추적 — 나중에 "이 건은 무엇을 근거로 부지급했나"를 추적할 때 조항이 그대로 남는다. 둘째 분쟁 대응 — 분쟁조정·소송 국면에서 인용 조항과 기준일이 곧 방어 논리가 된다. 셋째 신입 교육 — 신입이 답만 받는 게 아니라 "이 답이 어느 조항에서 나왔는지"를 같이 보며 베테랑의 판단 경로를 학습한다. 물론 심사 의견은 어디까지나 초안·검토 보조이고, 최종 판단은 담당자(사람)의 몫이다.
당장 이번 주에 할 수 있는 4단계
1. 가장 병목인 업무 1개부터 고른다. 한 주간 팀이 어느 단계에 가장 많은 시간을 쏟는지 측정하라. 약관 찾기가 병목이면 약관 QA, 청구서류 입력이 병목이면 서류 판독, 시책 공문 해석·정산이 병목이면 시책 파서다. 한 번에 다 깔지 말고 가장 아픈 곳 하나만 정한다.
2. 모듈 단위로 순서를 잡는다. 알티스 엔진은 약관·규정 QA, 보장분석, 서류 판독, 시책 파서를 모듈로 나눠 급한 업무부터 도입할 수 있다. 1단계에서 고른 그 업무를 첫 모듈로 두고, 효과가 확인되면 인접 업무로 넓힌다.
3. 4주 PoC로 검증 항목과 합격 기준을 못 박는다. "좋아 보인다"가 아니라 숫자로 판정해야 한다.
| 검증 항목 | 측정 방법 | 합격 기준(팀이 합의해 설정) |
|---|---|---|
| 약관 조항 인용 정확도 | 답변이 제시한 조항이 실제 근거와 일치하는 비율 | 예: 95% 이상 |
| 심사 의견 초안 채택률 | 초안을 무수정·소폭 수정으로 채택한 비율 | 예: 70% 이상 |
| 출처 추적 가능성 | 모든 답변에 조항·법령·기준일이 붙는가 | 예: 100% |
| 처리 시간 | 한 건 처리 시간(현행 대비) | 현장 기준으로 설정 |
4. 도입 형태별 체크리스트로 마지막을 점검한다.
온프레미스 체크리스트 — 폐쇄망·망분리 환경에서 엔드포인트 정상 동작 확인 / 학습·추론 전 과정 데이터 반출 0 보장 / GPU·스토리지 사양과 운영 인력 확보 / 약관·시책 개정 시 재학습 절차와 책임 주체 명문화.
SaaS 체크리스트 — 데이터 처리 위치·보관 기간·삭제 정책 계약 명시 / 개인정보·진료정보는 본인 인증·동의 범위 원칙 확인 / SLA 항목(가용성·응답시간·장애 복구·지원 시간) 확정 / 약관·시책 업데이트 반영 주기 합의 / 폐쇄망 요건 발생 시 온프레미스 엔드포인트 옵션 검토.
정리
온프레미스가 더 안전하고 SaaS가 더 싸다는 식의 일반론은 현장에서 통하지 않는다. 다섯 가지 변수에 우리 회사 상황을 대입해 답을 갈라내고, 가장 아픈 업무 하나를 4주 PoC로 숫자 검증한 뒤 모듈 단위로 넓히는 순서가 현실적이다. 어느 형태로 가든, 답변에 근거 조항과 기준일이 따라붙어야 감사·분쟁·교육에서 제값을 한다는 점은 같다.
도입 형태 판단이나 4주 PoC 범위가 고민이라면 [email protected] / 070-7715-5789로 문의하거나 ins.aixis.kr에서 확인할 수 있다. 최종 판단은 언제나 담당자의 몫이며, 그 판단을 더 빠르고 근거 있게 만드는 것이 이 엔진의 역할이다.