The Human-in-the-Loop Fallacy: AI 검토자 자리에 사람을 두는 설계가 오래가지 않는 이유
AI 결과를 사람이 검토하고 예외만 맡는 배치는 AI가 좋아질수록 사람 몫이 줄고 검토자의 숙련과 주의력도 떨어집니다. Choudary는 새 문제 발굴, 인력 재배치, 역량 점검, 시스템 내장 거버넌스, 팀·의사결정 구조 재편으로 조직을 다시 짜라고 권합니다.
AI 결과를 사람이 검토하고 예외만 처리하게 하는 배치는 AI가 좋아질수록 사람 몫이 줄어드는 구조입니다. Choudary는 AI가 아직 못 하는 일이 아니라 AI가 새로 가능하게 한 일을 기준으로 조직을 다시 짜라고 권합니다. 실제로 옮기려면 검토자 적발률을 재는 장치와, 통제를 사람의 눈에서 시스템 규칙으로 옮기는 작업이 먼저 필요합니다.
요약
AI·플랫폼 전략 자문가 Sangeet Paul Choudary는 2026년 11월 2일 HBR 글에서 지금 많은 기업이 택한 AI 도입 방식을 문제 삼습니다. AI가 맡는 일이 늘자 회사들은 직원에게 AI 산출물을 검토하고 AI가 다루지 못하는 예외를 처리하는 일을 맡깁니다. 흔히 human-in-the-loop(사람이 AI 처리 과정 중간에서 확인·승인하는 구조)라고 부르는 배치입니다.
저자는 이 배치가 사람 몫을 계속 줄인다고 봅니다. AI가 좋아질수록 사람이 확인할 필요는 줄고 검토자는 오류를 잡는 데 필요한 숙련과 주의력을 잃기 쉽습니다. 그래서 그는 AI의 빈틈에 사람을 맞추지 말고 AI가 새로 가능하게 한 능력을 기준으로 조직을 다시 설계하라고 말합니다. 방향은 다섯 가지입니다. 새로 풀 수 있게 된 문제를 찾아 직원을 더 가치 있는 일로 옮깁니다. 인력 역량은 계속 다시 평가합니다. 거버넌스는 AI 시스템 안에 넣고 팀과 의사결정 구조는 새 가치에 맞게 재편합니다. 아래에서는 이 주장을 네 가지 메커니즘으로 나누고 저자가 다른 공개 글에서 다룬 같은 틀을 하나 덧붙인 뒤, 실제로 옮길 때 필요한 기술·현업 디테일을 정리합니다.
핵심 메커니즘
Human-in-the-Loop 배치: AI가 못 하는 일을 사람 몫으로 정하는 방식
AI가 일을 처리하면 사람이 결과를 확인하고, AI가 다루지 못한 예외를 넘겨받는 배치입니다. 입력은 AI 산출물과 예외 건입니다. 사람은 산출물을 승인하거나 고치고 예외는 직접 처리합니다. 이때 사람의 역할은 “AI가 아직 못 하는 일”로 정의됩니다. 도입 초기에 위험을 줄이는 데는 맞는 방식입니다. 다만 이 정의를 조직 설계의 기준으로 굳히면 문제가 생긴다는 것이 저자의 요지입니다. 가상 예시로, 보험 청구 심사에 AI를 붙이고 심사역을 “AI 판정 검토자”로 바꾼 회사를 떠올리면 됩니다.
Shrinking Role: AI가 좋아질수록 줄어드는 사람 몫
사람 몫이 AI의 빈틈으로 정의되면, AI가 나아지는 만큼 그 몫이 줄어듭니다. 검토할 오류가 줄고 예외도 드물어지므로 사람이 확인할 이유가 약해집니다. 원문 요약은 이를 사람의 역할이 줄어드는 구조라고 표현합니다. HBR 페이지가 강조 문장으로 뽑은 것은 “There will still be a human in the loop.”입니다. 요약과 함께 읽으면 저자의 초점은 사람이 루프에 남느냐보다 남은 자리가 얼마나 좁아지느냐에 있습니다. 앞의 보험 예시라면 모델이 한 번 갱신될 때마다 검토 인력을 얼마나 줄일지를 다시 논의하게 됩니다.
Reviewer Erosion: 오류가 드물수록 무뎌지는 검토자
검토자가 대부분 문제없는 건만 보게 되면, 오류를 잡는 데 필요한 숙련과 주의력이 떨어집니다. 저자는 이것을 이 배치의 두 번째 위험으로 꼽습니다. 사람을 안전장치로 둔 이유가 드문 오류를 잡기 위해서인데, 오류가 드물어질수록 바로 그 능력이 약해지는 구조입니다. 그래서 사람을 루프에 남겨 두는 것만으로는 안전이 보장되지 않습니다. 이 위험은 검토 건수가 많고 오류율이 낮은 업무에서 커집니다.
Redesign Around New Capabilities: AI의 새 능력을 기준으로 조직을 짜기
저자의 대안은 기준을 뒤집는 것입니다. AI가 못 하는 일에 사람을 남기지 않고 AI 덕분에 새로 가능해진 일을 중심으로 조직을 다시 짭니다. 원문 요약이 밝힌 다섯 방향이 그 내용입니다. 먼저 새로 풀 수 있게 된 문제를 찾고 그 문제에 직원을 옮깁니다. 인력 역량은 한 번 진단하고 끝내지 않고 계속 다시 평가합니다. 통제는 사람의 검토에 기대지 않고 AI 시스템 안에 넣습니다. 마지막으로 팀과 의사결정 구조를 새로 생기는 가치에 맞게 재편합니다. 보험 예시라면 검토 인력 일부를 AI 덕분에 경제성이 생긴 소액 청구 사전 예방 상담 같은 새 업무로 옮기는 식입니다(가상 예시).
Formal Control vs Influence: 승인 클릭은 사람에게, 영향력은 도구에게
이 절은 HBR 글이 아니라 저자가 2026년 8월 30일 Substack ‘Platforms, AI, and the Economics of BigTech’에 쓴 글의 내용입니다. 에이전트가 구매 같은 업무에 들어오면 어떤 선택지를 볼지, 승인자에게 무엇을 보여 줄지를 에이전트가 정합니다. 마지막 승인은 여전히 사람이 누르지만 선택에 대한 실제 영향력은 도구 제공자 쪽으로 옮겨 간다고 그는 봅니다. 예로 든 회사는 기업 카드에서 구매 영역으로 넓혀 가는 Ramp입니다. Ramp는 회사 정책을 이해하고 결제 접근을 통제합니다. 저자는 human-in-the-loop라는 표현이 실제로는 옮겨 가지 않은 통제를 내세운다고 봅니다.
통념과 다른 주장
흔히 이렇게 봅니다AI 결과를 사람이 검토하게 하면 일자리도 지키고 안전도 지킬 수 있습니다.
저자는 이렇게 봅니다검토·예외 처리로 정의한 사람 몫은 AI가 좋아질수록 줄어들고 검토자의 감각도 함께 무뎌집니다.
근거AI 성능이 오르면 확인할 필요 자체가 줄고 오류가 드물어진 환경에서 검토자는 오류를 잡는 숙련과 주의력을 잃기 쉽다는 것이 저자의 설명입니다.
기술 디테일: 검토자를 재고 통제를 시스템에 넣으려면
아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. 저자의 주장을 실제 조직에 옮길 때 필요한 것을 정리했습니다.
검토자 숙련·주의력 저하(Reviewer Erosion)를 재려면 검토가 형식이 됐는지부터 숫자로 봅니다. 검토 건마다 case_id, ai_decision, human_decision, review_seconds, model_version, reviewer_id를 한 행씩 남깁니다. 그다음 정답을 아는 오류 건을 검토 큐에 2~5% 섞습니다(canary 케이스). 심은 오류의 적발률이 80% 아래로 떨어지거나 1건당 검토 시간이 처음의 절반 아래로 줄면 경보를 냅니다. 사람이 AI 판정을 그대로 승인한 비율(approve_as_is_rate)이 99%를 넘는 큐는 검토가 사실상 멈춘 것으로 보고 범위를 줄이거나 표본 감사로 바꿉니다.
{
"case_id": "CLM-20261105-0381",
"queue": "소액 청구 심사",
"ai_decision": "approve",
"human_decision": "approve",
"is_canary": true,
"canary_expected": "reject",
"caught": false,
"review_seconds": 14,
"model_version": "claims-v7",
"reviewer_id": "R-112"
}
큐 단위로는 주마다 canary_catch_rate(심은 오류 적발률), median_review_seconds, approve_as_is_rate(그대로 승인한 비율) 세 값만 대시보드에 올립니다. canary는 실제 과거 오류 사례에서 고르고 검토자가 canary인지 알아챌 수 없게 형식을 실제 건과 똑같이 맞춥니다.
거버넌스를 시스템 안에 넣으려면(Redesign Around New Capabilities) 사람의 눈에 맡기던 통제를 도구 쪽 규칙으로 옮깁니다. 금액·건수 한도는 프롬프트 문구가 아니라 도구가 실행을 거절하게 만들고 판정마다 입력, 적용 규칙, 모델·프롬프트 버전을 근거로 저장합니다. 사람 검토는 전수 대신 매주 무작위 표본 50건 재판정으로 바꾸고 불일치가 5%를 넘으면 그 규칙을 다시 봅니다. 에이전트가 승인자에게 보여 줄 선택지를 고른다면(Formal Control vs Influence) 제외한 선택지와 제외 이유도 함께 기록해, 사람이 무엇을 못 봤는지 나중에 확인할 수 있게 합니다.
| 실패하는 경우 | 대응 (가상 예시) |
|---|---|
| 검토자가 AI 판정을 거의 전부 그대로 승인 | canary 적발률로 실제 검토 여부 확인, 미달 큐는 표본 감사로 전환 |
| 모델 갱신 뒤 오류 유형이 바뀜 | 갱신마다 canary 세트를 새 오류 유형으로 교체 |
| 한도 규칙이 프롬프트에만 있음 | 도구 단위 거절로 옮기고 우회 시도를 기록 |
| 승인자가 에이전트가 고른 선택지만 봄 | 제외된 선택지와 이유를 함께 제시 |
현업 실행 디테일: 누가, 언제, 무엇을
저자가 말한 다섯 방향을 한 업무 단위에 적용하는 방법입니다. 역할, 일정, 기준은 모두 가상 예시입니다.
| 역할 | 맡는 일 (가상 예시) |
|---|---|
| 사업 부문장 | 새로 풀 수 있게 된 문제 후보 선정, 재배치 최종 결정 |
| CHRO·인사 | 검토 인력의 역량 재평가, 재배치 경로와 교육 설계 |
| AX 추진 조직 | 검토 기록·canary 측정 구축, 통제 규칙의 시스템 이전 |
| 리스크·감사 | 시스템 내장 통제와 표본 감사 기준 승인 |
| 현업 검토자 대표 | 실제 예외 유형과 판단 노하우 정리 |
시작 전 준비물은 세 가지입니다. AI 결과를 사람이 검토하는 업무 목록과 담당 인원, 최근 3개월 검토 기록(승인·수정·반려 건수), 업무별 오류가 났을 때의 비용 추정입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 검토·예외 처리 업무 전수 목록화, 업무별 승인률·검토 시간 집계 | 검토 업무 지도 |
| 3~4주 | canary 케이스로 검토자 적발률 측정 | 큐별 적발률 보고 |
| 5~6주 | AI 덕분에 새로 풀 수 있게 된 문제 후보 3~5개 도출 | 새 문제 후보 목록 |
| 7~8주 | 통제의 시스템 이전 범위 확정, 인력 재배치안 결정 | 재설계안, 재배치 계획 |
확인 질문은 이렇게 준비합니다. 지금 사람이 검토하는 업무 가운데 승인률이 99%를 넘는 곳은 어디입니까? 검토자가 최근에 실제로 잡아낸 오류는 몇 건이고 어떤 유형입니까? AI가 6개월 뒤 지금보다 좋아지면 이 검토 인력은 무엇을 하게 됩니까? AI 덕분에 처음으로 경제성이 생긴 고객 문제나 내부 문제는 무엇입니까? 검토자의 판단 노하우 가운데 규칙으로 옮길 수 있는 것과 없는 것은 무엇입니까?
진행 판정 기준은 업무마다 다시 정하되 출발점은 이렇습니다. 적발률 80% 미만인 큐는 전수 검토를 표본 감사로 바꾸고 인력 재배치 대상에 올립니다. 새 문제 후보는 담당 부문장이 지표와 책임자를 붙인 것만 다음 단계로 넘깁니다. 시스템 내장 통제는 리스크·감사가 승인한 뒤에만 사람 검토를 줄입니다.
AX 적용 제언. 국내 기업 다수가 AI 도입 초기에 “최종 확인은 사람이”라는 원칙으로 현업 반발과 리스크 우려를 함께 달랬습니다. 그 원칙을 버리기보다 기한을 붙이는 것이 현실적인 출발점입니다. 검토 업무마다 적발률을 재서 검토가 실제로 작동하는지 보이고 작동하지 않는 곳부터 통제를 시스템으로 옮깁니다. 그렇게 생긴 인력은 감축 대상이 아니라 새로 풀 수 있게 된 문제에 붙일 첫 팀으로 다룹니다. 인사와 AX 추진 조직이 이 작업을 같이 맡아야 역량 재평가와 재배치가 한 계획으로 묶입니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | HBR, Sangeet Paul Choudary, 2026.11.2, Generative AI 섹션 |
| 저자 | AI·플랫폼 전략 자문가, UC Berkeley 시니어 펠로, 『Reshuffle』 저자 |
| 문제 제기 | 기업들이 직원에게 AI 산출물 검토와 예외 처리를 맡김 |
| 위험 1 | AI가 좋아질수록 사람의 확인 필요가 줄어 역할이 축소 |
| 위험 2 | 검토자가 오류를 잡는 숙련과 주의력을 잃을 위험 |
| 대안 | 새 문제 발굴, 고가치 업무로 재배치, 역량 지속 평가, AI 시스템에 거버넌스 내장, 팀·의사결정 구조 재편 |
| 관련 공개 글 | 저자 Substack 2026.8.30. 마지막 승인은 사람에게 남아도 선택의 영향력은 도구 제공자로 이동. 예: Ramp |
핵심 개념
- human-in-the-loop
- AI가 처리하는 과정 중간에 사람이 확인·승인 단계를 맡는 구조입니다.
- exception handling
- 자동 처리 규칙에 맞지 않는 건을 따로 떼어 사람이 처리하는 일입니다.
- canary case
- 정답을 아는 오류 건을 검토 큐에 섞어 검토자가 실제로 잡아내는지 재는 장치입니다(새로 덧붙인 개념).
- embedded governance
- 통제 규칙을 사람의 확인이 아니라 시스템의 권한·한도·기록에 넣는 방식입니다.
- Reshuffle
- AI가 일과 조직, 산업 구조를 어떻게 다시 섞는지 다룬 저자의 책입니다.
내 메모
TODO: 내 생각 추가
원문은 Harvard Business Review의 「The “Human-in-the-Loop” Fallacy」(Sangeet Paul Choudary, 2026.11.2 게재)입니다. 본문은 유료벽으로 열리지 않아, HBR 페이지에 공개된 요약·강조 문장·저자 소개만 근거로 썼습니다. Formal Control vs Influence 절과 원문 사례 표의 Ramp 항목은 저자의 Substack ‘Platforms, AI, and the Economics of BigTech’ 글 「How agents transform the workflow, the organization, and the competitive landscape」(2026.8.30)에서 가져왔습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 원문 사례 표는 이 자료를 AX Review가 다시 정리했습니다. 메커니즘의 보험 예시, 기술·현업 실행 디테일, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 핵심 메커니즘 제목의 영어 이름(Shrinking Role, Reviewer Erosion 등)은 정리를 위해 붙인 것이고, 원문 용어는 human-in-the-loop입니다. 전문은 HBR 원문 페이지에서 볼 수 있습니다.