[멋쟁이사자처럼] RAG챗봇 프로젝트 00. 개요

About this offer

예금보험공사 RAG 챗봇 프로젝트 1. 프로젝트 한눈에 보기 프로젝트명 4MATION — 예금보험공사 데이터 관리체계 고도화 및 생성형 AI 서비스 구축 (PoC) 한 줄 소개 두 사이트에 흩어진 예보 안내 데이터를 통합하고, 출처를 붙여 답하는 자연어 챗봇 기간 2026.07.10 ~ 2026.09.02 (8주) 팀 4명 · LikeLion AI/NLP 5기 × 클라비 기업연계 기술 Python, FAISS, BM25, 하이브리드 검색, HyperCLOVA X, FastAPI Repository likelion-4MATION/4MATION 2. 왜 시작했는가 예보에는 이미 챗봇이 있습니다. '예솜24'라는 키워드 매칭 기반 카드형 챗봇입니다. 제시된 카드를 눌러 내려가면 답에 닿는데, 정의된 동작과 키워드를 벗어난 질의에는 대응하지 못합니다. 사용자가 자기 질문이 어느 카드 아래 있는지를 이미 알아야 한다는 게 문제입니다. "은행이 망했는데 제 돈 어떻게 되나요"는 예금자보호제도일 수도, 예금보험금 안내일 수도 있습니다. 예보 내부에서는 다른 업무지만 묻는 사람에게는 하나의 질문입니다. 데이터도 두 사이트에 흩어져 있습니다. www.kdic.or.kr 과 fins.kdic.or.kr . 같은 주제가 안내 페이지형과 FAQ 게시판형으로 따로 존재하고, 어느 쪽이 최신인지 사이트만 봐서는 알기 어렵습니다. 제공 데이터셋도 없었습니다. 로우데이터가 웹사이트 자체였고, 크롤링부터가 과제였습니다. 그리고 이 도메인은 돈과 법입니다. 과제 문서에 이렇게 적혀 있었습니다. 예금보험 도메인은 금액·수수료·기간 등 조건부 정보가 많아, 근거 없는 단정 답변이 민원 리스크로 직결 예금자보호한도는 2025년 9월에 5천만원에서 1억원으로 올랐습니다. 그런데 사이트 일부 페이지에 아직 5천만원이 남아 있었습니다. 그래서 목표를 "그럴듯한 답"이 아니라 "근거 있는 답" 으로 잡았습니다. 3. 무엇을 해결하려는가 사용자는 예보 사이트에 들어왔지만 어느 메뉴로 가야 할지 모르는 민원인입니다. 대상은 6개 업무입니다. 예금자보호제도, 예금보험금 안내, 고객 미수령금 신청, 착오송금 반환지원, 채무조정 안내, 은닉재산 신고. 착수 전 사이트 분석에서 필수 33페이지, 분석 필요 16페이지가 후보로 잡혔습니다. 6개는 서로 독립적이지만 문장이 닮았습니다. "신청 기한", "구비 서류", "수수료"가 업무마다 다 있습니다. "신청 기한 알려줘"를 구분 없이 검색하면 착오송금의 기한과 채무조정의 기한이 같이 나옵니다. 과제가 요구한 산출물은 다섯 가지였습니다. 6개 업무 검색 범위 정의서 및 수집 코퍼스 (계층 메타데이터 포함) 6개 업무 질의에 답하는 RAG 챗봇 (출처 표시·민원 처리 안내 포함) 관리자 트리거 기반 수집·전처리·적재 파이프라인 RAG 파라미터(Top-K, Chunk Size 등)를 테스트하는 관리자 UI 평가 테스트셋 및 성능 평가 리포트 다루지 않기로 한 범위는 팀이 정했습니다. 개인별 사안 판정("제 계좌 지금 어떻게 됐나요")은 문서로 답할 수 없어 상담 연결로 넘깁니다. 개인회생·파산면책은 법원, 신용회복은 신용회복위원회 소관이라 담당 기관을 알려주는 쪽을 택했습니다. 문제 정의 자기 상황이 어느 업무인지 모르는 민원인이 카드 앞에서 막히는 문제를, 출처를 명시한 자연어 답변과 소관 판정으로 해결한다. 4. 어떤 원칙으로 만들 것인가 과제의 답변 원칙 세 가지가 그대로 설계 기준이 됐습니다. 출처 표시 — 모든 답변에 근거 페이지 URL을 함께 제공 민원 처리 안내 — 절차 안내 → 서류 양식 다운로드 → 신청 페이지 연결 환각 방지 — 근거가 없으면 지어내지 않고, 모른다는 사실과 문의 경로를 안내 만들면서 시간이 가장 많이 든 쪽은 답을 잘하는 기능이 아니라 틀린 답을 막는 기능이었습니다. 카드형 챗봇을 걷어내면 잃기 쉬운 게 정확히 이 부분입니다. 카드는 없는 답을 지어내지는 않으니까요. 5. 시스템 전체 그림 과제는 프로젝트 3개가 누적되는 구조였습니다. 실전1이 만든 데이터를 실전2가 검색·답변에 쓰고, 종합 프로젝트가 그 둘을 제어합니다. 1 데이터 파이프라인 (실전1) 웹사이트 → 본문 추출 → 메타데이터 태깅·청킹 → 색인 ↓ 2 RAG 챗봇 (실전2) 질문 → 업무 분류 → 검색 → LLM 답변(출처 표시) → 검증 ↓ 3 관리자 콘솔 (종합) ├ 데이터 CRUD · 재수집 트리거 → 1로 └ RAG 파라미터 조정·테스트 → 2로 층을 나눈 덕에 챗봇이 틀렸을 때 어디가 틀렸는지 따로 잴 수 있었습니다. 원문을 잘못 잘랐는지, 엉뚱한 조각을 찾았는지, LLM이 근거를 벗어났는지가 구분됩니다. 6. 어떻게 개발할 것인가 Milestone 1 — 데이터 파이프라인 목표 두 사이트를 결정론적으로 텍스트화하고, 계층 메타데이터를 붙여 색인한다 완료되면 크롤링→파싱→청킹→색인이 한 명령으로 돌고, 바뀐 페이지만 다시 받는다 Milestone 2 — RAG 챗봇 목표 6개 업무 자연어 질의에 출처를 붙여 답한다 완료되면 민원 처리 질문에 절차·서류·신청 페이지까지 이어지는 답변이 나간다 Milestone 3 — 관리자 콘솔 목표 비전공자 관리자가 코드 없이 데이터와 파라미터를 다룬다 완료되면 파라미터 변경 전후를 화면에서 비교하고 재수집을 직접 돌린다 과제 문서에는 계층 필터링, Parent-Child Retrieval, HyDE 같은 설계 예시가 함께 들어 있었습니다. 다만 "확정 설계가 아니며 실제 설계는 팀이 정의한다"는 단서가 붙어 있었고, 진행하면서 이 중 몇 가지는 다시 판단하게 됐습니다. 그 이야기가 이 시리즈의 대부분입니다. 7. 내 역할과 기대 확인하고 싶은 건 "RAG의 정확도 문제가 검색기가 아니라 측정에 있는가" 입니다. 검색 성능을 올리는 작업과 성능을 제대로 재는 작업 중 어느 쪽이 실제 병목인지를 보고 싶었습니다. 가장 어려울 거라 예상한 부분은 한국어 검색 성능입니다. 6개 업무의 문장이 서로 닮아 있어서, 의미 검색이 업무 경계를 넘어버리는 상황이 자주 나올 것 같았습니다. 마무리 PoC의 목적은 사업화 전에 기술적 타당성을 확인하는 것입니다. 그래서 이 시리즈도 "됐다"보다 "되게 만들려면 무엇이 먼저인가"를 기록하는 쪽으로 쓰려고 합니다.