승인 단계를 늘려도 검토는 늘지 않아요
AI가 만든 결과가 늘어나면 사람이 검토할 시간도 필요해요. 승인 건수·검토시간·실행 위험을 함께 계산하고 감독이 작동할 조건을 짚었어요
비즈니스“사람이 최종 확인한다”는 말 다음에 정할 것
AI가 작성한 결과를 사람이 승인하도록 하면 안심하기 쉬워요. 하지만 누구에게 맡길지 정하는 것만으로 검토가 끝나지는 않아요. 그 사람이 하루에 몇 건을 읽어야 하는지, 무엇을 확인해야 하는지, 잘못된 결과를 멈출 권한이 있는지도 정해야 해요.
예를 들어 AI 도입 뒤 검토할 결과물이 열 배로 늘었는데 검토 인원과 시간은 그대로라면 어떻게 될까요. 승인자를 한 명 더 지정하더라도 실제 내용을 읽을 시간은 부족할 수 있어요. 요청을 빨리 처리하려다 확인을 생략할 위험도 커지고요.
저는 에이전트를 도입할 때 생성 속도와 검토 능력을 함께 설계해야 한다고 생각해요. 사람의 승인이 필요한 행동을 정하고, 그 행동이 얼마나 자주 생길지 계산하는 일이에요.
관리자들이 걱정하는 것은 결정의 책임이기도 해요
OECD는 프랑스·독일·이탈리아·일본·스페인·미국의 중간관리자 6,000명 이상을 조사했어요. 2025년 발표 자료에서 다룬 “알고리즘 관리”는 업무 배정, 근무 모니터링, 평가 등을 지원하거나 자동화하는 소프트웨어예요. 생성형 AI에 한정한 조사는 아니에요.
도구를 쓰는 관리자들은 의사결정에 도움이 된다고 평가하면서도 우려를 나타냈어요. 잘못된 결정의 책임이 불분명하다는 응답이 28%, 결정의 논리를 따라가기 어렵다는 응답과 노동자의 신체·정신 건강 보호가 부족하다는 응답이 각각 27%였어요. 책임 소재가 가장 많이 거론됐지만 다른 우려와 차이가 크지는 않았어요.
이 결과를 “관리자들은 정확도를 걱정하지 않는다”는 뜻으로 읽어서는 안 돼요. 잘못된 결정을 예방하는 일과 오류가 났을 때 누가 대응할지 정하는 일이 함께 필요하다는 뜻에 가까워요. 조사 역시 승인 단계를 늘린 원인이나 그 효과를 입증한 것은 아니고요.
제가 이 조사에서 주목한 것은 책임에 관한 불안을 승인 절차 하나로 해소하려 할 때의 문제예요. 승인자가 있다는 사실과 그 사람이 실질적으로 관리할 수 있다는 사실은 다를 수 있으니까요.
승인 기록에는 무엇을 검토했는지가 빠질 수 있어요
승인 절차는 오류를 찾고, 권한이 있는 사람이 실행을 허용했는지 기록하는 데 쓰여요. 두 기능이 함께 작동하려면 검토할 정보와 시간이 있어야 해요.
오류를 찾으려면 무엇이 바뀌는지, 어떤 근거로 판단했는지, 누구에게 영향을 주는지 읽어야 해요. 필요하면 원자료도 확인해야 하고요. 반면 시스템에는 내용을 읽었는지와 관계없이 승인 계정과 시각이 남을 수 있어요.
이 때문에 승인 건수만 세면 실제 검토가 이뤄졌는지 알기 어려워요. 담당자가 처리량을 맞추려고 여러 건을 한꺼번에 승인할 수도 있고, 반대로 충분히 검토하느라 요청이 오래 대기할 수도 있어요. 두 경우 모두 승인 화면만 봐서는 이유를 판단하기 어려워요.
여기서 책임이 승인자 한 명에게 자동으로 넘어간다고 보기도 어려워요. 권한을 설정한 사람, 시스템을 운영하는 조직, 원자료를 관리하는 담당자의 역할이 함께 얽혀 있으니까요. 승인 로그는 경위를 확인할 자료이지 책임 배분 자체를 대신하지는 않아요.
NIST의 2024년 생성형 AI 위험관리 프로필도 사람과 AI의 역할 배치에 따른 위험을 다뤄요. 감독 역할을 구분하고, 위험에 비례하는 평가를 마련하도록 제안해요. 자발적으로 참고하는 지침이지만, 승인 버튼의 개수보다 감독이 실제로 작동할 조건을 보라는 점에서 유용해요.
승인 대상 비율을 낮춰도 검토할 건수는 늘 수 있어요
아래는 관계를 설명하기 위한 가상 계산이에요. 실제 조직의 측정값은 아니에요.
실무자 5명이 하루 4건씩 요청하면 관리자는 20건을 검토해요. 에이전트를 붙인 뒤 1인당 하루 50건의 행동을 제안한다고 가정하면 전체는 250건이에요. 그중 20%만 사전 승인을 받도록 해도 관리자에게는 50건이 와요.
| 항목 | 도입 전 | 도입 후 가정 |
|---|---|---|
| 하루 생성되는 행동 | 20건 | 250건 |
| 사전 승인 대상 비율 | 100% | 20% |
| 하루 검토 요청 | 20건 | 50건 |
| 건당 3분 검토할 때 | 60분 | 150분 |
사전 승인 대상 비율은 줄었는데 검토 건수는 2.5배가 됐어요. 건당 검토시간까지 같다면 필요한 시간도 2.5배예요.
250건 가운데 20건만 검토하려면 비율은 8%가 돼요. 하지만 8%가 적절한 승인 기준이라는 뜻은 아니에요. 위험한 행동이 50건이라면 시간을 맞추려고 30건의 검토를 없앨 수는 없어요. 실행량을 제한하거나, 검토 인력을 보강하거나, 위험한 행동을 더 좁은 범위로 설계해야 해요.
저는 처음에는 다음처럼 계산하는 편이 이해하기 쉽다고 봐요.
필요한 검토시간 ≈ 행동 수 × 사전 승인 대상 비율 × 건당 검토시간 + 재검토·예외 복구시간
이는 업무량을 추정하는 간단한 식이에요. 실제로는 행동마다 검토시간이 다르고, 여러 건을 묶어서 보는 편이 효율적인 경우도 있어요. 반려한 결과를 다시 확인하거나 잘못 실행된 일을 복구하는 시간도 측정해야 하고요.
이 값이 담당자의 가용 시간을 넘으면 처리량을 조정해야 해요. “승인률을 낮췄다”는 보고만으로 도입 효과를 판단하지 말고, 실제 남은 요청과 대기시간을 확인할 필요가 있어요.
자동 승인이 많아져도 사람의 감독이 사라지는 것은 아니에요
앤스로픽의 2026년 2월 사용 연구에는 흥미로운 결과가 있어요. 클로드 코드 신규 사용자의 세션 중 완전 자동 승인을 사용하는 비율은 약 20%였고, 사용 경험이 많은 집단에서는 40%를 넘었어요. 동시에 경험이 많은 사용자는 작업 중간에 개입해 중단시키는 비율도 더 높았어요.
연구진은 이를 감독 방식의 변화로 해석해요. 매 행동을 미리 승인하기보다 실행을 지켜보다가 필요한 시점에 개입하는 방식이죠. 자동 승인이 늘었다는 이유만으로 검토를 포기했다거나 안전성이 입증됐다고 볼 수는 없어요.
같은 연구에서 복잡한 작업일수록 에이전트가 확인 질문을 하는 빈도와 사용자가 중단시키는 빈도는 모두 높아졌어요. 에이전트의 질문 빈도가 더 빠르게 늘었고요. 질문이나 중단 횟수만으로 사람이 내용을 얼마나 읽었는지까지 측정한 것은 아니에요.
저는 이 결과가 “사람의 개입은 늘지 않는다”는 결론보다, 어떤 방식으로 감독하는지 봐야 한다는 설명에 가깝다고 생각해요. 검토자가 중간 결과를 볼 수 있고, 이상한 진행을 알아채고, 즉시 멈출 수 있어야 사후 개입 방식도 작동할 수 있어요.
행동 하나보다 작업 계획을 먼저 검토할 수 있어요
앤스로픽은 4월의 별도 글에서 반복되는 승인 요청이 사용자에게 마찰이 되고, 요청을 흘려보내게 할 수 있다고 설명했어요. 해결 방식 중 하나로 클로드 코드의 플랜 모드를 소개했고요. 실행 계획을 먼저 보여주고 사용자가 검토·수정한 뒤 작업을 시작하는 방식이에요.
조직에서도 적용할 수 있는 생각이에요. 예를 들어 자료를 읽고 내부 보고서 초안을 만드는 작업은 목적, 읽을 자료, 결과물을 저장할 위치를 먼저 검토할 수 있어요. 작업 중 계획을 벗어나는 데이터 접근이나 외부 발송이 필요해지면 다시 판단하도록 하고요.
다만 계획에 동의했다고 모든 후속 행동을 허용한 것은 아니에요. 도구의 접근 권한, 금액 한도, 외부 전달에 필요한 승인은 별도로 설정해야 해요. 처음 허용한 범위를 넘어서는 행동을 알아채고 멈출 방법도 있어야 하죠.
승인 단위를 바꾼다는 것은 검토할 맥락을 한 번에 보여준다는 뜻이에요. 중간에 위험이 달라져도 처음 받은 승인으로 계속 실행한다는 뜻은 아니에요.
감독과 문서 보관은 각각 확인해야 해요
한국 인공지능기본법 제34조는 고영향 인공지능이나 이를 이용한 제품·서비스를 제공하는 사업자의 책무를 정해요. 제1항 제4호는 사람의 관리·감독, 제5호는 안전성·신뢰성 확보 조치를 확인할 수 있는 문서의 작성과 보관이에요.
승인 로그가 있다는 것만으로 어느 한 의무가 충족됐다고 단정할 수는 없어요. 실제로 어떤 관리·감독을 했는지, 안전성·신뢰성 조치가 문서에 충분히 담겼는지를 각각 봐야 해요. 단순히 클릭한 시각만 남긴 기록으로 제5호를 이행했다고 볼 수도 없고요.
적용 대상 역시 “사내 도구냐 외부 서비스냐”만으로 정해지지는 않아요. 법이 열거한 영역에서 쓰이는지와 생명·신체 안전·기본권에 중대한 영향이나 위험을 줄 우려가 있는지를 함께 살펴야 해요. 일반 문서 초안과 채용 평가에 쓰이는 문서가 모두 “내부 문서”라는 이유로 같은 취급을 받는 것은 아니에요.
업종별로 따로 정해진 절차가 있으면 그것도 따라야 해요. 검토시간을 줄이는 설계가 필요한 법적 절차를 생략할 근거가 되지는 않아요.
위험과 검토 능력을 함께 보고 승인 기준을 정해요
실무에서는 먼저 행동을 목록으로 적어보는 게 좋아요. 무엇이 바뀌는지, 잘못되면 피해가 얼마나 큰지, 되돌릴 수 있는지, 누가 영향을 받는지 살펴요. 내부 작업이라도 개인정보를 외부로 보내거나 중요한 데이터를 덮어쓴다면 위험할 수 있어요.
아래는 논의를 시작하기 위한 예시예요. 같은 행동도 데이터와 권한 범위에 따라 통제가 달라져요.
| 행동의 예 | 먼저 확인할 조건 | 통제 방식의 예 |
|---|---|---|
| 내부 초안, 허용된 자료 조회 | 민감정보 접근과 외부 전송 여부 | 좁은 접근 권한, 결과 표본 검토 |
| 내부 티켓 변경 | 변경 범위와 복구 가능성 | 범위·횟수 제한, 변경 기록과 예외 승인 |
| 고객 공지, 가격 변경 | 수신자·금액·외부 영향 | 실행 전 내용과 대상 확인, 변경 한도 |
| 큰 결제, 계정 삭제, 중요한 인사 판단 | 피해 규모와 관련 절차 | 자동 실행 권한 제한, 필요한 전문 검토와 승인 |
승인 화면에는 바뀌는 내용, 판단 근거, 영향을 받는 대상을 함께 보여줘야 해요. 원자료를 확인할 링크와 반려·중단할 방법도 있어야 하고요. 검토자가 매번 여러 시스템을 찾아다녀야 한다면 승인 요청을 줄여도 시간이 많이 들어요.
성과를 볼 때는 자동화율에 다음 지표를 더해볼 수 있어요.
- 하루 검토 요청, 건당 검토시간과 대기시간
- 승인 뒤 오류가 발견되거나 다시 수정한 비율
- 여러 건을 일괄 승인한 경우와 그 검토 방식
- 반려 후 재작업과 예외 복구에 쓴 시간
- 승인 부담 때문에 사용을 포기한 업무와 이유
마지막 항목은 시스템 기록만으로 파악하기 어려워요. 사용하지 않은 이유를 당사자에게 물어야 해요. 관리자뿐 아니라 요청하는 실무자의 시간과 업무 부담도 함께 확인해야 하고요.
오스왈드의 시선
저는 “사람이 최종 확인합니다”를 안전 설계의 시작으로 봐요. 그다음에 어떤 행동을 허용할지, 검토에 필요한 정보를 어떻게 제공할지, 담당자가 처리할 수 있는 양이 얼마인지를 정해야 해요.
모든 행동을 승인 대상으로 두면 당장은 권한 범위를 결정하지 않아도 되는 것처럼 느껴질 수 있어요. 하지만 그 결정은 매번 요청을 받는 사람에게 넘어가요. 요청이 많아질수록 개별 승인자가 같은 기준을 반복해서 해석해야 하죠. 미리 정할 수 있는 기준은 조직이 정하고, 판단이 필요한 예외를 검토자에게 보내는 편이 낫다고 생각해요.
지난 3월 이 뉴스레터에서 에이전트 도입의 제약으로 신뢰를 강조한 적이 있어요. 지금은 그 설명에 검토 능력을 더해야 한다고 봐요. 제품에 익숙해진 사용자가 자율성을 더 허용하는 모습은 보이지만, 그 사실만으로 조직이 감당할 수 있는 작업량까지 늘어나는 것은 아니니까요.
처리량을 늘리려면 검토에 쓸 시간을 확보하거나, 위험한 실행을 줄이거나, 반복 확인을 더 쉽게 만들어야 해요. 승인 단계만 추가하면 이 결정이 해결될 것이라고 기대하기는 어려워요.
이번 주에 하나를 확인한다면 지금 승인받는 행동 목록과 실제 검토시간을 함께 보길 권해요. 읽는 데 필요한 시간이 확보돼 있는지부터 알면, 어디에 승인을 남기고 어디의 실행 범위를 줄여야 할지 논의할 수 있어요.
💬 자동화 도구를 도입한 뒤 검토 요청이 늘었나요? 실제로 내용을 읽을 시간을 확보하기 위해 어떤 기준을 바꾸셨나요?
오늘 얻은 관점, 다음 이슈에서도 이어가세요.
쏟아지는 소식 사이에서 오래 남는 한 편을 골라 격일로 보내드립니다.
이메일 확인 후 구독이 완료돼요.
이미 구독 중이신가요? 로그인하고 댓글 남기기
SEND A COFFEE
이 관점이 좋았다면, 다음 글에 커피 한 잔
오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.
참고자료
- OECD, How widespread is algorithmic management in workplaces?, 2025년 12월
- Anthropic, Measuring AI Agent Autonomy in Practice, 2026년 2월 18일
- Anthropic, Trustworthy agents in practice, 2026년 4월 9일
- 인공지능기본법 제34조
- NIST, Generative Artificial Intelligence Profile, 2024년 7월
함께 읽기: AI 에이전트와 신뢰의 문제 · 검증자가 병목이라는 말, 절반만 맞아요

여러분의 생각이 다음 호를 만듭니다
이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?