1 of 21

디지털 소외계층을 위한

LLM 기반

은행 대출상품 상담 챗봇

보금자리론·주택연금 등 정책자금 대출 중심

20249242 양준호

2 of 21

목차

1

연구배경 및 문제정의

디지털 소외계층 현황과 정책대출 상담의 비효율성

2

프로젝트 개요 및 데이터 구조

보금자리론·주택연금 기반 RAG 챗봇 개발

3

1차 개발 결과 및 문제점

RAG v1의 정확도 30~40% 수준과 원인 분석

4

개선안 도출 및 성능 향상

RAG v2 구조 개선으로 정확도 50~60% 달성

5

결론 및 향후 발전 방향

사내 상담 지원 활용 및 금융권 확장 가능성

2

3 of 21

연구배경 1: 디지털 전환과 고객 기대수준 상승

금융산업의 패러다임 전환

디지털, AI 기술 발전과 함께 금융산업은 비대면·모바일 중심으로 급속히 고도화

국내 은행의 모바일뱅킹 이용 비중은 92%에 달하며, 영업점 방문은 8% 이하로 감소

GPT 등 생성형 AI의 대중화로 고객들은 자연어 기반 상담과 즉각적인 응답을 기대

은행들은 영업점 축소와 인건비 최적화를 위해 AI 기반 상담 서비스 도입 경쟁

핵심 문제: 고객 기대 수준은 LLM 수준인데, 현행 챗봇은 Rule-based에 머물러 있습니다.

3

4 of 21

연구배경 2: 현행 챗봇의 한계

1

키워드 매칭 중심의 한계

주요 시중은행 챗봇은 Rule-based 시스템이 주류를 이루고 있음

정책금융·대출·세부 요건 등 복잡한 질문에 대해 오답과 부정확한

응답이 빈번하며, 문맥과 의도 파악에 실패

2

은행원의 상담 역량 보조 역할 부족 (사내 지식DB , 챗봇)

충분한 경험과 지식이 축적되기 이전까지는 DB 검색 도움을 받아 상담 수행

검색 결과 질문 주제와 무관한 페이지가 함께 노출되어 찾는데 시간 소요

3

고객 불편 증가

고객들은 결국 앱 메뉴를 직접 탐색해야 하며, 이는 시간과 노력의 증가로 이어짐

정보는 많지만 상담과 선택은 더 어려워진 역설적 상황

4

5 of 21

디지털 소외계층 현황과 문제의식

고령층

과기정통부·NIA 조사에 따르면 디지털 정보화 수준이 약 70~73%로 가장 낮은 계층 중 하나입니다.

장애인

2024년 장애인 실태조사 결과 금융서비스 비사용 집단이 59.7%에 달합니다.

디지털 역량 취약계층

저소득·저학력·농어촌 거주자 등이 포함되며, 농어민 70~80%대, 장애인 80%대, 저소득층 90%대 수준의 어려움을 겪고 있습니다.

"단순한 나이나 장애의 문제가 아니라, 복잡한 화면 구조, 작은 글씨, 어려운 금융 용어,

그리고 돈과 직결되는 실수에 대한 두려움이 핵심 요인입니다."

5

6 of 21

비즈니스 관점의 문제 정의

누구를 위한 챗봇인가?

현실적 접근

디지털 소외계층은 앱이나 키오스크를 직접 사용하기 어려운 계층입니다.

이들은 여전히 영업점과 콜센터 상담을 선호합니다.

따라서 본 프로젝트의 1차 포지셔닝은 "디지털 소외계층이 직접 사용하는 챗봇"이 아니라 직원이 먼저 사용하는 정책 대출 상담 보조툴입니다.

비즈니스 필요성

  • 복잡한 보금자리론·정책대출 규정을 직원이 빠르게 찾고 설명
  • 규정 변경·특례·예외조항이 잦아 지식 격차와 설명 편차 발생
  • 상담 품질과 일관성 제고를 위한 실질적 도구 필요

6

7 of 21

국내외 사례

국내 사례

  • 시니어 특화 점포
  • 도움드림창구
  • 1090 디지털금융교실
  • 디지털 튜터 양성

교육·전담창구 중심 접근

해외 사례

  • Barclays Digital Eagles
  • Talking ATM
  • Voice Bot

교육 + 접근성 강화 + 보조도구 결합

본 프로젝트의 목적

교육과 전담창구만으로는 한계가 있는 규정 이해와 설명을 직원용 LLM+RAG 챗봇으로 보완하는 POC(Proof of Concept)입니다.

7

8 of 21

프로젝트 개요 및 개발 범위

대상 도메인

한국주택금융공사(HF) 정책 대출

보금자리론 중심

기능 범위

  • 정책 대출 규정 질의응답
  • 대상/요건/한도/절차 안내
  • FAQ 기반 반복 질문 자동화

데이터 원천

  • HF 공공데이터
  • 정책 대출 안내문
  • 업무처리기준 요약본

Langflow

AstraDB

OpenAI LLM

8

9 of 21

1차 버전 시스템 구조 (RAG v1)

개선 전 아키텍처

1

질문 입력

2

Embedding

3

AstraDB 검색

상위 N개 Chunk 전달

4

OpenAI LLM

5

답변 생성

DB 구성

  • 업무처리기준 요약 텍스트 기반 CSV
  • Chunk 크기: 1,000자 수준
  • 최소 수준의 메타데이터

프롬프트 전략

  • "문서 밖 지식은 사용하지 말 것"
  • 정책 문서 내에서만 답변

핵심 특징

구조는 RAG지만, 데이터·프롬프트·Chunk 설계가 충분히 정교화되지 않은 초기 버전

9

10 of 21

1차 버전 성능 결과

왜 30~40%였나?

35%

정확도

Accuracy

0%

근거제시

Evidence

50%

안전성

Safety

질문 의도 오해

"1주택 기준은?" 질문에 DTI·연령 요건으로 엉뚱한 답변 제공

부적절한 Chunk 선택

핵심 규정이 분산된 상태에서 일부만 Retrieval

근거 부재

답은 그럴듯하지만, 어떤 조항에 근거했는지 알 수 없음

결론: RAG 구조는 갖췄지만, 실사용에는 미달하는 성능 (30~40%)

10

11 of 21

원인 분석 ①

DB·Chunk·테스트 설계의 한계

DB의 양과 구조적 한계

  • 업무기준 요약 텍스트 CSV에 의존
  • 항목/조항 단위로 충분히 세분화되지 않음
  • Chunk가 커서 문맥 단절·중복 포함 발생

Chunking·Overlap의 한계

  • 의미 단위가 아닌 기계적 분할
  • overlap이 있지만 필요한 문맥이 끊기는 경우 多
  • 실제 필요한 정보가 여러 Chunk에 분산

FAQ·테스트셋 설계 이슈

DB에 FAQ 형식의 문장과 테스트용 질문이 뒤섞일 경우 과적합과 정확도 왜곡 우려가 발생합니다. 테스트용 질문은 DB에서 제거하거나 다른 표현으로 설계해야 합니다.

11

12 of 21

원인 분석 ②

RAG 설계·프롬프트 전략의 한계

1

문서 밖 지식 제한의 부작용

"문서 밖 지식은 쓰지 말라" 프롬프트로 인해 문서가 부족한 영역에서는 GPT 일반 지식조차 활용하지 못하고 무의미한 답 생성

2

Retrieval-augmented hallucination

유사도가 낮은 Chunk도 함께 전달되어 LLM이 엉뚱한 근거로 그럴듯한 오답 생성

3

근거제시 모듈 부재

Chunk 내에서 근거 문장을 별도로 추출하지 않아 평가 단계에서 Evidence=0%로 측정됨

교수님 코멘트 반영: "왜 30~40%인지, RAG 구조·프롬프트·DB 설계를 기준으로 분석해야 한다"

12

13 of 21

Baseline 비교 프레임

Plain LLM vs RAG v1 vs RAG v2

RAG 도입의 실질적 효과를 검증하기 위해 세 가지 접근법을 비교 분석했습니다.

Plain LLM (비RAG)

OpenAI LLM에 HF 보금자리론을 설명해주는 시스템 프롬프트만 설정한 기본 모델

RAG v1 (개선 전)

초기 DB · Chunk · 프롬프트 구조를 적용한 버전

RAG v2 (개선 후)

질문유형 분류 + Chunk 재설계 + Evidence 모듈 + 검증 에이전트를 도입한 개선 버전

13

14 of 21

개선 방향 요약

무엇을 바꿨는가?

DB·Chunk 구조 개선

의미 단위 세분화 및 메타데이터 강화

질문유형 분류 도입

Question Type Classification으로 검색 공간 축소

프롬프트 정교화

외부지식 활용 전략 재설계

검증 에이전트 도입

자가보정 + Evidence 모듈 추가

14

15 of 21

개선 후 구조 (RAG v2)

시스템 플로우

1

질문 입력

사용자의 자연어 질문 수신

2

질문유형 분류

자격/대상/한도·금리/신청절차/서류 등으로 카테고리화

3

타겟 검색

유형별 문서 풀에서 Embedding + AstraDB 검색

4

핵심 추출

Parser로 핵심 조항만 추출, Evidence 후보 문장 전달

5

답변 생성

LLM이 답변 + 근거 동시 생성

6

자가보정

검증 에이전트가 DB와 일치 여부 재검증

핵심 개선: 질문을 먼저 분류하고 → 좁은 범위에서 찾고 → 근거와 함께 답변하는 구조로 고도화

15

16 of 21

개선 요소 ①

질문유형 분류 도입 효과

1차 답변 생성 노드

입력: 자연어 질문

출력: 카테고리 라벨

- 자격요건

- 대상자

- 주택요건

- 신청방법

- 제출서류

- 한도·금리

- 예외·특례

35%

분류 없음

정확도 30~40%

48%

분류 도입 후

정확도 45~50%

각 카테고리별로 미리 정의된 문서·Chunk 집합을 사용하여 Retrieval 검색 공간을 좁혀 "정확한 부분을 더 잘 찾도록" 유도했습니다.

16

17 of 21

개선 요소 ②

프롬프트 · Evidence · 검증 에이전트

프롬프트 정교화

  • 문서 분석 전문 AI 역할 부여
  • 문서와 상충 시 "문서 우선" 원칙
  • 해당 조항·장 제목까지 명시
  • 지어내기 금지 + 정보 부족 시 "모른다" 답변

Evidence 모듈

  • LLM이 답변과 함께 근거 출력
  • "어떤 Chunk·문장을 근거로 삼았는지" 제시
  • 평가 시 Evidence 점수 측정 가능

자가보정 에이전트

  • 1차 답변과 DB를 다시 대조
  • 일치도/신뢰도 점수 산출
  • 기준 미만 시 답변 반려 및 재생성

결과: Hallucination 감소 + 근거제시율 향상 → 정확도 체감도 상승

자가보정 에이전트 및 답변 산출 노드

17

18 of 21

개선 결과: 성능 비교

개선 전 vs 개선 후

정확도 (%)

Evidence (%)

20%p

정확도 향상

30~40% → 50~60%

65%

근거제시율

0% → 60~70%

한 줄 요약: 단순히 DB를 늘린 수준이 아니라, 질문 분류 + Chunk 구조 개선 + Evidence/검증 레이어 추가를 통해 정확도 30~40% → 50~60%로 유의미한 향상

18

19 of 21

개선 사례 예시

같은 질문, 다른 답변 품질

질문

"무주택자인데 보금자리론 신청 가능한 주택 종류가 어떻게 되나요?"

RAG v1 답변 특징

  • 채무자 자격/연령 요건 위주로 엉뚱한 설명
  • 구체적인 주택 종류 구분 없음
  • 근거 조항 미표시

RAG v2 답변 특징

  • 질문을 "주택요건" 유형으로 분류
  • 주택 종류별 허용/제한사항 정리 제시
  • "○○규정 제○조(주택요건)에 근거" 출처 표시

현장 시사점: 직원이 바로 고객에게 설명·프린트·문자 전송할 수 있을 만큼 사용 가능한 수준의

답변 품질로 개선되었습니다.

DB에 적재된 상품 관련 질문

DB에 없는 상품 관련 질문

19

20 of 21

비즈니스 관점의 효과

직원용 툴로서의 가치

업무 효율 측면

직원이 복잡한 규정집을 직접 찾아보는 시간을 단축하고, 반복 질문에 대해 빠르고 일관된 설명이 가능합니다.

리스크 관리 측면

정책 근거에 기반한 설명으로 "임의 해석"에 따른 민원·분쟁 리스크를 완화하며, 향후 규제기관 문의나

내부 감사 시에도 근거 추적이 가능합니다.

디지털 소외계층 간접 지원

소외계층 고객은 여전히 창구를 선호하지만, 직원 뒤에 LLM+RAG 챗봇이 붙음으로써 더 정확하고 이해하기

쉬운 설명을 제공할 수 있습니다.

20

21 of 21

감사합니다