HITL 설계 가이드: AI 에이전트의 승인과 검토는 어디에 둘까

잘못 실행했을 때 손실이 크거나 되돌리기 어려운 AI 작업이라면, 실행 전에 사람이 판단하도록 해야 합니다. HITL, 즉 휴먼 인 더 루프에는 유용한 검토 지점이 3가지 있습니다. 실행 전 승인, 완료된 작업의 표본 검토, 예외 상황에서 사람이 넘겨받는 인계입니다. 각 작업에 맞는 지점을 정하고, 해당 작업에 대한 근거가 충분히 쌓였을 때만 반복적인 승인을 줄입니다.

HITL(휴먼 인 더 루프)이란 무엇인가요?

사람의 검토를 설계한다는 것은 권한을 정하는 일입니다. 사람이 먼저 동의하지 않아도 시스템이 실행할 수 있는 작업은 무엇일까요? 고객 지원 에이전트는 같은 대화 안에서 주문을 조회하고, 답변을 작성하고, 기록을 수정하고, 환불까지 처리할 수 있습니다. 이 작업들에 모두 같은 권한을 부여해서는 안 됩니다.

입구를 지키는 관리인이 있는 정원을 떠올려 보겠습니다. 관리인은 방문객의 발걸음을 일일이 확인하지 않습니다. 훼손되면 복구하기 어려운 곳에서는 출입을 통제하고, 일상적인 작업은 나중에 살펴보며, 평소와 다른 일이 생겨 호출 벨이 울리면 대응합니다. 핵심은 출입문을 어디에 둘지입니다.

휴먼 인 더 루프의 의미

Human-in-the-loop는 보통 HITL로 줄여 쓰며, 사람이 피드백이나 개입, 의사결정을 통해 AI 시스템의 운영에 참여한다는 뜻입니다. 승인 버튼 하나보다 훨씬 넓은 개념입니다. 실제 업무에서는 이를 구체적인 책임으로 정의해야 합니다. 누군가는 제안된 작업을 승인하고, 완료된 작업을 검토하거나, 예외 상황을 해결해야 합니다. Stanford HAI의 정의를 참고할 수 있습니다.

학습 데이터에 라벨을 붙이거나 모델의 출력을 바로잡고 학습 방향을 이끄는 사람의 역할도 이 용어에 포함됩니다. 모두 적절한 용례입니다. 다만 사람이 오늘 환불을 승인했다고 해서 내일의 모델이 자동으로 재학습되는 것은 아닙니다. 운영 중 검토는 근거를 남기는 과정이며, 모델이나 워크플로를 개선하려면 별도의 의도적인 절차가 필요합니다. Google Cloud의 설명에서도 이 개념을 다룹니다.

에이전트형 AI에서 사람은 어디에 개입하나요?

AI 에이전트는 모델을 이용해 수행할 단계를 선택하고, 주문 조회나 메시지 발송 같은 툴을 호출하는 소프트웨어입니다. 사람의 검토는 중요한 결과를 낳는 툴 호출 직전에 두어야 합니다. 처음에 에이전트의 계획을 승인하는 것만으로는 나중에 어떤 수신자, 금액, 기록을 선택할지 알 수 없습니다.

각 단계를 연결하고 조정하는 방식도 명확히 정해야 합니다. AI 에이전트 오케스트레이션에서는 에이전트의 작업에 상태 저장, 책임 주체, 인계가 어떻게 맞물리는지 설명합니다.

사람이 개입할 수 있는 세 지점

승인은 특정 작업의 실행을 막는 데, 표본 검토는 완료된 작업의 패턴을 찾는 데, 에스컬레이션은 에이전트의 권한을 벗어난 사안을 해결하는 데 사용합니다. 하나의 워크플로에 이 통제 방식을 함께 적용할 수 있습니다.

실행 전: 승인

시스템은 실행할 작업의 구체적인 내용을 준비한 뒤 기다립니다. 검토자는 수신자나 대상 기록, 제안된 변경 사항, 관련 근거, 검토가 필요해진 규칙을 확인합니다. 승인하면 해당 작업을 실행하고, 거절하면 실행하지 않습니다.

환불, 민감한 고객 응대, 되돌릴 수 없는 삭제에 적합한 방식입니다. 검토 화면에 “고객 지원 툴을 허용할까요?”라고만 표시하면 실제로 어떤 업무 판단을 하는지 알 수 없습니다. “이 사유로 이 주문을 원래 결제 수단에 환불합니다”라고 보여줘야 검토할 내용이 분명해집니다.

실행 후: 표본 검토

시스템이 이미 허용된 범위 안에서 작업을 실행하고, 사람이 나중에 일부 결과를 골라 확인합니다. 티켓 분류나 내부 요약처럼 간혹 오류가 발생해도 발견할 수 있고 그 영향을 감당할 수 있는 작업에 적합합니다.

표본 검토는 검토 대상이 된 오류 자체를 예방할 수 없습니다. 고객에게 보낸 메시지를 정정해 대화를 수습할 수는 있어도, 고객이 원래 메시지를 읽었다는 사실까지 되돌릴 수는 없습니다. 자동화 여부를 정할 때는 이처럼 남는 피해도 고려해야 합니다.

일상적인 품질을 파악할 때는 무작위 표본을 사용하고, 특이 사례는 별도의 표적 표본으로 검토합니다. 불만이 접수된 사례만 살펴보면 신고된 실패는 알 수 있지만, 완료된 전체 작업의 품질은 알 수 없습니다.

예외 발생 시: 사람에게 인계

에스컬레이션은 에이전트에게 필요한 근거나 권한, 적용할 규칙이 없을 때 사안을 담당자에게 넘기는 절차입니다. 계정 소유권을 두고 정보가 충돌하거나, 주문 데이터가 없거나, 정책상 예외에 해당하거나, 고객이 명시적으로 사람과의 상담을 요청하는 경우가 이에 해당합니다.

넘겨받는 담당자에게 근거, 시도한 작업, 해결되지 않은 질문, 현재 상태를 함께 전달합니다. 판단이 필요한 작업은 보류합니다. 내부 요약 작성처럼 안전하다고 명시적으로 정한 다른 작업은 정책이 허용하는 경우 계속할 수 있습니다.

Human Over the Loop는 무엇을 뜻하나요?

이 표현을 접하면 규칙을 정하고, 권한을 바꾸며, 시스템을 중단할 수 있는 사람의 거버넌스 역할을 가리키는 말로 이해하면 됩니다. 용어의 쓰임은 제각각이므로 이름에 기대기보다 책임을 명시해야 합니다. 성과를 감독하는 관리자가 개별 거래까지 검토하는 것은 아닙니다.

같은 이유로 in the loop의 승인과 on the loop의 모니터링을 구분해야 합니다. 대시보드가 문제를 빠르게 드러낼 수는 있습니다. 하지만 별도로 구현하지 않으면 다음 작업의 실행을 멈추지는 못합니다.

오류의 비용과 복구 가능성으로 판단합니다

발견하고 복구하기 전까지 감당할 수 있는 수준보다 예상 가능한 피해가 크다면 승인을 요구해야 합니다. 모델의 확신도만으로는 이 질문에 답할 수 없습니다.

다음 관점에서 작업을 평가합니다.

• 결과: 개인정보가 노출되거나, 돈이 이동하거나, 약속이 생기거나, 계정 접근 권한에 영향을 줄 수 있나요?
• 복구: 고객에게 수습을 떠넘기지 않고 이전 상태를 빠르고 완전하게 복원할 수 있나요?
• 영향 범위: 내부 초안에만 영향을 주나요, 고객에게 영향을 주나요, 아니면 여러 기록을 한꺼번에 바꾸나요?
• 근거: 신원, 원본 데이터, 정책이 판단할 수 있을 만큼 명확한가요?
• 탐지: 비슷한 작업이 누적되기 전에 문제가 생겼다는 사실을 알 수 있나요?

데이터베이스 필드를 되돌릴 수 있어도 그 변경이 촉발한 후속 사건은 되돌리지 못할 수 있습니다. 배송지 변경도 주문 이행이 시작되기 전까지만 쉽게 취소할 수 있습니다. 데이터베이스에 되돌리기 기능이 있는지만 볼 것이 아니라 전체 결과를 판단해야 합니다.

작업 범위가 제한되어 있고 근거가 신뢰할 만하며 남는 피해를 감당할 수 있다면 표본 검토를 사용합니다. 결과가 중대하거나 복구가 어렵다면 실행 전 승인을 적용합니다. 필요한 사실이나 규칙이 없으면 담당자에게 넘깁니다. 금지된 작업은 차단해야 합니다. 승인 대기열이 정책을 우회하는 통로가 되어서는 안 됩니다.

입력, 출력, 툴 호출을 자동으로 점검하는 AI 가드레일은 이런 설계를 뒷받침합니다. 잘못된 형식의 요청이나 허용되지 않은 목적지는 사람이 검토에 시간을 쓰기 전에 거부할 수 있습니다. 사람의 판단은 그 점검을 거친 뒤에도 남는, 실제로 판단이 필요한 모호함에 집중해야 합니다.

휴먼 인 더 루프 적용 사례: 고객 지원 에이전트

고객 지원 에이전트의 권한은 작업 유형별로 나눕니다. 아래는 주문 지원 업무에 에이전트를 도입하는 기업을 위한 가상의 초기 정책입니다. 설계 예시이며, 공급업체의 기본 설정이나 실제 측정 결과를 보고한 내용이 아닙니다.

고객이 주문 상품을 받지 못했다며 환불을 요청했다고 가정해 보겠습니다. 에이전트는 주문과 배송업체의 상태를 조회한 뒤 권고안을 준비할 수 있습니다. 배송 근거가 고객의 설명과 충돌하면 임의로 결론을 내리지 않고 판단을 담당자에게 넘깁니다.

근거상 정책에 따른 환불이 가능하면 에이전트는 정확한 주문, 금액, 환불 목적지, 사유를 정리해 승인을 요청합니다. 실행 구성요소는 결제 시스템을 호출하기 전에 승인과 현재 환불 상태를 확인합니다. 이어 반환된 거래 영수증을 기록합니다. 그 뒤에야 에이전트가 환불이 완료되었다고 말할 수 있습니다.

환불 승인과 답변 승인은 서로 다른 권한입니다. 금전 거래를 승인했다고 해서 함께 보내는 이메일에 근거 없는 배송 약속을 넣어도 되는 것은 아닙니다. 마찬가지로 고객을 안심시키는 메시지를 승인했다고 해서 다음 툴 호출에 숨겨진 환불까지 허용한 것은 아닙니다.

영업 목적의 아웃바운드 이메일에도 같은 구분을 적용합니다. 문안은 자동으로 생성하되, 새로운 수신자 목록에 발송할 때는 검토하도록 할 수 있습니다. 데이터 변경에서는 “기록을 정리했습니다”라는 요약 대신 기존 값과 제안된 값의 실제 차이를 검토해야 합니다.

실제로 처리할 수 있는 검토 대기열을 만듭니다

검토자에게는 판단에 필요한 자료, 처리 기한, 거절할 권한이 있어야 합니다. 채팅 채널에 승인 버튼을 넣는 것으로 해결되는 것은 알림 단계뿐입니다.

검토 자료에는 정확한 작업 내용, 영향을 받는 고객이나 기록, 제안된 인수, 원본 근거, 정책 부합 여부, 확인되지 않은 사실이 들어가야 합니다. 수정안 옆에는 이전 값을 함께 보여줍니다. 검토자가 전체 대화를 다시 구성하지 않아도 에이전트의 설명을 확인할 수 있도록 원본 근거를 링크합니다.

주 검토자와 부재 시 대신 맡을 책임자를 지정합니다. 긴급한 에스컬레이션과 일상적인 승인 요청은 분리합니다. 검토 기한이 지나면 대기 중인 작업을 보류하거나 취소하고 대체 책임자에게 알립니다. 응답이 없다는 이유로 허용해서는 안 됩니다.

처리 용량에는 분명한 한계가 있습니다. 가상의 대기열에서 시간당 요청 24건 × 건당 검토 3분 = 시간당 검토 시간 72분입니다. 검토자 한 명에게 주어진 시간은 다른 업무를 제외하기 전에도 60분뿐입니다. 모든 판단이 정확해도 대기열은 계속 늘어납니다. 응답 시간을 약속하기 전에 불필요한 승인을 줄이거나, 에이전트의 범위를 좁히거나, 검토 인력을 늘려야 합니다.

승인은 검토한 정확한 결과물과 인수에 연결합니다. 수신자, 환불 금액, 기록 버전, 메시지가 바뀌면 기존 결정을 무효화하고 다시 검토를 요청합니다. 실행 전에는 대기하는 동안 달라졌을 수 있는 사실도 재확인합니다. 예를 들어 다른 담당자가 이미 해당 주문을 환불했는지 확인해야 합니다.

검토 결정을 두 번 받아도 안전해야 합니다. 변하지 않는 작업 식별자를 사용하고, 결정은 한 번만 소비하며, 외부 시스템에 대한 쓰기가 중복되지 않도록 보호합니다. 멱등한 작업이란 반복해서 실행해도 한 번 실행했을 때와 효과가 같은 작업을 뜻합니다. 환불 요청이 시간 초과되면 다시 결제를 시도하기 전에 실제 처리 상태부터 대조해 확인합니다.

주요 툴은 HITL을 위해 에이전트를 어떻게 멈추나요?

툴마다 일시 중지 방식은 다르지만, 판단 규칙은 여전히 기업이 정해야 합니다. 아래 설명은 2026년 10월 21일 각 제작사의 당시 공개 문서를 기준으로 확인했습니다. 문서에 명시된 동작을 설명하며, 제품을 직접 사용해 시험한 결과는 아닙니다.

OpenAI Agents SDK: 대기 중인 툴 호출 승인

OpenAI Agents SDK는 애플리케이션 코드에서 에이전트를 만드는 라이브러리입니다. Python에서는 needs_approval=True, JavaScript에서는 needsApproval: true로 툴 승인을 지원합니다. 승인이 필요한 호출은 중단 정보와 재개 가능한 상태를 반환합니다. 애플리케이션이 대기 중인 항목을 승인하거나 거절한 다음 같은 실행을 재개합니다. 판단이 늦어질 경우를 위해 상태를 직렬화할 수도 있습니다. OpenAI 승인 문서에서 확인할 수 있습니다.

고객 지원 애플리케이션에서는 환불 툴이나 발송 툴에 승인 단계를 둡니다. 검토 인터페이스는 대기 중인 작업을 중심으로 구성합니다. 문서의 짧은 예시는 반환된 중단 항목을 코드에서 승인합니다. 이 무조건 승인 반복문을 그대로 복사해서는 사람의 검토가 이루어지지 않습니다. 애플리케이션이 먼저 사람의 결정을 받아야 합니다.

LangGraph: 저장된 작업 중단과 재개

상태를 유지하는 에이전트 워크플로용 라이브러리인 LangGraph는 interrupt()로 실행을 멈추고 외부 입력을 기다립니다. 실행 상태를 저장하는 구성요소인 영속 체크포인터와 안정적으로 유지되는 thread_id를 설정합니다. 재개할 때는 같은 스레드에서 Command(resume=...)를 사용합니다. LangGraph 중단 문서에 설명되어 있습니다.

실제 운영에서 주의할 점도 문서에 명시되어 있습니다. 중단된 노드는 재개 시 처음부터 다시 실행됩니다. 따라서 중단 지점 앞의 코드가 다시 실행될 수 있습니다. 외부 상태를 바꾸는 작업은 검토 지점 뒤에 두고, 반복 실행해도 안전하게 만들어야 합니다. 문서에서는 이런 작업을 별도의 노드로 분리하는 방법도 권장합니다. 중단 상태는 무기한 유지될 수 있으므로, 그 바깥에 업무상 검토 기한과 에스컬레이션 처리를 추가해야 합니다.

n8n: 선택한 툴에 사람의 검토 연결

시각적 워크플로 자동화 플랫폼인 n8n에서는 AI Agent 노드에 연결된 툴 중 일부를 골라 사람의 검토를 붙일 수 있습니다. 문서에 따르면 실행을 멈춘 뒤 제안된 툴과 매개변수를 보여주며, 승인하면 AI가 지정한 입력으로 실행하고 거절하면 작업을 취소합니다. n8n의 사람 검토 가이드를 참고할 수 있습니다.

에이전트의 Tools 커넥터를 열고 Human review에서 채널을 선택한 뒤, 검토가 필요한 툴을 그 단계에 연결합니다. 가이드에는 지원 채널로 n8n Chat과 Slack 등이 나와 있으며, 검토 메시지를 구성할 때 쓰는 $tool.name과 $tool.parameters도 설명되어 있습니다.

이 메시지로 검토자가 무엇을 승인하는지 분명히 보여줘야 합니다. 해당 가이드는 승인과 거절을 설명합니다. 수정 가능한 환불 양식까지 제공한다고 가정해서는 안 됩니다. 검토자가 변경을 요구하면 제안 내용을 수정 단계로 돌려보낸 뒤 다시 승인받도록 구성합니다.

Anthropic Claude Code: 툴 접근을 제어하는 권한 모드

코딩 에이전트인 Anthropic Claude Code는 툴 권한 모드를 문서화하고 있습니다. Manual로 표시되는 default는 허용된 작업과 규칙에 따른 예외를 제외하고 권한 확인 메시지를 띄웁니다. acceptEdits는 허용된 작업 디렉터리 안에서 파일 편집과 특정 파일 시스템 명령을 자동으로 허용합니다. plan은 소스 파일을 수정하지 않고 탐색합니다. Claude Code 권한 문서에서 확인할 수 있습니다.

auto 모드는 셸 명령이나 네트워크 요청 같은 작업에 백그라운드 분류기를 사용합니다. 이는 자동화된 검토 판단입니다. bypassPermissions는 어느 모드에서도 자동 승인하지 않는다고 문서에 명시된 작업을 제외하고 권한 확인 메시지를 건너뜁니다. 어느 쪽도 사람이 각 작업을 검토했다는 근거는 아닙니다.

이 설정들은 Claude Code의 실행 시 권한을 관리합니다. 고객 지원 서비스에는 여전히 환불, 수신자, 데이터 접근에 관한 자체 규칙이 필요합니다. Claude 권한 확인 생략 가이드는 이 모드의 운영상 경계를 더 좁은 범위에서 설명합니다.

무엇을 로그로 남겨야 하나요?

누가 어떤 작업을 허가했고 그 뒤에 무슨 일이 일어났는지 재구성할 수 있을 만큼 구조화된 근거를 남깁니다. 대화 기록만으로는 어렵습니다. 특히 처리가 중단되거나 담당자가 바뀌면 더 그렇습니다.

다음 항목을 각각 별도의 이벤트로 기록하고, 사례 식별자와 작업 식별자로 연결합니다.

• 제안: 작업 유형, 대상, 정확한 인수, 결과물의 버전 또는 다이제스트, 이전 값, 근거가 되는 원본 참조를 기록합니다. 다이제스트는 검토한 콘텐츠의 지문에 해당합니다.
• 판단 경로: 정책 버전, 적용된 규칙, 승인 또는 표본 검토 요건, 에스컬레이션 사유, 관련 검증 결과를 기록합니다.
• 사람의 결정: 인증된 검토자, 해당 작업에 대한 권한, 승인 또는 거절 결과, 요청한 수정 사항, 이유, 타임스탬프, 만료 시점을 기록합니다.
• 실행: 승인된 작업 식별자, 워크플로 및 모델 설정 버전, 시도 식별자, 툴 결과, 외부 시스템의 처리 확인 내역, 최종 상태를 기록합니다. 실패, 성공, 결과 미확인을 구분합니다.
• 품질 검토: 해당 사례가 표본에 포함된 방식, 발견한 오류 유형, 심각도, 시정 조치, 권한 규칙의 변경 여부를 기록합니다.
• 대기열 상태: 요청 도착 시간, 배정된 책임자, 대기 시간, 실제 검토 시간, 기한 초과 여부, 인계 결과를 기록합니다.

민감한 근거 자료의 접근 권한을 제한하고, 비밀정보를 가리며, 보존 규칙을 정합니다. 모든 로그에 모든 고객 데이터를 복사하기보다 가능한 경우 보호된 원본 기록을 링크합니다. 판단 이유와 근거는 간결하게 남깁니다. 승인을 감사하기 위해 모델의 숨겨진 추론이 필요한 것은 아닙니다.

책임 주체, 금지된 작업, 에스컬레이션 책임은 AI 허용 사용 정책에 명시합니다. 로그는 그 정책을 지켰는지 기록하는 수단입니다. 아무도 작성하지 않은 정책을 로그가 대신할 수는 없습니다.

작업 유형별로 검토를 줄입니다

좁은 범위에서 검증된 능력부터 자동 실행으로 전환하고, 새롭거나 결과가 중대한 작업은 계속 검토합니다. 전체적인 “에이전트 정확도” 점수에는 성격이 다른 위험이 섞여 있으므로 권한 변경의 근거로는 부족합니다.

1. 1

   작업 제안부터 시작합니다

   에이전트는 실행할 작업의 초안을 만들고, 결정은 사람이 맡습니다. 잘못된 수신자, 근거 없는 주장, 틀린 금액, 근거 누락, 불필요한 에스컬레이션처럼 오류 유형을 분류합니다. 이 사례들로 대표성 있는 평가 데이터셋을 만들고 적절한 접근 통제를 적용합니다.

2. 2

   정해진 범위 안에서 승인 후 실행합니다

   승인을 받아야만 실행할 수 있게 합니다. 거절하면 작업이 차단되는지, 인수가 바뀌면 승인이 무효화되는지, 같은 결정을 중복 수신해도 쓰기 작업이 반복되지 않는지 확인합니다. 접근 권한을 넓히기 전에 시간 초과와 외부 처리 결과가 불확실한 상황을 시험합니다.

3. 3

   적합한 작업을 표본 검토로 전환합니다

   확인된 데이터를 바탕으로 보내는 일상적인 주문 상태 답변처럼 구체적인 범주를 선택합니다. 결과를 보기 전에 허용 기준, 표본 선정 방식, 검토 책임자, 중단 조건을 정합니다. 반드시 담당자에게 넘겨야 하는 조건은 계속 유지합니다.

4. 4

   조건이 바뀌면 검토를 복원합니다

   모델, 프롬프트, 정책, 툴, 데이터 소스가 바뀌면 영향을 받는 권한을 재평가해야 합니다. 심각한 사고가 발생하거나 표본 검토 결과가 나빠지면 조사하는 동안 해당 승인 단계를 복원합니다.

작업 범주별로 피해를 일으킨 오류, 검토자의 수정, 누락된 에스컬레이션, 복구에 든 노력을 추적합니다. 표현만 다듬은 수정과 피해를 막은 수정을 구분합니다. 검토한 작업 수와 검토 대상이 될 수 있었던 전체 모집단을 모두 기록합니다. 표본의 오류율은 실제 검토한 작업을 분모로 계산하고, 무작위 표본과 표적 표본은 분리합니다. 일부 성공 사례를 검토했다는 사실만으로 시스템 전체의 신뢰성이 입증되지는 않습니다.

승인율만으로는 부족합니다. 검토자는 작업의 품질이 좋아서 승인할 수도 있지만, 검토 자료에 정보가 부족하거나 대기열을 감당하기 어려워서 승인할 수도 있습니다. 검토 결정 자체도 주기적으로 점검해야 합니다. 사람이 참여하면 오류를 잡을 기회가 생길 뿐, 반드시 잡는다는 보장은 없습니다.

휴먼 인 더 루프에 대한 과장된 기대

“사람이 개입합니다”라는 설명은 그 사람이 무엇을 보고 무엇을 막을 수 있는지 알기 전까지는 불완전합니다. 환불이 끝난 뒤 알림을 받는 사람은 사후 감독을 하는 것이지, 실행 전에 승인하는 것이 아닙니다.

“신뢰가 쌓일 때까지 모두 승인받자”는 접근도 충분하지 않습니다. 명확한 기준이 없으면 피로만 커지고, 조급함에 따라 권한을 넓히게 됩니다. 신뢰는 작업별 근거와 믿을 수 있는 복구 체계에서 나와야 합니다.

사람의 피드백만으로 시스템이 저절로 개선되는 것도 아닙니다. 누군가는 수정 내용을 더 나은 원본 데이터, 명확한 규칙, 개정된 프롬프트, 평가를 거친 모델 변경으로 이어가야 합니다. 검토 절차의 책임자를 정할 때는 이 업무까지 포함해야 합니다.

다음 업무일부터 무엇을 시작하면 좋을까요?

운영 담당자는 에이전트가 할 수 있는 작업을 목록으로 만들고, 각각에 검토 지점을 배정해야 합니다. 고객 지원 예시 표에서 시작해 실제 승인자를 정하고, 서비스를 약속한 시간 동안 대기열을 책임질 사람이 있는지 확인합니다.

개발자는 실행 시점에 규칙을 강제해야 합니다. 제안된 작업을 저장하고 승인을 해당 버전에 연결합니다. 거절, 만료, 중복 결정, 인수 변경이 발생했을 때 올바르게 동작하는지 검증합니다. 모델이 자신의 작업을 스스로 승인할 수 없게 해야 합니다.

창업자와 구매 담당자는 작업이 거절되는 상황과 아무도 검토하지 않아 기한이 만료되는 상황의 시연을 요청해야 합니다. 이 사례를 보면 시스템에 실제 운영 통제가 있는지, 승인 알림만 있는지 드러납니다.

에이전트가 명확한 경계 없이 이미 메시지를 보내거나, 돈을 이동시키거나, 고객 데이터를 바꿀 수 있다면 바로 조치해야 합니다. 정책이나 검토 인력 문제가 해결되지 않았다면 자율 범위를 넓히는 일은 미룹니다. 외부에 작업을 실행할 수 없는 내부 초안 작성 도우미라면 새로운 승인 시스템보다 일반적인 편집 검토가 적합할 수 있습니다.

사람의 AI 검토에 관한 자주 묻는 질문

AI에서 휴먼 인 더 루프는 무엇인가요?

사람이 검토, 피드백, 의사결정을 통해 AI 시스템의 운영에 참여한다는 뜻입니다. 업무를 수행하는 에이전트라면 실행 전에 사람이 승인하는지, 완료된 작업을 표본 검토하는지, 예외 상황을 처리하는지 구체적으로 정해야 합니다.

사람이 루프 안에 있다는 것은 어떤 의미인가요?

사람의 판단이 절차에 명시적으로 포함되어 있다는 뜻입니다. 실효성 있게 구현하려면 검토자가 누구인지, 어떤 결정을 맡는지, 어떤 근거를 보는지, 기다리는 동안 시스템은 무엇을 하는지 정해야 합니다.

휴먼 인 더 루프와 에이전트형 AI는 같은 개념인가요?

에이전트형 AI에 적용할 수 있지만 같은 개념은 아닙니다. 에이전트는 수행할 단계를 선택하고 툴을 사용합니다. 휴먼 인 더 루프는 그 작업의 어느 지점에서 사람이 영향을 미치거나 실행을 허가하는지 설명합니다.

AI 운영에 사람의 판단을 계속 반영하려면 어떻게 해야 하나요?

중대한 결과를 낳는 툴 호출에 승인 단계를 두고, 에스컬레이션을 받을 담당자를 배치하며, 검토 대상에 해당하는 완료 작업에서 미리 정한 방식으로 표본을 뽑아 검토합니다. 결정과 결과를 기록한 뒤, 작업 범주별 근거를 바탕으로 권한을 조정합니다.

AI가 반복 루프에 빠지는 이유는 무엇인가요?

에이전트 워크플로에서는 재시도나 툴 선택이 반복되거나 인계가 해결되지 않아 진행이 멈출 수 있습니다. 중단 조건과 에스컬레이션 책임자를 정해야 합니다. 이런 실패 루프는 이 글에서 다룬 의도적인 사람의 검토 절차와는 다릅니다.

AI를 실제 업무 워크플로에 적용하는 실용적인 가이드를 받아보려면 뉴스레터를 구독하세요.