설계 가이드
AI 선판단과 담당자 검토를 함께 쓰는 식품 제조 Human-in-the-loop 설계
AI가 점검 의견을 정리해 주면 담당자는 마지막에 승인 버튼만 누르면 될까요? 검토할 자료가 부족하거나, 의견을 고쳐야 하거나, 승인 직전에 원본이 바뀌는 상황을 생각하면 버튼 하나로 끝나지 않습니다.
이 글에서는 가상의 점검 검토 업무를 재구성해 살펴봅니다. 특정 조직의 승인 규칙이나 실제 자동화 범위를 설명하는 것은 아니에요.
먼저 자동화할 행동과 남겨둘 판단을 나눕니다
기록 정리, 관련 문서 찾기, 누락 항목 표시처럼 판단을 준비하는 일과, 출하·폐기·거래 제한처럼 영향이 큰 결정을 같은 단계로 묶지 않는 편이 좋습니다.
AI는 검토 초안을 작성하되 실제 조치를 실행할 권한은 별도로 두는 방식이 가능해요. 어디까지 자동화할지는 업무 영향과 조직의 기준에 따라 정해야 합니다. 사람이 참여한다는 이유만으로 모든 판단이 안전해지는 것은 아니고요.
NIST의 Govern 항목도 AI 위험 관리의 역할과 책임을 분명하게 정하도록 안내합니다.[1] 여기서 필요한 질문은 “승인자가 있나?”뿐 아니라 “누가 무엇을 확인하고, 문제가 있을 때 누가 멈출 수 있나?”예요.
검토 상태는 승인과 반려만으로 부족합니다
예시 업무에서는 AI 초안, 검토 중, 자료 보완 요청, 승인, 재검토 필요를 서로 구분해보세요. 자료가 빠져서 기다리는 항목을 단순 반려로 처리하면 무엇을 보완해야 하는지 찾기 어려워집니다.
담당자가 의견을 수정했을 때도 원래 AI 제안과 최종 의견을 따로 남깁니다. 수정 이유는 업무에서 다시 읽을 수 있을 정도로 구체적으로 적되, 불필요한 개인정보나 민감한 내용을 입력하게 만들지는 않아요.
AI가 근거를 찾지 못한 상황은 자동 승인으로 넘어가면 안 됩니다. ‘문제 없음’과 ‘판단할 자료가 없음’을 별도 상태로 두어야 해요.
승인 직전에 자료가 바뀌면 다시 확인합니다
검토자가 이전 자료를 보고 승인하는 동안 다른 담당자가 기록을 고쳤다고 해볼게요. 승인 시점에는 검토한 자료 버전과 현재 버전이 같은지 확인하도록 설계할 수 있습니다.
다르면 오래된 화면의 승인 요청을 그대로 반영하지 않고 변경 내용을 보여줍니다. 승인 후 중요한 근거가 바뀌었을 때도 이미 끝난 검토를 조용히 최신 상태처럼 표시하지 않아요. 영향 범위를 확인한 뒤 재검토 대상으로 돌리는 절차를 정합니다.
이때 어떤 변경이 재검토를 요구하는지는 조직이 정할 업무 규칙입니다. 모델의 자신감 점수 하나에 맡길 문제가 아니에요.
오래된 화면에서 승인한 요청은 어떻게 처리할까요?
가상의 검토 건 R-17을 두 사람이 동시에 열었다고 해볼게요. 검토자 A가 읽은 자료는 7판인데, 다른 담당자가 근거를 보완해 현재 자료가 8판으로 바뀌었습니다. A의 화면에는 여전히 7판이 남아 있어요. 이때 승인 버튼을 누르면 무엇이 저장돼야 할까요?
이 설계안에서는 바로 승인하지 않습니다. 요청에 검토자가 확인한 자료 버전과 검토 건 버전을 포함하고, 서버가 현재 상태와 대조해요. 승인 권한, 승인 가능한 상태, 자료 버전이 모두 맞을 때만 상태를 바꿉니다. 비교 후 저장하는 사이에도 값이 바뀔 수 있으므로, 비교와 갱신은 하나의 원자적인 처리로 묶어야 합니다. 화면에서 한 번 확인하는 것만으로는 충분하지 않아요.
검토자가 볼 안내는 “저장 실패”보다 구체적이어야 합니다. “검토 중 근거가 7판에서 8판으로 바뀌었어요. 변경 내용을 확인한 뒤 다시 검토해주세요”라고 알리고, 작성하던 의견은 보호해두는 거죠. 이전 의견을 새 근거에 대한 승인으로 자동 전환하지는 않습니다.
이 업무의 상태와 행동을 다음처럼 정해볼 수 있어요.
AI 초안: 근거를 모아 제안한 상태. 실제 조치는 실행하지 않아요.
검토 중: 담당자가 원본을 확인하고 의견을 작성해요.
자료 보완 대기: 무엇이 부족한지와 확인할 담당자를 남겨요.
검토 승인: 권한·상태·버전 확인을 통과한 의견을 기록해요.
재검토 필요: 중요한 근거 변경을 발견했을 때 이전 승인과 구분해 표시해요.
상태 이름은 조직마다 달라도 됩니다. 중요한 것은 ‘자료가 없어 기다린다’와 ‘내용을 검토해 승인했다’를 같은 상태로 두지 않는 거예요. 승인된 검토 의견을 출하나 거래 제한 같은 실행 명령으로 취급하지 않는 경계도 필요합니다. 후속 실행에는 별도의 권한과 확인 절차를 둘 수 있어요.
네트워크가 끊긴 경우도 시험해보세요. 서버에는 승인이 저장됐지만 응답이 사용자에게 도착하지 않을 수 있습니다. 사용자가 같은 요청 K-17을 다시 보내면 새로운 승인이나 후속 작업을 중복 생성하는 대신, 동일한 권한 범위와 요청 내용인지 확인한 뒤 이미 처리한 결과를 돌려주는 방식으로 설계합니다. 알림·외부 시스템 호출까지 중복을 막으려면 그 후속 단계에도 별도의 처리 식별자와 확인 절차가 필요해요.
검증할 장면은 정상 승인, 오래된 버전의 승인, 권한 없는 승인, 응답 유실 후 재요청입니다. 각각 한 번만 반영, 변경 안내와 미승인, 서버에서 거절, 기존 처리 결과 확인으로 끝나는지 봅니다. 이 결과는 기대 동작이며, 특정 고객 시스템에서 시험을 마쳤다는 의미는 아닙니다.
이미 물리적인 조치가 실행됐다면 화면 상태를 되돌리는 것만으로 복구됐다고 표시해서는 안 됩니다. 담당자가 실제 실행 여부와 영향을 확인하고 별도 대응을 결정해야 해요. 사람이 멈출 수 있는 버튼뿐 아니라, 어디까지 실행됐는지 확인할 정보도 함께 준비해야 합니다.
사람이 실제로 검토할 수 있는 화면이어야 합니다
승인 건수가 많으면 모든 항목을 같은 깊이로 읽기 어렵습니다. 우선순위의 이유, 원본 근거, 변경된 부분을 먼저 볼 수 있게 하고, 담당자의 검토 역량과 가용 시간도 함께 확인해야 해요.
운영 결과를 볼 때는 승인률만 높이려 하지 마세요. 보완 요청이 어느 이유로 반복되는지, 잘못된 제안을 그대로 받아들인 경우는 없는지, 되돌릴 수 없는 조치 전에 충분히 확인했는지를 봐야 합니다.
Human-in-the-loop는 사람을 마지막 칸에 배치하는 방식이 아닙니다. 사람이 판단을 바꾸고 멈출 수 있도록 정보와 권한을 연결하는 설계에 더 가까워요.
자동화와 담당자 판단의 경계가 모호하다면, 데이터스케쳐스와 실제 업무 한 단계를 골라 검토 흐름부터 정리해보세요.
참고자료
[1] NIST AI RMF Playbook · Govern
https://airc.nist.gov/airmf-resources/playbook/govern/
AI 위험 관리 역할, 책임, 의사소통과 감독 체계
자료 확인: 2026-10-08. 본문의 가상 상황·화면 구성·점검 절차는 출처의 실제 사례가 아니라 이 글에서 제안한 적용 예시입니다.