인간 개입률: AI 도입이 실제로 작동하는지 알려 주는 단 하나의 지표

프로덕션에서 AI 에이전트를 돌리는 회사 대부분은, 그 에이전트가 실제로 얼마나 자주 사람의 손을 필요로 하는지 말하지 못합니다. 인간 개입률은 그 질문에 답하는 숫자입니다. 이 글을 끝까지 읽으면, 이미 돌리고 있는 워크플로 하나에 대해 직접 계산할 수 있어야 합니다.

FabricLoop가 AI 조직을 위해 둔 틀은 인간 개입률을 분명하게 정의합니다. 자동화된 일이 얼마나 자주 사람을 필요로 하는가. 그것이 정의이고, 이 글도 거기에서 벗어나지 않습니다. 이어지는 내용은 개념 페이지가 끝까지 풀어 쓰지 않은 부분입니다. 실제 계산을 하나의 현실적인 워크플로에 적용하고, 바람이 아니라 숫자로 만드는 일입니다.

이 숫자가 실제로 재는 것

인간 개입률(HIR)은 정의된 하나의 워크플로와 하나의 기간 안에서, 결과가 끝난 것으로 서기 전에 사람이 개입해야 했던 에이전트 행동의 몫입니다. 여기서 “개입”은 뜻이 분명합니다. 사람이 출력을 고쳤거나, 에이전트가 내린 결정을 뒤집었거나, 진행하기 전에 에이전트가 명시적으로 던진 질문에 답한 경우입니다. FabricLoop의 Loop Agent가 ask_human 순간이라고 부르는 것입니다. 그 행동의 건수를 같은 기간에 에이전트가 취한 행동의 총수로 나누면 HIR이 됩니다.

이 지표가 가동률과 정확도 아래가 아니라 옆에 서는 이유는, 그 숫자로는 보이지 않는 것을 재기 때문입니다. 에이전트가 어떤 내부 벤치마크에서 정확도 95%를 찍고도, 틀린 5%가 조용히 통과하고 자신이 없는 20%는 매번 표시되는 에이전트보다 더 나쁜 도입일 수 있습니다. HIR은 에이전트가 잘하는지 묻지 않습니다. 사람이 필요한 때를 시스템이 아는지, 그리고 필요할 때 사람이 실제로 나타나는지를 묻습니다. 도입을 넓혀도 되는지를 결정하는 것은 두 번째 질문입니다.

하나의 실제 워크플로로 HIR 계산하기

IT나 운영 팀이 오늘 실제로 돌릴 수 있는 워크플로를 생각해 보십시오. 들어오는 지원 티켓을 분류하고(결제, 버그 보고, 환불, 계정 접근 등), 1차 답변 초안을 작성하는 에이전트입니다. 모든 초안은 고객에게 가기 전에 검토 대기열에 들어갑니다. 스스로 나가는 것은 없습니다. 그 검토 단계 자체는 개입이 아닙니다. 바꿀 필요가 없던 초안에서 검토자가 «보내기»를 누르는 것은 설계대로 워크플로가 도는 상태입니다. 개입은 초안에 손이 필요했을 때 일어납니다. 검토자가 다시 썼거나, 분류를 고쳤거나, 티켓을 다른 대기열로 돌렸거나, 에이전트 자신이 작업 중간에 멈추고 무엇을 쓰기 전에 질문을 던진 경우입니다.

아래 숫자는 설명을 위한 예이며, 실제 회사의 데이터가 아닙니다. 다만 이야기의 모양과 그 뒤의 계산은, 여러분 자신의 로그로 만들 것과 똑같습니다.

파일럿 달에 에이전트는 640건의 티켓을 건드립니다. 그중 415건이 개입을 필요로 합니다. 다시 쓰기, 재분류, 또는 다른 경로로 보내기입니다. 그 415건 가운데, 무엇을 쓰기 전에 에이전트 자신이 표시한 순간은 75건뿐입니다. 나머지는 검토자가 사후에 잡는 실수입니다. HIR은 64.8%이고, 에스컬레이션 비중은 겨우 18%입니다. 틀릴 때의 대부분을 에이전트는 확신에 차서 틀립니다. 이 문제의 가장 나쁜 형태입니다.

팀은 수정 로그를 꺼내 개입마다 이유를 붙입니다. 두 범주가 두드러집니다. 금액이 끼면 환불 정책을 잘못 읽고, 눈에 띄게 화난 고객에게는 차분하고 절차적인 답변을 씁니다. 둘 다 모델을 건드리지 않고 고칠 수 있습니다. 환불이 50달러를 넘거나 감정 임계값을 넘는 티켓은 초안 대신 ask_human 에스컬레이션을 일으키는 명시적 규칙을 넣습니다. 나머지는 전과 같이 초안을 쓰고 검토합니다.

3개월째가 되면 HIR은 80% 넘게 떨어집니다. 그러나 더 많은 것을 알려 주는 숫자는 에스컬레이션 비중입니다. 18%에서 79%로 올랐습니다. 남은 것의 대부분은 에이전트가 틀린 채로 잡히는 일이 아닙니다. 정말로 모호한 경우(VIP 계정, 정책 예외, 임계값 바로 위의 환불)를 에이전트가 올바르게 알아채고, 행동하기 전에 묻는 일입니다. 하락은 진짜이고, 벌어 낸 것입니다. 수정이 돌아올 때마다 명시적 규칙으로 들어갔고, 그래서 그 수정을 낳은 구체적인 실수는 반복되지 않습니다. 여전히 판단이 필요한 범주는 초안으로 피해 가지 않고 계속 표시됩니다.

실수: 0을 목표로 삼는 것

팀이 HIR이 달마다 떨어지는 것을 보기 시작하면, 다음 질문은 당연해 보입니다. 얼마나 낮아질 수 있는가. 본능은 0을 결승선으로 삼는 것입니다. 에이전트가 드디어 감독 없이 돌릴 만큼 좋아졌다는 증거라고 말입니다. 그 본능은 거꾸로이고, 이 지표를 가장 흔히 잘못 읽는 방식입니다.

실제 목표는 추상적으로 개입을 줄이는 것이 아니었습니다. 사람의 판단이 필요한 특정 순간만 드러나는 시스템입니다. 그래야 사람의 주의가 정말로 필요한 곳으로 가고, 모든 것에 고르게 나뉘거나 아예 빠지지 않습니다. HIR 12%인데 그 12%의 거의 전부가 정말로 모호하거나 이해관계가 큰 사례를 에이전트가 올바르게 표시하는 흐름은, HIR 2%인데 그 2%의 대부분이 에이전트가 한 번도 표시하지 않은 오류를 검토자가 우연히 발견하는 흐름보다 건강합니다. 더 낮은 숫자가 더 나쁜 시스템을 숨길 수 있습니다.

에스컬레이션 비중은 바로 이것을 위한 것입니다. HIR 옆에서 보면, 여러분이 어떤 이야기 안에 있는지 알려 줍니다.

HIR이 떨어지는데 에스컬레이션 비중이 평평하거나 함께 떨어지면, 아직 성과로 정리하지 마십시오. «개입 불필요»로 기록된 행동을 무작위로 뽑아, 샘플이 깨끗하다고 표시되었다는 말은 하지 않은 채 누군가에게 처음부터 다시 보게 하십시오. 동시에 하류 신호 — 다시 열린 티켓, 불만, 환불 회수, CSAT — 가 같이 올라가는지도 보십시오. HIR은 떨어지는데 하류 문제가 올라가는 것은 더 빨리 배운 시스템이 아닙니다. 제때 아무도 잡지 못한 시스템입니다.

오늘 이것을 재려면 무엇을 계측할 것인가

이것에 필요한 것은 새 도구라기보다 옳은 것을 기록하는 일입니다. 에이전트를 돌리는 팀 대부분은 이미 양을 추적합니다. 몇 건의 티켓을 건드렸는지, 몇 건의 작업을 초안으로 썼는지. 결과를 추적하는 팀은 거의 없습니다. HIR이 실제로 필요로 하는 것은 결과뿐입니다.

1. 활동 건수가 아니라, 행동마다 결과를 기록하십시오. 그대로 보냄, 보내기 전에 수정, 거절 후 다시 작성, 또는 에이전트 자신이 에스컬레이션. 결과 수준의 기록이 없으면 HIR은 계산할 수 없습니다. 에이전트가 무언가를 했다는 것은 알아도, 고쳐야 했는지는 모릅니다.
2. 분자를 고치기 전에 분모를 고정하십시오. 이 워크플로에서 하나의 행동이 무엇인지 정합니다. 건드린 티켓 하나, 초안을 쓴 작업 하나. 기간마다 그 정의를 그대로 두어야 HIR의 변화가 세는 방식의 변화가 아니라 에이전트의 판단을 반영합니다.
3. 개입마다 이유를 붙이십시오. «수정됨»은 거의 아무것도 말하지 않습니다. «수정됨: 50달러 초과 환불 정책을 잘못 적용»은 다음에 무엇을 고칠지 정확히 말합니다. 짧고 일관된 분류는 수정 로그를 점수판이 아니라 할 일 목록으로 바꿉니다.
4. HIR 대신이 아니라 HIR과 함께 에스컬레이션 비중을 추적하십시오. 두 숫자가 함께, 하락이 벌어 낸 것인지 빌려 온 것인지를 말합니다. 위의 추세 표를 보십시오.
5. 0을 목표로 두지 말고 하한을 두십시오. 워크플로마다, 그 안에 있는 실제 모호함을 감안할 때 0이 아닌 그럴듯한 HIR이 어떤 모습인지 정하십시오. 그 하한보다 훨씬 아래로 떨어지는 비율은 축하할 일이 아니라 조사할 일입니다.
6. HIR은 워크플로별로 보고하고, 회사 전체를 섞은 하나의 숫자로 보고하지 마십시오. 하나의 평균은 어떤 워크플로가 실제로 감독을 덜 받아도 되게 되었는지, 어떤 워크플로가 좋아 보이는 헤드라인 숫자 아래에서 조용히 위험을 쌓고 있는지를 숨깁니다.
7. «깨끗한» 샘플을 일정에 맞춰 다시 확인하십시오. 개입이 필요 없다고 기록된 행동을 주기적으로 뽑아, 깨끗하다고 표시되었다는 사실을 모르는 사람에게 다시 보게 하십시오. 검토자가 아직 읽고 있는지를 직접 확인하는 유일한 방법입니다.