Human-in-the-loop AI 워크플로 설계
Human-in-the-loop은 위험한 AI 실행 경로에 사람의 판단을 삽입하는 구조다. 승인 큐, 위험 기반 게이트, 상태 전이, 감사 로그, 피드백 루프를 함께 설계해야 운영 중 안전장치로 작동한다.
Script Companion
오디오와 함께 스크립트 보기
- 01
Human-in-the-loop AI 워크플로는 자동화를 포기하는 방식이 아니다. 결제, 삭제, 고객 발송, 배포처럼 권한 있는 action 앞에서 모델 판단만으로 실행하지 않도록 사람의 판단을 끼워 넣는 구조다. confidence가 낮거나 근거가 부족한 경우에도 사람에게 올려 품질을 보장한다. 여기서 중요한 질문은 단순히 승인했는지가 아니라, 누가 무엇을 보고 어떤 payload를 승인했는가다.
- 02
HITL의 개입 유형은 하나로 묶이지 않는다. Approval은 실행 허가나 거부이고, Correction은 모델 산출물을 사람이 직접 고치는 방식이다. Selection은 여러 후보 중 하나를 고르는 것이고, Escalation은 더 높은 권한자에게 넘기는 것이다. Labeling은 답변 품질 점수처럼 평가 데이터를 만드는 역할을 한다. 이 차이를 구분해야 UI 버튼 하나가 아니라 workflow 운영 구조로 설계할 수 있다.
- 03
실무의 HITL은 modal 하나가 아니라 승인 큐로 운영된다. agent가 멈춘 workflow는 queue item이 되고, reviewer는 SLA 안에서 승인, 수정, 거절, 에스컬레이션을 결정한다. queue item에는 workflow_id, risk_level, requested_action, context_summary, evidence_ids, payload_hash, deadline_at, assignee_policy 같은 필드가 필요하다. 특히 payload_hash는 승인자가 본 실행 내용이 이후에 바뀌지 않았는지 확인하는 기준이다.
- 04
승인 큐는 단순 FIFO로 정렬하면 안 된다. risk_level, deadline_at, customer_tier, action_type을 기준으로 봐야 고위험 요청이나 SLA가 임박한 요청이 뒤로 밀리지 않는다. reviewer에게도 raw trace 전체를 던지는 것이 아니라 action, 근거, 위험 이유, 변경 가능한 필드, 이전 유사 결정을 보여준다. 승인 이후 payload가 바뀌면 resume을 막고 새 queue item을 만들어야 한다.
- 05
Risk-based Gate의 핵심은 모든 step을 사람에게 묻지 않는 것이다. 모든 것을 승인받게 만들면 자동화 자체가 실패하고, 사람이 바쁜 순간 production bottleneck이 된다. risk는 비용, irreversible 여부, 개인정보, 외부 노출, 법적 영향으로 계산한다. Low는 24h 안에 자동 만료나 batch review로 이동할 수 있지만, High는 결제, 삭제, 배포, 법률 답변처럼 30~60m 안에 on-call이나 manager에게 넘어가며 자동 실행은 금지된다.
- 06
Escalation은 단순 알림이 아니라 권한과 책임의 이동이다. 1차 reviewer가 SLA를 넘기면 owner group으로 재배정하고, 금액, 고객 등급, 법적 영향이 임계값을 넘으면 manager 또는 domain expert 승인을 추가로 요구한다. timeout이 지나도 자동 승인하지 않는다. 자동화가 필요하다면 만료 시 취소하거나 안전한 fallback만 실행한다. escalation 이벤트도 audit log에 남겨 어떤 위험이 누구에게 넘어갔는지 보존한다.
- 07
HITL 구현은 상태 머신으로 남아야 한다. queued에서 assignee가 결정되면 assigned가 되고, reviewer가 열람하면 waiting_for_review가 된다. 여기서 approve, edit, reject, escalate, deadline 초과 같은 이벤트가 각각 approved, edited, rejected, escalated, expired로 이어진다. resume 시에는 같은 workflow_id와 승인 payload_hash를 검증하고, idempotency_key로 중복 resume을 막아야 한다. 실행 결과는 workflow_id로 audit log와 연결된다.
- 08
Reviewer UI는 요청 요약, 근거, 위험과 정책, 수정 가능 필드, 결정 순서로 구성한다. 보여주면 안 되는 것은 raw prompt, 전체 trace dump, secret이 포함될 수 있는 tool argument 원문, 다른 reviewer의 사전 판단이다. 이런 정보는 판단 오염과 PII 장기 보관을 만들 수 있기 때문에 evidence_id, trace_id, redacted diff로 연결한다. API 계약에서도 hash 불일치는 409 Conflict로 처리하고 새 item을 만드는 흐름이 필요하다.
- 09
감사 로그에는 승인했다는 결과만으로 부족하다. append-only로 저장하고, reviewer가 결정을 바꾸면 기존 row를 수정하지 않고 새 event를 추가한다. approval record와 실제 tool execution span은 workflow_id, payload_hash, idempotency_key로 join되어야 한다. 민감 정보는 원문 대신 참조와 hash를 남기고, app log와 audit log도 분리한다. app log는 장애 분석용이고, audit log는 책임, 권한, 증거 보존용이다.
- 10
HITL 결과는 평가 시스템으로 되돌아간다. reviewer마다 승인 기준이 다르면 HITL은 안전장치가 아니라 랜덤 gate가 되므로 calibration이 필요하다. Inter-reviewer agreement, Override rate, Rubber-stamp rate, Escalation accuracy, Drift in decisions 같은 신호를 보고 rubric과 policy를 조정한다. 고정 calibration set 50~200개를 두고, high-risk route에는 dual review 또는 expert review를 둘 수 있다.
- 11
대표적인 실패는 조용히 드러난다. 너무 많은 저위험 승인 요청은 rubber stamp를 만들고, 승인 payload와 실행 payload가 분리되면 승인 후 다른 내용이 실행된다. timeout이나 escalation이 없으면 workflow가 영원히 대기하고, raw trace만 제공하면 사람이 맥락을 이해하지 못한다. 정리하면 HITL의 중심은 confirm modal이 아니라 durable state, payload hash, SLA, escalation, append-only audit log, 그리고 calibration으로 이어지는 feedback loop다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정