AI 의사결정에 대한 책임성 확보를 위한 Human-in-the-Loop HITL 설계

HITL이란 무엇인가요?

Human-in-the-loop(HITL)는 AI 에이전트가 특정 “툴(tool)”을 실행하기 전에 사람의 승인(Approve / Deny)을 반드시 거치도록 하는 통제 구조입니다.

즉,

AI가 혼자 마음대로 실행하지 못하게 하고
사람이 의사결정의 최종 관문(Gatekeeper) 역할을 하도록 만드는 방식입니다.

300x250

특히 n8n, AI Agent, MCP, Agentic Workflow 환경에서 AI가 아래와 같은 위험한 액션을 수행할 때 매우 중요합니다.

메시지 발송
데이터 수정 / 삭제
외부 시스템 연동
비용 발생 작업

왜 HITL이 필요한가? (배경 & 문제의식)

기존 AI 자동화의 구조적 한계

AI Agent는 기본적으로

컨텍스트 오해 가능
프롬프트 인젝션 영향
권한 범위 오판
비가역 작업(undo 불가) 실행 가능

👉 “잘못된 판단 × 자동 실행” = 사고

보안/거버넌스 관점에서의 요구

보안팀·감사·규제 관점에서는 다음 요구가 존재합니다.

누가 승인했는가?
언제 실행되었는가?
왜 실행되었는가?
AI가 거부되었을 때 어떻게 반응했는가?

👉 HITL은 AI 자동화에 ‘통제 가능성(Accountability)’을 부여합니다.

HITL 동작 원리 (Workflow 레벨)

전체 흐름

1️⃣ AI Agent가 “툴 사용 필요” 판단
2️⃣ 해당 툴이 Human Review Enabled 상태
3️⃣ 워크플로우 일시 중단(Pause)
4️⃣ 승인 요청 메시지 발송 (Slack, Chat 등)
5️⃣ 사람이 Approve / Deny 선택
6️⃣ 결과에 따라

✅ 승인 → 툴 실행
❌ 거부 → 실행 취소 + AI에게 거부 사실 전달

핵심 포인트

HITL은 툴 실행 단위에서 작동
AI의 “출력”이 아니라 “행동”을 통제
일반 Output Gating보다 훨씬 정밀한 제어

언제 HITL을 적용해야 하는가?

1. 비가역적 작업

데이터 삭제
레코드 수정
시스템 설정 변경

2. 외부 커뮤니케이션

Slack / Email / WhatsApp 발송
고객 메시지 전송
티켓 자동 생성

3. 컴플라이언스 환경

금융 / 의료 / 개인정보
내부 승인 프로세스 필수 조직

4. 고가치 의사결정

정책 변경
차단 / 허용 결정
장애 조치 실행

5. AI 신뢰도 검증 단계

초기 도입
PoC / Pilot
신규 모델 교체 직후

👉 처음엔 HITL을 넓게 적용 → 점진적으로 축소하는 전략이 이상적입니다.

승인 채널 구조 (Approval Channel)

메인 인터페이스와 승인 채널 분리 가능

예시

사용자 ↔ AI Agent : n8n Chat
승인자 ↔ Approval : Slack DM

👉 업무 분리 + 보안 분리 + 책임 분리 효과

지원 채널

채널	설명
Chat	n8n 내장 채팅
Slack	채널 또는 DM
Discord	서버/채널
Telegram	봇 기반
MS Teams	채널/채팅
Gmail / Outlook	이메일 승인
WhatsApp Business	메시지 승인
Google Chat	조직 채팅

설정 방법 (n8n 기준)

Step 1. Tools Panel 열기

AI Agent 노드 클릭
Tools Connector → Tools Panel 진입

Step 2. Human Review 추가

Human review 섹션 활성화
승인 채널 선택 (예: Slack)
인증 정보 설정

Step 3. 승인 대상 툴 연결

승인 필요한 툴만 Human Review에 연결
나머지 툴은 자동 실행 유지 가능

👉 툴별 세분화 제어 가능 (매우 중요)

$tool 변수 활용 (리뷰 메시지 설계 핵심)

$tool 변수란?

사람에게 보여줄 승인 메시지를 AI 행동 중심으로 투명하게 설명하는 변수입니다.

제공 정보

속성	의미
`$tool.name`	실행하려는 툴 이름
`$tool.parameters`	AI가 설정한 입력 파라미터

메시지 예시

AI가 다음 툴을 실행하려고 합니다.

툴 이름:
{{ $tool.name }}

입력 파라미터:
{{ JSON.stringify($tool.parameters, null, 2) }}

👉 승인자는 “무엇을, 어떻게” 실행하는지 정확히 확인 가능

$fromAI()와 HITL의 결합

핵심 개념

$fromAI() : 툴 파라미터를 AI가 동적으로 생성
HITL 환경에서도 그 값 그대로 사람에게 노출

👉 AI 결정 → 인간 승인 → 실행의 투명한 체인 완성

보안적으로 중요한 이유

AI가 의도치 않게
- 다른 사용자
- 다른 채널
- 다른 대상
  를 지정해도 사람이 최종 검증

System Prompt 설계 (절대 중요)

필수 이유

AI가

“거부되었을 때”
“재시도해야 할지”
“대안을 제시해야 할지”
를 명확히 이해하지 못하면 UX 붕괴 + 무한 루프 발생

System Prompt에 반드시 포함할 내용

1️⃣ 어떤 툴이 승인 대상인지
2️⃣ 승인 거부 시 실행되지 않는다는 사실
3️⃣ 거부 시 AI의 대응 방식

사용자 안내
대안 제시
추가 정보 요청

예시 문구

일부 툴은 실행 전 사람의 승인이 필요합니다.
승인이 거부되면 해당 작업은 실행되지 않으며,
사용자를 안내하고 대안을 제안하세요.

Chaining / Sub-Agent 환경에서도의 HITL

Agent → Agent 구조

상위 AI가 하위 AI를 “툴”처럼 호출해도
하위 AI의 HITL 승인 단계는 정상 작동

👉 복잡한 멀티 에이전트 환경에서도 통제 지점 유지 가능

보안 관점 가이드 & 점검 포인트

1. 승인 대상 툴 정의

외부 통신
데이터 변경
권한 영향

2. 승인자 지정

개인 DM vs 팀 채널
대체 승인자 존재 여부

3. 승인 로그 확보

누가
언제
어떤 파라미터로

4. 거부 시 AI 행동 정의

무응답 ❌
사용자 안내 ⭕
재요청 제한 ⭕

5. 최소 권한 원칙

승인 없는 툴은 Read-only 위주

실무 활용 시나리오 예시

보안 운영

AI가 “IP 차단” 제안 → SOC 승인 후 실행

고객 커뮤니케이션

AI 초안 생성 → 사람 승인 후 발송

IT 운영

AI 장애 조치 제안 → SRE 승인 후 적용

데이터 관리

AI 정리 작업 → 관리자 승인 후 삭제

핵심 요약

HITL은 AI 자동화의 브레이크
“AI 판단 + 인간 책임” 구조를 완성
보안·감사·신뢰 확보의 핵심 장치
Agentic AI 시대의 필수 설계 패턴

AI 승인 기준 자동 분류(위험도 기반)

“승인 여부”를 자동으로 결정하는 방법

HITL을 모든 툴에 걸면 안전하지만 운영이 느려집니다. 그래서 보통은

저위험(자동 실행)
중위험(조건부 승인)
고위험(항상 승인)
금지(항상 거부)

이 4단계를 기준으로 툴 호출 요청을 자동 분류합니다.

핵심은 “AI가 하려는 행동”을 아래 요소로 정량/정성 스코어링해서 승인 정책을 고르는 겁니다.

위험도 분류에 쓰는 대표 신호(Features)

액션의 비가역성(Irreversibility)

삭제/변경/배포/권한변경은 기본적으로 위험이 큼
“되돌릴 수 없음”이 가장 강한 승인 트리거

예)

delete_user, drop_table, revoke_access, push_firewall_rule

외부 커뮤니케이션(External Comms)

고객/외부 조직으로 나가는 메시지, 티켓, 이메일
유출/오발송/명예훼손/컴플라이언스 리스크

예)

send_email, post_slack_external_channel, create_jira_ticket_to_vendor

데이터 민감도(Data Sensitivity)

개인정보(PII), 결제/계약, 인증정보, 보안로그 원문
특히 “본문 포함 전송”이 위험

예)

“사용자 이메일 목록 + 메시지 발송”
“사고 로그 원문을 외부 웹훅으로 전송”

권한/범위(Blast Radius)

단일 사용자 vs 전체 조직
단일 리소스 vs 전체 계정/프로젝트

예)

disable_account(user=1명) vs disable_accounts(filter=전체)
rotate_keys(service=1개) vs rotate_keys(all_services=true)

비용/자원 영향(Cost & Operational Impact)

클라우드 리소스 생성, 대량 API 호출, 유료 액션
장애 유발 가능성

신뢰도(Confidence) 및 입력 출처(Input Origin)

사용자의 명시 지시인지?
외부 텍스트(웹/메일/티켓)에서 유입된 프롬프트인지? (프롬프트 인젝션 위험)
AI가 파라미터를 “추론”으로 채웠는지?

위험도 산정 방식 2가지

방식 A) 룰 기반(가장 안정적)

툴 이름 + 파라미터 패턴으로 분류합니다.
초기 운영에 가장 강력합니다.

예

삭제 계열 툴은 무조건 승인
외부 도메인으로 이메일 발송이면 무조건 승인
“대상 수 > 50”이면 승인

방식 B) 스코어링 기반(확장성)

위험 점수(risk_score)를 계산 후 임계치로 결정합니다.

예시 임계치

0–29: 자동 실행
30–69: 조건부 승인(특정 항목만 승인)
70–89: 항상 승인
90+: 금지(거부)

현장에서는 A(룰) + B(스코어) 혼합이 가장 좋습니다.
(룰이 “하드 가드레일”, 스코어가 “운영 최적화” 역할)

정책 예시(Policy-as-Code 스타일)

아래는 “정책 엔진(Policy Engine)”이 참고할 수 있는 형태의 예시입니다.

policies:
  - id: deny_exfil_secrets
    when:
      tool: send_webhook
      parameters:
        body_contains_regex: "(api_key|secret|authorization|bearer\\s+)"
    decision: DENY
    reason: "비밀정보 포함 가능성"

  - id: approval_for_irreversible
    when:
      tool_in: [delete_record, drop_table, revoke_access, push_firewall_rule]
    decision: REQUIRE_APPROVAL
    reason: "비가역 작업"

  - id: approval_for_external_email
    when:
      tool: send_email
      parameters:
        recipient_domain_not_in: ["pages.kr", "internal.example"]
    decision: REQUIRE_APPROVAL
    reason: "외부 발송"

  - id: auto_for_readonly
    when:
      tool_tag: READ_ONLY
    decision: AUTO_APPROVE
    reason: "조회 전용"

승인 요청 메시지(사람이 판단하기 쉽게)

승인 품질은 “승인 메시지 품질”이 좌우합니다. 아래 정보는 필수로 넣는 걸 추천합니다.

툴 이름 / 목적
변경 전/후(가능하면 diff)
대상 범위(몇 명/몇 건/어디에)
데이터 민감도 경고(PII, Secret 가능성)
롤백 가능 여부 / 롤백 방법
AI 근거(왜 이걸 하려는지)

예시 포맷

[승인 요청] 고위험 툴 실행

- Tool: {{ $tool.name }}
- Risk: 78 (ALWAYS_APPROVAL)
- Why: 비가역 변경 + 대상 120건

- Parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

- Rollback: 가능(이전 스냅샷 id=...)
- Notes: body에 이메일/토큰 패턴 일부 감지됨(검토 필요)

“조건부 승인”의 실전 패턴(중요)

승인을 YES/NO만 두지 말고, 제한 승인을 지원하면 운영이 좋아집니다.

예)

“대상 수 10명 이하로 줄이면 승인”
“외부 도메인 발송 금지, 내부만 허용”
“삭제 대신 비활성화로 변경하면 승인”

이때 AI에게는 “거부/제한 조건”을 명확히 반환해야 합니다.

MCP + HITL 결합 아키텍처

MCP 툴 호출을 “승인/정책/감사”가 있는 실행으로 바꾸기

MCP(Model Context Protocol)는 에이전트가 다양한 도구를 표준화된 방식으로 호출하게 해주지만,
보안 운영 관점에서는 다음이 필요합니다.

호출 전에 정책 검사
고위험이면 사람 승인
실행 후 감사 로그
파라미터/응답의 민감정보 마스킹
재현 가능성(누가 무엇을 했나)

그래서 MCP 환경에서는 보통 “Tool Gateway(중계 게이트웨이)” 패턴을 둡니다.

권장 아키텍처(표준 구성 요소)

LLM Agent

MCP client 역할
툴 호출 의사결정

MCP Tool Gateway (중계 서버)

모든 툴 호출이 여기로 모임
정책/승인/감사를 강제하는 핵심 컴포넌트

Policy Engine

위험도 분류, 금지/승인 필요 여부 판단
룰+스코어 혼합

Approval Service (HITL)

Slack/Chat/Teams 등으로 승인 요청
Approve/Deny 결과를 Gateway에 전달

Tool Executors

실제 실행 주체(사내 API, DB, Slack, 방화벽, 티켓, CI/CD 등)

Audit Log / Evidence Store

요청/승인/실행/결과/시간/승인자 저장(불변성 권장)

호출 플로우(단계별)

1. Agent → MCP로 tool call 생성
2. Tool Gateway 수신
3. Policy Engine이 위험도 판단

AUTO_APPROVE면 4로 직행
REQUIRE_APPROVAL이면 3.5로
DENY면 종료(거부 사유 반환)

3.5. Approval Service로 승인 요청 발송

승인 메시지에 툴/파라미터/위험도/근거 포함

4. 승인되면 Executor 호출
5. 결과 수신(성공/실패)
6. Audit log 저장(요청, 파라미터, 승인자, 결과, 타임스탬프)
7. Agent에 결과 반환

핵심 설계 포인트

“MCP Tool Gateway”를 반드시 중앙 통제 지점으로

에이전트가 Executor를 직접 치면 HITL이 무력화됩니다.
따라서 네트워크/권한을

Agent → Gateway만 가능
Gateway → Executors 가능
Agent → Executors 직접 접근 차단

으로 설계하는 게 정석입니다.

승인 채널은 “업무 채널”과 분리 권장

사용자 대화는 Chat
승인 요청은 Slack DM(승인자) 또는 승인 전용 채널

승인 로그는 “변조 방지”가 중요

감사/사고 대응용이면 아래를 추천합니다.

Append-only 저장소
해시 체인(선택)
외부 SIEM 연동(Wazuh/Elastic)

민감정보 마스킹(입력/출력)

Gateway 레벨에서 다음을 수행하세요.

Authorization 헤더 제거/마스킹
토큰/키/패스워드 정규식 탐지 후 마스킹
PII 필드(이메일/전화/주소) 정책에 따라 마스킹 또는 승인 강제

MCP 메시지 래핑 예시(개념적)

Gateway가 내부적으로 이런 형태로 “요청 객체”를 만들면 정책 판단과 로그가 쉬워집니다.

{
  "request_id": "req_20260208_001",
  "agent_id": "security-agent-01",
  "tool": {
    "name": "send_email",
    "parameters": {
      "to": "external@vendor.com",
      "subject": "Incident report",
      "body": "..."
    }
  },
  "context": {
    "user_intent": "벤더에게 사고 요약 공유",
    "source": "chat",
    "confidence": 0.62
  }
}

Policy Engine 출력 예시

{
  "decision": "REQUIRE_APPROVAL",
  "risk_score": 74,
  "reasons": ["외부 커뮤니케이션", "본문 민감정보 가능성"],
  "required_review_fields": ["to", "body"]
}

n8n을 Approval Service로 쓰는 결합 패턴

n8n은 승인 워크플로 구현에 매우 적합합니다.

패턴

Gateway가 “승인 요청 이벤트”를 n8n Webhook으로 보냄
n8n이 Slack/Teams로 승인 카드 전송
승인 결과(Approve/Deny)를 다시 Gateway로 Callback

필수 고려

승인 타임아웃(예: 10분) 처리
타임아웃이면 자동 Deny
중복 승인 방지(요청 ID idempotency)

운영 체크리스트

A. 위험도 기반 자동 분류 체크

비가역 툴 목록 정의
외부 커뮤니케이션 기준(도메인 allowlist)
대상 범위(레코드 수/유저 수) 임계치
민감정보 탐지(토큰/PII 정규식) → 승인/거부 연동
조건부 승인(제한 승인) 규칙

B. MCP + HITL 아키텍처 체크

Agent는 Executor 직접 접근 불가
Gateway에서 정책/승인/마스킹/감사 강제
승인 채널 분리 및 대체 승인자 존재
승인/실행 로그 불변성 확보
타임아웃/중복/재시도 설계

728x90

그리드형(광고전용)

AI 의사결정에 대한 책임성 확보를 위한 Human-in-the-Loop HITL 설계

AI 의사결정에 대한 책임성 확보를 위한 Human-in-the-Loop HITL 설계

HITL이란 무엇인가요?

왜 HITL이 필요한가? (배경 & 문제의식)

기존 AI 자동화의 구조적 한계

보안/거버넌스 관점에서의 요구

HITL 동작 원리 (Workflow 레벨)

전체 흐름

핵심 포인트

언제 HITL을 적용해야 하는가?

1. 비가역적 작업

2. 외부 커뮤니케이션

3. 컴플라이언스 환경

4. 고가치 의사결정

5. AI 신뢰도 검증 단계

승인 채널 구조 (Approval Channel)

메인 인터페이스와 승인 채널 분리 가능

지원 채널

설정 방법 (n8n 기준)

Step 1. Tools Panel 열기

Step 2. Human Review 추가

Step 3. 승인 대상 툴 연결

$tool 변수 활용 (리뷰 메시지 설계 핵심)

$tool 변수란?

제공 정보

메시지 예시

$fromAI()와 HITL의 결합

핵심 개념

보안적으로 중요한 이유

System Prompt 설계 (절대 중요)

필수 이유

System Prompt에 반드시 포함할 내용

예시 문구

Chaining / Sub-Agent 환경에서도의 HITL

Agent → Agent 구조

보안 관점 가이드 & 점검 포인트

1. 승인 대상 툴 정의

2. 승인자 지정

3. 승인 로그 확보

4. 거부 시 AI 행동 정의

5. 최소 권한 원칙

실무 활용 시나리오 예시

보안 운영

고객 커뮤니케이션

IT 운영

데이터 관리

핵심 요약

AI 승인 기준 자동 분류(위험도 기반)

“승인 여부”를 자동으로 결정하는 방법

위험도 분류에 쓰는 대표 신호(Features)

액션의 비가역성(Irreversibility)

외부 커뮤니케이션(External Comms)

데이터 민감도(Data Sensitivity)

권한/범위(Blast Radius)

비용/자원 영향(Cost & Operational Impact)

신뢰도(Confidence) 및 입력 출처(Input Origin)

위험도 산정 방식 2가지

방식 A) 룰 기반(가장 안정적)

방식 B) 스코어링 기반(확장성)

정책 예시(Policy-as-Code 스타일)

승인 요청 메시지(사람이 판단하기 쉽게)

“조건부 승인”의 실전 패턴(중요)

MCP + HITL 결합 아키텍처

MCP 툴 호출을 “승인/정책/감사”가 있는 실행으로 바꾸기

권장 아키텍처(표준 구성 요소)

호출 플로우(단계별)

핵심 설계 포인트

“MCP Tool Gateway”를 반드시 중앙 통제 지점으로

승인 채널은 “업무 채널”과 분리 권장

승인 로그는 “변조 방지”가 중요

민감정보 마스킹(입력/출력)

MCP 메시지 래핑 예시(개념적)

n8n을 Approval Service로 쓰는 결합 패턴

패턴

필수 고려

운영 체크리스트

A. 위험도 기반 자동 분류 체크

B. MCP + HITL 아키텍처 체크

관련글

댓글