부록 B. 셀프 체크 정답과 해설

1-1. 에이전트는 필요한 단계 수를 미리 예측하기 어렵거나 불가능한 열린 문제에 맞습니다. 대가는 자율성에서 오는 비용 증가와 오류 누적 가능성이며, 넓은 도구 권한도 함께 따져야 합니다. 그래서 Anthropic은 샌드박스에서의 충분한 시험과 적절한 가드레일을 권합니다. 단계가 정해진 일이라면 워크플로가 더 단순한 답입니다.

1-2. 가이드는 여섯 가지를 듭니다. 예측 가능성을 유지해야 하는 일, 정적이거나 제한된 정보를 제공하는 일, 비싼 오류를 최소화해야 하는 일, 완전한 투명성이 필요한 일, 빠르고 싸게 만드는 것이 가장 중요한 일, 사람들이 가치를 두고 직접 하고 싶어 하는 일의 자동화입니다. 이런 일에서는 규칙, 검색, 사람의 판단이 AI보다 나을 가능성이 큽니다.

1-3. 규칙·조회가 맞습니다. 남은 좌석 수는 예약 시스템에 이미 정확한 값으로 있으므로, 질문 의도만 가볍게 알아듣고 조회한 값을 그대로 보여 주면 됩니다. 생성 모델이 숫자를 문장으로 옮기면 얻는 것은 없고 숫자를 잘못 옮길 위험과 비용만 생깁니다.

1-4. 방문 기록을 시스템에 남기는 업무 절차와 저장 구조부터 만듭니다. 예측 모델은 과거 기록이 있어야 만들 수 있고, 기대 결과가 있어야 평가할 수 있습니다. 종이 명부만 있는 상태에서는 개발을 시작해도 결과를 검증할 방법이 없습니다.

1-5. AI 기본법 제34조제1항은 위험관리방안의 수립·운영, 기술적으로 가능한 범위에서의 설명 방안 수립·시행, 이용자 보호 방안의 수립·운영, 사람의 관리·감독, 안전성·신뢰성 확보 조치를 확인할 수 있는 문서의 작성과 보관 등을 요구합니다. 이와 별도로 제31조제1항의 사전 고지가 적용되고, 제35조제1항은 사전에 사람의 기본권에 미치는 영향을 평가하는 고영향 인공지능 영향평가를 하도록 노력하라고 정합니다.

1-6. 제37조의2제1항 단서에 따라 동의·법률·계약 이행 등에 따른 결정이면 거부권은 제한될 수 있습니다. 하지만 정보주체가 결정에 대한 설명 등을 요구할 권리(제2항)와 그에 따른 처리자의 조치 의무(제3항), 결정의 기준과 절차, 개인정보 처리 방식을 쉽게 확인할 수 있게 공개할 의무(제4항)는 그대로 남습니다. 시행령에 따르면 처리자는 정당한 사유가 없으면 결정의 결과·주요 기준·처리 절차 등을 담은 간결하고 의미 있는 설명을 제공하거나, 정보주체가 낸 의견의 반영 여부를 검토해 알려야 합니다. 거부권 제한이 조항 전체의 면제를 뜻하지 않습니다.

1-7. 답은 과제마다 다릅니다. 좋은 답안은 다섯 질문(규칙으로 정해지는가, 원문을 보여 주면 끝나는가, 효과가 비용을 넘는가, 기록과 기대 출력이 있는가, 오류가 되돌릴 수 없는 피해로 이어지는가)에 차례로 답하고, 처음 걸린 질문에서 여섯 결론(착수(자동화), 착수(보조 형태), 형태 변경(규칙·검색), 데이터 선행, 보류(지금 방식 유지), 만들지 않음) 가운데 하나를 냅니다. 착수로 결론 났다면 평가 세트 준비를 다음 행동으로 적습니다.

2-1. 반드시 들어갈 네 요소는 무엇을(지표), 어디서(데이터), 얼마나(기준값), 어떻게(측정 방법)입니다. 하나라도 빠지면 다른 사람이 합격·불합격을 판정할 수 없습니다. 여기에 기준선(무엇과 비교한 숫자인지)을 함께 적으면 기준값이 왜 그 숫자인지 설명할 수 있습니다.

2-2. 예를 들어 "운영 요청의 95%에서 첫 토큰이 1.5초 안에 나오고, 전체 응답이 8초 안에 끝난다"처럼 백분위와 시간 한도로 씁니다. 사용자가 화면 앞에서 기다리는 기능은 체감 지연을 좌우하는 첫 토큰까지의 시간(TTFT)을 주된 지표로 삼고, 전체 시간은 보조 지표로 둡니다. 측정 방법에는 어디서 재는지(네트워크를 포함한 사용자 기기 기준인지, 서버의 API 응답 기준인지)도 적어야 개발팀과 같은 기준으로 판정할 수 있습니다.

2-3. 정밀도는 양성으로 판정한 것 가운데 실제 양성의 비율이고, 재현율은 실제 양성 가운데 양성으로 잡아낸 비율입니다. 앞의 것은 "잡은 것이 얼마나 맞나", 뒤의 것은 "잡아야 할 것을 얼마나 잡았나"를 잽니다.

2-4. 정밀도를 지켜야 합니다. 잡아낸 건이 사람 확인 없이 바로 예약 삭제로 이어지므로, 취소 요청이 아닌 문자를 잘못 잡으면 정상 예약이 지워지는 사고가 됩니다. 놓친 취소 요청은 직원이 문자를 다시 보거나 환자가 다시 연락해 처리할 수 있다면 비용이 상대적으로 작습니다.

2-5. 모델이 안전상의 이유로 거절한 경우(stop_reason이 refusal)에는 거절 메시지가 스키마 제약보다 우선해 출력이 스키마와 맞지 않을 수 있습니다. 출력이 max_tokens 한도에 닿아 잘린 경우에도 결과가 불완전해 스키마를 지키지 못할 수 있습니다. 그래서 검증과 실패 처리 규칙이 필요합니다.

2-6. (가) 계좌번호가 남는 비율은 개인정보 사고로 이어지므로 출시 차단 기준입니다. (나) 간결함 점수는 사용에 지장이 없는 품질 항목이므로 개선 목표입니다. (다) 환불 기한 오기 비율은 고객이 잘못된 기한을 믿고 행동해 피해가 생길 수 있으므로 출시 차단 기준입니다.

2-7. 좋은 답안은 실패 순간(답할 수 없음, 입력이 범위 밖, 근거 부족, 처리 지연, 시스템 장애 등)마다 사용자에게 보여 줄 문구와 다음 행동(직접 입력, 관련 메뉴, 담당자 연결, 다시 시도 시점)을 구체적으로 적습니다. "오류가 발생했습니다"처럼 다음 행동이 없는 칸이 있으면 아직 설계가 끝나지 않은 것입니다.

3-1. 평가 목표 정의, 데이터 수집, 평가 지표 정의, 실행과 비교, 지속 평가 순입니다. 앞 단계의 결과가 다음 단계의 입력이므로 순서를 바꿀 수 없습니다.

3-2. 관련 없거나 존재하지 않는 입력, 지나치게 긴 입력, 채팅 기능이라면 질 낮거나 해롭거나 관련 없는 사용자 입력, 그리고 사람끼리도 판정이 갈리는 애매한 사례입니다.

3-3. 코드 채점은 규칙으로 표현하기 어려운 복잡한 판단에 뉘앙스가 부족하고, 정답과 표현만 다른 올바른 답에 약합니다. LLM 채점은 결과가 조금씩 달라질 수 있어 신뢰도를 먼저 확인하고 사람 채점과 보정해야 합니다. 사람 채점은 품질이 높지만 느리고 비쌉니다.

3-4. 반납 기한 날짜는 대출 시스템의 값과 정확히 일치하는지 코드로 채점합니다. 정답이 정해져 있어 가장 빠르고 믿을 만합니다. 안내 말투는 정답 문자열이 없으므로 루브릭을 준 LLM 채점기로 매기되, 사람이 채점한 표본과 먼저 대조해 일치도를 확인한 뒤 씁니다.

3-5. 역량 평가는 아직 잘 못하는 일을 얼마나 잘하게 됐는지 보며 낮은 통과율에서 시작합니다. 회귀 평가는 이미 잘하던 일을 계속 잘하는지 보며 통과율이 거의 100%여야 합니다. 역량 과제를 꾸준히 잘하게 되면 그 과제를 회귀 묶음으로 졸업시켜 계속 돌리며 성능 저하를 감시합니다.

3-6. 개발 세트에 맞춰 고친 과적합을 의심해야 합니다. 개발 세트에서는 23%p 올랐지만 고칠 때 보지 않은 보류 세트에서는 2%p만 올랐으므로, 실제 개선은 작습니다. 출시 판단은 보류 세트 결과로 하고, 개발 세트에서만 고쳐진 사례를 읽어 원인을 찾습니다.

3-7. 사람이 여러 후보 가운데 하나를 고르는 기능은 k번 중 적어도 한 번 성공하면 되므로 pass@k가 맞습니다. 고객이 매번 같은 품질의 답을 받아야 하는 기능은 k번 모두 성공해야 하므로 pass^k가 맞습니다.

3-8. 좋은 답안은 이 장의 양식 칸을 모두 채우고, 성공 기준마다 채점 방식(정답과 대조할 수 있으면 코드 채점, 루브릭으로 판정할 수 있으면 사람과 대조해 보정한 LLM 채점, 전문 판단이 필요하면 사람 채점)과 그 이유를 적습니다. 평가 세트 칸에는 실제 비율 대비 구성, 경계 사례 묶음, 고위험 묶음, 그리고 각 묶음에서 떼어 둔 보류 세트가 따로 적혀 있어야 합니다.

4-1. 모델이 "모른다"고 말할 수 있게 허락하기, 긴 문서에서 직접 인용을 먼저 뽑아 근거로 삼기, 주장마다 인용으로 검증하고 근거를 찾지 못한 주장은 철회하게 하기입니다.

4-2. 과잉 거절은 틀린 정보를 주지 않으므로 틀린 답의 비율(오류율)에는 잡히지 않습니다. 정답률을 전체 문항 기준으로 재면 거절도 정답이 아닌 것으로 세어져 점수가 떨어지지만, 거절률을 따로 보지 않으면 그 하락이 거절 때문인지 드러나지 않습니다. 다루는 방향은 둘입니다. 답할 수 있었던 거절 사례를 평가 세트에 넣고 고쳐 거절 자체를 줄이는 것, 그리고 거절하더라도 관련 메뉴나 담당자 연결 같은 다음 행동을 보여 주는 것입니다.

4-3. Claude 문서에 따르면 구조화 출력은 문자열 열거값(enum, const)의 대소문자를 보장하지 않아, 오류나 특별한 중단 사유 없이 정상 종료한 응답에도 대소문자만 다른 값이 들어 있을 수 있습니다. 그래서 열거값은 대소문자를 구분하지 않고 비교하는 검증을 남깁니다. 거절(stop_reason이 refusal)이나 max_tokens 도달로 스키마를 벗어나는 경우도 있으므로, 중단 사유 확인과 스키마 검증을 함께 둡니다.

4-4. 대기열이 맞습니다. 30분째 이어지는 장애에는 몇 번의 재시도가 맞지 않고, 발송은 실시간이 필요 없으며 내일 오전까지 여유가 있습니다. 요청을 보관했다가 복구 후 처리하고, 담당자에게 완료 예정 시각을 알립니다. 단계적 축소는 사용자가 지금 결과를 봐야 하는 기능에서 더 단순한 경로를 제공할 때 맞는 대응입니다.

4-5. 사전 승인은 결과를 되돌릴 수 없고 처리량이 검토 여력 안일 때, 조건부 이관은 처리량이 크고 위험이 특정 부분집합에 몰려 있을 때, 사후 표본 점검은 오류를 쉽게 고칠 수 있고 피해가 작을 때, 이의 제기 처리는 결과가 개인에게 영향을 주고 당사자가 오류를 알아챌 수 있을 때 맞습니다.

4-6. 첫째, AI가 실제로 매우 정확해 모든 건의 사전 승인이 과한 상황일 수 있습니다. 이 경우 위험 조건과 낮은 확신에 걸린 건만 보내는 조건부 이관으로 줄입니다. 둘째, 검토자에게 판단 근거나 수정 권한이 없어 확인을 포기한 형식적 승인일 수 있습니다. 이 경우 검토 화면에 근거와 수정·거부 기능, 사유 기록을 넣습니다. 알려진 오류를 일부러 섞어 검토자가 잡아내는지 보면 둘을 가를 수 있습니다.

4-7. 제1항은 고영향 또는 생성형 인공지능을 이용한 제품·서비스를 제공하려는 경우 그 제품·서비스가 해당 인공지능에 기반해 운용된다는 사실을 이용자에게 사전에 고지하라고 요구합니다. 제2항은 생성형 인공지능이나 그것을 이용한 제품·서비스를 제공하는 경우 결과물이 생성형 인공지능으로 생성되었다는 사실을 표시하라고 요구합니다. 둘은 별개의 의무여서 한쪽을 이행했다고 다른 쪽이 면제되지 않습니다.

4-8. 좋은 답안은 적어도 지어낸 답, 과잉 거절, 형식 오류, 일시적 장애, 긴 장애를 행으로 두고, 각 행에 예방(근거 인용, 거절 사례 평가, 구조화 출력, 트래픽 점진 증가, 대체 경로 준비), 감지 지표, 실패 시 동작, 사용자에게 보이는 문구와 다음 행동을 채웁니다. 면책 문구만 적힌 칸이 있다면 그 칸은 대응이 아닙니다.

5-1. 문제를 드러낼 수 있어야 하고, 대표성이 있어야 하며, 변경에 귀속될 수 있어야 합니다.

5-2. 섀도 테스트는 사용자에게 새 결과를 보여 주지 않으므로 신고, 이탈, 전환 같은 사용자 반응을 잴 수 없습니다. 사용자 반응을 봐야 하고 되돌리기 쉬운 변경이면 카나리를, 두 안의 사업 지표 효과를 비교하려면 A/B 실험을 씁니다.

5-3. 작은 표본에서 나온 차이는 우연일 수 있어 기준을 넘었는지 판정할 수 없습니다. 최소 표본이 없으면 우연한 잡음 때문에 되돌리거나, 근거 없이 다음 단계로 넓히게 됩니다. 최소 표본은 판정의 전제 조건입니다.

5-4. 시스템(오류, 지연, 비용), 품질(근거 인용 비율, 스키마 검증 실패, 거절률, 표본 채점), 사용자 행동(재생성, 상담 전환, 이탈, 신고), 사업(전환, 절감)의 네 층입니다. 지어낸 답은 시스템 입장에서 정상 응답으로 나가므로 오류 응답률에는 아무것도 잡히지 않습니다.

5-5. Active(완전 지원, 권장), Legacy(업데이트 중단, 앞으로 지원 중단될 수 있음), Deprecated(동작하지만 권장되지 않음, 대체 모델과 은퇴일 지정), Retired(사용 불가)입니다. 은퇴한 모델로 보낸 요청은 실패합니다.

5-6. 확산 차단(끄기, 사람에게 돌리기, 되돌리기), 영향받은 사람 찾기와 알림·정정, 원인 수정과 복구(회귀 평가로 확인한 뒤 단계적으로 다시 열기), 기록, 비난 없는 회고, 재발 방지 조치의 실행과 확인 순입니다.

5-7. 첫째 유형은 50건 × 4만 원 × 고객에게 나간 10% = 월 20만 원, 둘째 유형은 1,200건 × 2,000원 = 월 240만 원입니다. 월 피해로는 둘째 유형이 먼저입니다. 다만 첫째 유형이 법·안전 문제나 큰 신뢰 손상으로 이어질 수 있다면, 차단 장치가 충분한지 따로 확인합니다.

5-8. 좋은 답안은 출시 범위, 출시 방식과 고른 이유, 단계별 비율·기간·최소 표본, 대조군, 숫자로 된 중단 기준, 되돌리는 방법(이미 처리된 결과 포함), 운영 지표와 알림, 변경 관리, 사고 연락 체계를 모두 담습니다. 중단 기준에 최소 표본이 없거나 대조군이 출시 전후 비교라면 다시 고칩니다.