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

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

AI 조직을 위한 FabricLoop의 자체 프레임워크는 인간 개입률을 분명하게 정의합니다. 자동화된 작업이 얼마나 자주 사람을 필요로 하는가입니다. 그것이 정의이고, 이 글도 거기에서 벗어나지 않습니다. 이어지는 내용은 개념 페이지에서 충분히 풀어 쓰지 않은 부분, 즉 실제 계산입니다. 하나의 현실적인 워크플로에 적용해, 이 개념을 희망 사항이 아닌 구체적인 숫자로 보여 드립니다.

이 숫자가 실제로 재는 것

인간 개입률(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. "문제없음" 샘플을 정기적으로 다시 확인하십시오. 개입이 필요 없다고 기록된 행동을 주기적으로 뽑아, 문제없음으로 표시되었다는 사실을 모르는 사람에게 다시 검토하게 하십시오. 검토자가 아직 제대로 읽고 있는지 직접 확인할 수 있는 유일한 방법입니다.