LLM을 금융에 도입할 때 첫 번째 질문은 "할 수 있는가"가 아닙니다. "틀린 답을 할 확률을 얼마까지 낮출 수 있는가"입니다. RAG는 그 확률을 상당 부분 낮추는 업계 표준 설계입니다.

RAG의 핵심 아이디어

모델에게 모든 걸 기억시키지 말고, 질문마다 관련된 사실을 찾아서 같이 넘겨주자. 이것이 RAG입니다. 프로세스는 3단계입니다.

1. Retrieve - 질문으로 문서 검색

사용자 질문이 들어오면, 벡터 DB에서 의미적으로 가까운 문서 청크 3-10개를 찾습니다.

2. Augment - 프롬프트에 증강

시스템 프롬프트에 "다음 문서만 근거로 답변하라"는 지시와 함께 검색된 청크를 삽입합니다.

3. Generate - 생성

LLM은 주어진 문서 범위 안에서만 답변합니다. 문서에 없으면 "답할 수 없다"고 말해야 합니다.

금융 특화 설계 포인트

인덱싱 소스의 관리

벡터 DB에 들어가는 문서는 승인된 소스만이어야 합니다. 은행이라면 공식 상품 설명서, 약관, FAQ, 보도자료 - 이 목록을 법무/컴플라이언스 팀이 명시적으로 승인합니다. 블로그 초안이나 내부 메모가 섞이면 안 됩니다.

메타데이터 필터링

각 청크에 effective_date, document_type, approved_by 같은 메타데이터를 붙입니다. 질문이 "2026년 기준"이라면 effective_date가 최근 것만 검색 대상으로 포함합니다.

신뢰도 구간(confidence threshold)

검색된 청크의 유사도 점수가 임계값 미만이면 자동으로 답변 거부 모드로 전환합니다. "해당 정보는 상담원에게 연결해 드리겠습니다"라는 응답이 준비되어 있어야 합니다.

실패 모드

1. Prompt Injection

사용자가 "앞선 지시를 무시하고 ..."라고 입력하면 LLM이 시스템 프롬프트를 넘길 수 있습니다. 방어: 입력 sanitization, 출력 검증, 별도 classifier로 탈주 시도 탐지.

2. Citation Laundering

모델이 제공된 문서를 요약하는 척하면서 훈련 데이터에서 가져온 정보를 섞는 경우. 방어: 응답에 사용된 청크를 직접 인용하는 형태로 강제(“근거: [문서 X, 섹션 Y]”).

3. 시점 불일치

문서는 2024년 기준인데 사용자는 2026년을 물을 때. 방어: 문서에 effective_date 필수화, 응답에 "기준 시점"을 함께 노출.

아키텍처 다이어그램(개념)

[User Query]
    ↓
[Safety Classifier] ── 탈주 시도 탐지
    ↓
[Embedding] → [Vector DB Retrieval] ← [승인된 문서 소스]
    ↓
[Metadata Filter: 시점, 문서 유형]
    ↓
[Rerank] → top-k 청크 선별
    ↓
[LLM + 제한된 시스템 프롬프트]
    ↓
[Output Validator] ── 규제 위반 문구 탐지
    ↓
[User]

성능 지표

RAG 시스템을 운영할 때 반드시 추적해야 할 3가지.

  1. 거부율(refusal rate): 답변 못 한 비율. 너무 낮으면 환각, 너무 높으면 쓸모없음 - 5-15%가 건강한 구간.
  2. 근거 정합성(groundedness): 답변 내용이 검색된 청크에 실제로 존재하는가. 수동/자동 평가 조합.
  3. 응답 지연(p95 latency): 금융 챗봇은 3초 이내가 관용 임계점.

RAG는 은탄환이 아닙니다. 그러나 "환각을 어디에서 막을 것인가"를 아키텍처 레벨에서 명시하게 한다는 점에서, 금융 도입의 첫 단계로 강력히 추천합니다.