세계 첫 AI 에이전트 규제와 HITL, AI에게 법인카드를 넘겨주고 있었나요?
신입사원한테 첫 출근 날부터 법인카드랑 계약서 도장을 맡기는 회사는 없잖아요. 일 잘하는 것과 결재권을 주는 건 완전히 다른 문제니까요. 그런데 그동안 우리는 AI 에이전트한테 은근슬쩍 도장부터 쥐여주고 있었는지도 몰라요. 이메일을 대신 보내고 티켓을 대신 닫고 환불을 대신 처리하는 에이전트들이 지금 이 순간에도 어딘가에서 돌아가고 있어요. 그런데 그 결정들 중에 사람이 한 번이라도 들여다본 건 얼마나 될까요.
규제가 움직이기 시작했어요
여기에 처음으로 규제 당국이 제동을 걸기 시작했습니다. 지난 5월, 중국 정부가 세계 최초로 AI 에이전트만을 겨냥한 국가 정책 프레임워크를 내놨거든요. 생성형 AI 규제야 여러 나라에 있었지만 '스스로 인지하고 결정하고 실행하는 에이전트'를 별도의 규제 대상으로 규정한 건 이게 처음이에요. 골자는 에이전트의 결정 권한을 세 단계로 나누라는 거예요. 사람만 할 수 있는 결정, 사람의 승인을 받아야 하는 결정, 에이전트가 알아서 해도 되는 결정, 이렇게요. 말하자면 에이전트에게도 결재 라인을 만들라는 거죠. 아직은 완성된 법률이라기보다 앞으로 만들어질 세부 기준의 설계도에 가깝지만 최종 결정권은 사람이 쥔다는 원칙만큼은 문서에 못 박혀 있습니다.
그리고 이건 중국만의 얘기가 아니에요. 이번 8월부터는 EU AI Act의 고위험 시스템 의무가 발효됩니다. 여기에는 사람이 시스템을 실질적으로 감독할 수 있게 설계하라는 인적 감독(Article 14) 요건이 들어 있어요. 신용 평가나 보험 심사처럼 사람의 삶에 직접 닿는 영역일수록 '자동화했다'는 말만으로는 부족하고
어디서 사람이 개입하는지를 증명할 수 있어야 한다는 겁니다. 방향은 분명해요. HITL(Human-in-the-Loop)이 권장사항에서 필수 과목으로 옮겨가는 중이라는 것.
HITL이 정확히 뭔가요?
HITL은 자동화된 프로세스의 중요한 지점에서 실행을 멈추고 사람의 검토를 거치게 하는 설계를 말해요. 시스템이 루틴한 일을 처리하되 판단이 필요한 순간에는 공을 사람에게 넘기는 거죠. 중요한 건 이걸 자동화의 후퇴로 읽으면 안 된다는 거예요. 에이전트가 잘못 설정되면 나쁜 결정을 한 번 하고 멈추는 게 아니라 같은 나쁜 결정을 대량으로 반복해요. 그 반복이 고객에게 닿기 전에 잡아내는 안전핀이 HITL이거든요. 속도를 조금 내주고 신뢰를 사는 거래인 셈이에요. 규제 환경에서는 이 거래가 선택이 아니라 입장료가 되어가고 있고요.
문제는 구현이었습니다. 워크플로우 중간에 승인 단계 하나를 넣자고 별도의 승인 시스템을 개발하고 알림을 연동하고 상태를 관리하다 보면 배보다 배꼽이 커지기 일쑤였으니까요.
Dify Human Input 노드로 결재 라인 만들기
Dify가 v1.13.0에서 내놓은 Human Input 노드가 정확히 이 지점을 노렸어요. 기존 워크플로우는 전부 자동이거나 전부 수동이거나 둘 중 하나였어요. 이 노드가 그 사이의 회색지대를 채웁니다. 작동 방식은 직관적이에요. 워크플로우 캔버스에서 사람의 판단이 필요한 지점에 Human Input 노드를 끼워 넣으면 실행이 그 자리에서 멈추고 검토용 화면이 생성됩니다. 검토자는 AI가 만든 결과물을 확인하고 그대로 승인할 수도, 변수를 직접 고쳐서(예를 들어 초안의 문구를 수정하거나 잘못된 데이터를 바로잡아서) 내려보낼 수도 있어요.
노드 하나를 설정하는 화면은 크게 세 칸으로 나뉘어요. 전달 방식, 폼 내용, 타임아웃. 이 셋만 이해하면 어지간한 결재 라인은 다 그려집니다.
첫 번째 칸, 전달 방식(Delivery Method) — 이 결정을 누가 보게 할까.
두 가지 중에 골라요.
Web App: 검토 폼을 앱 화면에 바로 띄웁니다. 결재자가 곧 그 앱을 쓰는 사람일 때, 그러니까 "내가 만든 초안을 내가 확인하고 넘긴다" 같은 즉석 검토에 맞아요.
이메일(Email): 지정한 수신자에게 폼을 메일로 보냅니다. 실무 담당자와 승인권자가 다를 때, 예를 들어 팀장 사인이 필요한 상황이죠. 제목과 본문을 원하는 문구로 바꿀 수 있어요.
두 번째 칸, 폼 내용(Form Content) — 결재자에게 뭘 보여주고, 뭘 입력받을까.
이 칸이 사실상 핵심이에요. 세 부분으로 다시 나뉩니다.
본문 영역: 마크다운으로 씁니다. 앞 노드의 변수를 그대로 끌어와 꽂을 수 있어서, "사용자가 던진 질문"이나 "LLM이 뽑은 답변" 같은 동적인 데이터를 결재 화면에 실시간으로 보여줄 수 있어요.
입력 필드: 본문 안에서
⌘/(윈도우는Ctrl/)를 누르면 편집 가능한 입력창이 박힙니다. 비워 두면 새로 받는 칸이 되고, LLM 초안을 미리 채워 두면 결재자가 그 자리에서 고치는 칸이 돼요. 이 필드 이름이 그대로 다음 노드로 넘어가는 출력 변수가 됩니다.결정 버튼: 버튼의 개수와 이름을 직접 정해요(예: 승인 / 반려 / 위임). 버튼 하나가 워크플로우 분기 하나예요. 결재자가 누른 버튼에 따라 흐름이 갈라집니다.
세 번째 칸, 타임아웃(Timeout Policy) — 아무도 응답하지 않으면.
대기 시간을 걸어 두면, 그 시간이 지날 때 워크플로우를 자동으로 끝낼 수도 있고, 아예 타임아웃 전용 분기를 따로 파서 처리하게 할 수도 있어요. 리마인더를 한 번 더 보내거나, 다른 담당자에게 넘기는 식으로요. 결재가 무한정 공중에 떠 있지 않게 잡아 주는 안전핀입니다.
실제로 한 번 그려 보기: 영업 리포트 승인 라인
말로만 보면 감이 안 오니, Dify 공식 예시를 우리 상황으로 옮겨 볼게요. "지난달 북미 영업 실적 좀 보여줘" 같은 요청을 받아 리포트를 만들고, 팀장 승인을 거쳐 내보내는 워크플로우예요.
데이터 준비 — 사용자 입력 노드가 질문을 받습니다.
분석 — 지식 검색 노드가 영업 데이터를 끌어오고, LLM이 1차 리포트를 씁니다.
팀장 승인(Human Input ①) — 여기가 결재 라인이에요.
전달 방식: 이메일 → 팀장
폼에 표시: 사용자 질문 + LLM 분석 + 코멘트 입력칸
버튼: 승인 / 재생성 / 위임
타임아웃: 3일
버튼별로 흐름이 이렇게 갈라져요.
승인 → LLM 분석을 그대로 사용자에게 반환
재생성 → 팀장이 남긴 코멘트를 LLM에 다시 물려 새 분석을 생성 (이때 코멘트 변수가 다음 LLM 노드로 넘어갑니다)
위임 / 3일 초과 → 다른 동료에게 넘기는 두 번째 결재(Human Input ②)로 승격 — 이번엔 버튼을 승인 / 반려로 단순화
마지막 처리까지 정하면 끝이에요. 동료가 승인하면 결과 반환, 반려하거나 또 응답이 없으면 "완료할 수 없습니다. 관리자에게 문의하세요"로 닫습니다.
눈치채셨겠지만, 이 그림이 맨 앞에서 본 규제의 3단계(사람만 / 승인 후 / 자율)와 그대로 포개져요. '승인이 필요한 결정'을 노드로 표시하고, 사람의 개입 지점을 실행 그래프 안에 박아 넣는 것. 규제 대응의 무게중심이 문서에서 워크플로우 설계로 옮겨왔다는 뜻이에요.
자체 시스템에 물릴 거라면
사내 툴에 이 승인 흐름을 코드로 붙일 계획이라면 딱 하나 기억해 두세요. 워크플로우가 Human Input 노드에 닿으면 스트리밍 응답에 human_input_required 이벤트가 뜨고, 거기 담긴 form_token으로 폼 제출까지의 생명주기를 제어하게 됩니다. 단, 이 form_token은 Web App 방식으로 띄운 폼에서만 나와요. 이메일 전용 전달에는 토큰이 실리지 않으니, API 연동을 염두에 뒀다면 전달 방식을 Web App으로 잡아야 합니다.
분기 설계도 유연합니다. Dify 공식 블로그의 예시를 보면 노드 하나로 가장 흔한 승인 패턴을 전부 커버해요. 바로 승인해서 다음 단계로 보내는 경로, 피드백을 달아 다시 생성시키는 경로, 다른 담당자에게 전달하는 경로, 정해진 시간 안에 아무도 응답하지 않으면 기본 경로를 타게 하는 타임아웃 폴백까지 만들 수 있죠. 눈치채셨겠지만 이 구조, 위에서 본 규제의 요구사항과 정확히 포개집니다. '승인이 필요한 결정'의 구간을 워크플로우 위에 노드로 표시하고 사람의 개입 지점을 실행 그래프 안에 박아 넣는 것. 규제 대응의 무게중심이 문서에서 워크플로우 설계로 옮겨왔다는 뜻이에요.
우리 팀 에이전트를 한번 떠올려 보세요. 지금 그 에이전트가 내리는 결정을 세 단계로 나눈다면 어디까지가 '알아서 해도 되는 일'이고 어디부터가 '결재가 필요한 일'일까요. 그 선을 긋는 작업이 아마 올해 하반기 AI 운영에서 꽤 큰 숙제가 될 거예요. 자동화의 다음 경쟁력은 속도가 아니라 어디서 멈출지 아는 감각일지도 모르니까요.