4장. 실패 대응과 사람의 감독

학습 목표

• 지어낸 답, 거절, 형식 오류, 일시적 장애를 구분하고 유형마다 예방책과 실패 시 대응을 설계한다.
• 재시도, 대기열, 대체 경로, 단계적 축소, 기능 중지 가운데 장애의 길이와 기능의 성격에 맞는 대응을 고른다.
• 오류의 되돌림 가능성, 처리량, 위험한 부분집합을 기준으로 사람의 개입 지점(사전 승인, 조건부 이관, 사후 점검, 이의 제기)을 정한다.
• 검토자가 실질적으로 판단할 수 있도록 판단 근거와 수정·거부 권한, 기록을 설계한다.
• 이용자 고지, 신뢰 보정, 피드백과 통제 장치를 법적 의무와 사용자 경험의 관점에서 설계한다.

들어가며

한 쇼핑몰의 AI 상담 봇이 어느 날 "이 상품은 구매 후 60일 안에 무료 반품됩니다"라고 안내했습니다. 실제 규정은 14일이었습니다. 봇은 오류를 내지 않았고, 응답도 빨랐고, 말투도 친절했습니다. 시스템의 모든 지표가 정상이었지만, 고객 수백 명은 잘못된 기한을 믿고 행동했습니다. AI 기능의 실패는 대개 이렇게 조용합니다.

기존 소프트웨어의 실패는 오류 화면으로 드러납니다. AI의 실패는 그럴듯한 답으로 숨습니다. 그래서 AI 기능의 기획에는 두 가지가 반드시 들어가야 합니다. 첫째는 실패를 유형별로 나눠 각각을 줄이고 실패했을 때의 동작을 정하는 일입니다. 둘째는 사람이 어디서 어떻게 개입할지 정하는 일입니다. OpenAI는 가능하면 결과를 실제로 쓰기 전에 사람이 검토하도록 권하고, 위험이 큰 영역일수록 이것이 중요하다고 강조합니다. 하지만 모든 곳에 사람을 둘 수는 없으므로, 어디에 둘지를 고르는 것이 기획입니다.

이 장은 먼저 실패의 네 유형과 각각의 대응을 보고, 장애가 길어질 때의 대체 경로와 단계적 축소를 다룹니다. 그다음 사람의 개입 지점을 고르는 기준과 검토자에게 줄 권한을 정리하고, 마지막으로 이용자 고지와 피드백 장치를 설계합니다.

핵심 개념

실패는 기획의 일부다

AI 기능의 실패는 크게 네 유형으로 나눌 수 있습니다.

Google PAIR 가이드는 오류를 시스템 한계, 맥락 오류, 배경 오류로도 나눕니다. 특히 배경 오류는 시스템이 제대로 작동하지 않는데 사용자도 시스템도 오류로 인식하지 못하는 경우로, 지어낸 답이 대표적입니다. 사용자가 모르는 실패는 사용자 피드백으로 잡히지 않으므로, 설계와 운영 지표로 잡아야 합니다. 일시적 장애는 대응을 정할 때 다시 길이로 나눕니다. 몇 초 만에 풀리는 장애와 복구 시점을 알 수 없는 긴 장애는 대응이 전혀 다르기 때문에, 뒤의 대응표는 네 유형을 다섯 행으로 펼쳐 씁니다. 악의적인 입력으로 지시를 우회하는 프롬프트 인젝션 같은 보안 실패도 있습니다. 이 과정에서는 깊이 다루지 않지만, 외부 입력을 받는 기능이라면 보안 검토 결과를 이 대응표에 함께 올립니다.

지어낸 답

지어낸 답(할루시네이션)은 모델이 사실과 다르거나 주어진 맥락과 맞지 않는 내용을 그럴듯하게 만들어 내는 현상입니다. Claude 문서는 이를 줄이는 기본 전략으로 세 가지를 듭니다.

1. "모른다"고 말할 수 있게 한다. 불확실성을 인정해도 된다고 명시적으로 허락하면 거짓 정보를 크게 줄일 수 있다.
2. 직접 인용으로 근거를 잡는다. 긴 문서(Claude 문서의 예로는 2만 토큰 이상)를 다룰 때 먼저 관련 문장을 그대로 뽑게 하고, 그 인용에 근거해 답하게 한다.
3. 인용으로 검증한다. 주장마다 근거 인용을 붙이게 하고, 근거를 찾지 못한 주장은 철회하게 한다.

고급 기법으로는 추론 과정 점검, 같은 질문을 여러 번 돌려 결과를 비교하는 방법, 결과를 다시 검증하게 하는 반복, 제공한 문서의 정보만 쓰도록 제한하는 방법이 있습니다. 같은 문서는 이 기법들이 지어낸 답을 크게 줄이지만 완전히 없애지는 못한다고 밝히고, 중요한 정보는 특히 위험이 큰 결정에서 반드시 검증하라고 합니다.

기능의 성격에 따라 지어낸 답을 다루는 방법이 다릅니다. 근거 문서가 있는 사실 안내는 답을 인용에 묶고, 근거가 없으면 확인할 수 없다고 말하게 합니다. 사실 주장이 없는 발상 작업은 폭넓게 생성한 뒤 사람이 고르게 합니다. 근거 문서로도 검증할 수 없는 물리적 판단처럼 근거가 없고 오류가 되돌릴 수 없는 피해로 이어지는 일은 기능을 만들지 않거나 전문가 연결로 바꿉니다.

거절과 과잉 거절

모델이 답하지 않는 것은 때로 올바른 동작입니다. 근거가 없거나 위험한 요청에 "확인할 수 없다"고 말하는 것은 지어낸 답보다 나은 정상 동작입니다. 실패는 두 가지입니다. 답할 수 있는 질문까지 거절하는 과잉 거절, 그리고 정상적인 거절이더라도 다음 행동 없이 대화를 끊는 안내 없는 거절입니다. 과잉 거절은 틀린 답의 비율(오류율)에는 잡히지 않고, 정답률에서도 거절을 따로 세지 않으면 원인이 드러나지 않습니다. 그래서 답할 수 있는 질문의 거절률을 따로 잽니다. 과잉 거절은 사용자 흐름을 막고 처리 비용을 상담원이나 전화 창구로 떠넘깁니다.

과잉 거절은 두 방향으로 다룹니다. 먼저 줄입니다. 답할 수 있었는데 거절한 사례를 모아 평가 세트에 넣고, 프롬프트나 근거 범위를 고쳐 다시 평가합니다. 그리고 거절하더라도 사용자가 다음 행동을 할 수 있게 합니다. PAIR 가이드는 실패 뒤 사용자가 할 수 있는 일에 초점을 두고, 실패하면 사용자가 일을 넘겨받을 수 있게 하라고 권합니다. "답변할 수 없습니다" 대신 "이 질문은 규정 문서에서 찾지 못했습니다. 관련 메뉴: ○○, 담당자 연결: ○○"처럼 씁니다. 근거가 없어 답하지 못한 경우와 안전 정책에 따라 답하지 않은 경우는 안내를 달리합니다. 앞의 것은 다른 경로를 열어 주고, 뒤의 것은 이유를 짧게 알린 뒤 같은 요청을 다시 유도하지 않습니다.

형식 오류

형식 오류는 약속한 출력 형식을 지키지 않는 실패입니다. 사람이 읽는 화면이면 화면이 비거나 깨지고, 다른 시스템으로 가는 결과면 연동이 실패합니다. 연동 실패는 아무도 모르는 사이에 쌓이기 쉬워 더 위험합니다.

Claude 문서는 구조화 출력을 쓰면 JSON 스키마를 지키는 응답이 보장된다고 설명하면서도, 안전상의 이유로 거절한 응답(stop_reason이 refusal)이나 max_tokens에 닿아 잘린 응답은 스키마와 맞지 않을 수 있다고 밝힙니다. 그래서 대응은 세 겹입니다.

1. 구조화 출력이나 엄격한 도구 입력(strict tool use, 도구 이름과 입력값이 스키마를 따르게 하는 설정)으로 형식을 고정한다. 문자열 열거값의 대소문자는 보장되지 않으므로 대소문자를 구분하지 않고 비교한다.
2. 받은 결과를 스키마로 검증하고, 실패하면 하위 시스템에 넘기지 않는다.
3. 검증 실패 건은 재처리 대기열이나 기본 화면으로 보내고, 그 비율을 운영 지표로 지켜본다.

일시적 장애와 재시도

모델 API도 장애가 납니다. Claude 문서는 오류 코드로 429(rate_limit_error, 속도 제한), 500(api_error, 내부 오류), 529(overloaded_error, 일시적 과부하) 등을 설명합니다. 내부 오류는 지수 백오프로 다시 시도하라고 하고, Anthropic 공식 SDK는 연결 오류·속도 제한·5xx 같은 일시적 실패를 기본 2회까지 지수 백오프로 자동 재시도하며 retry-after 헤더가 있으면 따른다고 밝힙니다. 지수 백오프는 다시 시도할 때마다 기다리는 간격을 1초, 2초, 4초처럼 늘려 가는 방식입니다.

재시도는 짧은 장애에 맞는 대응입니다. 몇 초면 풀리는 과부하라면 간격을 늘려 몇 번 다시 시도하는 것으로 대부분 해결되고, 정해진 횟수를 넘으면 사용자에게 알리고 다른 길을 보여 줍니다. 횟수를 제한하지 않으면 사용자는 끝없이 기다리고, 장애 중인 서버에 요청이 몰려 상황이 나빠집니다. 같은 문서는 사용량이 갑자기 크게 늘면 가속 제한(acceleration limits, 급증하는 사용량에 거는 제한)으로 429가 날 수 있으니 트래픽을 점진적으로 늘리라고도 권합니다.

대체 경로와 단계적 축소

장애가 길어지거나 복구 시점을 알 수 없으면 재시도만으로는 부족합니다. 기능의 성격에 따라 대응이 달라집니다.

단계적 축소(graceful degradation)는 AI 기능이 멈춰도 핵심 업무가 더 단순한 경로로 계속되게 하는 설계입니다. AI 추천 검색이 멈추면 키워드 검색으로, AI 상담이 멈추면 자주 묻는 질문과 상담원 연결로 돌아갑니다. NIST AI RMF는 의도한 용도에서 벗어난 성능이나 결과를 보이는 AI 시스템을 대체하거나, 해제하거나, 끄는 장치를 두고 그 책임을 정하라고 합니다(MANAGE 2.4). 이 장치는 출시 전에 만들어 두고 시험해야 합니다.

실패 유형별 대응표

실패 대응은 표 한 장으로 정리합니다. 각 칸이 비어 있으면 그 실패가 났을 때 무슨 일이 일어날지 아무도 모르는 것입니다.

사람의 개입 지점

사람이 개입하는 방식은 네 가지로 나눌 수 있습니다.

고르는 기준은 세 가지입니다. 오류를 되돌릴 수 있는가, 처리량이 검토 여력 안에 드는가, 위험이 특정 부분집합(판매 제한 상품, 큰 금액, 안전 관련)에 몰려 있는가. Anthropic은 에이전트가 검사 지점이나 막히는 지점에서 사람의 피드백을 위해 멈출 수 있다고 설명합니다. 기획자가 할 일은 그 지점을 미리 정하는 것입니다.

사람에게 보낸 건을 기다리는 사용자의 경험도 설계합니다. 검토에 걸리는 목표 시간을 정하고, 그동안 사용자에게 진행 상태를 보여 주며, 목표 시간을 넘긴 건은 어떻게 처리할지(담당자 추가 배정, 안전한 기본 처리) 정해 둡니다. 검토 대기열이 넘치는 날의 처리 규칙이 없으면 사람의 개입이 곧 서비스 지연이 됩니다.

여러 방식을 섞는 것이 보통입니다. 하루 수만 건의 분류라면 위험 조건에 걸린 건은 조건부 이관으로, 나머지는 자동 반영과 사후 표본 점검으로, 결과에 불만이 있는 판매자에게는 이의 제기 경로를 둡니다.

검토자의 권한과 근거

사람이 검토 단계에 있다고 해서 감독이 작동하는 것은 아닙니다. 검토 화면에 AI의 추천과 "확인" 버튼만 있다면, 검토자는 추천을 바꿀 수도, 왜 그런 추천이 나왔는지 볼 수도 없습니다. 형식은 사람의 결정이지만 실질은 자동화입니다.

검토가 실질적으로 작동하려면 세 가지가 필요합니다.

1. 판단 근거. AI가 그 결과를 낸 주요 근거(인용한 문서, 반영한 항목)를 검토자가 볼 수 있다.
2. 권한. 검토자가 결과를 고치거나 거부할 수 있고, 그 결과가 실제로 반영된다.
3. 기록. 수정·거부의 사유가 남아 나중의 점검과 개선 자료가 된다.

NIST AI RMF는 사람의 감독 과정을 조직의 정책에 따라 정의하고 평가하며 기록하라고 합니다(MAP 3.5). AI 기본법(「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」)도 고영향 인공지능, 즉 채용·대출 심사 같은 법이 정한 영역에서 생명·안전·기본권에 중대한 영향을 줄 수 있는 인공지능(1장 참고)이나 그것을 이용한 제품·서비스를 제공하는 인공지능사업자(개발사업자와 이용사업자)가 해야 할 조치에 사람의 관리·감독과 설명 방안, 조치 내용을 확인할 수 있는 문서의 작성·보관을 넣고 있습니다(제34조제1항). 고영향에 해당하지 않는 일반 상담 봇이라도 실질적인 검토 설계는 품질과 신뢰를 지키는 기본입니다.

신뢰 보정과 확신 표시

사용자가 AI 결과를 무조건 믿어도, 무조건 의심해도 문제입니다. Google PAIR 가이드는 사용자가 신뢰를 올바르게 보정해 어떤 상황에서는 믿고 필요할 때는 다시 확인하게 하는 것이 목표라고 설명합니다.

확신 수준을 보여 주는 것은 도움이 될 때가 있지만 방법이 중요합니다. 같은 가이드는 숫자로 된 확신도는 사용자가 확률을 잘 이해한다고 전제해 위험하다고 경고하고, 대신 여러 후보를 보여 주거나 확신 수준을 몇 단계로 나눠 단계마다 사용자가 할 일을 분명히 하라고 권합니다. 확신 표시가 사용자의 결정에 영향을 주지 않는다면 보여 주지 않는 것도 방법입니다.

이용자 고지

AI 기본법 제31조는 세 가지를 요구합니다. 고영향 또는 생성형 인공지능을 이용한 제품·서비스를 제공하려는 경우 그 제품·서비스가 해당 인공지능에 기반해 운용된다는 사실을 이용자에게 사전에 고지해야 하고(제1항), 생성형 인공지능이나 그것을 이용한 제품·서비스를 제공하는 경우 결과물이 생성형 인공지능으로 생성되었다는 사실을 표시해야 하며(제2항), 실제와 구분하기 어려운 가상의 음향·이미지·영상을 제공하는 경우 이용자가 명확하게 인식할 수 있는 방식으로 고지하거나 표시해야 합니다(제3항). 방법과 예외는 대통령령에 맡깁니다(제4항).

기획자에게 중요한 점은 사전 고지와 결과물 표시가 원칙적으로 별개의 의무라는 것입니다. 사전 고지를 했다고 결과물 표시 의무가 면제되지는 않습니다. 구체적인 방법과 예외는 시행령 제23조가 정합니다. 사전 고지는 이용약관 기재, 화면 표시, 제공 장소 게시 등으로 할 수 있고, 결과물 표시는 사람이 알아볼 수 있는 방법이나 기계가 판독할 수 있는 방법으로 할 수 있으며, 기계 판독 방식이면 생성형 AI가 만들었다는 사실을 1회 이상 문구나 음성으로 안내해야 합니다. 서비스명이나 화면 문구로 AI 활용이 명백한 경우, 내부 업무 용도로만 쓰는 경우 등에는 규정의 전부 또는 일부를 적용하지 않을 수 있습니다. 법적 의무와 별도로, PAIR 가이드는 처음 사용할 때 제품이 할 수 있는 일과 할 수 없는 일을 솔직하게 알리고, 기술보다 사용자가 얻는 이점을 설명하라고 권합니다. 사용자가 기능의 범위를 오해해 생기는 불만(실시간 정보를 본다고 생각하는 등)은 결과를 고쳐서가 아니라 기대를 맞춰서 해결합니다.

피드백과 통제

사용자의 피드백은 두 종류입니다. PAIR 가이드의 정의로 암묵적 피드백은 제품 로그에 남는 사용자 행동 데이터(수정, 재생성, 이탈)이고, 명시적 피드백은 사용자가 일부러 남기는 의견(좋아요·싫어요, 신고)입니다. 결과의 일부만 자주 틀린다면 사용자가 결과를 바로 고칠 수 있게 하고, 고친 내용을 기록하는 것이 사용자 부담과 개선 자료 문제를 함께 풉니다. 다만 사용자의 수정이 늘 옳지는 않으므로, 수정 기록은 검토를 거쳐 평가 세트나 개선 자료로 씁니다.

통제 장치도 필요합니다. PAIR 가이드는 사용자가 출력을 자기 필요에 맞게 고치거나 끌 수 있게 하고, AI를 처음 도입할 때는 시험해 보거나 끌 수 있게 하며, 쓰지 않겠다는 결정을 존중하라고 권합니다. OpenAI는 사용자가 부적절한 동작을 쉽게 신고할 방법을 두고, 그 신고를 사람이 모니터링하고 적절히 응답하라고 합니다. NIST AI RMF도 최종 사용자와 영향받는 공동체가 문제를 신고하고 결과에 이의를 제기할 수 있는 피드백 과정을 두라고 권합니다(MEASURE 3.3).

깊이 읽기

형식적 승인의 함정

사람이 모든 결과를 승인하는 구조는 안전해 보이지만, 처리량이 크고 AI가 대부분 맞으면 검토자는 점점 확인 없이 승인하게 됩니다. 하루 수백 건을 몇 초씩 보며 99% 이상을 그대로 승인한다면 그 검토는 감독이 아니라 서명입니다.

이 함정은 숫자로 드러납니다. 검토자의 수정률(그대로 승인하지 않은 비율), 건당 검토 시간, 검토자가 고친 건이 실제로 틀린 건이었는지를 정기적으로 봅니다. 사람이 AI의 추천을 따져 보지 않고 받아들이는 경향을 자동화 편향이라고 합니다. 수정률이 거의 0이고 검토 시간이 짧다면 두 가지 중 하나입니다. AI가 정말 정확해 사전 승인이 과하거나, 검토자가 판단할 근거와 권한이 없어 확인을 포기했거나. 앞의 경우는 조건부 이관으로 줄이고, 뒤의 경우는 검토 화면을 고칩니다. 일부 결과에 일부러 알려진 오류를 섞어 검토자가 잡아내는지 보는 방법도 있습니다.

다른 모델로 자동 전환의 함정

장애 대응으로 "다른 제공사 모델로 자동 전환"이 자주 제안됩니다. 가용성만 보면 그럴듯하지만, 기획자가 확인할 것이 셋 있습니다. 첫째, 그 모델로 평가 세트를 돌려 품질 기준을 넘는지 확인했는가. 같은 프롬프트도 모델이 바뀌면 결과가 달라집니다. 둘째, 그 제공사로 고객 데이터를 보내도 되는 계약과 처리 조건이 있는가. 셋째, 지연과 비용이 계약 조건 안인가.

셋 중 하나라도 확인되지 않았다면 자동 전환은 장애를 품질 사고나 계약 위반으로 바꿀 뿐입니다. 그런 경우에는 단계적 축소나 대기열이 더 안전한 답입니다. 예비 모델을 두려면 평소에 함께 평가하고 계약을 맺어 두는 것이 전제입니다.

면책 문구는 대응이 아니다

"AI 답변은 틀릴 수 있습니다"라는 문구는 흔하지만, 그 자체로는 실패 대응이 아닙니다. 사용자는 문구를 읽고도 답을 믿고 행동하며, 문구는 지어낸 답을 하나도 줄이지 않습니다. 법이 요구하는 고지(AI 기반이라는 사실, 생성 결과물이라는 표시)와 실패 대응(근거 인용, 사람 개입, 대체 경로)은 다른 층위의 일입니다.

고지는 사용자의 기대를 맞추는 일이고, 실패 대응은 실패의 피해를 줄이는 일입니다. 기획서에서 "면책 문구 추가"가 실패 대응 칸에 들어가 있다면, 그 칸은 아직 비어 있는 것입니다.

실무 장면

한빛렌즈의 도수 안내 봇

안경 쇼핑몰 '한빛렌즈'는 고객 문의에 답하는 AI 봇을 운영합니다. 시범 운영 기록을 보니 실패가 세 종류로 나왔습니다. 렌즈 교환 규정에 없는 "무상 교환 3회"를 안내한 지어낸 답, "도수 입력은 어떻게 하나요" 같은 간단한 질문을 거절한 과잉 거절, 그리고 주문 조회 결과가 앱 화면에 비어 나오는 형식 오류였습니다.

기획자는 유형별로 대응을 나눴습니다. 지어낸 답에는 교환 규정 문서의 문장을 인용해 답하게 하고, 인용을 찾지 못하면 "규정에서 확인할 수 없습니다"와 상담원 연결을 보여 주게 했습니다. 과잉 거절은 거절된 질문 120건을 평가 세트에 넣어 프롬프트를 고친 뒤, 고칠 때 보지 않은 보류 질문으로 거절률을 다시 쟀고, 거절할 때는 도수 입력 화면 바로가기를 함께 보여 주도록 했습니다. 형식 오류는 주문 조회 결과를 스키마로 고정하고 검증에 실패하면 기본 주문 화면으로 넘기도록 했습니다.

하나 더 있었습니다. 고객이 처방전 사진을 올리면 AI가 도수를 읽어 주문에 넣어 주는 기능이 제안됐습니다. 도수를 잘못 읽으면 맞지 않는 렌즈가 제작되고, 제작된 렌즈는 되돌릴 수 없었습니다. 처리량은 하루 60건이었습니다. 기획자는 AI가 읽은 도수를 고객이 처방전과 나란히 보며 확인하게 하고, 안경사가 제작 전에 모든 건을 승인하는 사전 승인 방식을 골랐습니다. 버린 안은 "확신이 높은 건은 자동 제작"이었습니다. 하루 60건이면 안경사가 모두 볼 수 있었고, 확신이 높아도 틀린 렌즈는 되돌릴 수 없었기 때문입니다.

구슬모아공방의 상품 검수

수공예 마켓 '구슬모아공방'은 하루 8,000개의 새 상품 등록을 AI로 검수해 금지 품목(모조품, 위험 물질)을 걸러 내려 합니다. 검수 인력은 하루 250건을 볼 수 있습니다.

처음 제안은 "AI가 의심한 건을 모두 사람이 검토"였습니다. 시험해 보니 AI가 의심한 건은 하루 900건이었습니다. 기획자는 위험을 나눴습니다. 위험 물질 의심은 드물지만 피해가 커서 모두 사람에게 보냅니다. 모조품 의심은 확신이 높은 건은 등록을 자동으로 보류하고, 확신이 낮은 건만 사람에게 보냅니다. 의심이 없는 상품은 자동 통과시킨 뒤 매일 표본 50건을 점검합니다. 이렇게 하니 사람에게 가는 건이 위험 물질 의심 30건, 확신이 낮은 모조품 의심 140건, 사후 점검 표본 50건을 합쳐 하루 220건으로 줄어 검토 여력 250건 안에 들었습니다. 등록이 자동 보류된 판매자에게는 사유를 보고 재심사를 요청할 수 있는 이의 제기 경로를 두었습니다.

검토 화면도 고쳤습니다. 처음 화면에는 "금지 의심"이라는 표시와 승인 버튼만 있었습니다. 검토자들은 왜 의심받았는지 몰라 대부분 그대로 승인했고, 첫 주 수정률은 2%였습니다. 기획자는 AI가 근거로 본 상품명·이미지 영역·설명 문장을 함께 보여 주고, 검토자가 판정을 바꾸면 사유를 고르게 했습니다. 검토자가 근거를 보고 잘못된 판정을 실제로 고치기 시작하면서 둘째 주 수정률은 11%로 올랐고, 사유 기록은 다음 평가 세트의 재료가 됐습니다.

자주 틀리는 지점

1. "'모른다고 답하라'는 지시를 넣으면 지어낸 답은 없어진다." 크게 줄 뿐 사라지지 않습니다. 중요한 정보는 검증 장치가 필요합니다.
2. "여러 번 생성해 답이 같으면 사실이다." 모델은 같은 오해를 반복할 수 있습니다. 일관성은 근거가 아닙니다.
3. "거절은 안전하니 실패가 아니다." 과잉 거절은 사용자를 막고 비용을 다른 창구로 옮기는 실패입니다.
4. "구조화 출력을 쓰면 형식 검증은 필요 없다." 거절이나 길이 한도에서는 스키마가 어긋날 수 있습니다.
5. "장애가 나면 다른 모델로 자동 전환하면 된다." 평가하지 않았거나 데이터 조건이 없는 모델로의 전환은 품질·계약 사고가 됩니다.
6. "모든 결과를 사람이 승인하면 가장 안전하다." 처리량이 검토 여력을 넘으면 형식적 승인이 되고, 되돌리기 쉬운 오류에는 과한 비용입니다.
7. "검토자가 있으면 감독이 작동한다." 근거와 수정·거부 권한, 기록이 없으면 감독은 서명에 그칩니다.
8. "면책 문구를 붙이면 실패 대응이 된다." 고지는 기대를 맞추는 일이고, 실패의 피해를 줄이는 것은 설계입니다.

한눈에 정리

• 실패 네 유형: 지어낸 답(사용자가 모름), 거절·과잉 거절(막힘), 형식 오류(깨짐), 일시적 장애(기다림).
• 지어낸 답: "모른다" 허용, 직접 인용, 인용 검증. 줄일 뿐 없애지 못한다.
• 형식 오류: 구조화 출력 + 검증 + 실패 건 재처리. 거절·길이 한도는 예외.
• 장애: 짧으면 횟수 제한 백오프 재시도, 실시간 불필요하면 대기열, 길면 단계적 축소, 예비 모델은 평가·계약이 전제.
• 사람 개입: 되돌림 가능성·처리량·위험 부분집합으로 사전 승인/조건부 이관/사후 점검/이의 제기를 고른다.
• 검토가 작동하려면 근거·권한·기록. 수정률과 검토 시간으로 형식적 승인을 감시한다.
• 확신 표시는 단계와 행동 안내로, 숫자 확신도는 조심.
• AI 기본법 제31조: 사전 고지와 결과물 표시는 별개의 의무. 신고 창구는 사람이 보고 답한다.

공식 문서로 확인하기

• Claude Docs — Reduce hallucinations: 기본·고급 기법과 "없애지는 못한다"는 주의.
• Claude Docs — Structured outputs: 스키마 보장과 거절·max_tokens 예외.
• Claude Docs — Claude API errors: 오류 코드, 지수 백오프, SDK의 자동 재시도.
• OpenAI — Safety best practices: 사람 검토, 레드팀, 신고 창구와 사람의 모니터링.
• Google PAIR Guidebook — Errors + Graceful Failure: 오류 유형, 실패 뒤의 다음 행동, 통제권 돌려주기.
• Google PAIR Guidebook — Explainability + Trust: 신뢰 보정과 확신 표시 방법.
• Google PAIR Guidebook — Feedback + Control: 암묵적·명시적 피드백, 수정과 끄기.
• NIST AI RMF — Core: MAP 3.5(사람의 감독), MEASURE 3.3(신고와 이의 제기), MANAGE 2.4(대체·해제·중지).
• 국가법령정보센터 — 인공지능기본법 시행령 제23조: 사전 고지와 결과물 표시의 방법, 적용 예외.

셀프 체크

4-1. Claude 문서가 지어낸 답을 줄이는 기본 전략으로 드는 세 가지를 쓰라.

4-2. 과잉 거절이 틀린 답의 비율(오류율)로는 드러나지 않는 이유와, 과잉 거절을 다루는 두 방향을 쓰라.

4-3. 구조화 출력을 쓰는 기능에서 응답이 오류 없이 정상 종료됐는데도 검증 단계를 남겨야 하는 이유를 쓰라.

4-4. 공문서 자동 발송 기능에서 모델 API가 30분째 응답하지 않는다. 발송은 내일 오전까지만 하면 된다. 재시도, 대기열, 단계적 축소 가운데 무엇이 맞고 왜 그런가?

4-5. 사람의 개입 방식 네 가지를 쓰고, 각각이 맞는 조건을 한 줄로 쓰라.

4-6. 검토자가 하루 500건을 평균 3초씩 보고 99.8%를 그대로 승인한다. 이 숫자가 뜻할 수 있는 두 가지 상황과 각각의 조치를 쓰라.

4-7. AI 기본법 제31조제1항과 제2항이 각각 요구하는 것을 쓰고, 둘의 관계를 설명하라.

4-8. (설계) 지금 맡은 AI 기능의 실패 유형별 대응표(예방, 감지, 실패 시 동작, 사용자에게 보이는 것)를 다섯 행으로 쓰라.

실습 과제