당신의 AI 에이전트는 자신이 4만 달러짜리 실수를 저질렀다는 사실을 전혀 모릅니다

더 읽기 전에 직관적으로 점검해 봅시다. 만약 현재 운영 중인 에이전트가 실제 고객과 실제 데이터를 대상으로 지금 당장 잘못된 결정을 내린다면, 사람이 실제로 이를 확인하기까지 얼마나 걸릴까요?

만약 당신의 솔직한 답변이 "누군가 로그를 확인하는 시점에 따라 다릅니다"라면, 당신은 모니터링의 공백을 가진 것이 아닙니다. 당신은 시스템 설계 결정(system design decision)을 놓친 것입니다. 이것을 Human in the Loop (HITL)라고 부르며, 대부분의 팀은 이를 아키텍처 요구 사항이 아닌 사후 고려 사항으로 취급합니다.

실패 모드, 한 문장으로 요약하자면

에이전트는 틀렸을 때 충돌(crash)하지 않습니다. 그저 실행을 계속할 뿐입니다. 예외(exception)가 발생하지도 않고, 알림(alert)도 울리지 않으며, 에러 트래커(error tracker)에도 아무것도 남지 않습니다. 환불이 승인되고, 이메일이 발송되며, 기록이 업데이트되고, 시스템은 그 과정 내내 성공을 보고합니다.

그 부분이 바로 충돌보다 당신을 더 걱정하게 만들어야 하는 지점입니다. 충돌은 소란스럽습니다. 하지만 자신 있게 틀린 자율적 행동은 조용합니다.

HITL의 실제 의미 (유행어가 아닌 버전)

HITL은 "누군가가 가끔 대시보드를 확인하는 것"이 아닙니다. 이것은 특정 설계 패턴입니다. 즉, 결정이 되돌릴 수 없게 되기 전, 파이프라인의 정의된 시점에서 사람이 에이전트의 결정을 검토, 승인하거나 무효화할 수 있는 것입니다.

이를 로깅(logging)보다는 병렬 시스템(concurrent system)에서의 동기화 지점(sync point)에 가깝게 생각하십시오. 검토되지 않은 잘못된 답변의 비용이 지연으로 인한 비용보다 높기 때문에, 선택된 단계에서 실행을 명시적으로 차단하는 것입니다.

이것은 체크포인트가 존재한다는 것만을 정의하는 승인/검토 레이어 (approval/review layer) 위의 레이어입니다. HITL은 사람이 단순히 대기열에 도장을 찍는 것이 아니라, 실제로 그곳에서 판단력을 행사하는지 여부에 관한 것입니다.

당신의 로드맵 우선순위를 바꿔야 할 수치들

IBM의 Institute for Business Value는 Oxford Economics와 함께 2,000명의 시니어 기술 경영진을 대상으로 2026년 연구를 수행했습니다. 그 결과는 다음과 같습니다:

• 조직당 연간 평균 54건의 에이전트 사고 (agent incidents) 발생 (인간의 수정 필요)
• 이 중 **17%**는 심각도가 높았으며, 수습에 4시간 이상 소요됨
• 심각도가 높은 사고 중: **37%**는 데이터 노출 또는 보안 침해를 유발, **33%**는 연쇄 실패 (cascading failures)를 유발, **17%**는 컴플라이언스 (compliance) 문제를 유발

그리고 여러분의 백로그 (backlog)에 실제로 반영해야 할 내용은 다음과 같습니다:

시스템 내에 거버넌스 (governance) 및 제어 메커니즘 (control mechanisms)을 구축한 조직은 사후 수동 검토에 의존하는 조직보다 사고 발생 건수가 25% 더 적었습니다.

이것은 단순히 "있으면 좋은 모니터링" 수치가 아닙니다. "사후 분석 (postmortem) 단계가 아니라 아키텍처 (architecture) 단계에서 구축해야 한다"는 수치입니다.

리더 그룹 vs 나머지 그룹의 격차

McKinsey의 2025년 AI 현황 보고서 (~2,000명 응답, ~105개국): 작년에 조직의 51%가 최소 하나 이상의 부정적인 AI 결과를 경험했으며, 부정확성 (inaccuracy)이 30%로 가장 큰 원인이었습니다.

중요한 차이점은 다음과 같습니다: 고성과 조직의 65%는 정의된 HITL (Human-in-the-Loop) 검증 프로세스를 보유하고 있었던 반면, **나머지 그룹은 23%**에 불과했습니다. 이것은 성숙도 곡선의 차이가 아니라, 완전히 다른 두 개의 시스템입니다.

이것이 특히 에이전트 중심 프로젝트를 망치는 이유

Gartner (2025년 6월)는 2027년 말까지 에이전트 중심 AI (agentic AI) 프로젝트의 40% 이상이 취소될 것이라고 예측합니다. 모델의 성능이 낮아서가 아닙니다. 비용 상승, 불분명한 ROI (투자 대비 수익), 그리고 약한 리스크 제어 때문이며, 이는 거버넌스 실패가 기술적 실패의 가면을 쓰고 나타나는 것입니다.

패턴은 항상 동일합니다: 파일럿 (pilot)은 훌륭해 보임 → 운영 (prod) 단계로 전환 → 감독 (oversight) 부재 → 오류가 조용히 누적됨 → 재무 부서에서 청구서를 발견함 → 프로젝트 중단. 정작 원인이 된 아키텍처 결정에 대해서는 아무도 책임을 묻지 않습니다.

체크포인트 (checkpoint)를 실제로 어디에 두어야 하는가 (모든 곳에 둘 필요는 없습니다)

KPMG의 4분기 AI Pulse 설문조사: 기업 리더의 60% 이상이 고위험 워크플로우 (workflows)에 HITL을 적용하고 있습니다. 또한 동일한 설문조사에 따르면, 40%는 여전히 인간의 승인 없이 에이전트의 민감한 데이터 접근을 제한하지 않고 있습니다. 바로 그 격차 속에 다음 사고가 도사리고 있습니다.

모든 행동에 인간이 필요하지는 않습니다. 요약 에이전트(summarization agent)와 결제 승인 에이전트(payment approval agent)는 위험 등급이 다르며, 이들을 동일하게 취급하는 것은 자동화의 이점을 없애거나 실제 보안 허점을 남기는 결과를 초래합니다.

이번 스프린트에서 실제로 구현할 수 있는 3단계 프레임워크

1. 에이전트가 '해야 하는' 일뿐만 아니라, 에이전트가 '할 수 있는' 모든 행동을 매핑하세요.
그 다음 결과에 따라 분류하십시오: 상태 업데이트 = 저위험, 환불/권한 변경/기록 수정 = 고위험. 결과가 중대한 행동은 실행 후가 아니라 실행 전에 승인을 받아야 합니다.

2. 체크포인트당 한 명의 지정된 소유자(owner)를 두세요. 팀이나 '플랫폼'이 아닙니다.
무언가 잘못되었을 때, 해당 검토 지점에 이름이 연결된 사람은 정확히 한 명이어야 합니다. 책임이 분산되면 아무도 실제로 감시하지 않게 됩니다.

3. 다른 지표를 기록하는 것처럼 오버라이드(override) 빈도와 이유를 기록하세요.
만약 인간이 특정 작업에서 에이전트를 10%의 비율로 오버라이드하고 있다면, 그것은 체크포인트가 '작동하고 있는 것'이 아닙니다. 그것은 데이터 품질, 프롬프트/학습(prompt/training), 또는 워크플로 설계와 같이 상류(upstream)의 무언가가 고장 났다는 신호입니다. 이를 단순히 마찰로 받아들이지 말고 시스템에 다시 피드백하십시오.

실제 핵심 요약

인간의 감독을 제거한다고 해서 시스템이 빨라지는 것은 아닙니다. 그것은 시스템을 눈멀게 만들며, 눈먼 시스템은 예상보다 조금 늦게, 하지만 매우 값비싼 대가를 치르며 실패하게 됩니다.

이 글은 Ysquare의 AI 에이전트 준비성(AI Agent Readiness) 시리즈의 일부입니다. 이 문제로 고군분투하고 있다면 다음 관련 글들을 참고하세요: scattered knowledge breaking agent context, security models that assume a human is always the actor, 그리고 why real-time data access changes the risk calculus.

전체 데이터 분석 및 구축 프레임워크를 포함한 전문: Human in the Loop AI Agents: Why Enterprise Oversight Is Non Negotiable