사람이 검토하는 단계가 제 역할을 하지 못하는 경우가 많은 이유는 무엇입니까?
사람이 검토하는 단계가 제 역할을 하지 못하는 경우가 많습니다. 검토자가 AI의 판정만 보고, 확인할 항목은 너무 많으며, 무엇을 살펴봐야 하는지 안내받지 못하면 승인이 가장 빠른 처리 방법이 되기 때문입니다. 이를 형식적 승인이라고 하며, 실질적인 감독 없이 감독하는 모양새만 갖추게 됩니다.
직원 25명의 가상 도매 유통업체 오크브리지 서플라이즈를 생각해 봅니다. AI 도구는 공급업체 청구서를 구매 주문서와 대조하고 각각 '일치' 또는 '불일치'로 표시합니다. 회계 담당자 프리야는 일치하는 항목의 지급을 승인합니다. 어느 목요일의 처리 대기 목록에는 '청구서 212건, 일치 205건, 불일치 7건'이라고 표시돼 있습니다. 각 행에는 공급업체, 금액, 녹색 체크 표시가 보입니다. 지난달에는 40개만 납품됐는데도 400개에 대한 공급업체 청구서가 지급됐습니다. 도구가 주문 번호의 일치 여부만 확인했고, 프리야는 체크 표시를 보고 승인했기 때문입니다.
어떤 단계에서 사람이 검토하고 개입해야 합니까?
AI 출력이 금전, 개인의 접근 권한, 고객과의 약속, 법적 결과나 안전에 영향을 준다면 사람이 검토에 참여해야 하며, 그 변화가 되돌리기 어려워지기 전에 검토해야 합니다. 일상적이고 되돌릴 수 있는 출력은 대신 표본을 추출해 확인할 수 있습니다.
EU AI Act의 고위험 시스템에 대한 인간 감독 조항도 같은 요점을 규제 용어로 설명합니다. 시스템을 감독하는 사람은 시스템의 한계를 이해하고, 자동화 편향을 경계하며, 출력을 무시하거나 되돌리거나 중단할 수 있어야 합니다. 이 법의 적용 대상이 아니더라도 좋은 설계 목표입니다.
사람이 검토하고 개입하는 절차는 어떤 방식으로 설계할 수 있습니까?
일반적인 검토 설계는 네 가지이며, 어떤 설계가 적합한지는 오류에 따른 비용과 검토할 항목 수에 따라 달라집니다.
실행 전 승인
어떤 조치가 실행되기 전에 사람이 각 출력을 승인합니다. 일정 금액을 넘는 지급이나 고객 환불처럼 건별 비용이 크고 처리 건수가 적은 업무에 사용합니다.
예외 검토
AI가 명확한 사례를 처리하고 불확실하거나 이례적인 사례는 사람에게 넘깁니다. 이 방식은 전달 규칙을 테스트하고 '명확한' 사례 중 일부도 계속 점검할 때만 유효합니다.
표본 감사
결과물을 먼저 내보낸 뒤 담당자가 무작위 표본을 확인합니다. 내부 요약처럼 되돌릴 수 있고 처리량이 많은 업무에 사용합니다.
먼저 스스로 수행
AI의 제안을 보기 전에 사람이 먼저 자신의 판단을 내립니다. 시간이 더 걸리지만, 중요한 판단에서 AI 답변에 생각이 고정되는 것을 막아 줍니다.
미흡한 검토 설계와 개선된 검토 설계는 어떻게 다릅니까?
미흡한 설계: 모든 청구서가 초록색 또는 빨간색 표시와 함께 프리야에게 전달됩니다. 프리야는 20분 만에 체크 표시 205개를 승인합니다. 각 항목에 왜 체크 표시가 붙었는지 알려 주는 정보도 없고, 프리야가 여전히 내용을 살펴보고 있는지 확인하는 장치도 없습니다.
개선된 설계: 일정 금액 미만의 청구서 중 주문 번호, 수량, 단가가 모두 납품서와 일치하는 건은 자동으로 지급하고, 프리야가 매주 무작위로 열 건을 확인합니다. 기준 금액을 초과하거나 신규 공급업체이거나 수량 차이가 있는 건은 세 항목을 나란히 배치하고 '청구 수량 400, 납품 수량 40'과 같은 AI의 판단 이유 한 줄을 덧붙여 프리야에게 전달합니다. 재무 책임자는 오류가 잡히는지 확인하기 위해 매달 오류가 있다고 확인된 두 건을 검토 대기 목록에 알리지 않고 넣습니다. 프리야는 AI의 판단을 번복할 때마다 기록도 남깁니다. 번복 건수가 갑자기 0으로 떨어지면 성공이 아니라 경고 신호로 봅니다.
검토가 형식적인 승인에 그치지 않고 실질적으로 이루어지는지 어떻게 확인합니까?
항목당 검토 시간, 검토자가 AI의 판단을 수정하는 빈도, 의도적으로 넣은 테스트용 오류의 발견 여부를 측정하여 실제로 검토가 이루어지는지 확인합니다. 도구의 판단에 한 번도 이의를 제기하지 않는 검토자는 매우 우수한 결과물을 검토하고 있거나, 아예 검토하지 않고 있는 것입니다. 어느 쪽인지 판단하려면 근거가 필요합니다.
판정만이 아니라 근거도 제시합니다
빠르게 확인할 수 있도록 AI 답변 옆에 원본 필드를 배치합니다.
대기열 제한하기
사람이 해당 분량을 제대로 검토할 수 없다면 더 노력하라고 요구하지 말고 설계를 바꿔야 합니다.
권한 부여
검토자는 허락을 받지 않고도 거부하거나 일시 중지할 수 있어야 합니다.
반복 과정 테스트
때때로 이미 알려진 오류를 포함하고, 해당 오류가 발견되는지 기록합니다.
사람이 검토에 참여하는 방식에서 흔히 하는 실수는 무엇입니까?
가장 흔한 실수는 다른 것은 그대로 둔 채 절차에 검토자만 추가하고, 그 사람의 승인을 결과가 정확하다는 증거로 여기는 것입니다. 그 밖에도 한 사람에게 하루 수백 건의 승인을 요구하거나, 여러 번 클릭해야 근거를 볼 수 있게 하거나, 되돌릴 수 없는 결정을 이미 실행한 뒤 검토하거나, 사람이 AI 판단을 수정하는 비율이 낮아진 이유는 묻지 않고 이를 성과로 여기는 실수가 있습니다. 신중한 사람도 자동화 편향의 영향을 받으므로, 좋은 의도보다 설계가 더 중요합니다.
Tosheo.ai 교육 과정에서 사람의 검토와 개입은 어디에 해당합니까?
사람이 검토 과정에 참여하는 방식은 AI 활용 역량 과정의 책임 있는 AI 및 정책 범주에 속하며, 윤리적 AI와 책임 있는 AI 통제 수업 다음에 나옵니다. 도구가 제안에 그치지 않고 직접 행동하는 에이전트형 AI 및 자동화 수업에서도 다시 다룹니다. 실습 과제에서는 자신의 업무에 있는 검토 단계를 재설계합니다. 평가 기준에 따른 피드백으로 검토 시점, 근거, 권한이 모두 명확한지 확인합니다.
출처와 범위
규정 (EU) 2024/1689(EU AI Act), 인간의 감독에 관한 제14조, EUR-Lex(2026년 10월 19일 확인) ↗