Human-in-the-Loop, 도대체 뭐고 왜 자꾸 무너지는가
요즘 AI 관련 글 보면 "human-in-the-loop" (HITL, 루프 안의 인간) 이라는 표현이 자주 나옵니다. "AI 는 잘못할 수 있으니 인간이 확인해야 한다" 는 원칙에서 출발한 개념인데, 알고 보면 이게 의외로 자주 무너지는 구조예요. 정리해봤습니다.
어디서 온 말인가
원래 항공·군사 공학 용어입니다. 비행기·미사일 방어 시스템이 너무 복잡해져서 자동화됐을 때, "긴급 정지할 수 있는 인간" 을 의미하는 표현이었어요.
가장 유명한 사례가 1983 년 Stanislav Petrov. 소련 방공망 자동 시스템이 "미국 핵미사일 발사 감지" 라고 경보를 울렸는데, Petrov 가 "이건 시스템 오류일 가능성이 높다" 판단해서 상부 보고를 안 했어요. 진짜로 오탐이었고, 그가 루프 안의 인간 역할을 제대로 해서 핵전쟁을 막은 사례입니다.
1990 년대 들어 AI / 머신러닝 분야로 흡수돼서 "AI 시스템 결정에 인간이 개입하는 구조" 의 표준 용어가 됐습니다.
비슷한 표현들 - in / on / out
같은 계열이지만 의미가 다릅니다:
| 용어 | 의미 |
|---|---|
| Human-in-the-Loop | 매 결정마다 인간 개입. AI 출력은 인간 승인 전에 사용자가 못 봄 |
| Human-on-the-Loop | 인간이 감독자. AI 가 자율 실행, 필요시 개입 |
| Human-out-of-the-Loop | 완전 자율. 인간 개입 없음 |
업계에서 human-on-the-loop 표현을 점점 많이 쓰는데, Carnegie Council 같은 윤리 기관에서는 이걸 "인간을 시스템에서 더 멀리 떼어놓으려는 정책 입안자들의 용어 조작" 이라고 비판하기도 합니다.
핵심 문제 - HITL 이 자주 무너지는 4 가지 패턴
1. Automation Bias (자동화 편향)
심리학 연구에서 일관되게 확인되는 현상. "AI 가 추천하면 그게 정답일 거라고 더 믿는 경향". 실제 실험 결과:
- 똑같은 추천을 "AI 가 제공" 으로 라벨링하면 인간이 더 잘 받아들임
- HITL 환경 (사용자가 추천을 모니터링·조정 가능) 에서 알고리즘 선호도가 7 percentage points 증가 (PLOS One / NCBI 학술 논문 자료, N=292)
- 결과: human-in-the-loop 자체가 의사결정 품질을 오히려 낮출 수 있음
즉 인간이 들어와 있어도 AI 답을 더 신뢰하니까 검토가 형식적이 됩니다.
2. Rubber-Stamp Oversight (도장 찍기 감독)
인간이 형식적으로 승인만 하고 실질 검토는 안 하는 패턴. EU AI Act Article 14 가 이걸 "oversight facade (감독 시늉)" 이라고 명시했어요. 발생 조건 다섯 가지 중 하나만 빠져도 감독은 연극이 됩니다:
- 검토 시간 부족 (1 건당 몇 초)
- 시스템 작동 원리에 대한 접근 불가
- 검토자의 도메인 역량 부족
- 반대 의견에 대한 제도적 보호 부재
- 진짜 override 권한 부재
다섯 가지 다 만족 못 하면 책임만 인간에게 떠넘기는 구조 가 됩니다.
3. Normalization of Deviance (일탈의 정상화)
Simon Willison 이 짚은 개념. AI 가 반복적으로 잘 처리하면 인간이 검토를 점점 안 하게 되는 현상:
"Claude Code 가 잘 처리해서 어느 순간 모든 줄을 더 이상 검토하지 않는 나 자신을 발견했다."
이게 automation bias 의 시간 차원 버전 입니다. 한 번의 잘못된 신뢰가 아니라, 누적된 신뢰가 검토 자세 자체를 무너뜨리는 패턴. AI 코딩 에이전트 쓰시는 분이라면 누구나 만나는 함정.
4. Loss of Situation Awareness (상황 인식 상실)
복잡한 시스템을 감독할 때 인간이 시스템의 현재 상태 를 파악하지 못하는 현상. 항공 사고 연구에서 오래된 패턴인데, AI 코딩 에이전트에도 그대로 나타납니다.
에이전트가 여러 파일을 동시에 수정하면 인간이 "지금 코드베이스가 어떤 상태인지" 못 따라갑니다. 잘 작동하는 동안은 모르지만, 뭔가 잘못된 순간에는 어디서부터 잘못됐는지 도 추적이 안 되는 상황.
LLM 시대의 새로운 양상
책임 귀속의 명확화
Simon Willison 의 표현:
"컴퓨터는 책임을 질 수 없다. 그게 루프 안의 인간으로서 당신의 일이다. Claude 는 당신의 버그 있는 PR 때문에 해고당하지 않는다."
법적으로 LLM 자체는 책임 주체가 아니라서, 결과물 책임은 인간이 져야 합니다. "AI 가 잘못 짠 거예요" 가 변명이 안 됩니다.
검토 부담의 비대칭
Xata 의 Richard Gill 진단:
"AI 의 비대칭성이 작업을 제출자에서 검토자로 옮긴다. 시니어 엔지니어가 AI slop 검토만 하다가 전체 생산성이 떨어질 위험."
3 줄짜리 프롬프트로 PR 생성 → 검토자가 1,000 줄을 읽어야 함. 작성 - 검토 균형이 깨졌어요.
본질 변화 - 코딩에서 판단으로
Matteo Collina (Node.js Technical Steering Committee 멤버) 가 "The Human in the Loop" 글에서 같은 흐름을 짚었어요. AI 가 구현을 처리하니까 본인은 모든 변경을 검토하는 역할로 바뀌었다 는 자기 보고. 즉 시니어 엔지니어 작업의 본질이 작성 에서 판단 으로 이동하고 있다는 진단입니다.
EU AI Act 의 법적 요구사항 (2026 년 발효)
Article 14 가 high-risk AI 시스템에 대해 의무화했어요:
- 자연인이 시스템의 capacity 와 limitation 을 이해할 수 있을 것
- automation bias 인지 상태를 유지할 것
- 출력을 correctly interpret 할 수 있을 것
- 시스템을 stop 또는 override 할 수 있을 것
규제 당국이 "감독이 진짜로 가능했는가" 를 사후 평가합니다. "정책 문서에 적었으니 됐다" 는 통하지 않아요. 독일 Bundesnetzagentur, 스페인 AESIA 같은 규제 기관이 사후 검증.
그래서 실무에서 어떻게 해야 하는가
패턴별 정리
| 패턴 | 의미 | 예시 |
|---|---|---|
| Approval Loop | AI 가 액션 제안, 인간 승인 후 실행 | Claude Code 의 파일 수정 confirmation |
| Interrupt-and-Resume | AI 자율 실행 중 특정 조건에서 정지, 인간 결정 후 재개 | 위험한 명령어 만나면 정지 |
| Output Validation | AI 출력을 별도 검증 (rule-based 또는 다른 AI) 후 인간에게 노출 | 멀티 에이전트 라운드테이블 |
Training-time vs Runtime
- Training-time HITL: RLHF, Constitutional AI - 학습 단계에서 인간 피드백 반영
- Runtime HITL: 위 패턴들 - 실행 중 인간 개입
- 두 가지 다 필요. 한 쪽만으로는 부족합니다
한계와 비판
"인간이 정말 더 정확한가" 의문
- HITL 도입이 사용자 신뢰와 시스템 활용도는 높이는데, 결정 정확도는 오히려 낮출 수 있음 (위 7 percentage points 자동화 편향 실험)
- 인간 검토자도 피로 / 편향 / 일관성 부족 문제 있음
- 특정 도메인 (의료 영상 일부 등) 에서는 AI 단독이 인간 단독보다 정확
의존 위험
HITL 이 "인간이 늘 거기 있을 것" 을 전제로 만들어졌는데:
- 인간이 AI 답을 더 신뢰하게 되면 검토 자세 약화
- AI 가 너무 빨라지면 인간이 따라가지 못함
- 결국 HITL 이 결정을 인간이 한 척 만드는 도구 로 전락할 수 있음
정리
Human-in-the-Loop 은 "AI 가 결정 → 인간이 검토" 같은 단순한 그림이 아닙니다. 실제로는 검토가 진짜로 가능한 조건 이 모두 갖춰져야 작동합니다:
- 검토 시간 충분 (자동화 압박 없음)
- 시스템 동작 이해 가능
- 검토자가 도메인 역량 보유
- 반대 의견 제도적 보호
- 진짜 override 권한
이 다섯 가지 중 하나라도 빠지면 HITL 은 연극 입니다. 책임만 인간에게 떠넘기는 구조가 되고, automation bias 와 normalization of deviance 가 결합해서 AI 단독 보다 더 위험할 수도 있어요.
AI 코딩 에이전트 쓰시는 분이라면 본인 워크플로우를 한 번 점검해볼 부분입니다. "내가 진짜 검토하고 있는가, 아니면 도장만 찍고 있는가" 가 점점 더 중요해지는 시대입니다.
출처
- IBM, "What Is Human In The Loop" (1차 정의 자료)
- Carnegie Council, "Seven Myths of Using the Term Human on the Loop" (in/on/out 구분과 비판)
- Stanislav Petrov 1983 사례 (Carnegie Council 인용)
- Sele & Chugunova, "Putting a human in the loop: Increasing uptake, but decreasing accuracy" (PLOS One, 2024 / Max Planck Institute Research Paper No. 22-20) - 7 pp 자동화 편향 실험
- EU AI Act Article 14 (법적 요구사항)
- Maschinenrecht (Dr. Raphael Nagel), "Human in the Loop & Automation Bias: The Oversight Facade" (다섯 가지 조건)
- Simon Willison, "Your job is to deliver code you have proven to work" (책임 귀속, normalization of deviance)
- Matteo Collina, "The Human in the Loop" (Node.js TSC 멤버 글, adventures.nodeland.dev)
- Xata, "AI Codes, Humans Engineer" (검토 부담 비대칭)
- Redis blog, "AI Human in the Loop: Production Oversight Patterns" (실무 패턴 정리)
