인사이트

API·데이터

출처는 맞는데 옛날 약관? 폐쇄망 RAG의 함정

출처를 인용하는 약관 RAG도 폐쇄망에서는 환각을 낸다. 인용한 조항이 구버전이면 출처는 맞고 내용은 틀리기 때문이다. 기준일·개정 이력을 따라잡는 API·데이터 허브로 최신성 공백을 메우는 점검 체크리스트와 도입 단계를 정리했다.

폐쇄망에 약관 RAG를 올린 한 심사팀의 이야기로 시작해 보겠습니다. 설계사가 "갑상선 결절로 청구된 건이 면책 대상인가"를 묻자, 시스템은 망설임 없이 "약관 제15조에 따라 보장개시일로부터 90일 면책"이라고 답했습니다. 근거 조항까지 또박또박 인용했으니 담당자는 그대로 신뢰했습니다. 문제는 그 약관 제15조가 6개월 전 구버전이었다는 점입니다. 개정본에서는 면책 관련 문구가 바뀌어 있었고, 결과적으로 출처는 정확한데 내용은 틀린 답이 나갔습니다.

이것이 폐쇄망 RAG에서 가장 잡아내기 어려운 환각입니다. 출처가 비어 있으면 사람이 한 번이라도 의심하지만, 그럴듯한 조항 번호가 붙어 있으면 검증 단계를 건너뛰게 되기 때문입니다. 보안 심의·폐쇄망 요건 때문에 일반 클라우드 SaaS 도입이 막혀 있는 보험사·GA(법인보험대리점) 현장이라면 이 함정은 한층 더 깊어집니다.

약관 조항 인용에 기준일과 개정 회차가 함께 표시되는 폐쇄망 RAG 응답 화면 개념도

출처 인용은 왜 환각을 줄이는가, 그리고 어디서 멈추는가

근거 조항과 법령 출처(예: 약관 제15조, 상법 제651조의2)를 답변과 함께 제시하는 RAG의 강점은 분명합니다. 답이 어느 문서의 어느 조항에서 나왔는지 추적할 수 있으니, 담당자가 원문을 펴서 곧바로 대조할 수 있습니다. "근거를 못 대는 답"이 줄어드는 만큼 환각도 줄어듭니다.

다만 여기에는 경계가 있습니다. 출처 인용은 "이 문장이 어느 조항에서 나왔는가"는 보장하지만, "그 조항이 지금 유효한 최신 개정본인가"는 보장하지 않습니다. 즉 출처를 인용한다는 사실만으로 환각이 사라지는 게 아니라, 인용된 그 출처가 최신본인가가 환각 여부를 가릅니다. 환각의 무게중심이 '출처의 존재'에서 '출처의 기준일'로 옮겨가는 셈입니다.

폐쇄망의 진짜 함정은 '최신성 공백'

폐쇄망은 정의상 인터넷이 끊겨 있습니다. 보안상 당연한 구성이지만, 그 대가로 약관 공시·법령·감독규정·분쟁조정례가 자동으로 갱신되지 않습니다. 처음 적재한 문서가 그대로 굳어버리고, 6개월 뒤 개정이 일어나도 폐쇄망 안의 RAG는 그 사실을 알 길이 없습니다.

여기에 응답이 기준일과 개정 이력을 함께 찍어주지 않으면, 구버전 인용을 사람이 알아챌 방법이 사라집니다. 조항 번호는 그대로 제15조이고, 글자도 멀쩡해 보이니까요. 폐쇄망 RAG 도입의 성패는 결국 "끊긴 망 안에서도 근거 데이터를 어떻게 따라잡게 할 것인가"라는 공급선 설계에 달려 있습니다.

API·데이터 허브로 최신성 공백을 메우는 구조

이 문제는 두 갈래의 공급선으로 풉니다.

첫째, AI API입니다. 보장분석·약관 QA·서류 판독 같은 엔진을 REST·웹훅으로 기존 심사 화면에 임베드하되, 폐쇄망 요건에는 온프레미스 엔드포인트로 제공합니다. 화면을 새로 만들 필요 없이 쓰던 심사 시스템 안에서 호출하고, 망 밖으로 데이터가 나가지 않는 구성을 유지합니다.

둘째, 데이터 API입니다. 상품·약관 공시, 법령·감독규정, 분쟁조정례 같은 공개·공시 데이터를 출처·기준일·개정 이력과 함께 정제해 증분 공급합니다. 핵심은 이 공급선이 폐쇄망 안에서도 최신 근거가 따라잡히게 만든다는 점입니다. 전체를 다시 밀어 넣는 방식이 아니라 바뀐 부분만 증분으로 흘려보내므로, 끊긴 망이라는 제약 아래서도 근거 데이터의 시차를 줄일 수 있습니다.

출처 인용 RAG 폐쇄망 도입 점검 체크리스트

도입 전, 다음 항목을 그대로 점검표로 써 보시기 바랍니다.

  • 데이터 출처별로 기준일·개정 이력이 응답에 노출되는가
  • 증분 갱신 주기와 SLA가 문서로 명시돼 있는가
  • 구버전을 인용했을 때 경고가 표시되는가
  • 온프레미스 엔드포인트가 망분리 구성 요건을 충족하는가
  • 응답에 조항 원문·기준일·개정 회차가 함께 찍히는가

다섯 항목 중 하나라도 비면, "출처는 있는데 최신인지는 모르는" 답이 그대로 심사 화면에 노출됩니다.

단계별 도입 액션

  1. 현행 인용 응답에서 기준일 누락을 먼저 진단합니다. 지금 쓰는 답변에 기준일·개정 회차가 없다면, 그것이 첫 번째 리스크입니다.
  2. 데이터 API 증분 공급을 연결해, 약관 공시·법령·감독규정·분쟁조정례의 최신본이 폐쇄망 안으로 따라 들어오게 합니다.
  3. AI API를 온프레미스 엔드포인트로 기존 심사 화면에 임베드합니다.
  4. 개정본 회귀 테스트를 돌립니다. 구버전 질문 세트를 개정 후 다시 던져, 답과 기준일이 바뀌는지 확인합니다.

응답에 기준일이 찍히면 이렇게 달라진다

같은 질문이라도 메타데이터가 붙으면 판단의 질이 달라집니다.

질문: 갑상선 결절로 청구된 건, 면책 기간 적용 대상인가?

응답:

  • 답변(검토 보조): 보장개시일로부터 90일 면책 조항 적용 여부를 확인 대상으로 표시
  • 근거: 약관 제15조(보장개시일 및 면책기간) · 기준일 2026-03-01 · 개정 3차
  • 법령: 상법 제651조의2 · 기준일 2026-01-01
  • 알림: 2026-06-01자 개정 4차가 데이터 API로 수신됨 → 본 답변은 재확인 필요(구버전 인용 경고)

이렇게 출력되면 담당자는 "출처가 있다"가 아니라 "이 출처가 오늘 기준으로 유효한가"를 한눈에 판단합니다. 그리고 면책 적용 여부의 최종 판단은 언제나 담당자(사람)의 몫으로 남습니다. 자동화는 근거와 기준일을 가지런히 정리해 검토를 돕는 데까지입니다.

정리

폐쇄망 RAG에서 환각을 가르는 것은 출처의 유무가 아니라 출처의 기준일입니다. 인용된 조항이 최신 개정본인지, 그리고 그 사실이 응답에 함께 찍히는지가 신뢰의 분기점입니다.

알티스(RT'S) 보험 도메인 팩의 API·데이터 허브는 이 최신성 문제를 풀기 위한 선택지 중 하나입니다. AI API는 약관 QA·보장분석·서류 판독 엔진을 온프레미스 엔드포인트로 기존 화면에 붙이고, 데이터 API는 공개·공시 데이터를 출처·기준일·개정 이력과 함께 증분 공급해 끊긴 망 안에서도 근거가 따라잡히게 합니다. 폐쇄망 요건 아래 약관 RAG의 최신성 공백이 고민이라면, 현행 응답의 기준일 누락 진단부터 함께 점검해 보시기 바랍니다.

도입 문의: [email protected] / 070-7715-5789

보험 문서 자동화, 직접 검토해 보세요

우리 약관과 업무에 어떻게 적용되는지 궁금하다면, 짧은 상담으로 시작할 수 있습니다.