실제 운영 중인 완전 자율형 AI 시스템은 치명적인 실수를 저지릅니다. Human-in-the-loop (인간 참여형) 방식을 추가하면 이러한 실수를 획기적으로 줄일 수 있지만, 지연 시간 (latency)과 처리 비용이 증가합니다.

문제는 루프 안에 인간이 필요한지 여부가 아닙니다. 문제는 AI 시스템을 수동 작업을 위한 값비싼 인터페이스로 만들지 않으면서, 위험한 결정을 잡아낼 수 있도록 정확히 어디에 인간을 배치하느냐입니다.

자율성이 효과적인 때와 제품을 망치는 때

두 가지 극단이 존재합니다. 완전 자율 (Full autonomy): 모델이 모든 것을 결정하고, 인간은 사후에 결과를 확인합니다. 완전 제어 (Full control): 모든 모델 응답이 사용자에게 도달하기 전에 수동으로 검토됩니다. 첫 번째 방식은 확장성 (scale)이 좋지만 오류가 발생했을 때 신뢰를 무너뜨립니다. 두 번째 방식은 신뢰할 수 있지만 경제성을 망칩니다.

실제 AI 제품은 이 두 극단 사이에서 존재합니다. 설계자 (architect)의 역할은 모델이 자율적으로 내릴 결정과 인간의 확인이 필요한 결정이 무엇인지 결정하는 것입니다.

경계선을 정의하는 세 가지 요소는 다음과 같습니다:

오류 비용 (Cost of error). 챗봇이 평점이 잘못된 식당을 추천하는 것은 짜증 나는 일입니다. AI 시스템이 환각 (hallucination) 분석을 바탕으로 50,000달러의 대출을 승인하는 것은 소송 대상입니다. 오류 비용이 높을수록 에스컬레이션 (escalation) 임계값은 낮아집니다.

가역성 (Reversibility). 이미 전송된 푸시 알림은 취소할 수 없습니다. 작성 중인 이메일은 보내기 전에 수정하기 쉽습니다. 되돌릴 수 없는 작업은 확인이 필요합니다.

모델 신뢰도 (Model confidence). 신뢰도가 0.95인 모델은 0.6인 모델보다 실수가 적습니다. 하지만 0.95라 할지라도 20번의 결정 중 한 번은 오류가 발생함을 의미합니다. 임계값은 작업에 따라 달라집니다.

신뢰도 임계값: 의사결정 프레임워크

신뢰도 임계값 (Confidence threshold)은 모델의 결정이 인간의 검토를 받도록 설정하는 수치적 차단 지점입니다. 간단해 보이지만, 실제로는 작업 유형별로 보정 (calibration)이 필요합니다.

기본 공식

IF confidence >= threshold AND risk_level == "low"
  -> autonomous decision
IF confidence >= threshold AND risk_level == "high"
...

임계값(Thresholds)은 고정되어 있지 않습니다. 고객 지원 티켓 분류(support ticket classification)의 경우 0.7이면 충분합니다. 의료 트리아지(medical triage) 시스템의 경우 0.95 이상이 필요합니다. 금융 결정의 경우 0.99가 필요합니다.

임계값 교정 (Threshold calibration)

교정되지 않은 임계값은 임계값이 아예 없는 것보다 더 나쁩니다. 모든 응답(오답 포함)에 대해 0.9의 신뢰도(confidence)를 출력하는 모델은 HITL(Human-in-the-Loop)에 무용지물입니다.

교정 프로세스:

1. 신뢰도 점수와 함께 500~1,000개의 모델 결정 사항을 수집합니다.
2. 각 결정이 정답인지 오답인지 레이블을 지정합니다 (수동 레이블링 또는 LLM-as-Judge).
3. 곡선을 그립니다: 각 임계값에서 결정의 몇 퍼센트가 검토(review)로 넘어가고, 오류의 몇 퍼센트가 통과되는지 확인합니다.
4. 비즈니스 요구 사항에 따라 임계값을 선택합니다: 허용 가능한 오류 통과율(error pass-through rate) 대 검토자 업무량(reviewer workload).

from sklearn.metrics import precision_recall_curve
import numpy as np

...

전형적인 교정 결과:

임계값 0.85에서 시스템은 1.4%의 오류율로 요청의 59%를 자율적으로 처리합니다. 나머지 41%는 검토로 넘어갑니다. 대부분의 B2B 제품에 있어 이는 수용 가능한 균형입니다.

리스크 매트릭스 (Risk Matrix): 필터링의 두 번째 차원

신뢰도 임계값은 하나의 축으로 작동합니다. 리스크 매트릭스는 두 번째 축, 즉 결정의 유형과 결과(consequences)를 추가합니다. 높은 리스크 상황에서의 높은 신뢰도는 여전히 감독(oversight)을 필요로 합니다.

                    낮은 리스크 (Low Risk)          높은 리스크 (High Risk)
                +-----------------+-----------------+
높은 신뢰도 (High Confidence) |  AUTO           |  AUTO + AUDIT   |
...

네 가지 영역, 네 가지 동작:

AUTO. 낮은 리스크, 높은 신뢰도. 모델이 결정하며 결과가 즉시 전송됩니다. 예시: 고객 지원 티켓 분류(support ticket classification), 콘텐츠 태그 생성(content tag generation), 검색 쿼리 자동 완성(search query autocomplete).

AUTO + AUDIT (자동 + 감사). 고위험(High risk), 고신뢰(High confidence). 모델이 자율적으로 결정하지만, 모든 결정 사항은 감사 로그(audit log)에 기록됩니다. 검토자가 사후에 샘플(10-20%)을 확인합니다. 예시: 콘텐츠 모더레이션 (content moderation), 자동 가격 책정 (automated pricing), 추천 개인화 (recommendation personalization).

QUEUE (대기열). 저위험(Low risk), 저신뢰(Low confidence). 결정 사항이 일괄 검토 대기열(batch review queue)로 넘어갑니다. 긴급하지는 않지만, 모델이 단독으로 처리할 수 없습니다. 예시: 비표준 요청 분류 (categorizing non-standard requests), 예외적인 제품에 대한 설명 생성 (generating descriptions for edge-case products).

ESCALATE (에스컬레이션). 고위험(High risk), 저신뢰(Low confidence). 즉시 사람에게 에스컬레이션됩니다. 결정이 내려질 때까지 프로세스가 차단됩니다. 예시: 사기 의심 (suspected fraud), 모호한 증상을 동반한 의료 권고 (medical recommendations with ambiguous symptoms), 계정 삭제 결정 (account deletion decisions).

위험 수준 결정하기 (Determining risk level)

위험은 정적(task type에 의해) 또는 동적(request content에 의해)으로 결정됩니다.

정적 분류 (Static classification):

RISK_LEVELS = {
    "ticket_classification": "low",
    "content_moderation": "high",
...

동적 분류 (Dynamic classification)는 두 번째 모델이나 규칙 세트를 사용합니다. 5달러 환불 요청은 저위험입니다. 50,000달러 환불 요청은 고위험입니다. 동일한 작업이지만 감독 수준이 다릅니다.

def assess_risk(task_type: str, context: dict) -> str:
    base_risk = RISK_LEVELS.get(task_type, "medium")

...

프로덕션 환경에서의 HITL 패턴 (HITL patterns in production)

다섯 가지 패턴이 있습니다. 각 패턴은 특정 아키텍처 문제를 해결합니다.

패턴 1: 실행 전 게이트 (Pre-action Gate)

모델이 결정을 생성하지만 동작을 실행하지는 않습니다. 사람이 승인하거나 거부합니다.

요청 (Request) -> LLM이 결정 생성 -> 게이트 (Gate) -> [사람이 승인] -> 동작 (Action)
                                    |
                            [사람이 거부] -> 피드백 (Feedback) -> 모델 재시도 (Model retries)

사용 사례: 되돌릴 수 없는 모든 동작. 사용자를 대신한 이메일 발송, 콘텐츠 게시, 금융 거래 등.

구현: 모델이 제안된 동작(proposed action)이 포함된 구조화된 JSON을 반환합니다. 시스템은 이를 검토 대기열(review queue)에 기록합니다. 검토자가 승인(Approve) 또는 거절(Reject)을 클릭합니다. 승인 시 시스템은 동작을 실행합니다. 거절 시에는 재생성(regeneration)을 위해 모델로 피드백이 전달됩니다.

class PreActionGate:
    def __init__(self, queue: ReviewQueue, executor: ActionExecutor):
        self.queue = queue
...

패턴 2: 사후 감사 (Post-action Audit)

모델이 자율적으로 동작합니다. 사람은 사후에 결정 사항의 샘플을 검토합니다. 잘못된 결정은 롤백(rollback)되거나 보상됩니다.

요청(Request) -> LLM -> 동작(Action) -> 감사 로그(Log to audit) 기록
                              |
                    검토자가 샘플 확인
...

사용 사례: 오류당 비용이 낮은 대량의 결정. 댓글 중재(Comment moderation), 티켓 분류(ticket classification), 메타데이터 생성(metadata generation).

샘플 크기는 모델의 성숙도에 따라 달라집니다. 초기에는 결정의 20-30%를 검토합니다. 안정화된 후에는 5-10%를 검토합니다. 성능 저하가 감지되면 다시 20-30%로 돌아갑니다.

패턴 3: 신뢰도 기반 라우팅 (Confidence-based Routing)

신뢰도 점수(confidence score)에 따라 요청을 모델과 사람 사이에서 분배합니다. 모델은 단순한 케이스를 처리하고, 사람은 복잡한 케이스를 처리합니다.

요청(Request) -> LLM 평가 -> 신뢰도 >= 0.85 -> 자율 응답(Autonomous response)
                         -> 신뢰도 0.6-0.85 -> LLM 응답 + 검토 플래그(review flag)
                         -> 신뢰도 < 0.6    -> 사람 응답

두 개가 아닌 세 개의 구역(zone)을 사용합니다. 중간 구역의 경우: 모델이 즉시 응답하여 지연 시간(latency) 영향이 없지만, 응답은 검토 대기열(review queue)로 들어갑니다. 만약 검토자가 오류를 발견하면 사용자는 수정된 응답을 받게 됩니다.

이 패턴은 지원 봇(support bots)에 효과적입니다. 요청의 60-70%는 일상적인 업무이며, 모델이 0.9 이상의 신뢰도로 처리합니다. 20-25%는 중간 정도의 복잡성을 가지며, 모델이 응답하고 검토자가 확인합니다. 5-15%는 복잡하며, 바로 사람에게 전달됩니다.

패턴 4: 계층적 검증 (Cascading Validation)

여러 단계의 검사 계층이 존재합니다. 각 후속 계층은 비용이 더 많이 들지만 더 정확합니다. 요청은 필요한 신뢰도(confidence)에 도달할 때까지 필요한 만큼의 계층을 통과합니다.

LLM Generator -> 자동화된 규칙 (정규표현식 (regex), 스키마 검증 (schema validation))
                  | (통과 시)
              -> LLM-as-Judge (두 번째 모델이 평가)
...

두 번째 계층에 대한 자세한 내용: LLM-as-Judge: automated quality gate.

각 계층은 일부 오류를 걸러냅니다. 자동화된 규칙은 명백한 형식 위반(필수 필드 누락, 응답 내 SQL 인젝션 (SQL injection), 금지어에 의한 차단 콘텐츠)을 잡아냅니다. LLM-as-Judge는 의미론적 오류(semantic errors), 즉 환각 (hallucinations), 무관함 (irrelevance), 어조 위반 (tone violations)을 잡아냅니다. 사람은 두 자동화 계층이 놓친 것을 잡아냅니다.

경제성: 자동화된 규칙은 100%의 요청을 0달러에 처리합니다. LLM-as-Judge는 85%(규칙에 의해 필터링된 15% 제외)를 요청당 0.0020.01달러에 처리합니다. 사람은 510%(두 계층을 모두 통과한 나머지)를 요청당 0.50~2.00달러에 처리합니다.

패턴 5: 학습을 포함한 피드백 루프 (Feedback Loop with learning)

검토자의 결정은 모델을 개선하기 위해 시스템으로 다시 피드백됩니다. 시간이 지남에 따라 모델은 수정을 통해 학습하며 검토가 덜 필요하게 됩니다.

LLM -> 결정 (Decision) -> 검토 (Review) -> [정답 (Correct)] -> 학습 데이터셋에 +1
                           -> [오답 (Incorrect)] -> 수정 + 학습 예시
                                                   |
...

피드백 루프는 구조화된 데이터 수집이 있어야만 작동합니다. 검토자는 단순히 거절 (Reject)을 클릭하는 것이 아니라, 거절 사유, 정답, 그리고 오류 카테고리를 지정합니다. 이 데이터는 자동화된 품질 모니터링 (automated quality monitoring)을 위한 평가 데이터셋을 구축합니다.

HITL 시스템 구현: 아키텍처 (architecture)

최소한의 프로덕션 아키텍처는 다섯 가지 구성 요소를 가집니다.

+----------+     +--------------+     +--------------+
|  Client  |---->|  AI Service  |---->|  Review Queue|
+----------+     |              |     |  (Redis/SQS) |
...

AI Service는 모델을 호출하여 신뢰도(confidence)를 수신하고, 위험 수준(risk level)을 결정하며, 의사결정을 라우팅합니다.

Review Queue는 검토를 기다리는 결정 사항들을 저장합니다. 단순한 사례에는 Redis를, 분산 시스템에는 SQS/RabbitMQ를 사용합니다. 큐에 쌓인 각 결정 사항에는 원본 요청, 모델 응답, 신뢰도, 위험 수준, 컨텍스트, 타임스탬프 및 우선순위가 포함됩니다.

Review UI는 검토자에게 컨텍스트와 함께 모델의 결정 사항을 보여줍니다. 검토자는 이를 승인, 수정 또는 거부합니다. 좋은 UI는 신뢰도를 드러내고, 불확실한 영역을 강조하며, 대안을 제안합니다.

Action Executor는 승인된 작업을 실행합니다. 멱등성(Idempotent)을 유지해야 합니다. 즉, 동일한 ID로 중복 호출하더라도 작업이 반복되지 않아야 합니다.

Feedback Store는 학습을 위해 검토자의 결정 사항을 수집합니다. 구조화된 데이터로는 모델의 결정, 인간의 결정, 차이(delta), 수정 이유 등이 포함됩니다.

HITL 시스템 지표

모니터링을 위한 6가지 지표입니다.

**Escalation Rate (에스컬레이션 비율)**이 상승한다는 것은 모델의 성능이 저하되고 있거나 임계값(threshold)이 너무 엄격하다는 것을 의미합니다. 하락한다는 것은 모델이 개선되고 있거나 임계값이 너무 관대하다는 것을 의미합니다.

**Error Escape Rate (오류 유출률)**은 주요 안전 지표입니다. 이 비율이 상승하면 임계값을 재조정하거나 모델을 재학습시켜야 합니다.

**Reviewer Agreement (검토자 일치도)**가 85% 미만인 경우 두 가지 신호 중 하나를 나타냅니다: 모델의 성능이 낮거나(검토자가 빈번하게 수정함), 검토자들 간의 일관성이 부족함(검토자 보정 필요)입니다.

안티 패턴 (Anti-patterns)

보정 없는 임계값 설정.

신뢰도에 대한 맹신 (Blind trust in confidence). 모델은 높은 신뢰도로 환각 (hallucinate with high confidence)을 일으킵니다. GPT-4는 사실과 다른 답변에 대해서도 0.95의 수치를 출력합니다. 로그 확률 (logprobs)에서 나오는 신뢰도와 모델의 자기 평가 (self-assessment)를 통한 신뢰도는 서로 다른 것입니다. 로그 확률 (logprobs)은 답변의 정확성이 아니라 토큰 선택의 확실성을 반영합니다. 외부 보정 (External calibration)이 필요합니다.

모든 단계에서의 HITL. 사람이 모든 모델의 결정을 확인합니다. AI 시스템이 수동 작업을 위한 UI가 되어버립니다. 만약 검토자가 수정 없이 결정의 90%를 승인한다면, 임계값 (threshold)이 너무 엄격한 것입니다.

조치 없는 피드백. 검토자가 결정을 수정하고 데이터가 수집되지만, 모델은 개선되지 않습니다. 매달 다음을 수행해야 합니다: 일반적인 오류 유형 분석, 프롬프트 (prompts) 업데이트, 임계값 (thresholds) 재보정.

체크리스트: HITL 패턴 선택하기

적절한 패턴을 선택하기 위한 알고리즘입니다.

1. 해당 동작이 되돌릴 수 없는 것인가?
   예 -> 사전 동작 게이트 (Pre-action Gate, 패턴 1)
   아니오 -> 계속
...

요약

Human-in-the-loop는 성능이 낮은 모델을 위한 차선책이 아닙니다. 이는 AI가 자율적으로 작동하는 곳, 감독 하에 운영되는 곳, 그리고 사람에게 양보해야 하는 곳을 정의하는 아키텍처 패턴 (architectural pattern)입니다.