연재: AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스(Harness) 작성 입문

제15회: Human-in-the-loop는 어디에 넣어야 하는가

제1~14회: ✅ 공개 완료 ｜ 해당 기사: 📖 ｜ 다음 회: 제16회

AI 에이전트가 업무의 일부를 자동화한다는 말을 들었을 때, "정말로 전부 맡겨도 괜찮을까?"라고 느낀 분들이 많지 않을까요.

사실, 그 감각은 옳습니다. AI 에이전트는 만능이 아니며, 특히 업무상 크리티컬한 장면에서는 "인간이 확인·승인하는 포인트"를 마련하는 것이 필수적입니다. 이를 **Human-in-the-loop (HITL)**라고 부릅니다.

이번에는 하네스(Harness)에서의 HITL을 "어디에", "어떻게" 넣어야 하는지를 설계 관점에서 정리합니다.

Human-in-the-loop란, AI의 처리 플로우(Flow) 안에 "인간의 판단·승인"을 포함시키는 설계 패턴입니다.

AI가 모든 것을 자율적으로 실행하는 것이 아니라, 특정 타이밍에 인간에게 판단을 맡김으로써 안전성과 신뢰성을 확보합니다. 기존의 업무 시스템에서도 승인 플로우나 더블 체크(Double-check) 메커니즘이 있는데, 그것과 같은 개념입니다.

어느 레벨을 선택할지는 "그 조작의 영향도"와 "실패 시의 가역성"으로 판단할 수 있습니다.

"전부 인간이 확인하면 된다"라는 생각도 있지만, 그렇게 하면 AI 에이전트를 사용하는 의미가 퇴색됩니다. 그렇다고 전자동으로 두기에는 리스크가 남습니다.

따라서 중요한 것은, "어떤 처리에 승인을 넣을 것인가"에 대한 판단 기준을 갖는 것입니다.

영향 범위: 외부 시스템에 대한 쓰기, 메일 전송 등 "취소할 수 없는 조작"이 있는가 -
비용: 과금 API 호출 등 금전적인 영향이 있는가 -
보안: 기밀 정보나 개인 정보를 다루는가 -
가역성: 실패했을 때 원래대로 되돌릴 수 있는가 -

이러한 축에서 "높음"에 해당하는 처리가 있다면, 승인 포인트를 마련할 후보입니다.

하네스의 아키텍처(Architecture)를 되돌아보면, HITL을 배치하는 레이어(Layer)는 크게 3가지로 나뉩니다.

에이전트에게 태스크(Task)를 투입하기 전의 단계입니다. 여기서는 주로 "태스크 내용의 타당성 확인"을 수행합니다.

• 태스크가 허가된 범위 내에 있는지에 대한 유효성 검사 (Validation)
• 기밀 정보가 포함되어 있지 않은지에 대한 체크
• 리스크 레벨의 자동 판정

MCP 툴 호출 등, 실제로 외부 시스템을 조작하기 전의 단계입니다. 여기가 가장 중요한 승인 포인트가 됩니다.

• 툴의 파라미터 (Parameter) 확인 (무엇을 어디에 쓰는가)
• 비용 견적 확인 (API 호출 횟수, 과금 금액)
• 실행 계획 리뷰

에이전트의 처리가 완료된 후의 단계입니다.

• 출력 내용의 품질 확인
• 이상 감지 시의 에스컬레이션 (Escalation)
• 감사 로그의 기록

지금까지의 정리를 바탕으로, 하네스에서 사용할 수 있는 승인 포인트 목록을 작성했습니다.

HITL을 기능하게 하기 위해서는 "무슨 일이 일어났는가"를 추적할 수 있는 로그가 필수적입니다.

import logging
from datetime import datetime
def log_approval_event(task_id: str, action: str, decision: str, approver: str):
...

포인트는 다음과 같습니다.

타임스탬프 (Timestamp): 언제 승인 이벤트가 발생했는가 -
태스크 ID (Task ID): 어떤 태스크에 대한 승인인가 -
액션 (Action): 무엇을 하려고 했는가 -
판단 결과: 승인·거절·타임아웃 중 하나 -
승인자: 누가 판단했는가 -

승인 포인트를 너무 늘리면 "승인 피로 (Approval Fatigue)"가 발생합니다. 인간이 확인을 형식적으로 수행하여 "일단 OK"를 눌러버리는 상태입니다.

이를 방지하기 위한 판단 기준을 가지고 있도록 합시다.

• 리스크 기반으로 압축: 영향도가 낮은 처리는 자동 승인으로 설정
• 단계적 완화: 처음에는 엄격하게, 실적이 쌓이면 자동화율을 높임
• 컨텍스트(Context) 추가: 승인 알림에 "왜 승인이 필요한지"에 대한 설명을 첨부
• 타임아웃(Timeout) 설정: 일정 시간 응답이 없으면 안전한 쪽으로 기울어지도록 설정 (기본값 거부)

업무 시스템을 개발·운영해 온 SE(System Engineer)라면, HITL(Human-in-the-loop)의 사고방식은 익숙할 것입니다.

워크플로 엔진(Workflow Engine)의 승인 설계 → 에이전트의 승인 플로(Flow) 설계에 응용
장애 대응의 에스컬레이션(Escalation) 규칙 → 에러 발생 시 개입형 HITL에 응용
감사 로그(Audit Log) 설계 → HITL 이벤트의 로그 설계에 응용
테스트 설계 관점 → 승인 플로의 테스트 케이스 설계에 응용

AI 시대이기에 더욱, 이러한 "인간이 시스템을 제어하는" 설계 경험이 요구되고 있습니다.

실제로 하네스(Harness)에 HITL을組み込む(결합)하려면, 우선 자신의 하네스 처리 플로를 작성하고, 각 처리에 대해 위의 승인 포인트 목록을 채워보세요.

처음부터 완벽을 목표로 할 필요는 없습니다. "영향이 큰 처리"부터 승인형 HITL을 도입하고, 미세 조정해 나가는 것이 현실적인 접근 방식입니다.

• Human-in-the-loop는 "전자동"과 "전수동" 사이를 메우는 설계 패턴
• 승인 포인트는 "영향 범위", "비용", "보안", "가역성"의 4개 축으로 판단
• 입력·처리·출력의 3개 레이어(Layer)에서 HITL 배치 검토
• 승인 피로(Approval Fatigue)를 방지하기 위해, 리스크 기반으로 압축하고 단계적으로 완화
• SE의 업무 시스템 경험이 그대로 HITL 설계에 활용됨

제16회 "Slack 승인을 상정한 하네스 처리 플로 그리기"에서는, 이번에 정리한 승인 포인트를 실제 Slack 연동 플로에 적용합니다. Mermaid 시퀀스 다이어그램(Sequence Diagram)을 사용하여, 태스크 접수부터 승인·실행·결과 통지까지의 플로를 시각화합니다. "승인 포인트는 알겠는데, 구체적으로 어떻게 구현하는 거지?"라는 의문에 답하는 회차입니다.

📖 연재 목록: 제114회 ✅ 공개 완료 ｜ 제15회 (본 기사) ｜ 제16회 속권 예정