CH13-AI가 계정을 멋대로 삭제하지 못하게 하는 법 — 위험도 기반 에스컬레이션과 인간 승인(HITL) 패턴

AGENTIC AI DESIGN PATTERNS · 13

멈춰야 할 순간, 사람을 부른다 — 휴먼 인 더 루프(Human-in-the-Loop)

AI가 스스로 결정할 때와 인간에게 물어야 할 때를 가르는 설계: 6가지 협업 측면, 에스컬레이션 4레벨(AUTO·REVIEW·REQUIRED·CRITICAL), LangGraph의 interrupt·Command·Checkpointer, Human-on-the-Loop 변형, Gemini·LangGraph 구현 2종, CRM·ERP·Groupware 적용까지

🟢 입문~중급 ⏱️ 약 20분 🔧 Python · LangGraph · Gemini 🏢 엔터프라이즈 🗓️ 최종 검토 2026-06-10

TL;DR — 넘어져도 다시 일어서는 에이전트도 결국 되돌릴 수 없는 결정 앞에서는 멈춰야 합니다. 계정 삭제, 고액 송금, 기밀 문서 공개 — AI가 단독으로 처리하면 사고가 됩니다. 휴먼 인 더 루프(Human-in-the-Loop)는 AI 워크플로우에 인간의 판단·검증·개입을 전략적으로 끼워 넣는 패턴입니다. 핵심은 위험도로 자동/수동을 가르는 에스컬레이션과, 실행 도중 멈췄다 사람이 결정하면 그 지점부터 재개하는 LangGraph의 interrupt() → 인간 결정 → Command(resume=…) 입니다. 모든 걸 사람이 보는 게 아니라 위험한 30%만 사람에게 — 그게 설계입니다.

목 차

1. 왜 휴먼 인 더 루프인가 2. 개념과 오해 3. 6가지 핵심 측면 4. 에스컬레이션 4레벨 5. 구현① Gemini API 6. 구현② LangGraph 7. interrupt·Command·Checkpointer 8. in-the-Loop vs on-the-Loop 9. 두 구현 비교와 한계 10. 엔터프라이즈 ROI 11. 케이스 스터디 12. 베스트 프랙티스

1. 왜 휴먼 인 더 루프인가 — 넘어져도 일어서는 AI의 마지막 안전장치

지난 편에서 에이전트는 장애를 만나도 재시도·폴백·복구로 죽지 않는 복원력을 얻었습니다. 그 다단계 방어의 맨 끝에 무엇이 있었는지 기억하시나요? 폴백 체인의 최후 단계는 늘 사람(Escalation)이었습니다. 자동 복구가 모두 실패하는 그 지점, AI가 스스로 결정해서는 안 되는 그 순간을 설계하는 것이 이번 편의 주제입니다.

교재가 던지는 핵심 난제는 한 문장입니다 — "언제 AI가 스스로 결정하고, 언제 인간에게 물어봐야 하는가?" 고객이 "계정 해지할게요"라고 했을 때, 안전장치 없는 챗봇은 "해지 완료되었습니다" → 고객 후회 → 클레임으로 끝납니다. 휴먼 인 더 루프가 있으면 위험 감지 → 담당자 승인 요청 → 리텐션 오퍼 → 고객 유지로 이어지죠. 휴먼 인 더 루프(Human-in-the-Loop, HITL) 패턴은 에이전트의 자율성에 인간 통제권이라는 핸들을 다는 일입니다.

🤖 무분별 자동화 (Full Auto)

❌ 되돌릴 수 없는 결정을 AI가 단독 실행

❌ 환각(Hallucination)이 그대로 고객·결재에 노출

❌ 책임 소재 불명확 — "AI가 알아서 했습니다"

❌ 감사 추적 부재 — 규제 대응 불가

🤝 휴먼 인 더 루프 (HITL)

✅ 위험도로 분기 — 안전한 건 자동, 위험한 건 사람

✅ AI 분석 + 인간 결정으로 오판 차단

✅ 최종 권한은 인간 — 책임 소재 명확

✅ 모든 결정 로깅 — Who/When/Why 감사 추적

그림 1. 무분별 자동화 vs 휴먼 인 더 루프 — 빨강은 통제 불능, 파랑은 설계된 협업

2025년 기업들이 이 패턴에 주목하는 이유는 네 가지입니다. 규제 준수(EU AI Act 등이 고위험 AI의 의사결정에 인간 감독을 요구), 신뢰 구축("AI가 알아서 했습니다"보다 "전문가가 검토했습니다"를 고객이 신뢰), 리스크 관리(환각으로 인한 법적·재정적 손실 방지), 품질 향상(인간 피드백으로 AI를 지속 개선, RLHF) — 자율성과 통제권을 동시에 요구하기 때문이죠.

2. 개념과 오해 — HITL은 AI의 실패가 아니라 설계된 협업이다

📌 한 줄 정의 — 휴먼 인 더 루프는 AI 워크플로우에 인간의 판단·검증·개입을 전략적으로 통합하는 설계 패턴입니다. 본질은 "AI와 인간이 각자의 강점을 발휘하되, 중요한 결정의 최종 통제권은 인간이 보유하는 것"이며, 네 가지 원칙 — 보완적 협력 · 통제권 유지 · 지속적 개선 · 투명성 — 위에 섭니다.

주니어가 이 패턴에서 가장 많이 빠지는 오해 세 가지를 먼저 짚습니다. 셋 다 "HITL은 어쩔 수 없이 끼워 넣는 군더더기"라는 잘못된 전제에서 나옵니다.

오해 ① "HITL은 AI 실패의 증거다"

아닙니다. HITL은 AI의 한계가 아니라 설계된 협업입니다. AI는 대량 데이터 분석을, 인간은 윤리적 판단을 맡는 역할 분담이지, AI가 못해서 사람이 떠받치는 구조가 아닙니다.

오해 ② "인간 개입 = 느린 시스템"

모든 요청을 사람이 보면 느려지지만, 적절한 에스컬레이션은 오히려 품질을 올립니다. 핵심은 위험한 건만 사람에게 보내고 나머지는 자동 처리하는 것 — 4절의 레벨 분기가 그 답입니다.

오해 ③ "HITL은 임시 방편이다"

AI가 더 똑똑해지면 없어질 거라고요? 고위험 영역(금융·의료·법률)에서는 영구적으로 필요한 패턴입니다. 규제가 인간 감독을 의무화하는 한, HITL은 사라지지 않습니다.

두 가지 비유가 이 패턴을 직관적으로 잡아줍니다. 첫째, 응급실 트리아지(Triage) 시스템입니다. 간호사(AI)가 들어온 환자를 초기 분류해 경미한 증상은 직접 처리하고, 중증 환자는 전문의(Human)에게 넘기며, 생명이 위급하면 즉시 인간이 개입합니다. 둘째, 항공기 자동조종장치입니다. 순항 비행은 자동조종(AI)이 담당하다가, 이상 기상이나 비상 상황에서는 조종사(Human)가 통제권을 인수하죠. "Autopilot Disconnect" 버튼이 바로 인간 개입 트리거 — HITL의 interrupt()에 해당합니다. 위험도에 따라 통제권이 AI와 인간 사이를 오간다는 점이 핵심입니다.

3. HITL의 6가지 핵심 측면 — 협업은 한 가지 모습이 아니다

"인간 개입"이라고 뭉뚱그리면 설계가 막힙니다. 교재는 HITL을 여섯 가지 측면으로 나눕니다. 각각 다른 시점·다른 방식의 협업이고, 실제 시스템은 이들을 조합해 씁니다.

① Human Oversight · 인간 감독

대시보드·로그로 AI 실행을 모니터링·검토·감사. 이상 감지 시 알림.

② Intervention & Correction · 개입과 수정

신뢰도가 낮거나 고위험일 때 실시간으로 끼어들어 오류를 바로잡음.

③ Feedback for Learning · 학습 피드백

👍/👎·순위·직접 수정으로 모은 피드백으로 AI를 개선(RLHF).

④ Decision Augmentation · 의사결정 증강

AI는 분석·추천만, 최종 결정은 인간. 대출 심사·진단이 대표 예.

⑤ Human-Agent Collaboration · 협업

AI(패턴 인식·24/7)와 인간(창의·공감·협상)의 역할 분담으로 1+1>2.

⑥ Escalation Policies · 에스컬레이션 정책

위험도 기준으로 자동/검토/승인/즉시개입을 가르는 규칙(→ 4절).

감독·개입·피드백·증강·협업·정책 — 여섯 측면이 한 시스템 안에서 맞물려 돈다.

그림 2. HITL의 6가지 핵심 측면

이 가운데 ⑥ 에스컬레이션 정책이 나머지를 작동시키는 스위치입니다. "언제 사람을 부를까?"를 정해야 감독·개입·증강이 발동하니까요. 그래서 다음 절에서 에스컬레이션을 독립적으로 깊게 봅니다.

4. 에스컬레이션 4레벨 — 위험도가 통제권을 정한다

HITL의 심장은 "이 요청을 누가 결정할 것인가?"를 가르는 에스컬레이션입니다. 교재는 위험도를 네 단계로 나눕니다. 위험이 낮을수록 AI가, 높을수록 인간이 통제권을 쥡니다 — 신호등처럼 초록에서 빨강으로 갈수록 인간 개입이 강해진다고 보면 됩니다.

A

AUTO

완전 자동화

저위험·고신뢰도
FAQ·배송 조회

→

R

REVIEW

검토 권장

중위험·사후 검토
처리하되 로깅

→

!

REQUIRED

승인 필수

고위험·사전 승인
환불·계정 변경

→

⚠

CRITICAL

즉시 에스컬레이션

매우 고위험
감정 고객·보안

왼쪽일수록 AI 자율, 오른쪽일수록 인간 통제 — 위험도가 통제권의 위치를 결정합니다.

그림 3. 에스컬레이션 4레벨 — AUTO → REVIEW → REQUIRED → CRITICAL

그렇다면 레벨은 무엇으로 정할까요? 학습 코드의 EscalationPolicy.evaluate()는 네 가지 신호를 우선순위 순서대로 검사합니다. 순서가 중요합니다 — 감정이 키워드보다 먼저입니다. "화가 납니다. 환불해주세요"는 환불 키워드(REQUIRED)가 아니라 감정(CRITICAL)으로 분류되어 즉시 상담원에게 연결되죠.

1순위 · 감정 키워드 — "화가/분노/실망/angry…" 감지 → CRITICAL (즉시 상담원)

2순위 · 고위험 키워드 / 고액 — "삭제·해지·환불·법적…" 또는 금액 > $1,000 → REQUIRED (승인 필수)

3순위 · 낮은 신뢰도 — AI confidence < 0.8 → REVIEW (검토 권장)

기본 · 그 외 모두 — 위 신호 없음 → AUTO (자동 처리)

이 다단계·우선순위 판단이 HITL 설계의 출발점입니다. 임계값(confidence_threshold=0.8, amount_threshold=1000)을 비즈니스에 맞춰 조정하면, 같은 코드로 보수적/공격적 정책을 자유롭게 오갈 수 있죠. 이제 이걸 실제 구현으로 옮겨봅니다.

5. 구현 ① Gemini API — 정책·에스컬레이션·의사결정 증강

프레임워크 없이 Gemini API만으로 패턴의 뼈대를 봅니다. 설계 철학은 정책의 투명성(에스컬레이션 기준을 코드 밖 설정으로), 의존성 주입(정책·검토 인터페이스를 외부에서 교체), 학습 가능성(인간이 수정한 케이스를 피드백 히스토리로 축적)입니다. 먼저 레벨과 정책을 @dataclass로 못 박습니다.

PYTHON · 에스컬레이션 정책과 우선순위 판단

class EscalationLevel(str, Enum): # 위험도 4단계 AUTO = "auto"; REVIEW = "review"; REQUIRED = "required"; CRITICAL = "critical" @dataclass class EscalationPolicy: confidence_threshold: float = 0.8 # 이하면 에스컬레이션 amount_threshold: float = 1000.0 # 이상이면 승인 필요 high_risk_keywords: list = [...] # 삭제·환불·해지·법적·소송… emotional_keywords: list = [...] # 화가·분노·실망·angry… def evaluate(self, request, confidence, amount=0) -> EscalationLevel: r = request.lower() if any(k in r for k in self.emotional_keywords): return EscalationLevel.CRITICAL # 1순위: 감정 if any(k in r for k in self.high_risk_keywords): return EscalationLevel.REQUIRED # 2순위: 위험 키워드 if amount > self.amount_threshold: return EscalationLevel.REQUIRED # 2순위: 고액 if confidence < self.confidence_threshold: return EscalationLevel.REVIEW # 3순위: 낮은 신뢰도 return EscalationLevel.AUTO # 기본: 자동

검토 채널은 추상 클래스로 분리합니다. HumanReviewInterface를 상속해 콘솔·Slack·웹 UI·이메일·자동 승인을 갈아끼우는 Strategy 패턴이죠. HITLAgent는 REQUIRED/CRITICAL일 때만 검토를 요청하고, 인간 결정을 피드백 히스토리에 쌓아 나중의 모델 개선에 씁니다.

PYTHON · HITLAgent.process() — 레벨에 따라 분기

def process(self, request: str) -> dict: ai_response = self._generate_ai_response(request) # 1) AI 응답 amount = self._extract_amount(request) level = self.policy.evaluate(request, ai_response.confidence, amount) # 2) 레벨 human_decision = None if level in [EscalationLevel.REQUIRED, EscalationLevel.CRITICAL]: human_decision = self.review_interface.request_review( # 3) 인간 검토 ai_response=ai_response, context={"request": request, "amount": amount}) self.feedback_history.append({...}) # 학습용 축적 if not human_decision.approved: return {"status": "rejected", ...} # 거부 시 종료 if human_decision.edited_content: # 인간이 수정했으면 반영 ai_response.content = human_decision.edited_content # REVIEW는 로깅만 하고 자동 진행, AUTO는 그대로 처리 return {"status": "success", "response": ai_response.content, ...}

한 가지 더 짚을 패턴이 Decision Augmentation(의사결정 증강)입니다. 일반 HITL이 "AI 응답 → 인간이 승인/거부/수정"이라면, 증강은 한 발 더 물러섭니다 — AI는 분석·추천만 내놓고, 결정 자체를 인간이 합니다. DecisionAugmentationAgent.analyze_and_recommend()는 강점·약점·위험을 정리하고 "승인/거부/보류" 추천과 신뢰도를 돌려줄 뿐, 대출 승인 버튼은 심사관이 누릅니다.

PYTHON · Decision Augmentation — AI는 정보 제공자, 인간은 의사결정자

def analyze_and_recommend(self, case_data: dict) -> dict: # AI는 "분석"만 제공한다 — 결정은 하지 않는다 return { "summary": "케이스 요약", "analysis": {"strengths": [...], "weaknesses": [...], "risks": [...]}, "recommendation": "승인|거부|보류", # 추천일 뿐 "confidence": 0.87, "considerations": ["최종 결정 시 고려사항…"] } # → 인간 심사관이 이 분석을 보고 "최종 결정"을 내린다

기본기는 이걸로 충분합니다. 다만 이 구조에는 빈틈이 있습니다 — request_review()가 동기적으로 블로킹한다는 점이죠. 사람이 결정할 때까지 프로세스가 기다려야 하고, 그 사이 서버가 죽으면 진행 중이던 상태가 날아갑니다. "사람이 1초 만에 누를 수도, 하루 뒤에 누를 수도 있는" 승인을 어떻게 견딜까요? 여기서 LangGraph가 등장합니다.

6. 구현 ② LangGraph — 그래프를 멈췄다 다시 잇는 HITL

최신 LangGraph(LangChain 팀, 2025년 기준 권장)는 인간 승인을 그래프의 일시 중지로 다룹니다. 폴링으로 입력을 기다리는 대신 interrupt()로 그래프 자체가 멈추고, 상태는 Checkpointer가 보관하며, thread_id로 언제든 복원되죠. 먼저 위험도를 평가하는 노드를 봅니다 — 5절의 우선순위 판단과 같은 골격입니다.

PYTHON · 위험도 평가 → 승인 필요 여부

def assess_risk(request, ai_analysis) -> tuple[RiskLevel, bool]: r = request.lower() if any(k in r for k in ["삭제","해지","취소","환불","delete","cancel"]): return RiskLevel.CRITICAL, True # 되돌릴 수 없음 → 승인 필요 if any(k in r for k in ["송금","이체","결제","transfer","payment"]): return RiskLevel.HIGH, True # 금액 관련 → 승인 필요 if ai_analysis.get("confidence", 0.5) < 0.7: return RiskLevel.MEDIUM, True # 신뢰도 낮음 → 승인 권장 return RiskLevel.LOW, False # 저위험 → 자동 처리

에러를 State에 새기던 지난 편처럼, 여기서는 승인 상태를 State에 담습니다. status는 analyzing → pending_approval → approved/rejected → completed로 전이하고, 핵심 승인 노드가 interrupt()를 호출합니다.

PYTHON · human_approval_node — interrupt()로 멈춤

def human_approval_node(state: AgentState) -> dict: approval_request = {"action": ..., "risk_level": state["risk_level"], "ai_recommendation": ..., "reasoning": ...} # ═══ interrupt(): 그래프 실행 일시 중지 ═══ decision = interrupt({ # 여기서 멈춤! "type": "approval_request", "message": "다음 액션에 대한 승인이 필요합니다.", "approval_request": approval_request}) # ↓ Command(resume=decision)으로 재개될 때 이 줄부터 실행 return {"approval_decision": {"approved": decision.get("approved", False), ...}, "status": "approved" if decision.get("approved") else "rejected"}

노드들은 조건부 엣지로 엮입니다. 분석 후 승인이 필요하면 human_approval로, 아니면 auto_execute로 갈라지고, 승인 후에는 결정에 따라 execute 또는 rejection으로 나뉩니다 — "승인 분기"가 if문이 아니라 그래프로 선언됩니다.

PYTHON · 조건부 라우팅 + 그래프 빌드

def route_after_analysis(state) -> Literal["human_approval", "auto_execute"]: return "human_approval" if state.get("requires_approval") else "auto_execute" def route_after_approval(state) -> Literal["execute", "rejection"]: return "execute" if state["approval_decision"].get("approved") else "rejection" builder = StateGraph(AgentState) builder.add_node("analyze", analyze_request) builder.add_node("human_approval", human_approval_node) # interrupt 노드 builder.add_conditional_edges("analyze", route_after_analysis, {"human_approval": "human_approval", "auto_execute": "auto_execute"}) builder.add_conditional_edges("human_approval", route_after_approval, {"execute": "execute", "rejection": "rejection"})

5절의 블로킹 request_review()가 중단 가능한 노드로, if 분기가 조건부 엣지로 바뀌었습니다. 그 대가로 따라오는 interrupt·Command·Checkpointer 3종이 이 패턴의 진짜 핵심이라, 다음 절에서 따로 깊게 봅니다.

7. interrupt · Command · Checkpointer — 멈춤과 재개의 3종 세트

LangGraph HITL은 세 부품으로 작동합니다. interrupt()가 그래프를 멈추고, Checkpointer가 그 순간의 상태를 보관하며, Command(resume=…)가 인간 결정을 들고 정확히 그 지점부터 재개합니다. 항공기 비유의 "Autopilot Disconnect → 조종사 조작 → 자동조종 복귀"가 코드로 옮겨진 셈이죠.

1

invoke()

워크플로우 시작
analyze 노드 실행

→

2

interrupt()

그래프 중단
상태 저장 → 반환

→

3

인간 결정

Slack·웹·이메일
(분/시간/일 무관)

→

4

Command(resume)

상태 복원
interrupt 지점부터 재개

2단계와 4단계 사이에 시간이 얼마나 흘러도 됩니다 — 상태가 Checkpointer에 안전하게 보관되니까요.

그림 4. interrupt → 인간 결정 → Command(resume)의 중단·재개 사이클

실행기는 두 메서드로 단순해집니다. start_workflow()가 시작하면 interrupt에서 멈춰 __interrupt__를 돌려주고, 인간 결정이 도착하면 resume_workflow()가 Command(resume=…)로 재개합니다.

PYTHON · 중단(start) → 재개(resume) — Checkpointer가 필수

self.checkpointer = MemorySaver() # 상태 영속화 (필수!) self.graph = build_hitl_graph().compile(checkpointer=self.checkpointer) # Checkpointer 없이 compile()하면 interrupt() 사용 불가 → 에러 def start_workflow(self, user_request, thread_id): config = {"configurable": {"thread_id": thread_id}} # 세션 격리 result = self.graph.invoke(initial_state, config=config) if "__interrupt__" in result: # 중단됨 → 승인 대기 return {"status": "interrupted", "interrupt_data": result["__interrupt__"][0].value} def resume_workflow(self, thread_id, decision): config = {"configurable": {"thread_id": thread_id}} result = self.graph.invoke(Command(resume=decision), config=config) # 재개 return self._process_result(result, config)

여기서 thread_id가 결정적입니다. 스레드별로 독립된 상태가 Checkpointer에 보관되므로, 수백 명의 승인 대기를 동시에 관리해도 서로 간섭하지 않죠. 사용자 A가 승인을 미뤄도 사용자 B의 워크플로우는 멀쩡합니다. 그리고 이 비동기 구조 덕분에 실무에서는 타임아웃 처리(24시간 초과 시 자동 에스컬레이션 또는 거부)와 Slack 버튼 콜백(버튼 클릭 → resume_workflow() 호출)을 자연스럽게 얹을 수 있습니다.

💡 핵심 — 5절 Gemini 구현이 "사람을 기다리며 멈춰 있는" 동기 블로킹이라면, LangGraph는 "멈췄다가 아무 때나 이어지는" 비동기입니다. 그 차이를 만드는 단 한 줄이 compile(checkpointer=...)입니다.

8. in-the-Loop vs on-the-Loop — 매 결정이냐, 정책이냐

HITL에는 형제 패턴이 있습니다. Human-on-the-Loop(HOTL)입니다. 둘의 차이는 "인간이 언제·무엇에 개입하느냐"입니다. in-the-Loop은 개별 결정마다 끼어들고, on-the-Loop은 정책을 정해두고 AI가 그 안에서 자율 실행하게 둡니다.

🙋 Human-in-the-Loop

인간 역할: 개별 결정에 개입

AI 역할: 인간 승인 후 실행

개입 시점: 매 결정 또는 에스컬레이션 시

적합: 고위험·소량 (대출 승인, 계정 해지)

🛰️ Human-on-the-Loop

인간 역할: 정책·규칙 설정

AI 역할: 정책 내에서 자율 실행

개입 시점: 정책 변경 시 · 예외 보고 시

적합: 저위험·대량 (자동 트레이딩)

그림 5. Human-in-the-Loop vs Human-on-the-Loop — 개별 결정 개입 vs 정책 후 자율

교재의 예가 직관적입니다. 자동 트레이딩에서 인간 전문가는 "Tech 70%·Bond 30%, 단일 종목 최대 5%, 손절선 -10%, 일일 한도 $100,000" 같은 정책만 설정합니다. AI 봇은 그 범위 안에서 실시간으로 자율 매매하고, 손절선·한도에 닿으면 스스로 멈추며, 인간은 정기 리뷰에서 정책을 조정할 뿐이죠. 매 거래를 승인받지 않습니다 — 대규모 자동화에는 on-the-Loop이 맞습니다.

💡 고르는 법 — "이 결정 하나가 잘못되면 되돌릴 수 없는가?" → 그렇다면 in-the-Loop(개별 승인). "대량이라 일일이 못 보지만 범위만 지키면 되는가?" → 그렇다면 on-the-Loop(정책 + 예외 보고). 많은 실무 시스템은 둘을 섞어, 평소엔 on-the-Loop으로 돌리다 위험 신호에서 in-the-Loop으로 전환합니다.

9. 두 구현 비교와 한계 — 어디서 막히고, 무엇을 조심할까

Gemini 기본 구현과 LangGraph는 같은 HITL 패턴을 다른 추상화로 담습니다. 단발성 승인이면 Gemini가 빠르고, 비동기 승인·재시작·다중 세션이 필요하면 LangGraph가 유리합니다.

측면	① Gemini API 기본	② LangGraph
승인 방식	동기 블로킹(request_review)	비동기 중단(interrupt())
상태 보존	메모리(휘발)	Checkpointer(영속)
재개	불가(처음부터)	Command(resume=…)
분기	if-else	Conditional Edge
다중 세션	수동 관리	thread_id 격리
검토 채널	인터페이스 추상화(Strategy)	resume 콜백(Slack·웹)
학습 곡선	낮음	중간

그림 6. Gemini API 기본 vs LangGraph — 같은 패턴, 다른 추상화

어떤 구현을 쓰든 HITL에는 네 가지 함정이 따라옵니다. 가장 흔한 게 인간 병목이죠 — 모든 요청에 승인을 걸면 시스템이 사람 속도로 느려집니다. 해법은 처음부터 분명합니다.

⚠️ 전수 검토 (인간 병목)

모든 요청을 사람이 승인 → 승인 큐 폭주 → 검토자 피로 → 검토 품질 저하 → 처리 지연 → 정확성도 처리량도 잃음

🎯 위험도 기반 분리 (Tiered)

저위험 자동 · 중위험 샘플링 · 고위험 전수 검토 → 검토자는 진짜 필요한 건에만 집중 → 정확성과 처리량을 동시에

그림 7. 인간 병목 vs 위험도 기반 분리(Tiered Approach) — 확장성과 정확성의 Trade-off 해소

나머지 셋도 함께 챙겨야 합니다. 전문성 의존(검토자 역량이 HITL 효과를 좌우 → 교육·가이드라인·다중 검토), 프라이버시(인간 검토 시 민감 정보 노출 → 데이터 익명화·접근 권한 제한·감사 로그), 일관성(사람마다 판단 기준이 다름 → 명확한 가이드라인·캘리브레이션 세션). 이 한계들을 정면으로 다루는 게 엔터프라이즈 설계의 절반입니다.

10. 엔터프라이즈 — CRM·ERP·Groupware의 승인 게이트

레거시 시스템의 공통 고통점은 "AI가 되돌릴 수 없는 결정을 단독으로 내린다"입니다. CRM은 민감 요청(해지·환불)을 AI가 단독 처리해 분쟁, ERP는 대금 지급을 자동 승인해 감사 지적, Groupware는 문서 공개 범위를 오판해 정보 유출 — HITL은 이를 위험도 기반 승인 게이트로 막습니다.

⚠️ 아래 수치는 적용 전략 문서의 도입 기대효과(목표치)이며 특정 기업의 실측 결과가 아닙니다.

시스템	핵심 적용	기대효과(목표치)
CRM 고객 민감 요청	해지·환불 위험도 평가 + 담당자 승인(리텐션 오퍼)	이탈 방지 5%→35% · NPS 45→72 · 클레임 80%↓
ERP 대금 지급	Tiered Approval(금액·이상 탐지로 4단계 라우팅)	처리 3일→0.5일 · 사기 차단 95% · 자동 처리 70%
Groupware 문서 분류·공개	AI 분류 추천 + 불일치 시 보안팀 확인 게이트	유출 99% 차단 · 분류 정확도 98% · 위반 95%↓

그림 8. CRM·ERP·Groupware 적용과 기대효과(목표치)

ERP의 Tiered Approval이 9절의 "위험도 기반 분리"를 그대로 구현한 예입니다. $1,000 미만+기존 업체는 자동 승인, ~$10,000은 담당자 1-click, $10,000 이상·이상 탐지는 재무팀장 결재, $100,000 이상은 CFO 직접 검토 — 4티어가 곧 4레벨 에스컬레이션이죠.

💰 12개월 ROI (목표치)

총 비용 $415,000 (초기 $320K + 운영 $95K)

총 효과 $550,000 (이탈 방지·분쟁 회피·사기 차단·유출 방지)

ROI 32.5% · 투자 회수 9.1개월

📈 3단계 도입 로드맵

Phase 1 (1~3개월) CRM 고위험 요청 · Slack 승인

Phase 2 (4~6개월) +ERP 결재 · 자동 처리 60%

Phase 3 (7~12개월) +Groupware · 컴플라이언스 100%

그림 9. ROI와 단계별 도입 로드맵 (목표치 기준)

권장 기술 스택은 LangGraph(HITL 워크플로우), MemorySaver/PostgreSQL·Redis(상태 영속화), Gemini(분석·추천), React+Slack Bot(승인 UI), Immutable Log(감사)입니다. 핵심 성공 요인은 위험도 기준의 비즈니스 합의, 검토자 가용성(대리자·에스컬레이션 체계), 신뢰할 만한 AI 추천 품질, 1-click·모바일 승인 UX, 그리고 모든 결정의 Who/When/Why 감사 추적 — 목표는 자동 70% + 인간 30%의 균형으로 오류율 90% 감소·처리 시간 60% 단축입니다.

11. 케이스 스터디 — VIP 고객의 "해지하고 싶어요"

3년 이용·월 $200 결제 VIP 고객이 "계정 해지하고 싶어요"라고 보냈습니다. 무방비 챗봇이라면 "해지 완료" 한 줄로 연 $2,400 매출을 날렸겠죠. HITL이 어떻게 한 흐름으로 이를 막는지 따라가 봅니다.

① AI 분석 — 의도="서비스 해지", 고객="VIP·3년·월 $200", 감정="불만 중간", 신뢰도 0.85, 추천="리텐션 오퍼 후 진행"

② 위험도 평가 — "해지" 키워드 감지 → requires_approval=True → REQUIRED 레벨로 에스컬레이션

③ interrupt() — 그래프 중단 → 담당자에게 승인 요청(AI 분석·이탈 확률·리텐션 옵션 3종 첨부) → 상태는 Checkpointer에 보관

④ 인간 결정 — 담당자가 "30% 할인 3개월 오퍼" 선택 → Command(resume={"approved": True, ...})로 재개

⑤ 실행 + 감사 로그 — AI가 리텐션 스크립트 실행 → 고객 유지 → 결정(누가·언제·왜)이 감사 로그에 기록

고객은 일방적 해지 대신 맞춤 제안을 받았고, AI는 단독으로 결정하지 않았으며, 모든 판단이 추적 가능하게 남았습니다. "AI가 알아서 한 것"이 아니라 "전문가가 AI 분석을 보고 결정한 것" — 이것이 신뢰와 책임을 동시에 잡는 HITL의 목표입니다.

12. 베스트 프랙티스 — 언제 사람을 부를까

HITL은 "사람을 많이 끼울수록 안전한 것"이 아닙니다. 되돌릴 수 없는 결정엔 반드시 사람을, 안전한 다수엔 자동화를 거는 균형이 핵심입니다. 모든 걸 검토하면 병목이고, 아무것도 검토 안 하면 사고죠. 관련 패턴으로는 최후 안전망인 12. 예외 처리·복구의 에스컬레이션과, AI가 스스로 점검하는 4. 리플렉션을 함께 보면 좋습니다.

✅ 도입 체크리스트

☐ 에스컬레이션 기준을 정의한다 (신뢰도 임계값·금액·위험 키워드·감정)

☐ 레벨을 4단계로 나눈다 (AUTO/REVIEW/REQUIRED/CRITICAL) — 위험도가 통제권을 정한다

☐ 비동기 승인은 interrupt + Checkpointer + thread_id로 (재시작·다중 세션 대비)

☐ 고위험·소량은 in-the-Loop, 저위험·대량은 on-the-Loop(정책)으로 가른다

☐ 인간 병목을 피한다 — 위험도 기반 분리로 자동 70% 목표

☐ AI는 분석·추천, 최종 결정은 인간(Decision Augmentation)을 명확히 한다

☐ 모든 결정에 Who/When/Why 감사 로그 + 민감 정보 마스킹

☐ 타임아웃·대리자·에스컬레이션 체계로 승인 지연을 방지한다

★ 마치며

순서대로 쪼개고(체이닝), 갈래를 나누고(라우팅), 병렬로 돌리고(병렬화), 스스로 비평하고(리플렉션), 도구를 쥐고(도구 사용), 계획하고(플래닝), 팀을 이루고(멀티 에이전트), 기억하고(메모리), 배우고(학습), 표준으로 연결되고(MCP), 스스로 채점하고(목표 설정), 넘어져도 일어서던(예외 처리) 에이전트 — 이번엔 멈춰야 할 순간 사람을 부르는 법(휴먼 인 더 루프)을 배웠습니다. 자율성의 끝에는 늘 인간의 판단이 안전장치로 서 있죠. 다음 편은 RAG(검색 증강 생성): 에이전트가 환각 대신 근거로 말하게 하는, 외부 지식을 끌어오는 법입니다.

#휴먼인더루프 #HumanInTheLoop #에스컬레이션 #interrupt #Checkpointer #LangGraph #HumanOnTheLoop #AI에이전트

📚 참고 자료 · 공식 문서

• LangGraph 공식 문서 — Human-in-the-Loop (interrupt · Command · Checkpointer)
• LangGraph Persistence — Checkpointer와 thread_id 상태 관리
• Google Gemini API 문서 — 모델 호출·구조화 출력

본문 ROI·효과 수치는 학습 자료 기반 도입 기대효과(목표치)이며 특정 기업의 실측이 아닙니다.