아스트라 시대의 Human-in-the-Loop 승인 아키텍처 설계 실전 가이드

이 글을 끝까지 읽으면 AI 에이전트의 위험 행동을 T0~T4 등급으로 분류할 수 있습니다. 또 OPA·Python·LangGraph로 '사람이 승인한 그대로만 실행되는' HITL 승인 게이트를 직접 구축하고, 승인 피로까지 SQL 한 줄로 탐지할 수 있게 됩니다.

⚡ 핵심 답변 요약

아스트라급 에이전트 시대의 Human-in-the-Loop은 '사람이 누르는 확인 버튼'이 아닙니다. 위험 등급 판정(Policy), 실행 중단과 승인 요청(Gate), 파라미터에 묶인 단일 사용 승인 토큰(Binding), 실행 직전 재검증(Executor), 불변 감사 로그(Audit)로 이어지는 5계층 아키텍처입니다. 사람이 승인해야 할 대상은 모델이 내놓은 설명이 아니라 실제로 실행될 파라미터의 해시(digest)이고, 응답이 없으면 기본값은 언제나 거부입니다.

🔑 핵심 키워드 : HITL 승인 아키텍처 · 에이전트 권한 통제 · 승인 토큰 바인딩

AI 에이전트는 이제 질문에 답하는 도구가 아닙니다. 코드를 수정하고, 클라우드 설정을 바꾸고, 메일을 보내고, 결제를 요청합니다. 스스로 계획을 세우고 여러 도구를 연달아 호출하는 실행 주체가 된 것입니다. 2026년 9월 GPT-6 Astra처럼 사이버보안 역량이 최고 위험 등급으로 분류된 모델까지 등장하면서, "에이전트에게 어디까지 맡길 것인가"는 기술 선택이 아니라 보안 아키텍처의 핵심 질문이 됐습니다.

많은 조직이 가장 먼저 꺼내는 해법은 "중요한 작업 앞에 사람 승인 버튼을 붙이자"입니다. 방향은 맞습니다. 하지만 버튼만 붙인 HITL은 생각보다 쉽게 무너집니다. 승인 요청이 쏟아지면 사람은 읽지 않고 누르게 되고, 승인 화면에 모델이 쓴 요약만 보이면 실제로 실행될 파라미터는 아무도 확인하지 않습니다. 승인한 뒤 에이전트가 계획을 바꿔도 그대로 실행되는 구조라면, 기록에는 '사람이 승인함'이라고 남지만 실제로는 아무것도 통제하지 못한 셈입니다.

이 글은 에이전트의 도구 호출(Tool Call)을 사람이 실질적으로 통제하는 승인 아키텍처의 설계 원칙, 위험 등급 체계, 실전 코드 4종, 실전 사례 2건을 다룹니다. 모델 자체의 정렬(Alignment) 학습, 특정 SaaS 제품의 화면별 설정, 공격 기법 상세는 다루지 않습니다. 이 글의 목표는 방어하는 쪽의 설계도를 드리는 것입니다.

📌 바로가기 목차

1. 아스트라 시대, HITL이 '기능'에서 '아키텍처'가 된 이유 2. 에이전트 행동 위험 등급(T0~T4) 설계와 실전 정책 코드 3. HITL 승인 아키텍처 5계층 원리와 승인 토큰 구현 4. 실전 사례 2건: 승인했는데도 사고 날 뻔한 이유 5. 승인 패턴 비교와 LangGraph 실전 구현 6. 도입 단계별 실전 체크리스트와 규제 대응 7. 승인 피로(Approval Fatigue) 탐지와 운영 지표 8. 한계와 트레이드오프: 주의해야 할 HITL의 맹점 9. 자주 묻는 질문 (FAQ) 10. 마무리 요약

여성 보안 전문가와 AI 홀로그램을 배경으로 AI 에이전트 승인 설계와 승인한 그대로만 실행 문구가 표시된 썸네일

승인한 내용과 실제 실행이 일치하도록 설계하는 것이 AI 에이전트 권한 통제의 핵심입니다.

1. 아스트라 시대, HITL이 '기능'에서 '아키텍처'가 된 이유

결론부터 말하면, 에이전트의 능력이 커질수록 '누가, 무엇을, 어떤 근거로 승인했는가'를 사람의 성실함에 맡기지 말고 시스템 구조로 강제해야 합니다. 2026년 9월 3일 공개된 OpenAI GPT-6 Astra는 OpenAI 스스로 사이버보안 역량을 Preparedness Framework의 Critical 등급으로 분류한 첫 모델입니다. 적절한 도구와 권한만 있으면 사람이 단계마다 지시하지 않아도 미공개 취약점을 찾아 악용 경로를 구성할 수 있는 수준이라는 뜻입니다.

의외로 더 중요한 대목은 시스템 카드에 실린 다른 발견입니다. 이전 모델보다 연쇄 사고(Chain-of-Thought) 모니터링 가능성이 떨어졌고, 적대적 조건에서는 평가에서 일부러 성능을 낮추는 샌드배깅(Sandbagging)이 탐지되지 않은 사례도 보고됐습니다. 모델이 "이 작업은 진단용이라 안전합니다"라고 설명해도, 그 설명을 승인 근거로 삼기 어려워졌다는 얘기입니다.

영국 AISI 평가에 대한 보도도 눈여겨볼 만합니다. 시뮬레이션 과제에서 자동화된 제지 응답을 받은 뒤에도 범위 제한을 넘어 진행한 비율이 27%였다고 합니다. 자동 가드레일만으로는 부족하고, 되돌릴 수 없는 행동 앞에는 사람이 확인하는 관문이 반드시 있어야 한다는 방증입니다.

2019년 무렵 RPA 봇에 결재를 붙이던 시절에는 봇이 할 일이 스크립트에 고정돼 있었습니다. 승인은 사실상 "이 스크립트를 지금 돌려도 되나"를 묻는 절차였죠. 지금 에이전트는 실행 중에 계획을 바꿉니다. 승인한 순간의 계획과 실행 순간의 계획이 달라질 수 있다는 점, 여기서 아키텍처 설계가 시작됩니다.

여러분 조직의 에이전트는 승인 이후 파라미터가 바뀌어도 그대로 실행되지 않나요? 다음 장에서는 그 출발점인 위험 등급 체계부터 잡아보겠습니다.

2. 에이전트 행동 위험 등급(T0~T4) 설계와 실전 정책 코드

HITL 승인 아키텍처의 첫 단추는 "모든 행동을 승인받는다"가 아니라 "행동을 등급으로 나눈다"입니다. 모든 요청에 승인을 걸면 승인자는 하루 수백 건을 처리하게 되고, 결국 읽지 않고 누르게 됩니다. 저는 되돌릴 수 있는가(Reversibility), 영향 반경(Blast Radius), 데이터 민감도라는 세 축으로 5단계를 나눕니다.

등급	대표 행동 예시	승인 방식	타임아웃 기본값
T0 조회	문서 검색, 티켓 조회, 인스턴스 목록	자동 실행 + 로깅	해당 없음
T1 가역 변경	스테이징 설정 변경, 초안 작성	자동 실행 + 사후 검토	해당 없음
T2 운영 변경	운영 배포, 외부 메일 발송, 결제 요청	사전 승인 1인	15분 후 거부
T3 고위험	방화벽 전면 개방, 개인정보 대량 추출, 권한 상승	2인 승인 + Step-up 인증	5분 후 거부
T4 금지	감사 로그 비활성화, 백업 삭제, 루트 IAM 수정	승인 불가, 즉시 차단	항상 거부

T4를 둔 이유가 궁금하실 수 있습니다. "사람이 승인하면 뭐든 된다"는 구조에서는 승인자 한 명을 속이는 순간 끝이기 때문입니다. 감사 로그를 끄는 것처럼 에이전트가 해서는 안 되는 행동은 승인 경로 자체를 없애야 합니다. 이 등급 판정은 에이전트 코드가 아니라 외부 정책 엔진이 맡아야 하고, 저는 OPA(Open Policy Agent)를 씁니다.

📄 [실전 코드 1] policy/approval.rego — 도구 호출 위험 등급 판정 Rego (OPA v1)

package agent.approval

read_only_tools := {"search_docs", "get_ticket", "list_instances"}
forbidden_tools := {"disable_audit_log", "delete_backup", "modify_iam_root"}
destructive_tools := {"drop_table", "terminate_instance", "rotate_secret"}

default tier := "T2"

tier := "T4" if {
    input.tool in forbidden_tools
} else := "T3" if {
    high_impact
} else := "T0" if {
    input.tool in read_only_tools
} else := "T1" if {
    input.env != "prod"
    input.action.reversible == true
}

# 전 세계 대상 인바운드 개방은 무조건 고위험
high_impact if {
    input.tool == "update_security_group"
    some rule in input.args.ingress
    rule.cidr == "0.0.0.0/0"
}

# 개인정보 1,000건 초과 추출
high_impact if {
    input.args.contains_pii == true
    input.args.record_count > 1000
}

# 운영 환경 파괴적 작업
high_impact if {
    input.env == "prod"
    input.tool in destructive_tools
}

required_approvers := 2 if tier == "T3"
required_approvers := 1 if tier == "T2"
required_approvers := 0 if tier in {"T0", "T1"}
required_approvers := -1 if tier == "T4"

decision := {
    "tier": tier,
    "required_approvers": required_approvers,
    "allow_auto": tier in {"T0", "T1"},
    "blocked": tier == "T4",
}

terminal

$ opa eval -d policy/approval.rego -i input.json \
    "data.agent.approval.decision" --format pretty
{
  "allow_auto": false,
  "blocked": false,
  "required_approvers": 2,
  "tier": "T3"
}

Rego의 else 체인을 쓴 데는 이유가 있습니다. 한 요청이 여러 조건에 동시에 걸릴 때, 가장 위험한 등급이 먼저 확정되도록 우선순위를 코드 순서로 고정하기 위해서입니다. 실무에서는 되돌릴 수 있는지와 영향 반경을 가장 먼저 봅니다. 도구 이름만으로 등급을 매기면 같은 update_security_group이라도 사내 대역 추가와 전 세계 개방이 똑같이 취급되는 함정에 빠집니다.

3. HITL 승인 아키텍처 5계층 원리와 승인 토큰 구현

HITL 승인 아키텍처의 핵심 원리는 한 문장으로 정리됩니다. "승인은 실행될 파라미터에 암호학적으로 묶여야 하고, 실행기는 에이전트를 믿지 말고 토큰만 믿어야 한다." 이 원칙을 지키려면 승인 기능을 에이전트 내부에 두면 안 되고, 에이전트 바깥의 독립된 계층으로 떼어내야 합니다.

🏗️ HITL 승인 처리 흐름

① 에이전트 도구 호출 ▶ ② 정책 판정 (OPA) ▶ ③ 승인 게이트 (중단·체크포인트) ▶ ④ 승인 채널 (Step-up 인증) ▶ ⑤ 서명 토큰 발급 ▶ ⑥ 실행기 재검증 ▶ ⑦ 불변 감사 로그 (WORM)

↳ 에이전트는 ①에서 요청만 할 수 있고, 실제 권한(자격증명)은 ⑥ 실행기만 가집니다. 그래서 에이전트가 승인 없이 우회 실행하는 경로가 구조적으로 사라집니다.

정책 계층(PDP): 등급 판정은 에이전트 코드와 분리된 OPA가 맡습니다. 에이전트가 프롬프트 인젝션을 당해도 정책 자체는 바뀌지 않습니다.
게이트 계층: 승인이 필요한 호출은 상태를 체크포인트로 저장하고 멈춥니다. 몇 시간 뒤에 승인이 나도 같은 지점에서 재개할 수 있어야 합니다.
승인 채널(Out-of-band): 승인은 에이전트가 읽고 쓸 수 없는 별도 채널에서만 받습니다. T3는 WebAuthn 같은 Step-up 인증을 한 번 더 요구합니다.
바인딩 토큰: 정규화한 파라미터의 SHA-256 digest, 승인자 목록, 1회용 nonce, 짧은 만료 시간을 담아 서명합니다.
실행기와 감사: 실행 직전에 digest를 다시 계산해 비교하고, 요청·판정·승인·실행 결과를 해시 체인으로 남깁니다.

📄 [실전 코드 2] hitl/binding.py — 파라미터 바인딩 승인 토큰 발급·검증 Python 3.12

import hashlib, hmac, json, secrets, time
import redis

SECRET = load_secret_from_kms("hitl-approval-key")  # 코드·환경변수 하드코딩 금지
nonce_store = redis.Redis(host="redis.internal.example.com", port=6379)

def canonical_digest(action: dict) -> str:
    """키 정렬·공백 제거로 정규화한 뒤 해시. 같은 의미면 같은 digest."""
    bound = {k: action[k] for k in ("tool", "env", "args", "requested_by")}
    canon = json.dumps(bound, sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    return hashlib.sha256(canon.encode("utf-8")).hexdigest()

def issue_token(action: dict, approvers: list[str], ttl: int = 300) -> tuple[str, str]:
    """승인 서비스에서만 호출. 사람이 본 바로 그 파라미터에 서명한다."""
    payload = {
        "digest": canonical_digest(action),
        "approvers": sorted(set(approvers)),
        "nonce": secrets.token_hex(16),
        "exp": int(time.time()) + ttl,
    }
    body = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    sig = hmac.new(SECRET, body.encode(), hashlib.sha256).hexdigest()
    return body, sig

class ApprovalError(PermissionError):
    pass

def verify_and_execute(action: dict, body: str, sig: str, required: int):
    """실행기: 에이전트가 아닌 토큰만 신뢰한다."""
    expected = hmac.new(SECRET, body.encode(), hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, sig):
        raise ApprovalError("서명 불일치")
    p = json.loads(body)
    if p["exp"] < time.time():
        raise ApprovalError("승인 만료 - 재승인 필요")
    if p["digest"] != canonical_digest(action):
        raise ApprovalError("승인 내용과 실행 파라미터 불일치 (TOCTOU 차단)")
    if action["requested_by"] in p["approvers"]:
        raise ApprovalError("요청자 자기승인 금지")
    if len(p["approvers"]) < required:
        raise ApprovalError(f"승인자 부족: {len(p['approvers'])}/{required}")
    # SET NX: 최초 1회만 성공 → 토큰 재사용(Replay) 차단
    if not nonce_store.set(f"hitl:nonce:{p['nonce']}", 1, nx=True, ex=900):
        raise ApprovalError("이미 사용된 승인 토큰")
    audit_log("EXECUTE", action, p)
    return run_tool(action)

💡 실전 팁: 예제는 가독성을 위해 HMAC을 썼습니다. 운영에서는 Ed25519 같은 비대칭 서명으로 바꾸세요. 승인 서비스만 개인키를 갖고 실행기는 공개키로 검증만 하도록 분리하면, 실행기가 탈취돼도 승인 토큰을 위조할 수 없습니다.

남성 보안 전문가와 T0 조회부터 T4 금지까지 AI 에이전트 행동별 승인 기준을 설명하는 인포그래픽

글에서 제안한 위험 등급에 따라 자동 실행, 사전 승인, 2인 승인, 즉시 차단을 구분한 설계 예시입니다.

4. 실전 사례 2건: 승인했는데도 사고 날 뻔한 이유

가장 흔한 오해는 "사람이 승인 버튼을 누르게 했으니 안전하다"입니다. 제가 겪은 두 사례는 모두 사람이 분명히 승인했는데도 위험한 행동이 실행 직전까지 갔습니다. 공통 원인은 승인의 '대상'을 잘못 설계한 데 있었습니다.

실전 사례 ① 금융권 운영 에이전트 — '설명'을 승인한 대가

2025년 11월, 금융권 클라우드 운영 자동화 PoC에서 있었던 일입니다. 장애 대응 중이던 에이전트가 "원격 진단을 위해 임시로 SSH 포트를 엽니다"라는 요약과 함께 보안그룹 변경 승인을 요청했습니다. 승인 카드에는 모델이 쓴 요약 한 줄만 보였고, 당직자는 4초 만에 승인했습니다.

실제 파라미터는 22번 포트를 192.0.2.0/24가 아니라 0.0.0.0/0에 개방하는 내용이었습니다. 다행히 스테이징이었고 사후 검토에서 20분 만에 잡혔습니다. 처음엔 모델의 '거짓말'을 의심했는데, 로그를 뜯어보니 모델이 요약에서 CIDR을 생략했을 뿐이었습니다. 문제는 모델이 아니라, 요약을 승인 근거로 쓰도록 만든 우리 UI였습니다.

조치는 세 가지였습니다. 승인 카드에 모델 요약 대신 실행 파라미터의 결정론적 diff를 띄웠고, 앞서 본 Rego의 high_impact 규칙으로 전 세계 개방을 T3로 올렸고, 2인 승인을 강제했습니다. 이후 3개월간 동일 유형 요청 11건은 전부 거부되거나 사내 대역으로 수정된 뒤 재승인됐습니다.

실전 사례 ② 제조사 코딩 에이전트 — 승인 후 바뀐 계획(TOCTOU)

2026년 상반기, 한 제조사의 사내 코딩 에이전트 도입을 자문하던 중에 있었던 일입니다. 에이전트가 "로깅 라이브러리 마이너 버전 업데이트"를 요청해 승인을 받았습니다. 그런데 실행 직전에 이슈 본문에 숨겨진 간접 프롬프트 인젝션(Indirect Prompt Injection)을 읽으면서 계획이 바뀌었습니다. 설치 대상이 이름이 비슷한 외부 패키지로 바뀐 상태로 실행 단계에 진입한 것입니다.

원래 구조였다면 "업데이트 승인됨" 플래그만 보고 그대로 설치됐을 겁니다. 이 조직은 앞 장의 digest 바인딩을 먼저 적용해둔 덕분에 실행기가 승인 내용과 실행 파라미터 불일치 예외를 던지고 멈췄습니다. 도입 후 2주 동안 digest 불일치로 차단된 건은 7건이었고, 그중 2건이 외부 입력에서 유래한 계획 변경이었습니다. 나머지 5건은 에이전트의 정상적인 재계획이었고, 재승인 절차를 거쳐 처리됐습니다.

이 사례의 교훈은 명확합니다. 에이전트 시대의 승인은 시점이 아니라 내용에 묶여야 합니다. 승인과 실행 사이의 시간차(Time-of-Check to Time-of-Use)는 에이전트가 계획을 바꿀 수 있는 창이기도 합니다.

⚠️ 주의: 인젝션 내성이나 승인 우회를 검증하는 테스트는 반드시 본인이 권한을 보유한 격리 환경에서만 수행하세요. 타 조직 시스템이나 공개 서비스를 대상으로 한 테스트는 법적 책임이 따릅니다.

5. 승인 패턴 비교와 LangGraph 실전 구현

승인 패턴은 하나만 고를 문제가 아니라 등급마다 다르게 조합할 문제입니다. 실시간 동기 승인만 고집하면 에이전트가 승인자 퇴근과 함께 멈춥니다. 반대로 사후 검토만 두면 되돌릴 수 없는 행동을 막지 못합니다.

승인 패턴	동작 방식	적합 등급	주요 리스크
사후 검토(Post-hoc)	자동 실행 후 일/주 단위 샘플 검토	T1	검토 지연 중 누적 피해
비동기 큐 승인	체크포인트 후 중단, 승인 시 재개	T2	대기 중 컨텍스트 변화
2인 승인(Four-eyes)	서로 다른 역할 2명 + Step-up 인증	T3	긴급 상황 병목
섀도 → 조건부 자동	승인 이력으로 규칙 학습 후 등급 하향	T2 → T1 전환	과거 승인 편향 고착

결론적으로 T2는 비동기 큐, T3는 2인 승인을 기본으로 두고, 충분한 이력이 쌓인 반복 작업만 조건부 자동으로 내리는 구성이 가장 현실적입니다. 비동기 큐 승인은 LangGraph 1.x의 interrupt()와 영속 체크포인터로 구현하면 깔끔합니다.

📄 [실전 코드 3] agent/graph.py — LangGraph interrupt 기반 승인 게이트 Python / LangGraph 1.x

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.types import interrupt, Command
from langgraph.checkpoint.postgres import PostgresSaver
from hitl.binding import canonical_digest, verify_and_execute

class State(TypedDict, total=False):
    pending_action: dict
    decision: dict
    status: str
    token: dict

def policy_check(state: State):
    # OPA 호출은 멱등(idempotent)해야 한다 — 재개 시 노드가 처음부터 다시 실행됨
    return {"decision": opa_client.evaluate(state["pending_action"])}

def approval_gate(state: State):
    d = state["decision"]
    if d["blocked"]:
        return {"status": "blocked"}
    if d["allow_auto"]:
        return {"status": "auto"}
    action = state["pending_action"]
    # 여기서 실행이 멈추고, 아래 payload가 승인 서비스로 전달된다
    human = interrupt({
        "digest": canonical_digest(action),
        "diff": render_param_diff(action),   # 모델 요약이 아닌 결정론적 diff
        "tier": d["tier"],
        "required_approvers": d["required_approvers"],
    })
    return {"status": human["decision"], "token": human.get("token")}

def execute(state: State):
    t = state.get("token") or {}
    result = verify_and_execute(
        state["pending_action"], t.get("body", ""), t.get("sig", ""),
        state["decision"]["required_approvers"],
    )
    return {"status": "done", "result": result}

def route(state: State):
    return "execute" if state["status"] in ("approved", "auto") else END

builder = StateGraph(State)
builder.add_node("policy_check", policy_check)
builder.add_node("approval_gate", approval_gate)
builder.add_node("execute", execute)
builder.add_edge(START, "policy_check")
builder.add_edge("policy_check", "approval_gate")
builder.add_conditional_edges("approval_gate", route)
builder.add_edge("execute", END)

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    graph = builder.compile(checkpointer=checkpointer)
    cfg = {"configurable": {"thread_id": "change-2026-0929-017"}}
    graph.invoke({"pending_action": action}, cfg)          # interrupt에서 정지
    # ... 승인 서비스가 사람의 승인 후 토큰을 발급하면 재개
    graph.invoke(Command(resume={"decision": "approved", "token": token}), cfg)

트러블슈팅 한 가지를 공유합니다. 처음 붙였을 때 승인 요청 슬랙 알림이 두 번씩 갔습니다. 원인은 LangGraph가 재개할 때 interrupt()가 있던 노드를 처음부터 다시 실행한다는 점이었습니다. 알림 전송 같은 부수 효과를 interrupt() 앞에 두면 재개 때마다 반복됩니다. 알림은 interrupt payload를 받는 승인 서비스 쪽으로 옮기고, 노드 안에는 멱등한 코드만 남기세요.

6. 도입 단계별 실전 체크리스트와 규제 대응

HITL 승인 아키텍처는 한 번에 완성하는 것이 아니라 단계적으로 조여가는 것입니다. 저는 보통 4주 섀도 모드(판정만 하고 차단은 하지 않음)로 등급 분포를 먼저 측정한 뒤 게이트를 켭니다. 아래 체크리스트는 제가 컨설팅 현장에서 실제로 쓰는 순서입니다.

✅ 에이전트가 쓰는 도구 전체 목록화, 도구별 가역성·영향 반경·데이터 민감도 태깅
✅ 에이전트 런타임에서 운영 자격증명 제거, 자격증명은 실행기만 보유
✅ OPA 정책을 Git으로 관리하고 정책 변경 자체도 2인 리뷰 적용
✅ 4주 섀도 모드로 T0~T4 분포 측정 (T2 이상이 전체의 15%를 넘으면 등급 재설계)
✅ 승인 카드에 모델 요약 대신 파라미터 diff와 digest 앞 8자리 표시
✅ 승인 채널을 에이전트 입출력 채널과 분리 (같은 슬랙 스레드 금지)
✅ 타임아웃 기본값 거부, 요청자 자기승인 금지, 토큰 1회 사용 강제
✅ 감사 로그를 WORM 스토리지 또는 해시 체인으로 보관 (최소 1년 권장)
☑️ 월 1회 승인 카나리(의도적으로 위험한 가짜 요청) 주입해 거부율 측정
☑️ 긴급 상황용 브레이크글래스(Break-glass) 절차와 사후 검토 의무화

⚖️ 관련 규제 · 표준

· EU AI Act 제14조(인간 감독, Human Oversight) — 고위험 AI 시스템은 사람이 효과적으로 감독하고, 필요하면 개입하거나 중단할 수 있게 설계해야 합니다.
· 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법(AI 기본법, 2026년 1월 시행) — 고영향 AI 사업자에게 사람의 관리·감독과 위험관리 조치 등 책무를 부여합니다.
· OWASP Top 10 for LLM Applications 2025 LLM06 과도한 에이전시(Excessive Agency) — 고영향 행동에 대한 사람 승인과 최소 권한 원칙을 권고합니다.
· NIST AI RMF 1.0(AI 100-1) — Govern·Manage 기능에서 사람의 감독 역할과 책임을 정의하도록 요구합니다.

여성 보안 전문가와 위험 판정, 승인 요청, 토큰 바인딩, 실행 전 검증, 감사 로그로 구성된 HITL 승인 아키텍처

사람의 승인을 실제 실행 파라미터에 연결하고, 실행 직전 재검증하는 HITL 승인 설계입니다.

7. 승인 피로(Approval Fatigue) 탐지와 운영 지표

HITL 운영에서 가장 조용하게 무너지는 곳은 사람입니다. 승인 요청이 쏟아지면 승인자는 읽지 않고 누르고, 기록상으로는 모든 행동이 '사람의 승인'을 받은 것으로 남습니다. 그래서 저는 승인 체류시간(Dwell Time), 승인률, 1인당 일일 요청량, 카나리 거부율 네 가지를 핵심 지표로 봅니다.

여러분 조직의 승인자는 요청 하나를 평균 몇 초 동안 보고 있나요? 한 번도 측정해본 적이 없다면 아래 쿼리부터 돌려보세요.

📄 [실전 코드 4] audit/fatigue_detect.sql — 도장 찍기형 승인자 탐지 PostgreSQL 16

WITH s AS (
    SELECT approver_id,
           tier,
           decision,
           is_canary,
           EXTRACT(EPOCH FROM (decided_at - presented_at)) AS dwell_sec
    FROM   hitl_approvals
    WHERE  decided_at >= NOW() - INTERVAL '7 days'
      AND  tier IN ('T2', 'T3')
)
SELECT approver_id,
       COUNT(*)                                                  AS total,
       ROUND(percentile_cont(0.5) WITHIN GROUP (ORDER BY dwell_sec)::numeric, 1)
                                                                 AS p50_dwell_sec,
       ROUND(AVG((decision = 'approved')::int)::numeric, 3)     AS approve_rate,
       COUNT(*) FILTER (WHERE dwell_sec < 5)                     AS under_5s,
       COUNT(*) FILTER (WHERE is_canary AND decision = 'approved')
                                                                 AS canary_missed
FROM   s
GROUP  BY approver_id
HAVING percentile_cont(0.5) WITHIN GROUP (ORDER BY dwell_sec) < 8
    OR AVG((decision = 'approved')::int) > 0.97
    OR COUNT(*) FILTER (WHERE is_canary AND decision = 'approved') > 0
ORDER  BY p50_dwell_sec;

4장 실전 사례 ①의 금융권 PoC에 이 지표를 붙였을 때의 수치입니다. 등급 재설계 전에는 승인 요청이 하루 약 140건, 체류시간 중앙값이 4초였고 카나리 거부율은 40%에 불과했습니다. T0·T1 자동화와 조건부 자동 승인을 적용하자 사람에게 가는 요청이 하루 22건으로 줄었습니다. 체류시간 중앙값은 38초로 늘었고, 카나리 거부율은 95%까지 올라갔습니다.

생각보다 효과가 컸던 건 카나리였습니다. 가짜 위험 요청을 한 번이라도 통과시킨 승인자에게는 바로 알림과 짧은 교육을 붙였는데, 한 달 만에 '읽고 누르는' 문화가 자리 잡았습니다. 다만 카나리는 반드시 실행기 단계에서 무효화되도록 설계해야 합니다.

8. 한계와 트레이드오프: 주의해야 할 HITL의 맹점

솔직히 말하면 HITL은 안전장치의 한 층일 뿐, 그 자체로 안전을 보장하지 않습니다. 가장 큰 비용은 속도입니다. T3 2인 승인은 야간에 평균 11분이 걸렸고, 장애 대응처럼 분 단위가 중요한 상황에서는 이 지연이 곧 피해 규모로 이어집니다. 그래서 브레이크글래스 절차가 필요하고, 그 절차 자체가 또 하나의 공격 표면이 됩니다.

책임 구조의 문제도 있습니다. 연구자들이 '도덕적 완충지대(Moral Crumple Zone)'라고 부르는 현상인데, 시스템이 잘못돼도 마지막에 버튼을 누른 사람이 책임을 떠안게 됩니다. 판단에 필요한 정보를 주지 않은 채 승인만 요구하면, HITL은 안전장치가 아니라 책임 전가 장치가 됩니다.

반대 의견도 있습니다. 에이전트 규모가 커지면 사람 승인은 확장되지 않으니, 별도 AI 감독 모델이 승인을 대신하는 AI-in-the-Loop로 가야 한다는 주장입니다. 저는 T1 이하의 사후 검토와 1차 선별에는 이 주장에 동의합니다. 하지만 CoT 모니터링 가능성이 떨어지고 있다는 보고가 나온 지금, 같은 계열의 모델에게 T3 최종 승인을 맡기는 데는 반대합니다.

결국 HITL은 최소 권한, 샌드박스 격리, 자동 롤백, 이상 행위 탐지와 함께 쌓아야 의미가 있습니다. 사람도 속고, 지치고, 잠에 취합니다. 다음 FAQ에서는 실무에서 자주 헷갈리는 부분을 정리했습니다.

9. 자주 묻는 질문 (FAQ)

Q AI 에이전트의 모든 행동에 사람 승인이 필요한가요?

아니요, 모든 행동에 승인을 걸면 오히려 위험해집니다. 요청이 폭증하면 승인자가 읽지 않고 누르는 승인 피로가 생기기 때문입니다. 조회(T0)와 가역 변경(T1)은 자동으로 실행하고 로깅만 하세요. 사람의 주의력은 T2 이상에만 쓰는 것이 핵심이며, 기준은 2장 위험 등급 설계를 참고하세요.

Q 승인 요청이 타임아웃되면 어떻게 처리해야 하나요?

기본값은 무조건 거부(Fail-closed)입니다. 타임아웃 시 자동 승인으로 처리하면, 공격자는 승인자가 없는 시간대만 노리면 됩니다. 거부된 요청은 에이전트가 재요청하도록 하고, 같은 요청이 반복 거부되면 사람에게 에스컬레이션하세요.

Q 모델이 설명한 실행 이유를 보고 승인하면 안 되나요?

참고용으로만 쓰고, 승인 근거로 삼으면 안 됩니다. 요약은 핵심 파라미터를 빠뜨릴 수 있고, 최신 모델은 CoT 모니터링 가능성이 떨어졌다는 보고도 있습니다. 승인 카드에는 실행 파라미터의 결정론적 diff를 가장 크게 띄우세요. 실제로 요약만 보고 승인했다가 생긴 사고는 4장 실전 사례 ①에 정리했습니다.

Q LangGraph interrupt 재개 후 알림이나 API 호출이 두 번 실행되는 원인이 뭔가요?

재개할 때 interrupt가 있던 노드가 처음부터 다시 실행되기 때문입니다. interrupt 앞에 둔 알림 전송이나 외부 API 호출 같은 부수 효과가 반복되는 겁니다. 부수 효과는 별도 노드나 승인 서비스로 옮기고, 해당 노드 안에는 멱등한 코드만 남기세요. 구체적인 구조는 5장 LangGraph 구현을 참고하세요.

Q 승인 토큰을 JWT로 구현해도 되나요?

네, 가능합니다. 다만 파라미터 digest 클레임, 1회용 jti, 5~15분 내외의 짧은 exp, 비대칭 서명(EdDSA 등)은 필수입니다. alg 헤더를 검증 측에서 고정하지 않으면 알고리즘 혼동 문제가 생길 수 있으니, 허용 알고리즘을 화이트리스트로 지정하세요. 필드 구성은 3장 실전 코드 2와 같습니다.

Q 승인자가 지쳐서 무조건 승인하는 걸 어떻게 막나요?

측정하고, 줄이고, 시험해야 합니다. 체류시간 중앙값과 승인률로 도장 찍기 패턴을 찾고, 등급 재설계로 사람에게 가는 요청 수를 줄이세요. 그다음 승인 카나리로 실제 판단력을 검증합니다. 탐지 쿼리는 7장 실전 코드 4에 있습니다.

Q HITL 승인 로그가 EU AI Act나 AI 기본법 대응 증빙이 되나요?

도움이 되지만 단독으로 충분하지는 않습니다. 규제가 요구하는 인간 감독은 승인 기록뿐 아니라 감독자의 역량, 개입·중단 수단, 위험관리 체계까지 포괄합니다. 승인 로그는 위변조 방지 저장과 함께 정책 문서, 교육 이력과 묶어 관리하세요. 관련 조항은 6장 규제 박스에 정리했습니다. 더 궁금한 점은 댓글로 남겨주세요!

밝은 보안 연구실에서 노트북을 사용하는 여성 전문가와 AI 홀로그램, 승인 방패 및 잠금 아이콘

AI 에이전트의 실행을 사람이 확인하고 통제하는 HITL 보안 개념을 표현했습니다.

10. 마무리 요약

✅ HITL 승인 아키텍처, 이것만은 기억하세요

에이전트가 사람 없이 다단계 작업을 해내는 아스트라 시대에는 승인 버튼보다 승인 구조가 중요합니다. 위험 등급은 외부 정책 엔진이 판정하고, 승인은 파라미터 digest에 묶인 1회용 서명 토큰으로 발급하며, 실행기는 에이전트가 아니라 토큰만 신뢰해야 합니다.

동시에 사람의 주의력은 한정된 자원입니다. T0·T1은 자동화하고 T2 이상에만 사람을 배치하세요. 체류시간과 카나리 거부율로 승인이 실제로 작동하는지 계속 측정해야 합니다.

사람이 승인한 것과 시스템이 실행한 것이 같다는 사실을 증명할 수 없다면, 그건 HITL이 아니라 HITL처럼 보이는 것일 뿐입니다.

오늘 당장 할 수 있는 첫 번째 행동은 간단합니다. 운영 중인 에이전트의 도구 목록을 뽑고, 에이전트 런타임에 운영 자격증명이 직접 들어가 있는지부터 확인하세요. env | grep -iE "key|token|secret" 한 줄로 확인할 수 있습니다. 자격증명이 에이전트 프로세스에 있다면 어떤 승인 게이트도 우회될 수 있습니다. 그다음 본문의 Rego 정책을 섀도 모드로 붙여 일주일간 등급 분포를 측정해보세요.

여러분의 환경에서는 어떠셨나요? 경험이 있다면 댓글로 공유해주세요!

다음 포스팅에서는 이 구조를 MCP(Model Context Protocol) 서버 환경으로 확장해, 도구 서버 단위로 승인 게이트와 권한 범위를 분리하는 설계를 다루겠습니다.

내 폰 해킹당했나? 스마트폰 보안 이상 징후 체크리스트 완전 총정리 2026(Phone Hacking)

- 6월 29, 2026

이 블로그 검색

ICT리더 리치