인간이 루프 위에 서려면 어떻게 해야 할까? (Human-in-the-loop vs. Human-on-the-loop)

최근 몇 군데서 Human-in-the-loop(HITL)과 Human-on-the-loop(HOTL)에 대해 언급한 적 있었는데, HOTL 설계는 어떻게 해야 하는가? 라는 질문을 받아서 답변한 걸 가볍게 적어봅니다.

참고로, 항상 언급하지만 제가 쓰는 내용들이 제가 잘 해서/잘 알아서라기보다는 줏어들은 거 + 아주 조금 경험해본 수준이라는 건 꼭 기억해주시고요. 즉 환각이 얼마든지 있을 수 있습니다.

우선 두 개념의 차이에 대해서는 저보다 LLM이 더 잘 알 것이므로, Claude Sonnet 4.5의 답변을 첨부합니다.

Q. Human-in-the-loop 와 Human-on-the-loop 의 설계 차이에 대해 예시를 들어 설명해줘.

(– 이하 LLM 답변)

Human-in-the-Loop (HITL)

사람이 의사결정 과정 안에 직접 참여합니다. AI가 결정을 내리기 전에 사람의 승인이나 입력이 필요합니다.

예시: 의료 영상 진단 시스템

1. AI가 X-ray 이미지를 분석해 "폐렴 가능성 85%"라고 판단
2. 시스템이 자동으로 멈추고 의사에게 알림
3. 의사가 AI의 분석을 검토하고 "승인" 또는 "거부" 결정
4. 의사의 승인 후에만 진단 결과가 환자 차트에 기록됨

예시: 자율주행차 (레벨 3)

• 고속도로에서는 AI가 운전
• 복잡한 교차로나 공사 구간에 접근하면 "운전자 개입 필요" 경고
• 운전자가 핸들을 잡고 직접 운전
• 상황 통과 후 다시 AI에게 제어권 이양

Human-on-the-Loop (HOTL)

사람이 시스템을 감독하고 모니터링합니다. AI가 자율적으로 작동하지만, 사람이 개입할 수 있는 권한을 유지합니다.

예시: 스팸 필터링 시스템

1. AI가 매일 수천 개의 이메일을 자동으로 분류
2. 사용자는 결과를 주기적으로 확인
3. 잘못 분류된 메일을 발견하면 수동으로 수정
4. 시스템은 이 피드백으로 학습하고 개선

예시: 공장 자동화 라인

• 로봇들이 24시간 자율적으로 제품 조립
• 관리자는 대시보드로 실시간 모니터링
• 불량률이 특정 임계값을 넘으면 경고 발생
• 관리자가 필요시 라인을 중단하고 조정

핵심 차이점

실무에서는 두 방식을 혼합해서 사용하기도 합니다. 예를 들어 금융 거래 시스템에서 소액은 HOTL로, 고액은 HITL로 처리하는 식입니다.

(– LLM 답변 끝)

HOTL 설계에 필요한 질문들

저는 인간이 루프 위에 서려면 HITL보다 몇 가지를 더 엄밀하게 고민해봐야 한다고 생각합니다.

1) 내가/전문가가 특정 과업의 결과물 품질에 대해 평가하는 기준을 정량적으로 어떻게 세울까?

• 이게 없으면 모든 게 무의미해짐. 정량적인 게 없다면 정성적인 루브릭이라도 만들어야 함
• 현재 구축된 기준이나 De-facto standard가 없다면 내가/전문가가 기존에 어떤 사례에 대해 어떻게 평가했는지, 즉 테스트 데이터 수집 필요. 물론 이 테스트 데이터도 LLM과 함께 수집하거나 만들 수 있음. 이 데이터 중 일부는 평가자 구현의 트레이닝 데이터로 쓰면 좋음
• 초기 데이터가 없을 때는 보수적 기준(더 자주 개입)에서 시작해 점진적으로 완화하는 전략이 필요. 즉 처음부터 HOTL로 가는 건 어렵거나, 위험함

2) 1을 평가하는 평가자를 어떻게 신뢰도 높게, 저비용으로 구현할까?

• Deterministic한 알고리즘일 수도 있고, LLM-as-a-judge 를 쓸 수도 있음

3) 평가자의 신뢰도는 어떻게 평가할까? (메타-평가자)

• False positive(틀리게 평가)와 False negative(중요한 내용을 빼먹음)을 모두 고려해야 함. 여기서도 다시 LLM을 쓸 수 있음

4) 작업 결과물, 평가자의 산출물, 메타 평가자의 산출물 등은 어떤 형태로 구성되어야 인간과 에이전트가 필요시 쉽게 읽고, 결과물 및 알고리즘을 자가개선할 수 있을까?

• 인간이 읽기 쉬운 것과 에이전트가 읽기 쉬운 것은 다를 수 있음. 인간은 시각화된 걸 보는 게 도움이 되지만, 시각화 이미지가 있으면 (아무리 멀티모달이라도) 에이전트에게 훨씬 불리해짐. 비용이든 속도든 품질이든.
• 에이전트가 비용/속도/품질 측면에서 읽기 쉬운 건 역시나 텍스트. 즉 어떻게든 텍스트파일로 저장할 생각을 해야 함

5) 에이전트가 무한히 루프를 돌게 만들려면 (토큰 비용이 훨씬 싸지기 전까지는) 비용 관리가 핵심. 어떤 행위에 어떤 모델을 쓸까?

• 언제 LLM을 쓰고, 언제 알고리즘을 쓰고, 언제 외부 API를 호출하고, 언제 인간이 개입해야 하는지 판단해야 함. 물론 이 설계도 LLM과 같이 할 수 있고, 꾸준히 조절해야 함
• 세부 과업 중 저비용이 중요한 부분, 고품질이 중요한 부분, 짧은 응답시간이 중요한 부분이 어디인지 구분해야 함

6) 무한히 도는 와중에 인간의 개입 시점 및 루프 종료 시점을 어떻게 인간/에이전트가 판단할까?

• 이 판단이 쉬워지려면 현재 상태에 대한 리포팅 시스템, 또는 대시보드를 어떻게 구현해야 하나?
• 종료 조건은? 테스트 커버리지 100%, 반복 n회, 비용 얼마까지, 개선된 델타가 일정 이하 등

7) 인간의 개입 결과를 어떻게 시스템에 재학습시킬까? 시스템이 점점 더 나아지는지 어떻게 알 수 있을까?

• 인간이 수동으로 평가하기보다는(좋아요/싫어요) 진행 과정에서 자동으로 유의미한 기록을 남기는 게 유리함

그 외

• 사전-부검(Premortem). 이 루프를 오랫동안 돌렸는데도 성과가 나지 않았다면 무엇 때문일까? 또는, 이 루프를 놔뒀을 때 생길 수 있는 최악의 시나리오는 무엇인가?
• 이를 고려하면 설계를 어떻게 개선해야 하나? 최악의 시나리오에 대한 안전장치는 어떻게 마련할까? 법적/윤리적 책임은?

등등.

서두에도 말씀드렸듯 제가 이것들을 잘 해서 주절주절 써둔 건 전혀 아닙니다. 그래도 요즘, '하루 최소 30분씩 에이전틱 루프 고민하기'를 실천하고 있는데 그러면서 (토이 프로젝트 수준일지언정) 조금씩 감이 생기고 있는 것 같습니다. 그 결과물 중 일부도 언젠가 공유할 기회가 있겠죠.