Human-in-the-loop AI 워크플로 아키텍처

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L12-60 (Agent), L12-80 (Security), L12-110/120 (State/Durable workflow)

Human-in-the-loop AI 워크플로 아키텍처 — Approval, Review, Escalation, Audit

1. 한 줄 정의

Human-in-the-loop(HITL) AI 워크플로는 LLM/agent가 모든 결정을 자동 실행하지 않고, 위험·불확실성·권한 경계가 있는 지점에서 사람의 승인, 수정, 선택, 책임 기록을 받도록 설계한 실행 구조다.

2. 왜 중요한가

권한 있는 action 보호: 결제, 삭제, 고객 발송, 배포 같은 action은 모델 판단만으로 실행하면 위험하다.
불확실성 흡수: confidence가 낮거나 근거가 부족한 경우 사람에게 올려 품질을 보장한다.
책임 소재: “누가 무엇을 보고 승인했는가”가 감사 로그로 남아야 한다.
학습 데이터 생성: 사람 수정은 gold dataset과 preference data가 된다.
UX 신뢰: 사용자는 agent가 멈춘 이유와 필요한 입력을 이해해야 한다.

2.5 선행 기술의 한계 — 완전 자동 agent와 마지막 Approve 버튼의 위험

완전 자동 agent는 낮은 위험의 반복 작업에서는 유용하지만, 외부 발송·삭제·결제·배포처럼 되돌리기 어려운 action에서는 모델의 confidence만으로 책임 경계를 세울 수 없다. 반대로 초기 HITL 구현처럼 마지막에 Approve / Reject 버튼만 붙이는 방식도 충분하지 않다. 실제 workflow에서는 승인이 마지막 한 번으로 끝나지 않는다.

검색 결과가 부족하면 사람이 query를 고쳐야 한다.
tool call 전에 권한과 파라미터를 승인해야 한다.
draft가 애매하면 직접 수정 후 이어가야 한다.
일정 시간이 지나면 다른 담당자에게 escalate해야 한다.
승인자가 본 context와 최종 실행 payload가 같았는지 기록해야 한다.

LangGraph의 interrupt는 graph 실행 중 특정 지점에서 멈추고 persistence로 상태를 보존한 뒤, Command(resume=...)로 이어가는 패턴을 제공한다. 출처: LangGraph human-in-the-loop interrupts. Durable workflow에서는 이 interrupt가 Temporal signal 같은 외부 이벤트와 연결된다.

3. 핵심 개념

3.1 HITL 개입 유형

유형	사람의 역할	예시
Approval	실행 허가/거부	”이 이메일을 고객에게 보낼까요?”
Correction	모델 산출물 수정	요약 문장 직접 편집
Selection	여러 후보 중 선택	검색 결과/계획 후보 선택
Escalation	더 높은 권한자에게 전달	환불 금액이 기준 초과
Labeling	평가 데이터 생성	답변 품질 점수 입력

Approval Queue 운영 모델

실무 HITL은 modal 하나가 아니라 승인 큐로 운영된다. agent가 멈춘 workflow를 queue item으로 만들고, reviewer가 SLA 안에 승인·수정·거절·에스컬레이션한다.

[Agent workflow]
   ↓ risk/confidence/policy decision
[Approval Queue]
   ↓ assign reviewer + deadline + context package
[Review UI]
   ↓ approve / edit / reject / escalate
[Resume workflow]
   ↓ payload hash 검증 + execution
[Audit log + eval dataset candidate]

queue item에는 최소 필드가 필요하다.

필드	의미
`workflow_id`	resume할 durable workflow 식별자
`risk_level`	low/medium/high 또는 점수. SLA·권한·escalation 기준
`requested_action`	send_email, refund, deploy, delete 같은 실행 의도
`context_summary`	reviewer가 볼 결정 요약. raw trace 전체를 대신한다
`evidence_ids`	근거 문서·trace span·tool result 식별자
`payload_hash`	승인자가 본 실행 payload의 불변성 검증
`deadline_at`	SLA 만료 시각
`assignee_policy`	owner, on-call, domain expert, manager 등 배정 규칙
`reviewer_decision`	approved/edited/rejected/escalated
`calibration_outcome`	reviewer 간 판정 일치도·품질 샘플링에 쓰는 후처리 라벨

운영 규칙:

queue는 risk_level, deadline_at, customer_tier, action_type으로 정렬한다. 단순 FIFO면 고위험·SLA 임박 요청이 뒤로 밀린다.
reviewer에게는 trace 원문이 아니라 action, 근거, 위험 이유, 변경 가능한 필드, 이전 유사 결정만 보여준다.
승인 이후 payload가 바뀌면 resume을 막고 새 queue item을 만들어야 한다.
batch approval은 저위험 반복 작업에만 허용한다. 외부 발송·금전·권한 변경은 item 단위 확인을 유지한다.

3.2 Risk-based Gate

모든 step을 사람에게 묻는 것은 자동화 실패다. gate는 risk에 따라 둔다.

if action.risk == "low" and confidence >= 0.9:
  auto_execute
elif action.risk == "medium":
  ask_reviewer
else:
  require_owner_approval

risk는 비용, irreversible 여부, 개인정보, 외부 노출, 법적 영향으로 계산한다.

SLA와 Escalation Policy

HITL gate는 사람이 바쁘면 곧바로 production bottleneck이 된다. 그래서 queue item마다 SLA와 escalation 정책을 먼저 정의한다.

위험도	예시	기본 SLA	만료 시 동작
Low	내부 요약 수정, 태그 추천	24h	자동 만료 또는 batch review로 이동
Medium	고객에게 보낼 초안, 환불 제안	4h	팀 owner에게 escalate, agent는 대기 유지
High	결제·삭제·배포·법률 답변	30~60m	on-call/manager에게 escalate, 자동 실행 금지
Critical	보안 사고 대응, 대량 발송	15m 이하	incident 채널 호출, 변경 freeze, 수동 runbook

escalation은 단순 알림이 아니라 권한과 책임의 이동이다.

1차 reviewer가 SLA를 넘기면 owner group으로 재배정한다.
금액·고객 등급·법적 영향이 임계값을 넘으면 manager 또는 domain expert 승인을 추가 요구한다.
timeout이 지나도 자동 승인하지 않는다. 자동화가 필요하면 “만료 시 취소” 또는 “안전한 fallback 실행”만 허용한다.
escalation 이벤트도 audit log에 남긴다. “누가 지연시켰는가”가 아니라 “어떤 위험을 누구에게 넘겼는가”가 핵심이다.

3.3 Interrupt/Resume State

HITL에는 최소 세 가지 상태가 필요하다.

{
  "workflow_id": "wf_123",
  "blocked_state": "waiting_for_approval",
  "approval_payload": {
    "proposed_action": "send_email",
    "recipient": "[email protected]",
    "draft": "...",
    "evidence": ["doc-1", "ticket-7"]
  }
}

resume 시에는 같은 workflow id와 승인 payload hash를 검증해야 한다.

상태 전이 표

HITL 구현 산출물은 상태 머신으로 남겨야 한다. 버튼 이름이 아니라 어떤 상태에서 어떤 이벤트가 허용되는지가 계약이다.

현재 상태	이벤트	다음 상태	검증/부수 효과
`queued`	assignee 결정	`assigned`	reviewer role·conflict-of-interest 확인
`assigned`	reviewer가 열람	`waiting_for_review`	context_summary_hash, evidence_ids audit 기록
`waiting_for_review`	approve	`approved`	payload_hash 재계산, policy_version 고정
`waiting_for_review`	edit	`edited`	새 payload_hash 생성, 변경 diff 저장
`waiting_for_review`	reject	`rejected`	실행 금지, 거절 사유 필수
`waiting_for_review`	escalate	`escalated`	assignee_policy 재평가, deadline 재설정
`waiting_for_review`	deadline 초과	`expired`	자동 승인 금지, safe fallback 또는 취소
`approved`/`edited`	resume 요청	`resumed`	idempotency_key로 중복 resume 차단
`resumed`	tool 실행 성공/실패	`executed` / `failed`	execution span과 audit log를 workflow_id로 join

3.4 UX 원칙

사람에게 raw trace 전체를 던지면 안 된다. HITL UI는 다음을 보여준다.

agent가 하려는 action
근거와 출처
위험 수준과 이유
수정 가능한 필드
승인/거절/수정/에스컬레이션 버튼
실행 후 되돌릴 수 있는지

Reviewer UI 정보 구조와 API 계약

reviewer 화면은 요청 요약 → 근거 → 위험/정책 → 수정 가능 필드 → 결정 순서로 구성한다. 금지 필드는 raw prompt, 전체 trace dump, secret이 포함될 수 있는 tool argument 원문, 다른 reviewer의 사전 판단이다. 이런 필드는 판단 오염과 PII 장기 보관을 만들기 때문에 evidence_id, trace_id, redacted diff로 연결한다.

Endpoint	요청/응답 계약	실패 시 처리
`GET /approval-items/:id`	redacted context, editable fields, payload hash	권한 없음·만료 item은 decision button 비활성화
`POST /approval-items/:id/decision`	decision, edited payload, reason, payload hash	hash 불일치면 `409 Conflict` 후 새 item 생성
`POST /workflows/:workflow_id/resume`	decision id, idempotency key, final payload hash	중복 resume은 기존 execution result를 반환

3.5 Audit Log

감사 로그에는 “승인했다”만으로 부족하다.

who: user id / role
when: timestamp
what: action payload hash
why: reason / comment
context: evidence ids, model version, prompt version
result: executed / canceled / failed

payload hash는 승인 이후 action 내용이 바뀌지 않았음을 확인하는 안전장치다.

추가로 운영 audit log에는 decision context와 queue lifecycle이 남아야 한다.

queue: created_at, assigned_at, deadline_at, escalated_at, resolved_at
decision: approved / edited / rejected / escalated / expired
review_context: context_summary_hash, evidence_ids, trace_id, policy_version
reviewer_context: reviewer_id, role, delegation_chain, conflict_of_interest flag
execution: payload_hash, idempotency_key, result, rollback_reference

감사 로그 설계 원칙:

append-only로 저장한다. reviewer가 결정을 바꾸면 기존 row를 수정하지 말고 새 event를 추가한다.
승인 근거와 실행 결과를 연결한다. approval record와 실제 tool execution span이 workflow_id·payload_hash·idempotency_key로 join되어야 한다.
민감 정보는 원문 대신 참조와 hash를 남긴다. reviewer가 본 context는 재현 가능해야 하지만 PII를 장기 보관하면 안 된다.
감사와 디버깅을 분리한다. app log는 장애 분석용이고, audit log는 책임·권한·증거 보존용이다.

3.6 Feedback Loop

HITL 결과는 평가 시스템으로 되돌아간다.

human correction
  -> gold dataset candidate
  -> prompt/retrieval failure label
  -> regression eval
  -> gate threshold 조정

사람 개입을 비용으로만 보지 말고 데이터 수집 지점으로 설계한다.

3.6.1 Reviewer Calibration

reviewer도 하나의 평가 시스템이다. 사람마다 승인 기준이 다르면 HITL은 안전장치가 아니라 랜덤 gate가 된다. calibration은 reviewer 판정을 일관되게 만드는 운영 절차다.

Calibration 항목	측정 신호	조치
Inter-reviewer agreement	같은 샘플에 대한 reviewer 간 일치율	rubric 보강, 예시 추가, 교육
Override rate	승인 후 agent 실행을 사람이 다시 되돌린 비율	risk 기준 상향, reviewer 권한 재검토
Rubber-stamp rate	검토 시간이 비정상적으로 짧고 승인율이 높음	batch 기준 재조정, 샘플 감사 확대
Escalation accuracy	escalate된 케이스가 실제 high-risk였는지	escalation threshold 조정
Drift in decisions	같은 유형의 승인/거절 비율이 시간에 따라 변함	calibration set 재평가, policy versioning

실무 절차:

고정 calibration set 50~200개를 두고 신규 reviewer·정책 변경 시 재판정한다.
reviewer decision에는 rubric_version과 policy_version을 남긴다.
disagreement case는 weekly review에서 공통 기준을 업데이트하고, 바뀐 기준은 이후 queue item에만 적용한다.
high-risk route는 dual review 또는 expert review를 둔다. 두 reviewer가 불일치하면 escalation으로 처리한다.
calibration 결과는 eval dataset으로도 편입한다. 사람이 수정한 “정답”이 아니라, 사람 간 합의된 기준이 gold label이다.

3.7 Silent Failure

증상	원인	복구
승인자가 rubber stamp	너무 많은 저위험 승인 요청	risk threshold 상향, batch approval
승인 후 다른 payload 실행	승인 payload와 실행 payload 분리	payload hash 검증
workflow가 영원히 대기	timeout/escalation 없음	deadline timer, owner fallback
사람이 맥락을 이해 못 함	raw trace만 제공	decision summary와 근거 span 제공
수정 내용이 학습에 안 쓰임	feedback pipeline 없음	correction을 eval dataset 후보로 저장
승인 큐 backlog 폭증	SLA·우선순위 정책 없음	risk/deadline priority queue, auto-expire
reviewer마다 기준 다름	calibration set 없음	rubric versioning, dual review sample

4. 실무에서 어디에 쓰이나

고객에게 발송되는 AI 이메일/메시지 승인
코드 변경 agent의 patch review
운영 자동화 runbook의 위험 action 승인
의료·법률·금융 답변의 전문가 검수
채용/평가 시스템의 AI 추천 결과 검토

5. 현재 내 업무와 연결점

프론트엔드에서 confirm modal은 단순 UI처럼 보이지만, AI workflow에서는 confirm이 실행 상태·권한·감사 로그·데이터 품질과 연결된다. 플랫폼 엔지니어 관점에서는 “버튼”보다 어떤 상태에서 어떤 payload를 누가 승인했는지가 핵심이다.

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
HITL	Manual QA	HITL은 실행 중 decision gate, Manual QA는 별도 검수 단계
Approval	Correction	승인/거절 vs 내용을 직접 수정
Interrupt	Breakpoint	interrupt는 운영 중 동적 중단, breakpoint는 개발/디버깅 개념
Escalation	Retry	escalation은 사람/권한 변경, retry는 같은 작업 재시도
Audit log	Application log	audit은 책임과 증거, app log는 디버깅 중심

7. 체크리스트

어떤 action이 human approval을 요구하는지 risk 기준으로 정의할 수 있다.
approval queue item schema와 우선순위 기준을 설계할 수 있다.
interrupt/resume에 필요한 state와 payload hash를 설계할 수 있다.
risk별 SLA와 escalation policy를 상태 머신에 포함할 수 있다.
승인 UI에 보여줄 근거·위험·수정 필드를 정할 수 있다.
timeout과 escalation 경로를 상태 머신에 포함할 수 있다.
audit log에 queue lifecycle, reviewer decision, execution result를 append-only로 남길 수 있다.
reviewer calibration set과 disagreement 처리 절차를 운영할 수 있다.
human correction을 eval dataset으로 연결할 수 있다.

8. 추가 학습 키워드

human-in-the-loop, LangGraph interrupt, approval workflow, escalation policy, audit trail, payload hash, AI governance, review queue, SLA, reviewer calibration, dual review, active learning

9. 내가 직접 확인해볼 것

“AI가 고객 이메일 초안 작성 → 사람이 수정/승인 → 발송” 상태도 작성
approval queue table schema와 priority sorting 규칙 작성
risk score 기준을 비용·외부 노출·되돌릴 수 있음으로 나눠보기
medium/high/critical risk별 SLA와 escalation owner 정의
승인자가 본 payload와 실행 payload가 일치하는 hash 검증 설계
audit log event를 created/assigned/escalated/approved/executed로 나누어 설계
reviewer 2명이 같은 샘플 50개를 판정했을 때 disagreement를 기록하는 schema 만들기
수정된 답변을 gold dataset 후보로 저장하는 schema 만들기

10. 5줄 요약

HITL은 자동화를 포기하는 것이 아니라 위험한 경로에 사람의 판단을 삽입하는 구조다.
승인, 수정, 선택, 에스컬레이션은 서로 다른 개입 유형이며 approval queue로 운영된다.
interrupt/resume은 durable state, SLA, escalation policy와 함께 설계해야 운영 중 대기를 견딘다.
승인 로그에는 queue lifecycle, reviewer, payload hash, 근거, 실행 결과가 append-only로 남아야 한다.
사람의 수정과 calibration 결과는 비용이 아니라 평가 데이터와 개선 loop의 입력이다.

11. 출처

최종 수정: 2026-05-21