HITL은 두 번 설계되어야 한다 — 실패 관측과 의사결정 권한

0. 문제 제기

우리는 HITL을 너무 작게 이해하고 있었다. 대부분의 에이전트 시스템에서 Human-in-the-Loop는 "모델이 틀릴 것 같을 때 사람을 부르는 장치"로 설계된다. confidence가 낮거나, 모델끼리 불일치하거나, 삭제·결제처럼 되돌리기 어려운 행동을 앞두고 있으면 일단 멈추고 사람에게 묻는다. 승인이 떨어지면 다시 진행한다. 틀린 설명은 아니지만, 충분한 설명도 아니다.

HITL은 실패 대응 장치이기 전에 의사결정 권한 배분 장치다. 언제 AI가 맡아야 하는지, 언제 인간이 먼저 판단해야 하는지, 언제 AI가 초안을 만들고 인간이 필터링해야 하는지, 언제 실행은 AI에게 맡기되 경계 조건은 사람이 쥐고 있어야 하는지 — 이 질문이 빠지면 시스템은 기묘한 모양으로 굳는다. 실패 감지는 잘 돌아가고 로그도 쌓이고 confidence threshold도 작동하는데, 정작 중요한 판단은 어느새 AI가 대신하고 있다. 사용자는 승인 버튼만 누른다. 겉으로는 HITL처럼 보이지만, 실제로 일어나는 일은 decision outsourcing이다.

이 글은 HITL을 두 층으로 나누어 본다. 하나는 실패 관측 체계로서 언제 시스템이 멈추고 검토를 요청해야 하는지를 다루고, 다른 하나는 의사결정 배분 체계로서 이 단계의 판단 권한이 누구에게 있어야 하는지를 다룬다. 두 층은 서로 연결되어 있지만 같지 않으며, 같지 않다는 사실을 놓치는 순간 설계는 조용히 무너진다.

1. 첫 번째 층 — 실패 관측으로서의 HITL

실패 관측 체계의 출발점은 "모델이 자신 있게 말하고 있는가"가 아니라 "무엇을 합의의 단위로 볼 것인가"라는 질문이다. 출력 형태가 달라지면 합의의 의미가 달라지고, 합의의 의미가 달라지면 실패 모드도 달라진다. 이 구조는 여러 모델을 비교할 수 있는 앙상블 환경과, 한 번의 generation 결과만 가진 단일 모델 환경에서 각기 다른 방식으로 드러난다.

1.1 앙상블이 있을 때 — 합의의 구조적 관측

NLP 앙상블 그래프를 구성하면서 먼저 눈에 들어온 것은 실패 관측 체계였다. 태스크는 출력 형태에 따라 서로 다른 집계 방식을 요구하고, 집계 방식이 달라지면 실패 모드도 함께 달라진다.

출력 형태	집계 방식	대표 실패 모드
라벨 고르기 — 정해진 목록에서 하나 선택. 감정 분류, intent 분류 (`discrete_label`)	다수결 — 여러 모델의 답 중 가장 많이 나온 라벨을 택한다 (`majority_voting`)	모델끼리 서로 다른 라벨을 낸다 (`disagreement`), 답이 세 방향으로 갈라진다 (`three_way_split`)
구간 찾기 — 텍스트 안에서 특정 범위를 잡아 타입을 매김. QA의 답 span, 개체명 인식(NER) (`span_type`)	겹침으로 합치기 — 모델들이 가리킨 범위가 얼마나 겹치는지(IoU)를 본다 (`span_iou_merge`)	범위가 충분히 겹치지 않는다 (`iou_below_threshold`), "답이 있다 vs 없다"에서부터 갈린다 (`answerability_disagreement`)
자유 서술 — 요약·설명·번역처럼 문장을 생성하는 문제 (`free_text`)	재평가 후 고르기·재구성 — 여러 후보를 비교해 가장 일관적인 것을 뽑거나(MBR), 여러 모델의 답을 전문가 앙상블처럼 재조합한다(MoA) (`moa_or_mbr`)	생성물 품질이 기준 이하 (`quality_below_threshold`), 질문·맥락과의 관련성 판단이 모델별로 어긋남 (`relevance_disagreement`)
표현 묶기 — 같은 대상을 가리키는 표현들을 하나의 묶음으로. 지시어 해소(coreference) (`span_cluster`)	묶음 일치 확인 — 모델들이 동일한 묶음을 만드는지 검증한다 (`cluster_merge_agreement`)	어디까지를 한 묶음으로 볼지 모델별로 다르다 (`cluster_conflict`)
쌍 관계 매기기 — 두 대상 사이 관계에 이름을 붙임. 관계 추출, 원인-결과 판단 (`span_pair_label`)	쌍 단위 투표 — 각 쌍마다 어떤 관계인지 다수결한다 (`pair_level_voting`)	같은 쌍에 대해 모델들이 서로 다른 관계를 매긴다 (`relation_disagreement`)
점수 매기기 — 위험도·품질처럼 연속값 출력 (`continuous_score`)	평균 — 모델 점수를 평균낸다 (`ensemble_average`)	모델 간 점수 편차가 크다 — 평균이 중립처럼 보여도 의견이 크게 갈렸다는 신호 (`high_variance`)

라벨 문제에서는 합의가 비교적 단순하다. 여러 모델이 같은 라벨을 고르면 그 라벨은 일단 안정적인 후보가 되므로 majority_voting이 자연스럽게 작동한다. 그러나 모델들이 서로 다른 라벨을 고르거나 세 방향으로 갈라질 때 이 현상은 모델 성능만의 문제가 아니라 라벨 경계가 흐리거나 taxonomy 자체가 아직 충분히 정리되지 않았다는 신호일 가능성이 크다.

Span 문제에서는 합의가 훨씬 섬세해진다. 두 모델이 모두 "답을 찾았다"고 말해도 가리키는 위치는 다를 수 있으며, 이때 필요한 것은 투표가 아니라 겹침의 확인이다. span_iou_merge는 모델들이 같은 evidence boundary를 보고 있는지를 묻는 장치이고, IoU가 낮다는 것은 단순한 오답이 아니라 시스템이 텍스트 안에서 무엇을 증거로 삼아야 하는지 아직 공유하지 못한다는 뜻이다.

Free text 문제에서는 합의가 한층 더 어려워진다. 좋은 요약이나 좋은 설명은 하나의 정답 라벨로 환원되지 않으므로, 표현이 서로 달라도 모두 괜찮을 수 있고 반대로 유창해 보여도 질문과 어긋나 있을 수 있다. 그래서 moa_or_mbr 방식은 단순 다수결이 아니라 평가와 재구성을 요구하며, 여기서의 실패는 "모델들이 다르다"가 아니라 "무엇을 좋은 답으로 볼 것인가"가 아직 고정되지 않았다는 신호다. Cluster 문제에서는 개별 답보다 묶음의 일관성이 관건이 되어 cluster_merge_agreement가 깨질 때 발생하는 cluster_conflict는 분류 실패라기보다 개체 경계·지칭 관계·문맥 해석이 서로 어긋났다는 증거에 가까우며, pair label 문제에서는 관계의 방향과 이름 자체가 핵심이어서 A가 B의 원인인지 B가 A의 결과인지 혹은 단지 함께 언급되었을 뿐인지에 따라 의미가 완전히 달라진다. Continuous score 문제에서는 평균이 편리한 집계이긴 하지만, 한 모델이 0.1을 다른 모델이 0.9를 냈을 때 평균 0.5를 중립적 판단으로 받아들이면 안 되며, ensemble_average 뒤에는 항상 분산 확인이 따라와야 한다.

이 표가 단순한 구현 표가 아닌 이유가 여기에 있다. 어떤 출력은 투표로 모을 수 있고, 어떤 출력은 겹침을 봐야 하며, 어떤 출력은 품질 기준을 다시 세워야 한다. 실패 모드는 오류명이 아니라 사람이 어떤 질문을 들고 다시 들어와야 하는지를 알려주는 관측 신호다.

1.2 앙상블이 없을 때 — 단일 모델의 내부 신호

앙상블 기반 관측의 전제는 "여러 모델의 출력을 비교할 수 있다"는 것인데, 실제 프로덕션의 많은 LLM 호출은 한 번의 generation 결과만을 남긴다. 이 경우에도 실패를 감지하려면 모델 내부 신호와 출력 자체의 속성을 세 축으로 분해해서 보아야 한다.

첫째 축은 자기 일관성이다. 같은 질문을 여러 번 샘플링하면 단일 모델 안에서도 답변 분포가 드러난다. Wang et al.(ICLR 2023)은 chain-of-thought 다중 샘플링의 다수결이 단일 greedy decoding보다 추론 과제에서 일관되게 개선된다는 것을 보였으며, 상위 답 비율이 낮을 때 그 자체가 저신뢰 신호로 작동한다. Farquhar et al.(Nature 2024)의 semantic entropy는 표면 표현이 달라도 의미가 같은 답변을 클러스터링한 뒤 의미 분포의 엔트로피를 계산하여, 어휘 수준이 아닌 의미 수준의 분산을 환각 탐지 신호로 전환했다. 로짓 접근이 불가능한 black-box 환경에서는 Manakul et al.(EMNLP 2023)의 SelfCheckGPT가 여러 stochastic 샘플과 원 출력의 일치도를 비교해 같은 역할을 수행한다.

둘째 축은 attribution이다. 출력이 제공된 근거에 실제로 귀속되는가를 측정하는 축으로, RAG나 tool-use 환경에서 특히 중요하다. Rashkin et al.(CL 2023)의 AIS 프로토콜은 주장과 근거의 귀속 여부를 인간 평가 수준에서 정의했고, Gao et al.(EMNLP 2023)의 ALCE는 citation recall/precision을 NLI 모델로 자동 계산하여 단일 모델 출력에 대해서도 faithfulness를 측정할 수 있게 했다. Lanham et al.(Anthropic 2023)은 chain-of-thought을 perturbation해도 최종 답이 변하지 않는 경우를 "rationalization"으로 분류하여, 모델의 reasoning이 답변과 인과적으로 연결되지 않는 구조적 실패를 드러냈다.

셋째 축은 calibration이다. 모델이 스스로 보고하는 확신도가 실제 정답률과 얼마나 일치하는가. Kadavath et al.(Anthropic 2022)은 모델의 P(True) self-evaluation이 단순 확률 추정보다 잘 calibrated된다는 것을 보였고, Tian et al.(EMNLP 2023)은 RLHF 모델의 verbalized confidence가 logit 기반 추정보다 우수하지만 실제 정답률과의 gap은 여전히 남아 있다고 보고했다. Steyvers et al.(Nature Machine Intelligence, 2025)은 이 calibration gap이 사용자의 과신이라는 사회적 결과로 이어진다는 것까지 추적했다. 즉 calibration은 결정 장치가 아니라 threshold 설정을 돕는 입력 신호로 이해해야 한다.

여기서 주의해야 할 제약이 하나 있다. 자기 평가의 연장선으로 자기 수정을 곧바로 실패 탐지기로 삼는 접근은 위험하다. Madaan et al.(NeurIPS 2023)의 Self-Refine은 외부 피드백과 결합될 때 품질을 일관되게 개선하지만, Huang et al.(ICLR 2024) "Large Language Models Cannot Self-Correct Reasoning Yet"은 외부 신호 없는 순수 자기 수정이 reasoning 과제에서 오히려 성능을 저하시킨다는 것을 보였다. 여기에 Zheng et al.(NeurIPS 2023)이 보고한 LLM-as-judge의 position·verbosity·self-enhancement 편향을 더하면, "한 번 더 생각해봐" 프롬프트로 실패를 걸러내겠다는 전략은 신뢰 가능한 관측 장치가 되지 못한다. Lightman et al.(OpenAI 2023)이 제시한 process reward model처럼 reasoning 단계별로 외부 verifier를 주입할 때에야, 단일 모델 파이프라인에서도 신뢰할 수 있는 실패 탐지가 성립한다.

1.3 어느 전략을 언제 쓸 것인가 — 실무 선택 조건

두 환경의 신호 체계를 이해했다고 해서 설계가 완성되는 것은 아니다. 실제로 어떤 실패 탐지 전략을 파이프라인에 탑재하느냐는 신호의 특성만큼이나 운영 환경의 제약에 의해 결정된다. 여기서 제약은 세 가지 축으로 작동한다: 레이턴시와 처리량, 비용, 태스크 유형.

레이턴시 축부터 본다. TTFT(첫 토큰까지의 응답 시간)가 100ms 이하여야 하는 환경 — 코드 자동 완성, 음성 기반 대화 — 에서는 앙상블이 물리적으로 불가능하다. 병렬 GPU 인프라 없이 N개 모델을 순차 호출하면 TTFT는 N배 증가하기 때문이다(RunPod, 2026). 반대로 처리량이 5,000 req/s를 넘는 고용량 서빙 환경에서는 GPU 비용이 모든 것을 지배하므로, 앙상블이 제공하는 accuracy 개선폭이 GPU 증설 비용을 정당화하기 어렵다(Microsoft TechCommunity, 2026). 이 두 임계값 안쪽의 영역 — TTFT 200~500ms, 처리량 100~5,000 req/s — 에서만 앙상블과 단일 모델 샘플링 양쪽이 현실적인 선택지로 열린다.

비용 축은 토큰 단가가 결정한다. 단가가 $0.001/M 이하인 경우 semantic entropy에 필요한 5~10회 샘플링은 경제적으로 허용된다. 단가가 $0.01/M을 넘으면 샘플링을 3회 이하로 줄이거나 NLI attribution 검증 1회 추가로 대체하는 편이 낫다(Introl, 2026). Taubenfeld et al.(ACL 2025)이 보인 것처럼, 신뢰도 가중 샘플링을 활용하면 18.6회에 해당하는 품질을 10회로 달성할 수 있다. 표본을 무조건 많이 뽑는 것보다 언제 멈출지를 아는 전략이 더 효율적이다.

태스크 유형 축은 가장 세밀하게 분기된다. 분류(intent, 감정)와 span extraction(NER, QA)에서는 앙상블 투표가 ROI가 좋다. 모델 수를 3개 늘리면 비용 3배에 정확도 3~5% 개선이 오며, disagreement 신호도 명확하다. RAG 스택에서는 단일 모델 생성에 NLI attribution 검증 1회를 더하는 것이 가장 효율적인 조합이다. 유창하지만 근거 없는 문장은 앙상블 disagreement로는 잡히지 않으므로, 이 환경에서 앙상블을 늘리는 것은 진짜 실패 모드를 지나치게 된다. 수학·CoT 추론에서는 Best-of-N 샘플링(8~16회)이 표준이며, Snell et al.(2024)은 동일 compute 예산에서 모델 파라미터 스케일링보다 test-time compute 스케일링이 더 효율적인 조건이 있다는 것을 보였다. Lightman et al.(2023)의 process reward model처럼 단계별 외부 verifier를 결합할 때 이 효율이 더 높아진다.

세 번째 선택지도 있다. 앙상블과 단일 모델 샘플링 사이에서 고민할 때, 라우팅이 종종 더 나은 답이 된다. Jitkrittum et al.(2025)의 Universal Model Routing은 쿼리 복잡도에 따라 소형·대형 모델을 동적으로 선택하여 앙상블 없이도 동등한 accuracy를 더 낮은 비용에 달성했다. Dekoninck et al.(2024)의 cascading 전략은 작은 모델이 실패할 때만 큰 모델로 에스컬레이션하여, 비용이 급증하지 않는 선에서 실패 탐지를 구현한다. "앙상블이냐 단일 모델이냐"보다 "이 쿼리에 어떤 크기의 모델이 적합한가"라는 질문이 설계의 출발점이 되는 경우가 실제로 더 많다.

세 결정 변수를 종합하면 전략 선택은 다음 표로 압축된다.

결정 변수	조건	앙상블 투표	단일 모델 샘플링	라우팅
레이턴시	TTFT < 100ms	✗	○ (≤5회)	○
	TTFT 200~500ms	○	○	○
처리량	> 5,000 req/s	✗	○ (배치 최적화)	○
	100~5,000 req/s	○	○	○
비용	< $0.001/M 토큰	○	○ (5~10회)	○
	> $0.01/M 토큰	△	○ (≤3회 또는 NLI 1회)	○
태스크	분류·intent	◉	○	△
	Span extraction (NER·QA)	◉	○ (latency 제약 시)	△
	RAG	△	◉ (attribution 검증 1회)	○
	수학·CoT 추론	△	◉ (Best-of-N 8~16 + PRM)	△
	Free-text 생성	○ (quality-critical만)	○	○

◉ 최적, ○가능, △ 조건부, ✗ 불가

두 환경을 관통하는 원리는 단순하다. 앙상블의 disagreement는 여러 모델 사이의 의미 분산이고, semantic entropy는 한 모델 안에서의 의미 분산이다. 앙상블의 IoU 실패는 모델들이 같은 evidence boundary를 공유하지 못한다는 신호이고, attribution 실패는 모델이 제공된 근거를 실제로 참조하지 않았다는 신호다. 실패 관측의 단위는 모델 수가 아니라 합의·근거·자신감의 세 축이며, 이 축들은 전략이 달라져도 살아남는다. 세 축의 신호는 [[technique__hitl-checkpoint]]의 confidence_score 입력으로 합성되어 [[reflective|Reflective]] 게이트를 작동시킨다.

이 구조에서 escalates_on 관계는 유용하게 작동한다.

nlp-task
  -> aggregated_by
  -> ensemble method | single-model signal
  -> escalates_on
  -> failure-mode

예컨대 relation_extraction이 앙상블에서 pair_level_voting으로 집계될 때 relation type·방향이 엇갈리면 relation_disagreement가 발생한다. 이때의 HITL은 모델이 실패했으니 사람에게 넘긴다는 뜻이 아니라, 관계 판단 자체가 경계 케이스이므로 관계 정의를 검토하라는 요청에 가깝다. 좋은 관측이고 유용한 장치이기는 하지만, 여기까지가 첫 번째 층이 할 수 있는 일의 범위다.

2. 실패 관측만으로는 decision outsourcing을 막지 못한다

실패 관측 체계는 언제 멈출 것인가를 다룬다. 그러나 모든 중요한 문제가 실패로 드러나는 것은 아니다. 모델이 자신 있게 답하고, 모델끼리 합의하며, 출력도 깔끔하고, 지표상 문제가 전혀 없는 상태에서도, 그 과정에서 사용자의 판단권이 조용히 빠져나가는 일이 벌어진다.

예를 들어 AI가 여러 후보 전략을 분석하고 "A안을 추천합니다"라고 말한다고 하자. confidence는 높고 근거도 그럴듯하다. 시스템은 실패하지 않았다. 그러나 사용자가 원래 해야 했던 선택은 단순히 A/B/C 중 하나를 고르는 일이 아니라, 어떤 기준을 우선할지를 정하는 일이었다. 비용인지 속도인지, 학습 효과인지 조직 저항을 줄이는 것인지, 단기 성과인지 장기 역량인지. 기준 선택은 그 자체로 판단이고, 그 판단을 AI가 조용히 대신하면 시스템은 성공적으로 작동하면서도 잘못된 방향으로 흘러간다. 실패보다 이쪽이 훨씬 위험하며, 실패는 눈에 보이지만 권한 이전은 눈에 잘 띄지 않기 때문이다.

그래서 HITL에는 두 번째 질문이 필요하다. 이 단계에서 인간과 AI 중 누가 먼저 판단해야 하는가. 이 질문은 confidence threshold로도 task category로도 풀리지 않는 user experience와 governance의 문제이며, 모델 품질의 문제가 아니라 권한 설계의 문제다.

3. 두 번째 층 — 의사결정 배분으로서의 HITL

HITL을 의사결정 배분의 관점에서 보면, 대화와 작업은 여섯 단계로 나뉜다.

분류	단계	핵심 질문	배분 방향
Exploratory	Discover	무엇이 있는가?	AI에게 맡긴다
Exploratory	Recommend	무엇이 중요해 보이는가?	AI 초안 + 내가 필터링
Decision	Advisory	어떤 선택지가 있고 트레이드오프는 무엇인가?	내가 먼저
Decision	Reflective	이 판단이 맞는가?	내가 먼저
Task Support	Instructional	어떻게 실행하는가?	AI 초안 기반
Task Support	Transactional	실제로 실행한다	AI에게 맡긴다, 단 경계 필요

Discover 단계에서는 AI에게 많이 맡기는 쪽이 자연스럽다. 자료 수집, 현황 파악, 후보 목록화는 AI가 잘하는 일이며, 사용자는 범위를 정하고 누락을 확인하는 정도로 충분하다. Recommend 단계에서도 AI 초안은 여전히 유용해서, 패턴을 찾고 중요해 보이는 항목을 뽑고 우선순위 후보를 제시하게 할 수 있다. 다만 "중요하다"는 판단은 아직 확정이 아니므로 필터링의 권한은 사용자에게 남아야 한다.

Advisory 단계부터는 성격이 달라진다. 선택지와 트레이드오프가 등장하는 순간 AI는 구조화할 수는 있어도 대신 결정해서는 안 된다. 이 단계의 핵심은 정답 생성이 아니라 decision frame의 정렬이며, 어떤 기준을 쓸 것인가, 어떤 손실을 감수할 것인가, 무엇을 포기할 것인가 같은 질문은 AI가 도와주더라도 최종 선택은 사람이 쥐고 있어야 한다. Reflective 단계는 여기서 한 걸음 더 나아간 단계로, 편향·불확실성·과신·자동화 의존을 점검하기 때문에 AI는 반대 근거를 제시하거나 다른 프레임을 보여줄 수 있지만, 이 판단을 유지할지는 철저히 인간의 몫이다.

Instructional 단계는 다시 AI 쪽으로 무게가 기운다. 실행 방법, 절차, 체크리스트, 복구 전략을 구성하는 일은 AI가 잘 해내고, 사용자는 의도와 제약을 확인하는 역할을 맡는다. Transactional 단계에서는 실제 실행을 AI에게 위임할 수 있지만, 삭제·결제·권한 변경·외부 전송·공개 게시처럼 되돌리기 어렵거나 외부 영향이 있는 행동에는 반드시 경계 조건이 붙어야 하며, HITL checkpoint가 바로 이 자리에 필요하다.

이렇게 보면 HITL의 의미가 달라진다. HITL은 사람이 중간에 한 번 눌러주는 일이 아니라, 각 단계마다 인간과 AI의 권한을 다르게 배치하는 설계에 가깝다.

4. 두 층은 어떻게 연결되는가

실패 관측과 의사결정 배분은 별개의 축이지만 따로 놀면 안 된다. 실패 관측은 대체로 Reflective로 흘러 들어간다.

failure-mode
  -> allocated_by
  -> Reflective

앙상블의 모델 불일치나 high variance, 단일 모델의 semantic entropy 급증이나 attribution 실패는 모두 "이 판단을 다시 보라"는 신호이기 때문에, retry나 fallback으로만 처리하면 중요한 질문이 사라진다. 많은 경우 이 신호들은 Reflective 단계로 보내야 하고, 그곳에서 사용자는 이 불일치가 데이터 오류인지, taxonomy 경계 문제인지, 근거 부재인지, 모델 다양성 부족인지, 아니면 애초에 선택 기준이 잘못 잡힌 것인지를 묻게 된다.

반면 실행 경계는 Transactional로 흘러 들어간다.

HITL checkpoint
  -> allocated_by
  -> Transactional

삭제, 배포, 결제, 권한 변경, 외부 커뮤니케이션은 모델이 아무리 확신하더라도 사람의 확인이 필요하다. 이때의 HITL은 실패 때문에 작동하는 것이 아니라 권한 때문에 작동하며, 행동의 결과가 외부 세계에 남기 때문이다. 이 둘을 섞으면 설계가 흐려진다. 실패 때문에 사람을 부르는 것(epistemic review)은 "알 수 없음"의 문제이고, 권한 때문에 사람에게 묻는 것(authority boundary)은 "누가 결정해야 하는가"의 문제이기 때문에, 트리거가 비슷해 보여도 질문의 성격이 다르다.

정리하면, 불확실성에서 출발한 HITL은 Reflective로, 외부 영향에서 출발한 HITL은 Transactional로 라우팅되며, 선택의 국면은 그 사이에 놓인 Advisory의 영역이다.

5. NLP 파이프라인에서 보이는 운영 원칙

이 모델은 추상적인 UX 원칙에 머물지 않고 실제 NLP 파이프라인에도 그대로 적용된다. 예컨대 intent_classification은 앙상블 환경에서 다음과 같은 흐름을 갖는다.

intent_classification
  -> aggregated_by: majority_voting
  -> escalates_on: disagreement_or_low_confidence
  -> allocated_by: Reflective

모델이 서로 다른 intent를 낼 때, 사람에게 "정답 레이블을 골라주세요"라고만 묻는 것은 약한 설계다. 더 나은 질문은 "이 발화가 기존 intent taxonomy 안에 들어가야 하는가, 아니면 새 intent 후보인가"이며, 이 질문은 Reflective 질문이고 사용자를 taxonomy 자체의 검토로 이끈다. 단일 모델 환경에서도 결과는 다르지 않다. semantic entropy가 임계를 넘으면 같은 Reflective 게이트로 들어가되, 이때 사용자에게 제시되는 질문은 "모델이 여러 샘플에서 서로 다른 intent를 말하고 있으므로 발화 자체의 해석 여지를 검토하라"는 형태가 된다.

relation_extraction도 같은 논리로 다룬다. 앙상블이라면 모델 간 관계가 엇갈릴 때, 단일 모델이라면 Lanham et al.(2023)의 기법을 따라 reasoning chain을 perturbation했을 때 관계 판정이 쉽게 뒤집히는 경우, 사람이 할 일은 A→B인지 B→A인지 고르는 것이 아니라, 관계 정의가 충분한지·방향성이 의미적으로 안정적인지·relation schema에 빠진 범주가 없는지를 살피는 것이다. summarization이나 data_to_text에서는 또 다른 문제가 드러난다. 앙상블에서는 quality_below_threshold로, 단일 모델에서는 SelfCheckGPT score나 ALCE citation precision 저하로 포착되는 이 실패에 대해 "이 요약이 맞나요?"라고 묻는 것은 너무 늦은 개입이다. 더 좋은 질문은 "이 출력이 어떤 의사결정 단계에 쓰이는가"이며, 단순 Discover용 요약이라면 AI에게 재위임해도 되지만 Advisory나 Reflective에 투입되는 요약이라면 반드시 불확실성과 누락을 드러내야 한다. 같은 실패라도 stage에 따라 다르게 처리되어야 한다는 점이 이 원칙의 핵심이다.

6. 설계 원칙 — HITL을 두 번 모델링한다

HITL을 설계할 때는 두 개의 관계를 모두 모델링해야 한다. 첫째는 시스템 관측을 담당하는 escalates_on이다.

relations:
  - type: escalates_on
    target: "[[failure-mode__disagreement]]"
    trigger: disagreement

이 관계는 어떤 신호에서 멈출 것인가, 어떤 실패 모드를 별도 노드로 승격할 것인가, 어떤 조건에서 retry·fallback·human review로 갈라질 것인가를 정의한다. 단일 모델 환경에서는 같은 관계가 trigger: semantic_entropy_above_threshold나 trigger: attribution_precision_below_threshold 같은 형태로 구체화된다. 둘째는 권한 배분을 담당하는 allocated_by다.

relations:
  - type: allocated_by
    target: "[[decision-allocation__reflective]]"
    allocation_direction: human_first

이 관계는 이 작업을 AI에게 맡겨도 되는지, 인간이 먼저 판단해야 하는지, AI 초안 후 인간 필터링이 맞는지, 실행은 AI가 하되 경계 조건만 사람이 승인하면 되는지를 정의한다. 둘 중 하나만 있으면 설계는 반쪽짜리다. escalates_on만 있으면 시스템은 실패에는 민감하지만 decision outsourcing에는 둔감해지고, allocated_by만 있으면 원칙은 그럴듯하지만 운영 신호가 비어버린다. 관측과 권한은 함께 모델링되어야 비로소 맞물려 돌아간다.

7. 실전 체크리스트

에이전트 시스템이나 NLP 품질 파이프라인을 설계할 때는 여섯 가지 질문을 순서대로 통과시킨다.

첫째, 이 작업은 어느 decision-allocation stage에 속하는가. Discover인지 Recommend인지 Advisory인지 Reflective인지 Instructional인지 Transactional인지를 먼저 정해야 한다. stage를 정하지 않으면 HITL의 위치가 계속 흔들린다.

둘째, 기본 권한 배분은 무엇인가. AI delegated인지, AI draft + human filter인지, human first인지, AI draft based인지, AI delegated with boundary인지를 명시해야 한다. 권한 배분은 UX 문구보다 먼저 확정되어야 하며, 이것이 정해져야 버튼·확인·설명·로그의 의미가 비로소 고정된다.

셋째, 실패 탐지 전략의 선택 조건이 정의되어 있는가. TTFT SLA가 100ms 이하이거나 처리량이 5,000 req/s를 넘으면 앙상블은 선택지에서 빠진다. 그 안쪽의 영역에서는 태스크 유형으로 분기한다. 분류·span 추출은 앙상블 투표가 ROI가 좋고, RAG는 단일 생성 + attribution 검증이 sweet spot이며, 수학·추론은 Best-of-N + step verifier가 표준이다. "앙상블이냐 단일 모델이냐" 이전에 "이 쿼리에 라우팅이 더 나은 선택인가"도 함께 검토해야 한다.

넷째, 실패 관측 신호는 선택한 전략에서 자연스럽게 도출되는가. 앙상블이라면 disagreement·high variance·schema violation이, 단일 모델이라면 semantic entropy·attribution precision·verbalized confidence가 구조적으로 흘러나와야 한다. 임의 규칙이 아니라 출력 유형과 집계 방식에서 유도된 신호여야 신뢰할 수 있다.

다섯째, 실패 신호는 어느 stage로 보내야 하는가. 대부분의 실패는 Reflective로 가지만 모든 실패가 사람의 승인까지 끌고 갈 필요는 없다. Discover 단계의 누락은 재검색으로 충분한 경우가 많고, Instructional 단계의 절차 오류는 repair strategy로 회복할 수 있으며, Transactional 단계의 외부 행동은 반드시 명시 승인으로 가야 한다.

여섯째, 인간에게 묻는 질문은 권한에 맞는가. "이 결과를 승인하시겠습니까?"는 나쁜 질문이다. "이 판단 기준을 유지하시겠습니까?", "이 relation schema에 새 범주가 필요합니까?", "이 행동은 외부 전송을 포함합니다. 지금 실행할까요?"는 좋은 질문이다. HITL의 품질은 결국 질문의 품질에서 결정된다.

8. 결론

HITL을 실패 대응으로만 보면 사람은 시스템의 예외 처리 장치로 전락한다. 반면 HITL을 의사결정 배분으로 보면 사람은 판단권의 주체로 남는다. AI 시스템이 점점 더 많은 일을 대신할수록 중요한 것은 "어디에서 멈출 것인가"만이 아니며, 오히려 더 무거운 질문은 "어디에서 사람이 먼저 판단해야 하는가"이다. 실패 감지와 로그와 fallback은 자동화할 수 있어도 판단권 배분만큼은 설계의 대상으로 남는다.

그래서 HITL은 두 번 모델링되어야 한다 — 한 번은 실패 관측의 층위에서 앙상블의 disagreement와 단일 모델의 semantic entropy·attribution·calibration을, 그리고 그것을 뒷받침하는 전략 선택(레이턴시·비용·태스크 유형)을 같은 축으로 엮는 방식으로, 또 한 번은 의사결정 권한의 층위에서 decision-allocation stage마다 누가 먼저 판단하는지를 명시하는 방식으로. 두 층이 함께 모델링될 때에야, HITL은 사람을 시스템의 꼬리표에서 판단권의 주체로 되돌려놓는다.