31차시. 예외 처리 설계

4. 왜 안내 문구를 나누는가

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

사용자 입장에서 생각해보면 명확합니다.

상황	획일적 안내	계층화된 안내
문서에 없는 주제	"찾지 못했습니다"	"문서에 없을 가능성이 높습니다. 담당 부서 문의"
API 한도 초과	"찾지 못했습니다"	"요청이 많습니다. 잠시 후 재시도"
시스템 오류	"찾지 못했습니다"	"일시적 오류입니다. 관리자 문의"

🎯 사용자의 다음 행동이 달라집니다
"찾지 못했습니다"만 보면
→ 질문을 계속 바꿔가며 시도합니다
→ 사실 API 한도 문제였다면 헛수고입니다
"요청이 많습니다"를 보면
→ 잠시 기다렸다 다시 시도합니다
→ 적절한 행동을 하게 됩니다
정확한 안내는 사용자의 시간을 아껴줍니다.

4-1) 미검증 답변 처리

출력

■ 27차시 방식
검증 실패 + 상한 도달 → END (답변 그대로, 표시 없음)

■ 31차시 방식
검증 실패 + 상한 도달 → fallback(unverified)
                       → 답변 유지 + verified=False
                       → 화면에서 경고 표시

■ 화면 출력 예시
⚠ 아래 답변은 자동 검증을 통과하지 못했습니다.
   내용을 원문과 대조해 확인해주세요.

환불은 상품 수령 후 7일 이내에 신청하실 수 있습니다[1].

📎 참고: 이용약관.pdf 4페이지

💡 불확실성을 숨기지 않는 것이 신뢰의 조건
"확실하지 않은 답을 확실한 척 주는 것"이
"확실하지 않다고 말하는 것"보다 훨씬 나쁩니다.
사용자가 판단할 수 있게 정보를 주세요.