사람 검수 단계, 어디에 넣어야 하나

사람 검수 단계, 어디에 넣어야 실패가 줄어드나?

결론부터: 모든 단계에 사람을 넣는 것도, 아예 넣지 않는 것도 최선이 아니다. 위험도와 가역성 기준으로 개입 지점을 나누는 동적 게이트가 완전 자율보다 성공률이 높고, 모든 단계를 사람이 승인하는 정적 방식보다 처리 속도가 빠르다. 2026년 기준 공개된 합성 실험에서 이 구조가 확인됐다.

핵심 요약

동적 개입(위험 기반 게이트): 과제 성공률 98.2%, 사람 개입은 의사결정 단계의 14.5%
완전 자율: 성공률 84.3% — 사람 없는 처리의 한계선
정적 HITL(모든 단계 승인): 성공률 99.1%로 가장 높지만, 동적 방식 대비 처리 지연이 89% 더 큼
검수는 "항상 승인"이 아니라 저위험·가역 작업은 자동 실행, 불확실·비가역 작업은 승인 대기, 실패는 에스컬레이션으로 분리하는 것이 기준
평가는 성공률 하나가 아니라 성공률·개입률·지연시간·수정률을 같은 조건에서 함께 기록해야 비교가 성립한다

이 실험에서 실제로 검증하려는 질문은 "사람 검수를 넣으면 정확도가 오르는가"가 아니다. 정확도는 거의 항상 오른다. 진짜 질문은 "어느 지점에 넣어야 정확도와 처리 속도를 동시에 잃지 않는가"다. 내부에서 반복 작업 자동화를 설계할 때마다 이 경계선을 매번 새로 긋게 되는데, 그 기준을 공개 자료 수치와 함께 정리해본다.

검수 게이트는 어떤 기준으로 나눠야 하나?

작업의 결과가 얼마나 되돌리기 어려운가를 기준으로 세 단계로 나누는 게 실무에서 가장 다루기 쉬웠다. 2026년 조달·재무 업무 가이드는 이를 HITL, HOTL, HOOTL 세 모델로 구분한다.

모델	개입 시점	적용 예
HITL	실행 전 승인·수정	결제 승인, 계약 체결, 공급업체 해지, 민감정보 접근
HOTL	실행 후 사후 검토	송장 분류, 공급업체 통합, 접수 라우팅
HOOTL	자동 처리 + 모니터링만	데이터 보강, 상태 업데이트, 입력 누락 확인

Zip 가이드는 이 구분을 "결정을 되돌릴 수 있는가", "금전 흐름이나 운영 시스템에 영향을 주는가", "보안·개인정보에 관련되는가"라는 세 질문으로 요약한다. 직접 적용해보니 이 세 질문에 "아니오"가 전부인 작업은 사람을 빼도 큰 저항이 없었고, 하나라도 "예"면 승인 화면을 붙이는 식으로 작업 목록을 분류할 수 있었다. 다만 금액 한도처럼 구체적인 숫자 기준은 공개 자료가 제시하지 않는다. 이건 조직마다 다르게 정해야 하는 영역이고, 우리도 처음엔 임의로 정했다가 두 번 조정했다.

검수 화면에는 무엇을 보여줘야 하나?

결론을 요약한 한 줄만 보여주면 검수자가 승인 버튼을 누르는 속도는 빨라지지만, 판단의 질은 떨어진다. 실무 사례는 에이전트의 도구 호출 내역, 호출 인자, 반환 결과, 생성된 산출물, 적용된 규칙을 승인 화면에 함께 남기는 방식을 권장한다. 요약문만 주면 검수자가 실제 처리 과정을 머릿속으로 재구성해야 하는데, 이 재구성 비용이 쌓이면 결국 "대충 승인"으로 흐른다.

여기에 더해 개발자 대상 연구는 모델 최종 답변만 출력하지 말고 현재 단계, 수행한 작업, 사용한 근거, 불확실성, 다음 실행, 승인 필요 여부를 구조화해 보여주라고 제안한다. 실제로 승인 화면에 "입력 원문 / 모델의 제안 / 근거와 출처 / 정책 위반 여부 / 예상 영향 / 되돌리기 방법 / 승인·수정·거부 버튼"을 넣는 구조로 바꾸자, 검수자가 거부하거나 수정하는 비율 자체는 늘었다. 이건 품질이 나빠진 게 아니라, 이전에는 안 보이던 문제가 보이기 시작한 것에 가깝다.

사람에게 넘길 조건은 어떻게 정의하나?

조건은 결과물이 아니라 프롬프트와 정책으로 명시해야 실행 전에 걸린다. 사후에 로그를 보고 "이건 사람이 봤어야 했는데"라고 깨닫는 구조는 검수가 아니라 사고 보고서다. Zip 가이드가 제시하는 조건 형태는 다음과 같다.

금액이 사전 정의한 한도를 초과하면 실행하지 않고 승인 요청
근거 문서가 없거나 서로 상충하면 자동 완료하지 말고 보류
외부 시스템 변경 전 변경 전·후 값을 함께 제시
실패 시 재시도 횟수를 초과하지 말고 담당자에게 전달
사람이 수정한 결과를 곧바로 성공 사례로 학습하지 말고 별도 평가 큐에 저장

마지막 항목은 처음엔 왜 필요한지 몰랐다. 사람이 고친 걸 바로 학습시키면 좋을 것 같았는데, 수정 이유를 검증하지 않고 넣으면 특정 검수자의 습관이나 실수까지 같이 들어간다. 별도 큐에 모아뒀다가 주기적으로 검토하는 쪽이 느리지만 덜 위험했다.

검수 추가 후 무엇을 측정해야 하나?

정확도 하나만 보면 "검수를 넣었더니 좋아졌다"는 결론이 항상 나온다. 당연하다. 사람이 한 번 더 보니까. 문제는 그 대가로 무엇을 잃었는지를 같이 재지 않으면 이 판단이 재현되지 않는다는 점이다. Zip 가이드가 제시하는 실무 지표는 환각률, 목표 달성률, 정책 준수율, 반복 실행 일관성, 사람의 개입·재정의 비율이다. 여기에 검수 대기시간, 승인 거부율, 재작업률, 예외 누락률, 감사 로그 완전성을 더해야 운영 관점의 그림이 완성된다.

동적 개입 실험은 이걸 숫자로 보여준다. 성공률 98.2%와 개입률 14.5%를 같은 테스트 세트에서 동시에 보고했고, 정적 HITL 대비 지연을 89% 줄였다는 수치도 함께 냈다. 성공률만 떼어 보면 정적 HITL(99.1%)이 더 높아 보이지만, 지연까지 같이 보면 어느 쪽이 운영에 맞는지는 업무 성격에 따라 달라진다. 결제 승인처럼 느려도 되는 작업이면 정적 방식이 맞고, 접수 라우팅처럼 속도가 중요한 작업이면 동적 방식 쪽이 맞는 식이다.

이 수치들은 어디서 나온 근거인가?

위 수치는 2026년 발표된 연구에서 합성 기업 자동화 과제 5,000건을 대상으로 측정된 것이다. 해당 연구는 완전 자율, 정적 HITL, 동적 개입 프레임워크 세 방식을 같은 과제 세트에서 비교했고, 학습이 진행되면서 사람 개입률이 첫 단계 21.0%에서 다섯 번째 단계 11.5%로, 상대적으로 45.2% 줄었다는 수치도 함께 제시했다. 조달·재무 업무의 3단계 감독 모델과 승인 화면 구성 원칙은 Zip의 업무 가이드와 dev.to 실무 사례에서 가져왔다. 이 자료들은 실제 제품의 운영 수치가 아니라 연구 데이터셋과 업무 설계 가이드라인이라는 점을 분명히 해야 한다.

이 설계는 어디까지 되고 어디서 막히나?

가장 먼저 막히는 지점은 "검수자가 실제로 역할을 수행할 수 있는가"다. 임상검사실 에이전트 설계 논문은 사람 감독이 의미 있으려면 검수자에게 충분한 시간과 역할별 교육, 시스템 한계에 대한 이해, 추천을 수정·거부할 실제 권한이 있어야 한다고 지적한다. 승인 버튼만 누르도록 큐를 설계하면 검수 단계는 숫자로는 존재하지만 실질적으로는 작동하지 않는다. 이건 의료 외 업무에서도 똑같이 나타나는 문제였다.

두 번째는 위 수치들이 합성 데이터와 특정 프레임워크 조건에서 나왔다는 점이다. 모델 버전, 프롬프트 버전, 도구 목록, 테스트 세트, 검수자 수가 바뀌면 성공률과 개입률은 다시 측정해야 한다. 우리 환경에서 98.2%가 재현된다고 보장할 근거는 없고, 이 글도 그걸 보장하지 않는다. 같은 연구가 강조하듯 이 수치는 "2026년 연구 환경의 결과"로 다뤄야지 특정 제품의 보편적 성능으로 일반화하면 안 된다.

세 번째는 운영 전환 비용이다. 같은 논문이 제안하는 회고 평가·섀도 모드·점진적 통합은 검수 단계를 처음부터 실행 권한에 연결하지 않고, 추천 결과와 실제 담당자 판단을 비교하는 단계부터 시작하라는 뜻이다. 이 단계를 생략하고 바로 실서비스에 붙이면, 검수 게이트가 잘못 설계됐다는 사실을 실패가 난 뒤에야 알게 된다.

반복하면서 무엇을 배웠나?

처음에는 "검수 넣을 작업"과 "안 넣을 작업"을 한 번 정하면 끝이라고 생각했다. 실제로는 사람이 반복적으로 수정하는 분기가 계속 바뀌었고, 그 지점을 새 게이트로 승격하는 작업이 운영의 본체였다. 동적 개입 실험에서 개입률이 21.0%에서 11.5%로 줄어든 것도 같은 이유로 읽힌다 — 게이트 위치 자체가 고정값이 아니라 반복 수정 데이터를 기반으로 업데이트되는 값이라는 것. 검수 단계를 넣는 작업은 한 번의 설계가 아니라, 사람이 어디서 자꾸 고치는지를 계속 관찰하고 그 지점을 옮기는 순환 작업에 가까웠다.

핵심 정리

사람 검수는 "전부 넣기"와 "전부 빼기" 사이에서, 위험도·가역성 기준으로 지점을 나누는 설계가 기준이다
승인 화면에는 결론뿐 아니라 도구 호출 내역·근거·예상 영향·되돌리기 방법을 함께 보여줘야 검수 품질이 유지된다
사람에게 넘길 조건(금액 한도, 근거 상충, 재시도 초과 등)은 프롬프트·정책으로 사전에 명시해야 실행 전에 걸린다
평가는 성공률 하나가 아니라 개입률·지연시간·수정률·재작업률을 같은 조건에서 함께 기록해야 비교가 성립한다
반복 수정이 몰리는 분기를 주기적으로 새 검수 게이트로 승격하는 순환 구조가 필요하다