AI 에이전트의 자동화, 많은 기업들에서 사용하고 그 성능이나 장점은 잘 알고 있지만 AI의 결정을 과연 신뢰할 수 있을까요.
처음엔 그 불안이 그냥 기술에 익숙하지 않아서 생기는 감정인 줄 알았지만, 실제로 고객사들에 AI 워크플로우를 구축하면서 이 불안이 얼마나 합리적인 감각인지를 피부로 느껴지는 경우도 있었습니다.
그리고 그 불안이 실제 사고로 터진 뉴스들을 보면서 확신이 생겼습니다. AI가 혼자 결정하게 두는 설계, 위험합니다.
실제로 일어난 일 — AI 단독 실행이 만든 사고들
에어캐나다 챗봇 소송 사건 (2024년 2월)
승객 한 명이 할머니가 돌아가신 직후, 한 남성이 에어캐나다 웹사이트에 접속해서 상조 할인 운임에 대해 문의했습니다. 챗봇은 이렇게 안내했어요.
"정가로 항공권을 먼저 구매하신 뒤, 90일 이내에 상조 할인을 신청하시면 환불받으실 수 있습니다."
그는 그 말을 믿고 편도 794.98캐나다달러, 왕복 845.38캐나다달러, 총 1,640달러(캐나다달러) 상당의 항공권을 구매했습니다.
결과는요? 에어캐나다는 환불을 거절했습니다. "구매 후 신청은 불가능하다"는 이유로요.
결국 법원까지 갔고, 캐나다 민사분쟁심판소는 에어캐나다에 812.02캐나다달러 배상을 명령했습니다. 재판관은 이렇게 말했어요. "고객에 대한 주의 의무는 에어캐나다에 있다. 챗봇이 자신의 행동에 책임을 지는 별도의 법적 존재라는 주장은 받아들일 수 없다."
챗봇의 실수지만, 책임은 회사가 진다는 것입니다.
관련 기사 — CIO Korea: '기업의 AI 책임 문제 강조' 에어캐나다 챗봇 사건의 시사점
맥도날드 AI 드라이브스루 전면 중단 (2024년 6월)
맥도날드는 2021년 IBM과 손잡고 미국 드라이브스루 매장 100여 곳에 AI 음성 주문 시스템을 도입했습니다. 당시 CEO는 "직원이 5건 중 1건 꼴로만 개입하면 될 것"이라며 자신감을 드러냈어요.
그런데 틱톡에 퍼진 영상들이 현실을 보여줬습니다. 손님이 "그만해! 그만해!"라고 소리를 질러도 AI는 치킨 맥너겟을 계속 추가해서 최종 260개까지 만들었고, 물과 바닐라 아이스크림을 주문했더니 버터와 커피크림이 추가됐으며, 아이스티 1잔을 요청했더니 9잔이 찍혔습니다.
3년의 실험 끝에 맥도날드는 2024년 6월 해당 AI 시스템을 전면 종료했습니다. 브랜드 이미지 타격은 덤이었고요.
관련 기사 — SBS 뉴스: '아이스크림에 베이컨이?' 맥도날드 AI 주문 결국 중단
뉴욕시 공식 AI 챗봇의 불법 안내 (2024년 3월)
뉴욕시가 시민과 사업자를 위해 도입한 공식 AI 챗봇 'MyCity'는 다음과 같은 답변을 제공했다가 언론에 적발됐습니다.
사업주가 직원의 팁을 가져갈 수 있다 (뉴욕주 노동법 위반)
성희롱을 호소하는 직원을 해고할 수 있다 (고용차별금지법 위반)
설치류가 갉아먹은 음식을 제공해도 된다 (식품 위생법 위반)
공공기관이 운영하는 AI도 인간의 검토 없이는 이 정도 오류를 냅니다.
관련 기사 — CIO Korea: 생성형 AI가 만든 대형사고 10선
세 사건의 공통점은 딱 하나입니다.
AI가 내린 결정의 결과를, 사람이 미리 볼 수 없었다는 것.
그리고 그 결과는 소송, 브랜드 타격, 서비스 전면 중단이었습니다.
그렇다면 왜 이런 일이 생기는 걸까요
사실 이건 AI가 멍청해서가 아닙니다. 자율적인 AI 시스템에는 구조적으로 세 가지 한계가 존재합니다.
첫째, AI는 '맥락'을 모릅니다.
에어캐나다 챗봇은 틀린 정보를 의도적으로 안내한 게 아니에요. 그냥 학습된 정책을 그대로 전달했을 뿐입니다. 문제는 그 정책이 실제 상황과 달랐고, AI에겐 그 차이를 판단할 능력이 없었다는 겁니다.
저도 고객사에 AI 워크플로우를 구축하다 보면 이 문제를 자주 마주칩니다. "이 문서는 지금 협상 중이라 절대 외부로 나가면 안 돼요"라든지, "이 고객은 특이 케이스라 자동 처리하면 안 됩니다" 같은 암묵적인 상황 판단은 아무리 잘 짜인 프롬프트에도 담기 어렵습니다. 그 맥락을 읽는 건 결국 사람만이 할 수 있어요.
둘째, 실수의 비용이 비대칭적입니다.
AI가 99번 잘 처리해도, 1번의 잘못된 실행이 가져오는 피해가 99번의 성과를 훌쩍 넘길 수 있습니다. 특히 외부 발송, 결제 실행, 데이터 삭제처럼 한 번 실행되면 되돌리기 어려운 행동(Irreversible Action) 이 포함된 워크플로우에서는 이 비대칭성이 치명적으로 작용합니다.
셋째, 책임은 결국 사람에게 돌아옵니다.
에어캐나다 판결이 명확히 보여줬습니다. AI가 어떤 형식으로 제공되든, 그 결과에 대한 법적 책임은 기업이 집니다. AI 시스템을 도입했다는 것 자체가 면책 사유가 되지 않아요.
그렇다고 모든 걸 사람이 하라는 얘기는 아닙니다
여기서 많은 분들이 오해하는 게 있어요. "그러면 결국 자동화 못 하겠네?"라는 생각이요.
아닙니다. 자동화는 해야 합니다. 다만 어디서 멈춰야 하는지를 설계에 포함시켜야 한다는 겁니다.
그게 바로 Human-in-the-Loop(HITL) 입니다.
Human-in-the-Loop란 정확히 무엇인가요
HITL은 "AI 중간에 사람이 끼어드는 것"이 아닙니다. 더 정확하게 말하면, AI의 자율성과 인간의 판단력을 설계 단계에서 함께 구조화하는 아키텍처입니다.
기존 AI 워크플로우에는 사실 선택지가 두 가지뿐이었어요.
완전 자동: AI가 처음부터 끝까지 혼자 처리
완전 수동: 사람이 일일이 확인하고 진행
근데 실제 업무에서 문제가 되는 구간은 딱 중간 어딘가입니다. 대부분의 단계는 AI가 잘 처리하는데, 외부 발송, 결제 승인, 계약서 최종 확인처럼 "이건 사람이 한 번 봐야 해"라는 포인트가 반드시 있거든요.
HITL은 이 포인트를 워크플로우에 명시적으로 설계하는 방법입니다. AI는 빠르게 처리하되, 고위험 구간에서는 자동으로 멈추고 사람의 판단을 기다립니다. 사람이 승인하면 다시 자동으로 이어서 진행됩니다.
속도도 잡고, 안전도 잡는 설계입니다.
HITL 워크플로우를 만들려면 기술적으로 뭐가 필요할까요
실제로 구현 관점에서 보면 세 가지 요소가 필요합니다.
1. 워크플로우 일시 정지(Pause) 알림을 보내는 게 아닙니다. 워크플로우 자체가 멈추고, 인간의 입력이 들어올 때까지 상태를 유지해야 합니다. 이게 생각보다 구현이 까다로워요.
2. 검토와 수정(Review & Edit) 사람이 AI 출력물을 그냥 '확인'만 하는 게 아니라, 필요하면 내용을 수정하거나 변수를 직접 바꿀 수 있어야 합니다. '읽기 전용 개입'이 아니라 '편집 가능한 개입'이어야 해요.
3. 판단에 따른 분기 라우팅(Action-Based Routing) 승인을 눌렀을 때와 반려를 눌렀을 때, 이후 워크플로우 경로가 달라져야 합니다. "예/아니오"를 받는 게 아니라, 그 판단 결과가 자동으로 다음 단계를 결정하는 구조입니다.
이 세 가지를 직접 코드로 구현하려면 상태 관리 시스템, 알림 파이프라인, 검토 UI를 따로따로 만들어야 합니다. 보통 개발 리소스가 상당히 필요한 작업이에요.
HITL 기능도 ‘드레그&드랍’으로 : Dify 1.13.0 — Human Input 노드
2026년 2월 출시된 Dify 1.13.0에 Human Input 노드가 추가됐습니다.
작동 방식은 이렇습니다. 워크플로우 캔버스에서 사람 검토가 필요한 지점에 Human Input 노드를 추가하면, 그 순간부터 해당 지점에서 워크플로우가 자동으로 멈추고 담당자에게 검토 요청이 전송됩니다.
주요 기능을 정리하면 다음과 같습니다.
워크플로우 자동 일시 정지: 노드가 실행되는 순간 워크플로우가 대기 상태로 전환됩니다. AI가 임의로 다음 단계를 진행하지 않아요.
검토 UI 자동 생성: 담당자가 AI 출력물을 확인하고 변수를 직접 수정할 수 있는 인터페이스가 자동으로 만들어집니다.
커스텀 액션 버튼: '승인', '반려', '에스컬레이션' 등 버튼 레이블을 직접 설정하고, 버튼 선택 결과에 따라 이후 경로가 자동으로 분기됩니다.
유연한 전달 방식: 검토 요청을 웹앱 또는 이메일로 전달할 수 있어서, 담당자 업무 환경에 맞게 선택하면 됩니다.
실행 이력 추적: 누가, 언제, 어떤 판단을 내렸는지가 기록으로 남습니다. 내부 감사나 컴플라이언스 대응에 유리합니다.
기술적으로도 중요한 변화가 있었어요. Dify 1.13.0은 HITL의 상태 유지(Pause/Resume) 메커니즘을 안정적으로 지원하기 위해 워크플로우 기반 실행을 Celery 워커 방식으로 전환하고, Redis Pub/Sub을 통해 이벤트를 스트리밍하도록 실행 엔진을 재설계했습니다. 기능 하나를 얹은 게 아니라, 시스템 레벨에서 HITL을 지원하는 구조를 새로 만든 거예요.
실제로 이런 업무에 적용할 수 있습니다
Dify를 구축하면서 가장 자주 나오는 유스케이스를 정리해봤습니다.
업무 영역 | AI가 처리하는 것 | 사람이 개입하는 지점 |
|---|---|---|
마케팅/콘텐츠 | SNS 초안 자동 생성 | 담당자 최종 수정 및 승인 후 발행 |
법무/계약 | 계약서 초안 작성 | 법무팀 이메일 검토 → 승인 후 발송 |
IT 운영 | 장애 감지 및 패치 스크립트 생성 | 시니어 엔지니어 승인 → 자동 배포 |
구매/재무 | 견적 비교 분석 보고서 생성 | 특정 금액 초과 시 결재자 승인 요청 |
고객 응대 | 민원 분류 및 초안 답변 생성 | 고위험 케이스 담당자 검토 후 발송 |
특히 법무, 재무, 외부 발송이 포함된 워크플로우에는 HITL을 반드시 설계에 포함시키는 걸 권장합니다. 에어캐나다 사례처럼, "AI가 한 일이지만 책임은 우리가 진다"는 걸 기억해야 하니까요.
AI 시대에 인간의 역할은 사라지지 않습니다
에어캐나다와 맥도날드의 사례는 AI 자동화가 나쁘다는 걸 말하지 않습니다. 오히려 AI는 분명히 더 빠르고, 더 많이 처리할 수 있어요.
다만 '어디서 멈춰야 하는지'를 설계하지 않은 자동화는, 아직 준비가 덜 된 자동화입니다.
Human-in-the-Loop는 AI에게 더 많은 자율성을 주는 동시에, 인간이 진짜 가치 있는 판단에만 집중할 수 있게 해주는 설계입니다. AI가 더 많은 일을 실행할수록, 그 판단이 닿는 지점은 더 중요해집니다.
그 지점을 설계하는 것, 그게 지금 AI 기업에게 가장 중요한 과제입니다.
자주 묻는 질문 (FAQ)
Q. Human-in-the-Loop(HITL)가 정확히 무엇인가요? AI 워크플로우 중 특정 단계에서 인간이 검토하고 승인해야 다음 단계로 진행되도록 설계한 구조입니다. 완전 자동화와 완전 수동 사이의 중간 설계 방식으로, 속도는 유지하면서 고위험 의사결정 구간에만 인간이 개입합니다.
Q. Dify에서 HITL을 구현하려면 코딩이 필요한가요? Dify 1.13.0부터는 워크플로우 캔버스에 Human Input 노드를 추가하는 것만으로 HITL을 구현할 수 있습니다. 별도의 코딩 없이 노드 설정에서 검토 UI, 전달 방식(이메일/웹앱), 액션 버튼 레이블까지 모두 설정할 수 있습니다.
Q. HITL이 필요한 워크플로우는 어떤 경우인가요? 외부 발송, 결제 승인, 법무 검토, 고위험 고객 응대처럼 실행 후 되돌리기 어렵거나 법적·비즈니스적 리스크가 있는 구간이 포함된 워크플로우에는 HITL 적용을 권장합니다.
Q. AI 챗봇이 실수하면 책임은 누구에게 있나요? 2024년 에어캐나다 판결에 따르면, AI가 잘못된 정보를 제공했더라도 법적 책임은 해당 AI 시스템을 운영한 기업에 있습니다. "챗봇이 한 일"이라는 주장은 법원에서 면책 사유로 인정받지 못했습니다.
Q. Dify Human Input 노드는 언제 출시됐나요? 2026년 2월 11일 출시된 Dify 1.13.0에서 처음 공개됐습니다.
오픈네트웍시스템 ㅣ 권태규