2장. 요구사항과 성공 기준

학습 목표

• "잘 작동한다"는 모호한 요구를 데이터, 지표, 기준값, 측정 방법이 있는 판정 가능한 성공 기준으로 바꾼다.
• 정확도뿐 아니라 일관성, 어조, 개인정보 처리, 지연, 비용 같은 여러 차원의 기준을 함께 세운다.
• 기능이 받는 입력과 돌려주는 출력을 입력·출력 계약으로 정하고, 범위 밖 입력과 형식 오류의 처리 규칙을 적는다.
• 품질과 지연·비용의 균형을 맞추는 설계 선택지(모델, 출력 길이, 스트리밍, 일괄 처리)를 고른다.
• 사용자에게 보이는 실패 경험을 요구사항으로 쓰고, 출시 차단 기준과 개선 목표를 구분한다.

들어가며

한 기획서의 요구사항 칸에 이렇게 적혀 있었습니다. "AI 요약은 정확하고 자연스러워야 하며 빠르게 응답해야 한다." 출시 한 달 전, 개발팀은 "정확도 91%면 정확한 겁니까?"라고 물었고, 영업팀은 "고객사가 원하는 건 99%"라고 했고, 디자이너는 "빠르게가 몇 초인가요?"라고 물었습니다. 아무도 틀리지 않았습니다. 요구사항이 판정할 수 없는 말로 쓰여 있었을 뿐입니다.

AI 기능은 확률적으로 작동하므로 "틀리지 않는다"를 약속할 수 없습니다. 대신 "이 데이터에서, 이 방법으로 쟀을 때, 이 비율 이상"을 약속합니다. Claude 문서는 성공적인 LLM 애플리케이션이 성공 기준을 명확히 정의하는 데서 시작하고, 그 기준을 재는 평가를 설계하는 순환이 핵심이라고 설명합니다. 이 장은 그 순환의 앞쪽, 즉 무엇을 성공으로 볼지를 정하는 일을 다룹니다.

먼저 판정 가능한 기준의 조건과 여러 차원을 익히고, 모호한 요구를 숫자로 바꾸는 절차를 연습합니다. 그다음 입력·출력 계약과 품질·지연·비용의 균형을 다루고, 사용자에게 보이는 실패 경험을 요구사항으로 쓰는 법을 봅니다. 마지막으로 모든 기준을 출시 차단 기준과 개선 목표로 나눠 요구사항 문서 한 장으로 묶습니다.

핵심 개념

AI 기능의 요구사항은 무엇이 다른가

기존 기능의 요구사항은 "버튼을 누르면 결제 화면으로 간다"처럼 참·거짓이 분명합니다. AI 기능의 요구사항은 "문의 유형을 맞힌다"처럼 대부분 맞고 일부 틀리는 성질을 가집니다. 그래서 AI 요구사항에는 세 가지가 더 필요합니다.

1. 비율로 쓴 기준. "맞힌다"가 아니라 "평가 세트 1,000건에서 95% 이상 맞힌다".
2. 측정 방법. 누가, 무엇과 대조해, 어떻게 판정하는가.
3. 틀렸을 때의 약속. 틀린 5%가 사용자에게 어떻게 보이고 어떻게 처리되는가.

비유하자면 기존 요구사항은 설계도이고, AI 요구사항은 품질 검사 규격서에 가깝습니다. 공장은 불량을 0으로 만들 수 없으니 불량률 상한과 검사 방법, 불량품 처리 절차를 함께 정합니다.

판정 가능한 성공 기준

Claude 문서는 좋은 성공 기준의 조건으로 네 가지를 듭니다. 구체적이고(specific), 측정 가능하며(measurable), 달성 가능하고(achievable), 목적과 관련 있어야(relevant) 합니다. "좋은 성능" 대신 "정확한 감정 분류"처럼 구체적으로 쓰고, 숫자나 잘 정의된 척도로 재며, 업계 기준, 이전 실험 결과, 전문가 지식에 근거해 목표를 잡고, 사용자의 필요와 맞아야 합니다.

같은 문서의 예시가 차이를 잘 보여 줍니다.

좋은 기준에는 네 요소가 반드시 들어갑니다. 무엇을(지표), 어디서(데이터), 얼마나(기준값), 어떻게(측정 방법). 하나라도 빠지면 회의에서 숫자를 두고 다시 논쟁하게 됩니다. 여기에 무엇과 비교한 숫자인지(기준선)를 함께 적으면 기준값이 왜 그 숫자인지까지 설명할 수 있습니다. 위 표의 감정 분류 예시가 기준선(현재보다 5% 개선)까지 갖춘 형태입니다.

성공 기준의 여러 차원

Claude 문서는 대부분의 기능이 여러 성공 기준으로 평가해야 한다고 하며, 흔한 차원으로 다음을 듭니다.

정확도 하나만 기준으로 두면 다른 차원의 실패를 놓칩니다. 정확도를 올리려고 큰 모델을 쓰면 지연과 비용이 나빠지고, 답을 길게 쓰면 관련성이 떨어질 수 있습니다. 차원마다 기준을 따로 두어야 무엇을 맞바꾸는지 보입니다.

정밀도와 재현율

무언가를 "잡아내는" 기능(사기 의심, 스팸, 긴급 요청 탐지)에는 정확도보다 정밀도와 재현율이 중요합니다. Google PAIR 가이드의 정의로 정밀도는 양성으로 판정한 것 가운데 실제 양성의 비율이고, 재현율은 실제 양성 가운데 양성으로 잡아낸 비율입니다.

PAIR 가이드는 거짓 양성과 거짓 음성의 비용을 따지는 일이 사용자 경험을 좌우하는 결정이며, 둘을 기계적으로 같은 비중으로 다루려는 태도를 경계하라고 합니다. 두 지표는 함께 오르기 어려우므로 기능마다 어느 쪽을 지킬지 요구사항에 적어야 합니다. 둘을 하나로 묶어 보고 싶을 때 쓰는 지표가 F1 점수(정밀도와 재현율의 조화 평균)입니다.

모호한 요구를 기준으로 바꾸는 절차

"요약이 의도를 잘 담아야 한다" 같은 요구를 받으면 다음 순서로 바꿉니다.

1. 뜻을 쪼갠다. "의도"가 해결 약속인지, 다음 조치인지, 말투인지 요구한 사람과 함께 나눈다.
2. 관찰 가능한 행동으로 바꾼다. "다음 조치(누가, 언제, 무엇을)가 요약에 빠짐없이 들어 있다".
3. 측정 방법을 정한다. 정답이 있으면 대조(코드), 판단이 필요하면 루브릭(항목별 판정 기준과 점수 척도를 적은 채점 기준표)과 채점자(사람 또는 사람과 대조한 LLM 채점기).
4. 데이터를 정한다. 실제 기록에서 뽑은 평가 세트, 크기와 구성.
5. 기준선과 기준값을 정한다. 현재 수준(기준선)을 재고, 그 근거를 보고 달성 가능한 기준값을 정한다.

Claude 문서는 윤리나 안전처럼 "흐릿한" 주제도 수치로 바꿀 수 있고, 정성적 척도도 정량 지표와 함께 일관되게 쓰면 가치가 있다고 설명합니다. 바꾸는 과정에서 요구한 사람과 합의하는 것이 숫자보다 중요합니다.

입력 계약

입력 계약은 기능이 무엇을 받는지 정한 약속입니다. 언어, 파일 종류, 길이, 필수 정보, 받지 않을 정보를 적습니다. 입력 계약이 없으면 기능은 검증되지 않은 입력까지 처리하고, 결과가 나빠도 사용자는 이유를 모릅니다.

형식·길이처럼 모델에 보내기 전에 검사할 수 있는 범위도 있지만, "지원하지 않는 업무에 대한 질문"처럼 내용을 읽어야 알 수 있는 범위도 있습니다. 앞의 것은 사전 검증으로, 뒤의 것은 의도 분류나 모델의 판단으로 걸러 정해진 안내 경로로 보내고, 그 판정도 평가 세트로 확인합니다. 입력 범위는 평가로 검증한 범위와 같아야 합니다. 평가하지 않은 언어나 길이를 지원하려면 그 입력을 평가 세트에 넣고 기준을 넘긴 뒤 범위를 넓힙니다. Google PAIR 가이드는 오류 상태를 이용해 AI가 어떤 입력을 필요로 하는지 사용자에게 알려 주라고 권합니다.

출력 계약

출력 계약은 기능이 무엇을 어떤 형식으로 돌려주는지 정한 약속입니다. 사람이 읽는 화면이면 길이와 구성, 다른 시스템이 받아 쓰는 결과면 필드와 형식, 빈 값 처리 방식을 적습니다.

다른 시스템으로 가는 출력은 특히 엄격해야 합니다. Claude 문서는 구조화 출력(structured outputs)이 제약된 디코딩(스키마에 맞는 토큰만 생성되게 막는 방식)으로 대부분의 경우 JSON 스키마를 지키는 응답을 보장한다고 설명합니다. 다만 거절(stop_reason이 refusal)이거나 출력 길이 한도(max_tokens)에 닿은 경우에는 출력이 스키마와 맞지 않을 수 있고, 문자열 열거값(enum, const)의 대소문자는 보장하지 않아 오류 없이 정상 종료한 응답에서도 대소문자만 다른 값이 나올 수 있다고 밝힙니다. 그래서 열거값은 대소문자를 구분하지 않고 비교하고, 대소문자만 다른 값을 따로 정의하지 않습니다. 그래서 출력 계약에는 스키마와 함께 "검증에 실패한 결과는 쓰지 않고 다시 처리하거나 사람에게 보낸다"는 규칙을 적습니다.

[출력 계약 예]
형식: JSON {"item": 문자열, "quantity": 정수, "unit_price": 정수}
빈 값: 판독할 수 없는 필드는 null로 두고, 추측해 채우지 않는다
검증: 스키마 검증 실패, 거절, 길이 한도 도달 → 하위 시스템으로 보내지 않고 재처리 대기열
실패 알림: 재처리 대기열이 1시간에 20건을 넘으면 담당자에게 알림

정확도가 높아도 형식이 어긋나면 하위 시스템은 깨집니다. 정확도와 형식은 다른 요구사항입니다.

품질·지연·비용의 균형

품질, 지연, 비용은 서로 맞바꾸는 관계지만 조절 손잡이는 여러 개입니다. Claude 문서는 먼저 제약 없이 잘 작동하는 구성을 찾은 뒤 지연을 줄이라고 권합니다. 너무 일찍 지연을 줄이면 최고 성능이 어디까지인지 알 수 없기 때문입니다.

지연을 잴 때는 응답 전체가 끝나는 시간과 첫 토큰이 나오기까지의 시간(TTFT, Time To First Token)을 구분합니다. 사용자가 화면 앞에서 기다리는 기능은 TTFT가, 다른 시스템으로 결과를 넘기는 기능은 전체 시간이 중요합니다. 비용은 "건당 비용 × 월 처리량"으로 적고 예산과 비교합니다.

사용자에게 보이는 실패 경험

AI 기능은 일정 비율 실패합니다. 그 순간 사용자가 무엇을 보는지가 요구사항입니다. Google PAIR 가이드는 사용자가 생각하는 오류가 시스템에 대한 기대와 깊이 연결돼 있다고 하며, 오류를 시스템 한계, 맥락 오류, 배경 오류로 나눕니다. 그리고 실패 뒤 사용자가 할 수 있는 일에 초점을 두고, 실패하면 사용자가 일을 넘겨받을 수 있게 하라고 권합니다.

스트리밍을 쓰면 실패가 응답 도중에도 생깁니다. Claude 문서는 스트리밍 응답에서는 정상 응답(200)이 시작된 뒤에도 오류가 날 수 있다고 설명합니다. 그래서 "반쯤 나온 답"을 어떻게 보여 줄지도 요구사항에 넣습니다. "답변할 수 없습니다"만 보여 주는 화면은 틀린 답의 비율에는 잡히지 않지만 사용자를 막습니다. 사용 로그에서 실패 화면 다음의 행동(이탈, 재시도, 전화 문의)을 함께 보면 실패 경험의 비용이 드러납니다.

출시 차단 기준과 개선 목표

모든 기준이 같은 무게는 아닙니다. 출시 차단 기준은 넘지 못하면 다른 지표가 아무리 좋아도 출시하지 않는 기준이고, 개선 목표는 출시 뒤 끌어올릴 수준입니다.

차단 기준이 너무 많으면 출시가 끝없이 밀리고, 너무 적으면 사고가 납니다. NIST AI RMF는 조직의 위험 허용 수준을 정해 기록하라고 합니다(MAP 1.5). 차단 기준은 그 허용 수준을 숫자로 옮긴 것입니다. 또 하나의 선택지가 있습니다. 특정 유형만 기준에 못 미치고 그 유형을 사람에게 보낼 경로가 있다면, 그 유형을 범위에서 빼는 조건부 출시가 차단과 개선 사이의 답이 됩니다.

기준값의 근거

기준값은 협상으로 정하는 숫자가 아닙니다. Claude 문서는 업계 기준, 이전 실험, AI 연구, 전문가 지식에 근거하고, 현재 최신 모델의 능력으로 비현실적이지 않게 잡으라고 합니다. 실무에서 쓰는 근거는 세 가지입니다.

1. 현재 수준(기준선). 지금 사람이나 기존 시스템이 하는 수준. 사람 상담원의 분류 정확도가 93%면 AI 목표를 99%로 잡을 근거는 약합니다.
2. 오류의 비용. 한 건이 틀릴 때의 피해. 피해가 클수록 기준을 높이거나 사람의 확인을 붙입니다.
3. 작은 실험. 표본 50~100건으로 돌려 본 결과. 기준이 달성 가능한지 미리 봅니다.

경쟁 서비스의 홍보 숫자는 측정 방법을 알 수 없어 근거로 쓰기 어렵습니다.

요구사항 문서의 구조

AI 기능의 요구사항 문서는 다음 구조로 쓰면 검토와 판정이 쉬워집니다.

1. 목적과 사용자: 누가 무엇을 위해 쓰는가
2. 입력 계약: 받는 것, 받지 않는 것, 범위 밖 처리
3. 출력 계약: 형식, 빈 값, 검증 실패 처리
4. 성공 기준: 차원별 지표·데이터·기준값·측정 방법(기준선 포함)
   4-1. 출시 차단 기준
   4-2. 개선 목표
5. 실패 경험: 실패 순간별 화면과 다음 행동
6. 지연·비용: TTFT/전체 시간, 건당 비용 × 처리량
7. 법적 요건: 고지·표시, 개인정보 처리 조건
8. 미정 사항: 정의가 필요한 요구와 담당자, 기한

깊이 읽기

지표 하나로 줄이고 싶은 유혹

경영진은 대개 숫자 하나를 원합니다. "그래서 몇 점이에요?" 여러 차원을 가중 평균한 종합 점수는 보고하기 좋지만 위험합니다. 개인정보 노출 같은 차단 기준이 다른 차원의 높은 점수에 묻히기 때문입니다. 정확도 95점, 어조 90점, 개인정보 40점의 가중 평균이 80점이라면, 그 80점은 출시해도 된다는 신호처럼 보입니다.

차단 기준은 평균에 넣지 않고 따로 판정합니다. 종합 점수가 필요하면 차단 기준을 모두 넘긴 기능에 한해 개선 목표들의 추이를 보여 주는 용도로 씁니다. 보고서의 첫 줄은 "차단 기준 다섯 개 모두 통과"여야 하고, 종합 점수는 그다음입니다.

오류의 크기도 기준이 된다

모든 오류가 같은 무게가 아닙니다. Claude 문서의 다차원 기준 예시에는 "오류의 90%는 심각한 오류가 아니라 불편을 주는 수준"이라는 항목이 있습니다. 정확도가 같은 두 기능이라도 틀린 답이 "다른 표현으로 다시 물어보면 되는 수준"인지 "잘못된 금액을 약속하는 수준"인지에 따라 출시 판단이 달라집니다.

그래서 성숙한 요구사항은 오류를 심각도로 나눠 기준을 둡니다. 예를 들어 심각 오류(잘못된 금액·기한·자격 안내)는 0.5% 이하, 경미 오류(표현 어색함)는 개선 목표로 둡니다. 심각도의 정의 자체도 요구사항이므로 예시와 함께 적습니다.

일관성은 언제 요구사항인가

같은 질문에 매번 다른 답이 나오면 사용자는 신뢰를 잃습니다. 특히 규정 안내, 가격 설명, 자격 판단처럼 "같은 조건이면 같은 답"이 당연한 영역에서는 일관성이 정확도만큼 중요합니다. Claude 문서는 일관성을 성공 기준의 한 차원으로 들며, 같은 질문을 두 번 했을 때 의미가 비슷한 답을 받는 것이 얼마나 중요한지 물으라고 합니다.

반면 아이디어 발상이나 문구 후보처럼 다양성이 가치인 기능에서는 일관성을 요구하면 오히려 쓸모가 줄어듭니다. 일관성 요구는 기능의 목적에서 나와야 하고, 일관성이 높다는 것이 정확하다는 뜻은 아님을 기억하세요. 같은 오답을 일관되게 낼 수도 있습니다.

실무 장면

달무리게임즈의 신고 분류

게임 회사 '달무리게임즈'는 하루 2만 건의 플레이어 신고(욕설, 부정 프로그램, 결제 문제 등)를 AI로 분류해 담당 부서로 보내려 합니다. 첫 요구사항은 "신고를 정확하게 분류한다"였습니다.

기획자는 먼저 차원을 나눴습니다. 분류 정확도, 긴급 신고(현금 사기·개인정보 노출) 탐지, 지연, 비용입니다. 정확도는 지난달 사람이 분류한 신고 3,000건을 평가 세트로 삼아 "11개 유형 정확 일치 92% 이상"으로 적었습니다. 사람 담당자의 현재 일치율이 94%였기 때문에 100%를 요구할 근거는 없었습니다.

긴급 신고는 따로 다뤘습니다. 긴급 신고는 전체의 0.3%였지만 놓치면 실제 금전 피해로 이어졌습니다. 분류된 긴급 신고는 담당자가 모두 다시 보므로 오탐은 감당할 수 있었습니다. 그래서 "긴급 신고 재현율 98% 이상"을 출시 차단 기준으로 적었습니다. 정밀도는 담당자의 하루 검토 여력 300건에서 거꾸로 계산했습니다. 실제 긴급 신고가 하루 약 60건이므로, 긴급으로 분류되는 건이 300건을 넘지 않으려면 정밀도가 20% 이상이어야 합니다. 이 "정밀도 20% 이상"을 운영 조건으로 적었습니다. 버린 안은 "전체 정확도 95% 이상 하나만 차단 기준"이었습니다. 0.3%의 긴급 신고는 전체 정확도에 묻혀 보이지 않기 때문입니다.

출력 계약도 넣었습니다. 분류 결과는 11개 유형 코드 가운데 하나만 허용하고, 그 밖의 값이나 형식 오류는 "미분류 대기열"로 보내 사람이 처리합니다. 마지막으로 "분류 사유 문장의 자연스러움"은 개선 목표로 두었습니다. 담당 부서가 사유를 읽지 않고 원문을 보기 때문에 출시를 막을 이유가 없었습니다.

들꽃편지의 카드 문구

꽃 배달 서비스 '들꽃편지'는 주문자가 받는 사람과 상황을 고르면 AI가 메시지 카드 문구 세 개를 제안하는 기능을 기획했습니다. 처음 요구사항은 "감동적인 문구를 빠르게"였습니다.

기획자는 "감동적"을 쪼갰습니다. 주문자 인터뷰에서 나온 것은 "상황에 맞다(조문에 축하 표현이 없다)", "받는 사람 호칭이 맞다", "너무 길지 않다(카드에 들어간다)"였습니다. 앞의 둘은 차단 기준이 됐습니다. 조문 상황에 축하 표현이 섞이는 오류는 한 건이라도 큰 항의로 이어지므로 "조문 상황의 축하 표현 0건(금지 표현 목록으로 모든 문구를 코드 검사), 그 밖의 상황 불일치 0.5% 이하"로 적었습니다. 카드 길이는 출력 계약(문구당 80자 이하)으로, 문구의 따뜻함은 루브릭 채점의 개선 목표로 두었습니다.

"빠르게"는 TTFT 기준으로 바꿨습니다. 주문자는 화면 앞에서 기다리므로 첫 문구가 2초 안에 보이도록 스트리밍을 쓰기로 했습니다. 평가에서 작은 모델이 차단 기준을 모두 넘었기 때문에, 큰 모델 대신 작은 모델을 골라 건당 비용도 줄였습니다. 버린 안은 "max_tokens를 낮게 잡아 길이를 맞춘다"였습니다. 문장이 중간에 잘려 카드에 쓸 수 없기 때문입니다.

자주 틀리는 지점

1. "정확도 하나면 충분하다." 지연, 비용, 어조, 개인정보 처리는 정확도와 따로 움직입니다. 차원마다 기준을 둡니다.
2. "숫자가 있으면 좋은 기준이다." 측정 방법을 믿을 수 없거나(생성 모델의 자기 평가) 목적과 무관하면(짧을수록 좋다) 숫자가 있어도 나쁜 기준입니다.
3. "모든 기준을 출시 차단 기준으로 두면 안전하다." 사용에 지장 없는 품질까지 차단하면 출시가 끝없이 밀립니다. 피해로 이어지는 기준만 차단 기준입니다.
4. "정확도가 높으면 형식 검증은 필요 없다." 형식은 정확도와 다른 요구사항입니다. 구조화 출력도 거절이나 길이 한도에서 어긋날 수 있습니다.
5. "max_tokens를 줄이면 답이 짧고 깔끔해진다." 길이 한도에 닿으면 문장 중간에서 잘립니다. 길이는 프롬프트와 출력 계약으로 정합니다.
6. "속도가 문제면 작은 모델로 바꾼다." 품질 기준을 넘는 모델이 하나뿐이면 스트리밍이나 출력 길이로 체감 지연을 줄입니다.
7. "답할 수 없을 때 거절만 하면 안전하다." 다음 행동이 없는 거절은 사용자를 막고 비용을 다른 창구로 옮깁니다.

한눈에 정리

• 좋은 기준 = 지표 + 데이터 + 기준값 + 측정 방법, 그리고 기준값의 근거가 되는 기준선. 다른 사람이 판정할 수 있어야 한다.
• 성공 기준은 여러 차원(정확도, 일관성, 관련성, 어조, 개인정보, 맥락 활용, 지연, 비용)으로 세운다.
• 잡아내는 기능은 정밀도와 재현율 가운데 오류 비용이 큰 쪽을 지킨다.
• 입력 계약은 평가로 검증한 범위와 같게, 범위 밖 입력은 처리 전에 안내한다.
• 출력 계약에는 스키마와 함께 검증 실패·거절·길이 한도의 처리 규칙을 적는다.
• 지연은 TTFT와 전체 시간을 구분하고, 스트리밍·출력 길이·모델·일괄 처리로 조절한다.
• 실패 순간마다 사용자의 다음 행동을 요구사항으로 쓴다.
• 차단 기준은 법·계약·피해로 이어지는 것만, 나머지는 개선 목표. 정의가 없으면 정의부터.

공식 문서로 확인하기

• Claude Docs — Define success criteria and build evaluations: 좋은 성공 기준의 조건, 나쁜 기준과 좋은 기준의 예, 흔한 성공 기준 차원.
• Claude Docs — Structured outputs: 스키마 준수 보장과 예외(거절, max_tokens).
• Claude Docs — Reducing latency: 기준 지연과 TTFT, 모델 선택, 출력 길이, 스트리밍.
• Claude Docs — Batch processing: 비실시간 대량 작업의 비용과 처리 시간.
• Google PAIR Guidebook — User Needs + Defining Success: 정밀도와 재현율, 거짓 양성과 거짓 음성의 비용.
• Google PAIR Guidebook — Errors + Graceful Failure: 사용자가 인식하는 오류, 오류 상태, 실패 뒤의 다음 행동.
• NIST AI RMF — Core: MAP 1.5(위험 허용 수준의 결정과 기록).

셀프 체크

2-1. 좋은 성공 기준에 반드시 들어가야 할 네 요소를 쓰고, 기준값의 근거로 함께 적으면 좋은 것을 쓰라.

2-2. "답변이 빨라야 한다"를 판정 가능한 기준으로 바꾸고, 사용자가 화면 앞에서 기다리는 기능이라면 어떤 지연 지표를 쓸지 설명하라.

2-3. 정밀도와 재현율을 각각 한 문장으로 정의하라.

2-4. 병원 예약 문자에서 "예약 취소 요청"을 잡아 자동으로 예약을 지우는 기능이 있다. 잡아낸 건은 사람 확인 없이 실행된다. 어느 지표를 출시 차단 기준으로 지켜야 하고, 왜 그런가?

2-5. 구조화 출력을 써도 출력 계약에 검증 실패 처리 규칙을 적어야 하는 이유를 두 가지 상황으로 설명하라.

2-6. 다음 항목을 출시 차단 기준과 개선 목표로 나누라: (가) 상담 요약에 고객 계좌번호가 남는 비율 (나) 요약 문장의 간결함 점수 (다) 환불 기한을 잘못 적는 비율.

2-7. (설계) 자주 쓰는 AI 기능 하나를 골라, 실패 순간 세 가지와 각 순간에 사용자에게 보여 줄 다음 행동을 표로 쓰라.

실습 과제