16장. 사람 검토를 ‘마지막 눈대중’에서 역할로 바꾼다

human-in-the-loop는 결과가 나온 뒤 누군가 대충 읽는다는 뜻이 아니다. 누가, 무엇을, 어떤 근거로, 언제까지 확인하고, 거절하면 무엇이 일어나는지 설계해야 한다. Google Cloud의 생성형 AI 개발 가이드는 중요한 결정에서 사람 검토를 고려하고 자동 평가와 사람 평가를 조합하도록 안내한다.

검토 역할을 나눈다.

한 사람이 모두 맡을 수 있지만 체크 항목은 분리한다. 승인 화면에는 최종 문장만 보여 주지 않는다. 사용 자료, 변경 diff, 위험, 예상 영향, 롤백, 만료 시간을 함께 보여 준다.

승인은 영구 토큰이 아니다. “이 고객 100명에게 이 문구를 오늘 한 번 발송”처럼 범위와 시간이 제한되어야 한다. 내용이나 대상이 바뀌면 다시 승인한다.

DecisionDesk는 자동 검사가 모두 통과해도 awaiting_approval에서 멈춘다. 외부 공지와 고객 초대 권한이 계약에 없기 때문이다. 이 멈춤은 실패가 아니라 정상 완료 상태다.

검토 대기열이 쌓이면 사람을 없애지 말고 검토 대상을 줄인다. 저위험 사례의 샘플링, 위험 기반 라우팅, 명확한 diff, 자동 규칙으로 검토 시간을 줄인다. 승인자가 무조건 승인하게 되는 피로를 측정한다.

좋은 승인 화면의 최소 정보

승인자는 한 화면에서 “무엇이 달라지고, 왜 하며, 무엇이 위험하고, 어떻게 되돌리는지” 볼 수 있어야 한다. AI의 전체 대화 로그를 읽게 하는 것은 검토가 아니라 부담 전가다.

행동: 베타 초대 이메일 100명에게 1회 발송
변경: 지난 승인본 대비 제목 1줄·본문 2문장 변경
근거: SRC-01, SRC-02
위험: 잘못된 대상, 중복 발송
보호: 대상 allowlist, idempotency key, 테스트 수신자
롤백: 발송 취소 불가 → 후속 정정 절차
승인 만료: 30분

승인 후 내용이 바뀌면 기존 승인을 재사용하지 않는다. 승인 요청 자체가 인젝션으로 조작될 수 있으므로 서버가 실제 대상과 diff를 계산한다. 승인자에게 거절, 수정 요청, 범위 축소 선택을 제공한다.