휴먼인더루프(Human-in-the-Loop, HITL)는 AI의 판단·실행 과정에 사람이 단계마다 직접 개입하는 운영 방식이다. 결론부터 말하면, AI에게 일을 맡기는 수준은 켜고 끄는 스위치가 아니라 3단계의 다이얼이다. 사람이 루프 안에 있는가(HITL), 루프 위에서 지켜보는가(HOTL), 루프 밖으로 나갔는가(HOOTL).
이 글에서는 휴먼인더루프를 포함한 위임 3단계의 차이를 비교하고, 다이얼을 한 칸 올리기 전에 반드시 갖춰야 할 조건을 정리한다.
휴먼인더루프란 무엇인가
휴먼인더루프는 AI가 결과를 만들면 사람이 확인·승인해야만 다음 단계로 넘어가는 구조다. AI는 보조자이고, 실행의 마지막 손은 항상 사람이다. 번역 초안을 AI가 만들고 사람이 검수해 발송하는 방식, 분석 코드를 AI가 짜고 사람이 실행하는 방식이 전형적이다.
안전하지만 상한이 명확하다. 모든 결과물이 사람의 확인을 기다리므로, 산출 속도의 상한은 결국 사람의 처리 속도다. 그래서 휴먼인더루프는 위임의 끝이 아니라 시작점으로 이해해야 한다.
HITL HOTL 차이 — 사람은 어디에 서 있는가
세 단계의 차이는 ‘사람의 위치’로 구분하면 명확하다.
| 구분 | HITL (루프 안) | HOTL (루프 위) | HOOTL (루프 밖) |
|---|---|---|---|
| AI의 역할 | 보조 — 초안·제안 생성 | 운영 — 정해진 권한 안에서 스스로 실행 | 자율 — 목표 단위로 완결 수행 |
| 사람의 역할 | 건건이 확인하고 실행 | 기준을 정하고 예외에 개입 | 사후 감사와 목표·기준 설계 |
| 개입 시점 | 모든 단계 | 이상 신호가 있을 때 | 주기적 리뷰 |
| 적합한 업무 | 오류 비용이 큰 비정형 업무 | 패턴이 검증된 반복 운영 업무 | 충분한 이력으로 신뢰가 쌓인 업무 |
HITL HOTL 차이의 핵심은 기본값이다. HITL은 ‘사람이 승인해야 실행’이 기본값이고, HOTL은 ‘실행이 기본값, 사람은 예외에만 개입’이다. 같은 AI라도 어느 모드로 운영하느냐에 따라 조직의 산출 구조가 완전히 달라진다.
F1 레이스에서 이런 상황을 상상해보자. 피트스톱 타이밍을 정하는 세 팀이 있다. A팀은 전략 알고리즘이 제안을 띄우면 수석 전략가가 매번 승인해야 콜이 나간다(HITL). B팀은 알고리즘이 정해진 조건 안에서 자동으로 콜을 내고, 전략가는 세이프티카 같은 돌발 상황에만 개입한다(HOTL). C팀은 레이스 중 개입 없이 알고리즘이 운영하고, 레이스 후 리뷰에서 기준을 보정한다(HOOTL). 어느 팀이 정답일까. 정답은 없다. 알고리즘의 검증 이력과 상황의 변동성에 따라 적정 단계가 다를 뿐이다.
이 시나리오는 개념 설명을 위한 가상의 상황입니다. 실제 F1 팀의 전략과 다를 수 있습니다.
위임 다이얼을 올리기 전 알아야 할 3가지
휴먼인더루프에서 다음 단계로 넘어가는 것은 선언이 아니라 설계의 문제다.
1. 신뢰는 검증 이력에서만 나온다. 사람에게 일을 맡길 때도 전문성, 신뢰, 맥락 이해를 본다. AI도 같다. 충분한 기간 HITL로 운영하며 결과를 검증한 이력이 쌓여야 HOTL로 올라갈 자격이 생긴다. 이력 없는 위임은 위임이 아니라 방치다. 이때 결과를 제대로 의심하는 할루시네이션 방지 검증 습관이 이력의 품질을 결정한다.
2. 권한의 경계를 먼저 긋는다. HOTL의 전제는 ‘정해진 권한 안에서’다. 어떤 데이터에 접근하고, 어디까지 실행할 수 있으며, 어떤 조건에서 사람을 호출해야 하는지 경계가 명시되어야 한다. 경계 없는 자율은 사고로 이어지고, 사고는 위임 전체를 후퇴시킨다.
3. 지표를 바꿔야 단계가 보인다. 사람 중심 조직의 지표는 개인의 산출량이다. 위임 구조에서는 ‘AI가 사람 개입 없이 끝까지 처리한 업무의 비율’, 즉 위임률이 새로운 지표가 된다. 이 비율이 정체되어 있다면 조직은 아직 휴먼인더루프 단계에 머물러 있다는 뜻이고, 병목이 AI인지 사람의 승인 절차인지 들여다봐야 한다.
개인의 위임과 조직의 위임은 다르다
개인이 AI에게 문서 작성과 리서치를 맡기면 개인의 속도가 빨라진다. 그러나 조직의 생산성은 다른 문제다. 업무가 사람 사이를 흐르는 구조, 책임의 소재, 승인의 단계가 그대로면, 개인이 아무리 빨라져도 조직 전체는 느리다.
조직 차원의 위임은 운영 자체를 맡기는 일이고, 그래서 HOTL 설계가 조직 생산성의 분기점이 된다. AI가 스스로 일하는 구간이 생기는 순간, 그 결과를 지켜보고 개선 루프를 도는 감독 역량이 사람의 새 역할이 된다.
위임 다이얼을 올렸다가 되돌린 기록
이 블로그의 운영은 HOTL 쪽에 가깝다. AI가 원고를 쓰고 워드프레스에 올리고 메타까지 채우는 동안 사람은 게이트에서만 본다. 그 다이얼을 한 칸 더 올렸다가 사고가 난 적이 있다.
2026년 8월 4일, 검색엔진 색인 요청 10건을 처리했다. 절차대로 눌렀고 화면도 넘어갔다. 7일 뒤에 확인해보니 크롤 기록조차 없었다 — 10건 전부 무효였다. 같은 절차로 8월 6일에 넣은 10건은 다음 날 전부 색인됐다. 두 배치에서 달랐던 것은 요청을 넣은 뒤 접수가 확인되는 화면까지 지켜봤느냐뿐이었다.
여기서 배운 것은 HOTL에서 사람의 몫이 “지켜보기”가 아니라는 점이다. 지켜보기만 하면 화면이 넘어간 것을 완료로 읽는다. 사람이 확인해야 하는 것은 진행이 아니라 완료 신호다. 이후 절차서에는 “버튼을 눌렀는가”가 아니라 “접수 확인 창을 봤는가”가 완료 조건으로 들어갔다.
다이얼을 내리는 방법도 규칙이 아니라 도구였다. 이 블로그의 점검 작업은 AI 여러 대가 나눠 맡는데, 그중 누구에게도 사이트를 수정하는 도구를 주지 않았다. “읽기만 하라”고 지시하는 대신 쓰기 도구 자체를 빼버린 것이다. 이유는 단순하다 — 읽기와 쓰기가 하나의 통로로 묶여 있어서 읽기 전용 권한을 기술적으로 만들 수 없었다. HITL은 사람이 더 자주 들여다보는 것으로 구현되기보다, AI가 할 수 없게 만드는 것으로 구현될 때가 많다.
위임에서 가장 무서운 실패는 실패로 보이지 않는 실패다. 본문의 한 단어를 고치는 작업에서 AI가 잘못된 글자를 심은 적이 있는데, 도구는 “1건 치환 성공”을 돌려줬다. 찾지 못했다면 0건이 떴을 텐데 성공했기 때문에 아무도 다시 보지 않았다. 발행된 페이지를 다시 읽는 검증 단계에서야 잡혔다. 위임 다이얼을 올릴 때 같이 올려야 하는 것은 감시가 아니라 사후 검증이다.
핵심 요약
휴먼인더루프(HITL)는 사람이 건건이 승인하는 위임의 1단계이고, HOTL은 AI가 권한 안에서 실행하고 사람은 예외에 개입하는 2단계, HOOTL은 사후 감사만 남는 3단계다. 다이얼을 올리는 조건은 검증 이력, 권한 경계, 그리고 위임률이라는 새 지표다. 개인의 위임은 속도를, 운영의 위임은 조직 생산성을 만든다. 지금 내 업무의 다이얼은 몇 단계에 있는가.
함께 읽으면 좋은 글
AI가 스스로 일하는 구간을 만들었다면, 다음 질문은 “그걸 어떻게 지켜볼 것인가”다.
AI 관찰가능성이란 — AI가 스스로 진화하는 구조와 감독자의 3가지 조건
위임이 커질수록 사람의 강점이 어디로 이동하는지는 이 글에서 다뤘다.
AI 엔지니어가 살아남는다 — AI를 쓰는 엔지니어가 강한 3가지 이유
AI 시스템의 신뢰성·거버넌스 프레임워크는 NIST AI Risk Management Framework에서 공식 자료를 확인할 수 있다.
