
제3장: 인간과 AI의 협조 루프 (Human-in-the-Loop: HITL)
요약
AI 에이전트의 자율성과 안전성 사이의 균형을 맞추기 위한 Human-in-the-Loop(HITL) 설계 패턴을 다룹니다. 리스크와 복잡도에 따라 HITL, HOTL, HIC의 세 가지 토폴로지를 제안하며, 구현을 위한 상태 저장 및 실행 제어 방식을 설명합니다.
핵심 포인트
- 리스크와 복잡성에 따른 단계적(Gradation) 자동화 설계 필요
- HITL, HOTL, HIC의 세 가지 주요 협조 모델 분류
- 불가역적 액션 수행 시 인간의 승인 단계(Breakpoint) 필수
- 비동기 에이전트를 위한 상태 저장(Checkpoint) 및 재개 메커니즘 중요
AI 에이전트의 자율성이 높아지는 한편, 시스템의 결정을 완전히 AI에 맡기는 것에는 할루시네이션 (Hallucination, 환각)이나 의도하지 않은 동작, 보안상의 취약점과 같은 중대한 리스크가 따릅니다. 특히 「메일 전송」, 「결제 처리」, 「운영 코드 배포」와 같이 불가역적인 액션 (Side Effect, 부작용)을 동반하는 태스크에서는 인간이 개입하는 시스템 설계가 필수적입니다.
본 장에서는 자율성과 안전성의 균형을 맞추기 위한 **Human-in-the-Loop (HITL)**의 그라데이션 설계, UX에서의 개입 접점, 승인·수정·감사의 라이프사이클, 그리고 할루시네이션 (Hallucination)을 전제로 한 UX 설계 패턴에 대해 구현 수준의 아키텍처와 코드 예시를 곁들여 해설합니다.
에이전트 시스템을 설계할 때, 자동화의 정도를 「0 아니면 100」으로 생각해서는 안 됩니다. 태스크의 리스크 (실패했을 때의 영향도)와 복잡성에 따라 인간과 AI의 역할 분담을 그라데이션 (단계적)으로 설계해야 합니다.
일반적으로 HITL 시스템은 다음과 같은 세 가지 토폴로지 (Topology)로 분류됩니다.
Human-in-the-Loop (HITL - 개입·승인)-
동작 원리: 에이전트가 특정 액션 (예: 데이터베이스 업데이트, 메일 전송)을 실행하기 직전에 처리를 반드시 일시 정지하고, 인간의 명시적인 「승인 (Approve)」을 기다립니다. -
적합한 유스케이스 (Use Case): 금융 거래, 운영 환경으로의 변경, 고객에 대한 직접 연락 등 실패 비용이 극도로 높은 태스크.
Human-on-the-Loop (HOTL - 감시·개입)-
동작 원리: 에이전트는 기본적으로 완전 자율로 동작을 계속하지만, 실행 로그나 상태 (State)를 인간이 대시보드 상에서 실시간으로 감시하며, 문제가 발생했을 때 「개입 (Interrupt)」이나 「긴급 정지 (Emergency Stop)」를 수행할 수 있습니다. -
적합한 유스케이스 (Use Case): 대량의 웹 스크레이핑 (Web Scraping), 문서 자동 정리, 장시간 실행되는 데이터 파이프라인.
Human-in-command (HIC - 주도·협조)-
동작 원리: 인간이 태스크의 분해나 대국적인 의사결정의 대부분을 컨트롤하며, AI는 「수식 계산」, 「프로그래밍 코드의 개별 파트 구현」 등 완전히 제어된 샌드박스 (Sandbox) 내에서의 정형 작업만을 담당합니다. -
적합한 유스케이스 (Use Case): 복잡한 시스템 설계, 법적 문서의 초안 작성.
프로젝트 매니저 (PM)나 시스템 설계자는 다음 매트릭스 (Matrix)를 기준으로 자동화 수준을 결정합니다.
| 액션의 영향 범위 | 실패의 회복성 | 권장되는 접근 방식 | 구체적인 구현 방침 |
|---|---|---|---|
| 극히 높음 (결제, 인프라 파괴) | 불가역 (회복 어려움) | HITL (게이트형) | 특정 노드의 실행 전에 반드시 breakpoint를 설정하여, 인간이 UI 상에서 「승인」을 누를 때까지 상태를 동결. |
| 중간 (메일 초안, 사내 통지) | 가역 (수정 용이) | HITL (리뷰형) | AI가 결과물 (Draft)을 작성하고, 인간이 「수정」을 가한 후 전송 버튼을 직접 누름. |
| 낮음 (요약, 데이터 분석) | 가역 (재실행 가능) | HOTL / 완전 자율 | 에이전트에게 완전한 자율 주행을 허용하면서, 에러나 이상 출력이 감지되었을 때만 알림 통지. |
HITL을 뒷받침하는 엔지니어링의 핵심은 **「상태의 저장 (Checkpoint)」**과 **「실행의 일시 정지 및 재개」**입니다. 비동기로 동작하는 에이전트에 대해 인간 사용자가 스트레스 없이 개입이나 피드백을 수행할 수 있도록 설계해야 합니다.
에이전트가 비동기 태스크를 실행하고 도중에 사용자의 승인을 요청할 때의 표준적인 시퀀스 (Sequence)는 다음과 같습니다.
웹 애플리케이션에서 이를 수행할 경우, 에이전트를 실행하는 스레드 (Thread)나 프로세스 (Process)를 메모리 상에서 슬립 (Sleep) 상태로 두고 기다릴 수는 없습니다. 왜냐하면 인간의 리뷰에는 수 분에서 수 일이 걸릴 수도 있기 때문입니다.
따라서 다음과 같은 요구 사항을 충족해야 합니다.
- 체크포인터 (Checkpointer): 각 노드의 실행이 끝날 때마다 에이전트의 내부 상태(메모리, 변수, 메시지 이력)를 관계형 데이터베이스 (PostgreSQL 등)나 Key-Value 스토어 (Redis 등)에 직렬화 (JSON 등)하여 저장한다.
- 스레드 세이프한 재시작 (Thread-safe Restart): 사용자가 승인 요청을 보냈을 때, 일시 중지된 스레드 ID (또는
thread_id)를 지정하여 그 시점의 DB 상태로부터 에이전트를 즉시 재구축하고 다음 노드를 실행한다.
여기서는 엔지니어가 실제로 시스템에 통합하기 위한 「승인·수정·감사 (Approve/Correct/Audit)」의 트리플 패턴에 대해, LangGraph의 상태 머신 (State Machine) 설계를 기반으로 한 Python 코드 예시로 보여드립니다.
구체적인 예시로, 「AI가 SQL 쿼리를 생성하고, 실행 전에 인간이 리뷰·수정·실행한다」 라는 시나리오를 모델링합니다.
이 코드에서는 인간이 「SQL을 그대로 실행한다 (Approve)」, 「SQL을 에디터에서 직접 고쳐 쓴다 (Correct)」, 「피드백을 돌려주어 AI가 다시 생성하게 한다 (Audit / Feedback)」의 세 가지 액션을 취할 수 있도록 설계되어 있습니다.
from typing import TypedDict, Optional, Literal
import json
# =====================================================================
...
자율형 AI를 탑재한 프로덕트를 설계할 때 가장 중요한 패러다임 전환은, 「AI는 틀릴 수 있다 (할루시네이션 (Hallucination)을 일으킨다)는 전제에 서는 것」 입니다. 에러를 프로그래밍 방식으로 제로(0)로 만드는 것은 불가능하기 때문에, UI/UX 디자인을 통해 그 악영향을 무효화합니다.
AI가 생성한 문서나 코드, 액션의 실행 결과를 즉시 엔드 유저에게 공개하거나 실행 환경에 배포해서는 안 됩니다.
[ AI 생성 ] ──> [ 초안 (Draft) ] ──> [ 인간이 수정 (Correct) ] ──> [ 공개/실행 ]
▲ (리뷰 화면에서 차이점 하이라이트)
- 초안 표시 (Draft Marking): AI가 생성한 요소에는 반드시 「AI Draft (AI에 의한 초안)」라는 배지를 붙여, 확정되지 않은 상태임을 리뷰어에게 시각적으로 전달합니다.
- 차이점 표시 (Diff Highlight): 인간이 「과거의 초안」과 「AI의 제안」 사이의 차이점, 또는 「AI의 제안」과 「인간의 수정 사항」 사이의 차이점을 즉시 확인할 수 있는 Git 라이크 (Git-like)한 UI를 준비합니다.
AI가 잘못된 추론을 계속하여 수정 루프가 수렴하지 않거나, 예외적인 비즈니스 규칙을 적용하고 싶은 경우, 인간이 상태 (State)의 일부 필드를 강제로 덮어쓰고 AI에 의한 덮어쓰기를 「잠금 (Lock/금지)」하는 메커니즘을 데이터 스키마 상에 설계합니다.
{
"project_id": "proj-1029",
"summary": "AI가 생성한 요약 텍스트...",
...
is_locked 플래그가 is_locked: true로 설정된 필드는, 이후의 에이전트 추론 루프 내 (LLM으로의 프롬프트 생성이나 State 업데이트 노드의 로직)에서 LLM이 결코 덮어써서는 안 되는 「확정값 (상수)」으로 취급됩니다. 이를 통해 인간이 한 번 수동으로 수정한 값을 AI가 다시 할루시네이션으로 덮어써 버리는 「재작업 (Rework)」을 방지할 수 있습니다.
- AI의 동작을 동기적으로 기다리지 않기: HITL은 비동기 처리로 설계하며, 상태의 완전한 영속화와 스레드 세이프한 재시작을 표준으로 한다.
- 모든 변경에 이력과 작성자를:
updated_by: "ai"와updated_by: "human"을 구분하여, 인간의 주권을 항상 AI보다 위에 둔다. - 잠금 메커니즘 구현: 인간이 수정한 값은 잠금 처리하여, AI 루프에 의한 「재작성(Re-writing)의 비극」을 완전히 차단한다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기