RAG2026-5일31차시 · 예외 처리 설계5 / 19← 이전목차다음 →MetaContents

31차시. 예외 처리 설계

2. 부분 실패를 허용하는 설계

출처: 원본 PDF 31차시_방어적코딩실습.pdf 5~6쪽 · 쪽 그림 5쪽 6쪽

이번 차시의 핵심 사고방식입니다.

2-1) 전부 아니면 전무 vs 부분 성공

출력
■ 전부 아니면 전무 (나쁨)
──────────────────────────────────────
검증 실패 → 예외 → 아무것도 못 줌

■ 부분 성공 (좋음)
──────────────────────────────────────
검증 실패 → 검증 없이 답변 제공
          + "이 답변은 검증되지 않았습니다" 표시

🏥 응급실 비유
CT 촬영 장비가 고장 났다고
환자를 돌려보내지 않습니다.
· 촬영 없이 할 수 있는 처치는 합니다
· "정밀 검사는 못 했습니다"라고 알립니다
· 필요하면 다른 병원을 안내합니다
할 수 있는 만큼은 하고, 못 한 것은 알린다.
이것이 Graceful Degradation입니다.

2-2) 단계별 부분 실패 정책

실패 단계남아 있는 것정책
분류 실패질문document로 간주하고 진행
검색 실패없음재작성 시도 → 안 되면 안내
생성 실패근거 문서근거 원문을 그대로 보여줌
검증 실패답변 + 근거답변 제공 + 미검증 표시
재작성 실패이전 검색 결과있으면 그것으로 생성 시도

💡 생성 실패 시 근거 원문을 보여준다?
의외로 유용합니다.
"답변 생성에 실패했습니다. 대신 관련 자료를 보여드립니다."
[1] 이용약관 4페이지
"환불은 상품 수령 후 7일 이내에 신청..."
사용자가 직접 읽고 판단할 수 있습니다.
아무것도 안 주는 것보다 훨씬 낫습니다.

← 이전 절31차시 · 1. 시스템이 커질수록 실패 지점도 늘어난다다음 절 →31차시 · 3. Fallback 계층화