「생성 AI를 업무에 사용해도 될까요?」라고 물었을 때, 자주 돌아오는 답변이 있습니다.

「마지막에는 인간이 확인해 주세요」

언뜻 보기에는 타당합니다. AI의 출력을 그대로 사용하지 않고, 인간이 확인한다. 이라면 안전해 보입니다.

하지만 현장에는 여기에 함정이 있습니다.

인간이 확인한다고 해도, 다음과 같은 상태라면 실효성이 없습니다.

• 무엇을 확인해야 할지 정해져 있지 않다
• 누가 승인 권한을 가질지 정해져 있지 않다
• AI의 출력을 반려할 기준이 없다
• 판단 로그가 남지 않는다
• 너무 바빠서, 결국 「AI가 그렇다고 하니까」라며 그냥 넘어가 버린다

즉, Human-in-the-loop는 '인간을 중간에 두는 것'만으로는 부족합니다.

본고에서는 생성 AI 시대의 Human-in-the-loop를 운영 설계로서 정리합니다.

Human-in-the-loop, 영어로는 Human-in-the-loop, 줄여서 HITL이라고 불립니다.

직역하면 「루프 안에 인간이 있다」입니다.

여기서 말하는 루프란, AI가 출력하고, 인간이 확인하며, 그 결과가 다음 개선이나 판단으로 돌아가는 일련의 흐름입니다.

단순화하면 다음과 같은 구조입니다.

입력
↓
AI에 의한 생성·예측·추천
...

중요한 것은, 인간이 「마지막에 보는」 것뿐만 아니라, AI의 출력에 대해 다음의 선택지를 가지고 있다는 점입니다.

• 채택한다
• 수정한다
• 반려한다
• 사용하지 않는다
• 상급자에게 에스컬레이션(Escalation)한다
• 시스템을 정지한다
• 평가 데이터로서 개선에 활용한다

EU의 AI 법에서도 고위험 AI 시스템에 대한 인간의 감독에 대해, AI의 능력과 한계를 이해하고 출력을 무시·덮어쓰기·반전시키며, 필요에 따라 정지할 수 있어야 함을 명시하고 있습니다1.

이 관점에서 보면, HITL의 본질은 「인간이 읽는 것」이 아니라 「인간이 개입할 수 있는 것」입니다.

HITL 주변에는 유사한 개념이 있습니다.

현장에서 혼동하기 쉬운 것은 Human-in-the-loop와 Human-on-the-loop입니다.

예를 들어, AI가 작성한 메일 문구를 송신 전에 인간이 승인한다면 HITL입니다.

반면, AI가 24시간 로그를 감시하고, 인간은 이상 통지를 받았을 때만 개입한다면 HOTL에 가까운 설계입니다.

어느 쪽이 옳다는 이야기가 아닙니다.

리스크에 따라 인간의 관여 수준을 바꾸는 것이 중요합니다.

가설로서, HITL이 실패하는 가장 큰 이유는 인간의 배치를 「책임을 떠넘길 곳」으로 사용해 버리기 때문입니다.

AI의 출력에 문제가 생겼을 때, 이렇게 말할 수 있기 때문입니다.

「최종 확인은 인간이 했습니다」

하지만 이것은 거버넌스(Governance)로서 취약합니다.

왜냐하면, 인간이 확인하고 있더라도 확인할 수 있는 조건이 없다면 실질적인 감독이 되지 않기 때문입니다.

AI가 그럴듯한 출력을 내놓으면, 인간은 그것을 과신하기 쉬워집니다.

이는 일반적으로 「자동화 편향 (Automation Bias)」이라고 불립니다.

특히 생성 AI에서는 다음과 같은 조건이 겹치면 위험합니다.

• 문장이 자연스럽다
• 전문 용어가 포함되어 있다
• 단정적인 어조로 출력된다
• 출처가 있는 것처럼 보인다
• 업무가 바빠서 확인 시간이 짧다

EU AI 법 제14조에서도 고위험 AI의 감독자가 AI 출력에 자동적으로 의존하거나 과도하게 의존하는 경향, 즉 automation bias를 인식하고 있을 것을 요구하고 있습니다1.

여기서 알 수 있는 것은, HITL에서는 「인간을 신뢰하는 것」만으로는 부족하다는 점입니다.

인간이 과신하지 않도록 화면, 권한, 로그, 교육, 반려 기준을 설계해야 합니다.

흔히 발생하는 실패 사례를 정리하면 다음과 같습니다.

인간이 루프에 들어와 있어도, 멈출 수 없다면 안전장치가 아닙니다.

HITL은 인간의 선의가 아니라, 업무 프로세스로서 설계해야 합니다.

NIST의 AI Risk Management Framework는 AI 리스크 관리를 GOVERN, MAP, MEASURE, MANAGE의 4가지 기능으로 정리하고 있습니다2.

이를 현장의 HITL에 적용하면 다음 5가지 관점이 유용합니다.

먼저, AI의 역할을 정합니다.

이 부분이 모호하면, AI가 "참고 정보를 제공하고 있는 것"인지 "판단하고 있는 것"인지 알 수 없게 됩니다.

생성 AI (Generative AI)의 경우, 특히 주의해야 할 점은 "초안"과 "판단"의 경계입니다.

문장 생성 목적으로 도입한 AI가 어느샌가 채용, 평가, 여신, 의료, 법무와 같은 판단 영역으로 들어가는 경우가 있습니다.

그럴 경우, HITL의 설계 수준을 높여야 합니다.

AI 사업자 가이드라인에서는 AI 활용 대책을 리스크의 크기에 따라 생각하는 리스크 기반 접근 방식 (Risk-based Approach)이 중요하다고 명시하고 있습니다3.

HITL도 마찬가지입니다.

모든 것을 인간이 확인하면 속도가 느려집니다.

반대로, 모든 것을 AI에 맡기면 위험합니다.

따라서 리스크에 따라 인간의 관여도를 바꿉니다.

포인트는 AI의 성능뿐만 아니라, 실패했을 때의 영향력을 보고 판단하는 것입니다.

같은 요약 AI라도 개인용 메모를 요약하는 것이라면 저리스크입니다.

반면, 징계 판단의 근거 자료를 요약한다면 리스크는 높아집니다.

단순히 "확인해 주세요"라고만 해서는 확인이 불가능합니다.

리뷰 관점을 명시해야 합니다.

생성 AI의 출력물 확인 시에는, 최소한 다음 관점을 나누면 실무에 적용하기 쉽습니다.

특히 중요한 것은 AI의 문장 표현이 아니라 "근거"입니다.

문장이 유려한가가 아니라, 무엇을 근거로 하고 있는가입니다.

이 관점을 놓치면 HITL은 단순한 교정 작업이 되어버립니다.

HITL에서는 인간이 멈출 수 있는 것이 중요합니다.

따라서 리뷰 담당자에게는 다음과 같은 권한을 정의합니다.

• 승인
• 수정
• 반려 (差し戻し)
• 거절
• 상급자에게 에스컬레이션 (Escalation)
• 외부 전송 중지
• AI 이용 일시 중지
• 인시던트 (Incident) 등록

여기서 주의할 점은 현장 담당자에게 과도한 책임을 지우지 않는 것입니다.

예를 들어, 법무 판단이 필요한 출력을 일반 직원이 확인하도록 설계하는 것은 위험합니다.

인간을 투입한다면, 그 사람이 판단할 수 있을 만큼의 지식, 권한, 시간, 정보를 제공해야 합니다.

HITL은 사후에 검증할 수 있어야 비로소 개선할 수 있습니다.

최소한 다음의 로그를 남깁니다.

ai_review_log:
use_case: "고객용 답변문 생성"
input_summary: "문의 내용 요약"
...

이 로그는 단순히 책임을 추궁하기 위한 것이 아닙니다.

오히려 AI 이용을 개선하기 위한 재료입니다.

• 어떤 프롬프트에서 실패가 많은가
• 어떤 업무에서 반려가 많은가
• 어떤 지식 베이스 (Knowledge Base)가 오래되었는가
• 어떤 담당자에게 부하가 집중되는가
• 어떤 리스크가 예상보다 높았는가

이러한 정보가 보이면, HITL은 "인간이 열심히 노력하는 구조"에서 "지속적으로 개선하는 구조"로 바뀝니다.

여기서는 실무에서 사용하기 쉬운 구현 패턴을 정리합니다.

사내 메모, 아이디어 도출, 문장의 초안 등은 모두를 승인 프로세스에 태우면 너무 무거워집니다.

이 경우에는 이용자 스스로 체크하는 셀프 체크형으로도 충분할 수 있습니다.

생성 AI
↓
이용자가 확인
...

단, 최소한의 금지 사항은 명시합니다.

• 기밀 정보를 입력하지 말 것
• 개인 정보를 부주의하게 입력하지 말 것
• 외부 전송 전에는 별도로 확인할 것
• 숫자, 법령, 계약, 고유명사는 1차 자료로 확인할 것
• AI 출력을 그대로 공식 견해로 삼지 말 것

저리스크라 하더라도 교육과 가이드라인은 필요합니다.

고객용 이메일, FAQ, 제안서, 보도자료 초안 등은 외부로 나가기 전에 인간의 승인을 거칩니다.

생성 AI
↓
담당자가 편집
...

이 설계에서는 승인자가 확인해야 할 관점을 명확히 합니다.

• 고객에게 오해를 불러일으키지 않는가
• 계약상의 약속이 되어버리지는 않았는가
• 최신 정보에 기반하고 있는가
• 사외비 정보를 포함하고 있지 않은가
• 회사 차원에서 내보내도 괜찮은 표현인가

단순한 오탈자 체크가 아닙니다.

외부로 나갔을 때의 영향을 확인하는 공정입니다.

인사, 여신, 의료, 법무, 보안 관련 중대 판단 등은 AI의 출력을 그대로 판단에 사용해서는 안 됩니다.

이 경우, HITL은 더욱 강력한 설계가 됩니다.

AI에 의한 분석 및 후보 제시
↓
전문 담당자에 의한 확인
...

여기서 AI는 판단자가 아니라 보조자입니다.

AI가 도출한 스코어(Score)나 추천은 어디까지나 재료입니다.

최종 판단에서는 근거, 문맥, 예외, 본인에 대한 설명 가능성 (Explainability)을 포함하여 인간이 책임을 질 필요가 있습니다.

AI 사업자 가이드라인에서도 AI 출력을 특정 개인 또는 집단에 대한 평가의 참고 자료로 사용하는 경우, AI를 이용하고 있다는 사실의 통지, 정확성·공정성·투명성 등의 절차, 자동화 편향 (Automation Bias)을 고려한 인간에 의한 합리적 판단, 설명 책임 (Accountability)에 대한 대응이 제시되어 있습니다³.

운영 모니터링이나 보안 모니터링에서는 모든 이벤트를 인간이 확인하는 것은 현실적으로 불가능합니다.

이 경우에는 AI가 상시 모니터링하고, 임계값 (Threshold)을 초과했을 때 인간에게 통지합니다.

로그·이벤트
↓
AI에 의한 탐지
...

이 설계에서는 다음 세 가지가 중요합니다.

• 어떤 조건에서 통지할 것인가
• 누가 몇 분 이내에 대응할 것인가
• AI 탐지를 중단하거나 설정을 변경할 권한은 누가 갖는가

모니터링 계통의 HITL에서는 인간이 항상 판단한다기보다, 인간이 개입할 수 있는 상태를 유지하는 것이 중요해집니다.

마지막으로, 구현 전에 확인하고 싶은 체크리스트를 제시합니다.

• AI에게 맡길 범위를 정의하고 있는가

• AI에게 맡기지 않을 범위를 정의하고 있는가

• AI 출력을 참고 정보, 추천, 판단 보조, 자동 실행 중 무엇으로 취급할지 정의하고 있는가

• 리스크에 따라 인간의 관여 수준을 바꾸고 있는가

• 예외 발생 시의 에스컬레이션 (Escalation) 경로를 정의하고 있는가

• 리뷰 관점을 명문화하고 있는가

• 승인, 수정, 거절, 반려의 기준이 있는가

• 리뷰 담당자에게 필요한 지식과 권한이 있는가

• 리뷰 담당자의 부하를 산정하고 있는가

• AI 출력을 과신하지 않기 위한 교육을 실시하고 있는가

• 입력, 출력, 참조원, 모델, 프롬프트 버전을 기록하고 있는가

• 인간의 판단 결과를 로그 (Log)로 남기고 있는가

• 고위험 시 정지 또는 에스컬레이션할 수 있는가

• AI의 출력 근거를 확인할 수 있는가

• 모델이나 지식 베이스 (Knowledge Base) 업데이트 시 재평가할 수 있는가

• AI 개발자, AI 제공자, AI 이용자의 책임 분계를 정리하고 있는가

• 인시던트 (Incident) 발생 시의 보고 경로가 있는가

• 이용자에 대한 설명 방침이 있는가

• 불이익을 받을 가능성이 있는 사람에 대한 배려가 있는가

• 정기적으로 운용 로그를 검토하고 있는가

HITL을 도입하는 목적은 인간의 작업을 늘리는 것이 아닙니다.

AI를 안전하게 계속 사용하기 위해, 인간이 개입해야 할 지점을 파악하는 것입니다.

휴먼 인 더 루프 (Human-in-the-loop)는 생성 AI 시대의 편리한 구호가 되어가고 있습니다.

하지만 "인간이 확인하니까 괜찮다"라는 말은 위험합니다.

확인하는 인간에게 관점, 근거, 권한, 시간, 로그, 정지 수단이 없다면 HITL은 형식에 그치게 됩니다.

본고의 결론은 다음과 같습니다.

• HITL은 "인간이 보는 것"이 아니라 "인간이 개입할 수 있는 것"
• 인간의 확인은 책임 전가가 아니라 리스크 제어로서 설계할 것
• AI의 출력을 과신하지 않도록 자동화 편향을 전제로 할 것
• 리스크에 따라 인간의 관여 수준을 바꿀 것
• 로그를 남기고, 리뷰 결과를 개선으로 연결할 것

생성 AI를 업무에 도입할 때, 가장 먼저 만들어야 하는 것이 고도의 AI 기반은 아닐 것입니다.

오히려 처음에 필요한 것은 "AI가 내놓은 것을 누가, 무엇을 근거로, 어디까지 사용해도 좋다고 판단할 것인가"라는 운용 설계입니다.

HITL은 인간이 AI를 방해하는 메커니즘이 아닙니다.

AI를 현장에서 쓸 수 있는 도구로 만들기 위한, 마지막 안전 설계입니다.

--
AI Act Service Desk 「Article 14: Human oversight」

EU AI Act에서의 고위험 AI 시스템에 의한 인간의 감독, 능력·한계의 이해, 자동화 편향, 덮어쓰기·정지 수단에 관한 근거로 참조했습니다. ↩ ↩2 -
NIST 「Artificial Intelligence Risk Management Framework (AI RMF 1.0)」

AI 리스크 관리를 GOVERN, MAP, MEASURE, MANAGE로 정리하는 사고방식, 지속적인 AI 리스크 매니지먼트의 근거로 참조했습니다. ↩ -
총무성·경제산업성 「AI 사업자 가이드라인 (제1.2판)」

일본에서의 AI 거버넌스, 리스크 기반 접근 방식 (Risk-based approach), 인간 중심, AI 개발자·AI 제공자·AI 이용자의 정리, AI 출력을 개인·집단 평가에 사용할 경우의 유의점 근거로 참조했습니다. ↩ ↩2