AI에서의 Human-in-the-Loop (HITL)란 무엇인가? 실무 가이드

AI에서의 Human-in-the-loop (HITL)는 자동화된 시스템의 결정 과정에 사람이 개입하여 — AI가 수행하는 작업을 승인, 편집 또는 중단함으로써 — 시스템이 완전히 스스로 작동하게 두지 않는 것을 의미합니다. AI 에이전트 (AI agents)의 경우, Human-in-the-loop는 에이전트가 특정 지점에서 동작을 멈추고, 실제 효과가 나타나기 전에 사람이 해당 동작을 검토하거나 조종할 수 있도록 하는 관행입니다. 어려운 점은 단순히 사람을 '추가'하는 것이 아니라, 그 사람이 실제로 중요한 실수를 잡아낼 수 있도록 만드는 것입니다.

이 가이드는 Human-in-the-loop가 무엇인지, 실제 AI 에이전트에서 나타나는 세 가지 형태, 이것이 완전 자동화(full automation) 및 Human-on-the-loop와 어떻게 다른지, 그리고 — 가장 중요하게는 — 검토 단계가 왜 안전(safety)과 동일하지 않은지를 설명합니다. 그런 다음 HITL을 잘 수행하는 방법과, 검토를 통해 대응하는 대신 나쁜 결과를 사전에 방지해야 하는 시점에 대해 다룹니다.

Human-in-the-loop의 실제 의미

이 문구는 제어 시스템 (control systems)과 머신러닝 (machine learning)에서 유래되었으며, 여기서 '루프 (loop)'는 동작, 그 결과, 그리고 수정의 순환 과정을 의미합니다. 루프 '안에 (in)' 사람을 두는 것은 사람 없이는 순환이 완료될 수 없음을 의미합니다 — 즉, 시스템이 멈추고 입력을 기다립니다. 루프 '위에 (on)' 사람을 두는 것은 사람이 지켜보며 개입할 수 있는 동안 시스템이 자율적으로 작동함을 의미합니다. 루프에서 사람을 '제외 (out)'하는 것은 완전 자동화 (full automation)를 의미합니다.

AI 에이전트 — 코드 에이전트 (code agents), 컴퓨터 사용 에이전트 (computer-use agents), 지원 봇 (support bots), 운영 자동화 (ops automations) — 에서 Human-in-the-loop는 자율성이 커짐에 따라 팀이 감독을 유지하려고 노력하는 방식입니다. 에이전트가 동작을 제안하거나 시작하면, 사람이 의견을 냅니다. 그것이 핵심 아이디어입니다. 이것이 효과가 있을지는 전적으로 세부 사항에 달려 있으며, 바로 이 지점에서 대부분의 구현이 조용히 실패합니다.

Human-in-the-loop AI의 세 가지 모드

HITL은 에이전트에서 세 가지 인식 가능한 형태로 나타납니다. 대부분의 제품은 이를 혼합하여 사용합니다.

1. 실행 전 승인 (Approve-before-act)

에이전트가 행동을 설명하고 실행하기 전에 승인을 기다립니다: "이 명령을 실행할까요?" "이 이메일을 보낼까요?" "이 행들을 삭제할까요?" 이것은 가장 흔한 패턴이자 가장 과도하게 신뢰되는 패턴입니다. 클릭 없이는 아무 일도 일어나지 않기 때문에 안전하게 느껴지지만, 클릭이 곧 이해를 의미하는 것은 아닙니다. (이에 대해서는 아래에서 더 자세히 다룹니다.)

2. 검토 및 수정 (Review-and-edit)

에이전트가 초안(코드, 메시지, 계획, 설정 변경 등)을 생성하면, 사람이 이를 검토하고 수정하여 배포합니다. 결과물(artifact)을 읽을 수 있고 검토자에게 시간이 있을 때, 즉 작은 차이(diff), 짧은 이메일, 단일 쿼리 같은 경우에 진정으로 유용합니다. 하지만 출력물이 방대하거나 밀도가 높으면 검토자들이 대충 훑어보게 되므로 성능이 급격히 저하됩니다.

3. 중단 및 재개 (Interrupt-and-resume)

에이전트가 자율적으로 실행되지만, 사람(또는 모니터)이 작업 중간에 이를 일시 중지하거나, 방향을 재설정하거나, 종료할 수 있습니다. 이것은 스펙트럼 상에서 Human-on-the-loop(인간이 루프 위에 있는 형태)에 해당하며, 모든 동작마다 멈추는 것이 불합리한 고처리량(high-throughput) 작업에 적합한 기본 설정입니다. 중단(interrupt)이 실제로 가능할 때, 즉 도달 가능하고, 빠르며, 진행 중인 작업을 중단할 수 있을 때만 감독(oversight)으로서 의미가 있습니다.

HITL vs. 완전 자동화(full automation) vs. Human-on-the-loop

이것들은 세 개의 별개 영역이 아니라, 자율성 사다리(autonomy ladder) 상의 지점들이며, 적절한 지점은 수행하는 행동에 따라 달라집니다.

• 완전 자동화 (Full automation) — 에이전트가 행동하며, 인간의 관문(gate)이 없습니다. 인간이 기여할 바가 없는 사소하고, 되돌릴 수 있으며, 범위가 제한된 행동에 적합합니다.
• Human-on-the-loop — 에이전트가 자율적으로 행동하며, 인간이 감독하고 중단할 수 있습니다. 적절한 킬 스위치(kill switch)와 모니터링이 갖춰진 대량 작업에 좋습니다.
• Human-in-the-loop (HITL) — 에이전트가 행동 전(또는 도중)에 사람을 기다립니다. 결과가 중대하고 관문(gate) 설정이 필요한 중간 단계의 작업에 사용하도록 아껴두어야 합니다.

실수는 이를 에이전트가 할 수 있는 모든 일에 적용되는 하나의 전역 설정(global setting) — "우리는 Human-in-the-Loop (HITL)를 갖추고 있다" — 으로 취급하는 것입니다. 이는 피로(사소한 정보에 관문을 설정함) 또는 맹목적인 위험(위험한 작업에 관문을 충분히 설정하지 않음) 중 하나를 보장하게 됩니다. LoopRails framework는 제품 단위가 아니라 행동(action) 단위로 모드를 선택해야 한다고 주장합니다. 등급별 자율성 모드(autonomy modes)에 대한 전체 매핑은 playbook을 참조하세요.

오해: 검토 단계가 곧 안전은 아니다

대부분의 HITL 설계를 망가뜨리는 믿음은 다음과 같습니다. "사람이 승인하면 안전하다." 하지만 그렇지 않으며, 그 증거는 명확합니다.

AI 코딩 에이전트에 대한 연구(LoopRails codex 참조)에 따르면, 에이전트가 행동하기 전에 계획 승인(plan-approval)을 요구했을 때 공격 발생률은 약 90%에서 6074%로 감소했습니다. 이는 승리처럼 들릴 수 있지만, 나쁜 행동이 통과되었을 때 사람이 실제로 이를 포착(caught) 했는지를 살펴보면 이야기가 달라집니다. 테스트된 모든 승인 전략에서 인간의 개입 성공률은 단 **926%**에 머물렀습니다. 관문(Gating)은 나쁜 행동이 발생하는 _빈도_를 줄였지만, 이를 인식하고 중단시키는 인간의 능력은 거의 개선하지 못했습니다. 관문은 탐지기(detector)가 아니라 과속 방지턱(speed bump)처럼 작동했을 뿐입니다.

왜 그럴까요? 바로 자동화 편향 (Automation bias) 때문입니다. 사람들은 시스템의 제안을 과도하게 신뢰하며 실질적인 정밀 조사 없이 승인합니다. 특히 시스템이 이전에 옳았을 때, 출력이 확신에 차 보일 때, 그리고 계속 진행해야 한다는 시간적 압박이 있을 때 더욱 그렇습니다. 확인 프롬프트(confirmation prompt)는 사람을 훌륭한 오류 포착자로 만들어주지 않습니다. 그것은 주로 사람을 단순히 '클릭하는 존재'로 만들 뿐입니다.

이로부터 두 가지 실패 모드가 발생합니다:

• 고무도장 (The Rubber Stamp) — 승인이 반사적으로 클릭되어, 관문이 가끔 나쁜 행동을 막기는 하지만 표적화된 행동을 포착하는 일은 거의 없습니다.
• 도덕적 크럼플 존 (The Moral Crumple Zone) — 무언가 잘못되었을 때, 문제를 포착할 현실적인 기회가 전혀 없었음에도 불구하고 "승인"을 클릭한 인간이 비난을 받게 됩니다. 검토 단계가 피해를 방지하기 위해서가 아니라 책임을 할당하기 위해 존재하게 된 것입니다.

만약 당신의 감독(oversight)이 단지 _검토 단계가 존재한다_는 사실만을 증명한다면, 당신은 유령 감독 (Phantom Oversight) 상태에 놓인 것입니다. 이는 조직도상으로는 안전 장치처럼 보이지만, 실제 운영(production) 환경에서는 아무런 역할도 하지 못하는 통제 수단을 의미합니다.

더 나은 질문

"인간이 이것을 검토해야 하는가?"라고 묻지 마십시오. 대신 다음과 같이 물어야 합니다: "인간이 현실적으로 이 실수를 제때 잡아낼 수 있는가?"

이렇게 질문하면 감독(oversight)은 테스트 가능한 답을 가진 엔지니어링 문제로 재정의됩니다. 만약 검토자가 실제 동작과 그 결과를 볼 수 있고, 판단할 수 있는 역량과 시간을 갖추고 있으며, 실제로 그 동작을 중단하거나 되돌릴 수 있다면 — 그때는 게이트(gate)가 작동할 수 있습니다. 만약 그럴 수 없다면 — 즉, 결과의 영향력은 크지만 통제력은 낮다면 — 검토는 함정입니다. 당신은 인간이 실제로 내릴 수 없는 결정을 무대 위에 올리고 있는 것이며, 확인 프롬프트(confirmation prompt)는 단지 그 위험을 인간의 이름으로 세탁(launders)할 뿐입니다.

이것이 해를 방지하는 감독과, 해가 발생한 후에 지목하기 위해 존재하는 감독의 차이입니다.

Human-in-the-loop을 잘 수행하는 방법

LoopRails는 훌륭한 HITL을 네 가지 단계로 정의합니다: 등급 분류(Grade), 보호(Guard), 표시(Show), 증명(Prove).

등급 분류 (Grade)

에이전트가 취할 수 있는 모든 행동을 세 가지 축 — 가역성 (reversibility), 영향 범위 (blast radius), 그리고 이해관계 (stakes) — 에 따라 점수를 매기고, 가장 높은 축을 기준으로 G0에서 G3까지 등급을 설정합니다.

• G0 — 사소함 (trivial): 가역적이고, 국소적이며, 이해관계가 없음 (파일 읽기, 읽기 전용 쿼리 실행). 게이트를 두지 않습니다. 게이트를 두는 것은 피로감만 유발합니다.
• G1 — 낮음 (low): 최대 하나의 중간 축 (로컬 파일 수정, 테스트 실행). 확인 절차보다는 저렴한 실행 취소(undo)가 더 효과적입니다.
• G2 — 높음 (high): 하나의 높은 축 포함 (git push, 예산 내 지출, 내부 메시지 전송). 실제 미리보기를 통한 사전 확인(Confirm-before)을 수행합니다.
• G3 — 치명적 (critical): 가역적이지 않으면서 외부적이거나 심각함 (배포, 결제, 운영 데이터 삭제, 공개 게시). 차단하거나 에스컬레이션(escalate)해야 합니다. 여기서는 검토만으로는 충분하지 않습니다.

보호 (Guard)

통제 수준을 등급에 맞추십시오. G0/G1 단계에 주의를 쏟지 마십시오. G2 단계는 미리보기(preview)로 게이트(gate)를 설정하고, G3 단계에서는 승인 프롬프트(approval prompts)보다는 방지 패턴(prevention patterns)에 의존하십시오. 즉, 샌드박스 우선(Sandbox-First, 환경 내 폭발 반경(blast radius) 제한), 폭발 반경 제한(Blast-Radius Cap, 단일 작업의 규모 제한), 권한 잠금(Capability Lock, 나쁜 작업이 권장되지 않는 수준이 아니라 불가능하게 만듦), 런타임 실드(Runtime Shield), 킬 스위치(Kill Switch), 서킷 브레이커(Circuit Breaker), 그리고 메이커-체커(Maker-Checker, 제안자가 결코 승인자가 될 수 없음) 방식을 활용하십시오.

보여주기 (Show)

사람을 개입시킬 때는 그 순간을 설계하십시오. 단순히 "승인하시겠습니까?"라고 묻는 것이 아니라, 실제 작업과 그 결과(diff, 미리보기, 부작용, 실행 취소 가능 여부 등)를 보여주어야 합니다. 사람이 맹목적으로 신뢰하기보다 검토할 수 있도록 에이전트(agent)의 불확실성과 출처(provenance)를 드러내십시오. 그리고 주의를 아껴서 사용하십시오. 프롬프트를 너무 자주 띄우면 사람들이 프롬프트를 무시하도록 훈련시키게 되므로, 드물게 그리고 의미 있는 중단점(breakpoints)에서만 개입하십시오.

증명하기 (Prove)

"사람이 검토한다"를 단순히 체크박스를 채우는 것이 아니라, 검증해야 할 주장(claim)으로 취급하십시오. 파이프라인에 알려진 오류와 프롬프트 인젝션(prompt-injection) 시도를 심어두고, 사람(또는 모니터)이 실제로 이를 _포착(catches)_하는지 측정하십시오. 중요한 수치는 승인율(approval rate)이 아니라 개입 성공률(intervention-success rate)입니다. 테스트되지 않은 감독은 검증되지 않은 감독입니다.

이 네 가지 움직임의 밑바탕에는 모든 통제된 작업이 RAIL을 따르도록 유지하십시오: 가역성(Reversible), 권한 부여(Authorized), 중단 가능성(Interruptible), 그리고 로그 기록(Logged). 작업이 이 네 가지를 충족한다면, 검토를 놓치더라도 복구 가능하고, 범위가 제한되며, 중단할 수 있고, 책임 소재를 가릴 수 있습니다.

HITL이 잘못된 도구일 때 — 대신 방지하십시오

때때로 "사람이 제때 이것을 잡아낼 수 있는가?"라는 질문에 대한 정직한 답변은 "아니오"입니다. 동작이 너무 빠르거나, 불투명하거나, 되돌릴 수 없어서 어떤 현실적인 프롬프트로도 사람이 효과적으로 개입할 수 없는 경우가 있습니다. 그런 경우에는 검토 단계를 추가하지 마십시오. 검토를 추가하는 것은 '고무 도장 (Rubber Stamp)'과 '도덕적 완충 지대 (Moral Crumple Zone)'를 동시에 만드는 일입니다. 대신 나쁜 결과가 발생할 수 없도록 하거나, 발생하더라도 되돌릴 수 있도록 동작 자체를 변경하십시오.

가장 명확한 예시는 **치명적인 삼중주 (lethal trifecta)**입니다. (1) 개인 데이터에 접근할 수 있고, (2) 신뢰할 수 없는 콘텐츠에 노출되며, (3) 데이터를 외부로 전송할 수 있는 방법을 가진 에이전트는 프롬프트 인젝션 (Prompt Injection)에 속아 해당 데이터를 유출할 수 있습니다. 어떤 "정말 확인하시겠습니까?"라는 프롬프트도 이를 확실히 잡아낼 수 없습니다. 악의적인 지시 사항은 사람이 읽지 않을 콘텐츠 속에 숨겨져 있으며, 에이전트는 마치 자신의 업무를 수행하는 것처럼 보이기 때문입니다. 해결책은 검토가 아니라 예방입니다. 외부 전송 기능을 차단하거나, 개인 데이터를 격리하거나, 신뢰할 수 없는 입력을 정화 (Sanitize) 하는 등 세 가지 요소 중 하나만 제거해도 공격을 완료할 수 없습니다. 이것은 게이트 (Gate)가 아니라 '역량 잠금 (Capability Lock)'입니다.

결과가 중대하고 통제 가능성이 낮을 때는, 검토보다 예방이 언제나 승리합니다.

핵심 요약 (Key takeaways)

• **Human-in-the-loop (HITL)**는 사람이 AI의 동작이 실행되기 전에 이를 승인, 편집 또는 중단할 수 있음을 의미하며, 이는 완전 자동화 (Full automation)의 반대 개념입니다.
• 이는 세 가지 모드로 나타납니다: 실행 전 승인 (Approve-before-act), 검토 및 편집 (Review-and-edit), 중단 및 재개 (Interrupt-and-resume).
• 검토 단계를 추가하는 것이 곧 안전을 의미하는 것은 아닙니다. 게이트는 나쁜 동작이 발생하는 빈도를 줄여주지만, 사람이 이를 잡아내는 능력(개입 성공률 9~26%)을 거의 개선하지 못하며, 자동화 편향 (Automation bias)으로 인해 승인이 반사적으로 이루어지게 만듭니다.
• "사람이 이것을 검토해야 하는가?"가 아니라 "사람이 현실적으로 제때 이것을 잡아낼 수 있는가?"를 물으십시오.
• Grade, Guard, Show, Prove 원칙을 통해 HITL을 제대로 수행하고, 모든 동작을 되돌릴 수 있고 (Reversible), 권한이 부여되며 (Authorized), 중단 가능하고 (Interruptible), 기록되는 (Logged) 상태로 유지하십시오.
• 사람이 실수를 제때 잡아낼 수 없을 때는, 검토 단계를 마련하는 대신 나쁜 결과를 예방하십시오.

시작하기 (Get started)

루프 안에 사람이 있는지 묻는 것을 멈추고, 에이전트 (Agent)의 행동을 등급 매기기 시작하십시오. 가장 위험한 행동들을 interactive grader를 통해 실행하여 G0–G3 등급과 그에 맞는 제어 수단을 확인한 다음, practitioner playbook에 따라 네 가지 단계를 수행하십시오. 다음 에이전트 검토 시 cheatsheet를 옆에 두십시오. 그리고 다음에 누군가 "그냥 승인 단계를 추가하자"라고 제안한다면, 사람이 실제로 실수를 제때 잡아낼 수 있는지 물어보십시오.

원문은 looprails.dev/article-what-is-human-in-the-loop.html에 게시되었습니다. LoopRails는 AI 에이전트 (AI agents)의 Human-in-the-loop 감독을 설계하기 위한 무료 오픈 소스 프레임워크입니다.