AI 자동화에서 사람 검토를 남겨야 하는 업무를 분류하는 기준
반복 업무를 AI로 처리하기 시작하면 처음에는 처리 속도가 빨라집니다. 문의 내용을 분류하고, 문서에서 정보를 추출하고, 내부 시스템에 값을 입력하는 작업이 줄어듭니다.
문제는 그다음에 생깁니다. AI가 잘못 분류한 건을 사람이 다시 찾아야 하고, 자동 입력된 데이터를 승인하기 위한 화면이 필요해집니다. 자동화율은 높아졌지만 오류 검토와 승인 업무가 새로 생기는 상황입니다.
핵심은 모든 단계를 자동화할지 정하는 것이 아닙니다. 어떤 업무는 AI가 끝까지 처리해도 되는지, 어떤 업무는 사람의 판단을 거쳐야 하는지, 그리고 검토를 워크플로우 어디에 배치할지 구분하는 일입니다.
먼저 업무를 한 덩어리로 보지 않는다
자동화 검토를 의뢰할 때 “이 업무를 AI로 자동화할 수 있나요?”라고 묻는 경우가 많습니다. 하지만 하나의 업무 안에도 입력 수집, 분류, 정보 추출, 판단, 실행, 결과 통지 단계가 섞여 있습니다.
예를 들어 운영자가 들어온 요청을 처리하는 과정은 다음처럼 나눌 수 있습니다.
- 요청 내용을 읽고 유형을 분류하는 단계
- 필요한 값을 문서나 메시지에서 추출하는 단계
- 처리 우선순위나 담당 부서를 제안하는 단계
- 실제 데이터 변경이나 외부 발송을 실행하는 단계
- 처리 결과를 기록하고 담당자에게 알리는 단계
앞부분은 AI가 보조하기 쉽습니다. 반면 데이터 변경, 금액이 연결된 실행, 외부 발송처럼 결과가 바로 발생하는 단계는 별도의 판단 기준이 필요합니다. 자동화 단위를 작게 나누면 사람 검토를 어디에 둘지 더 선명해집니다.
네 가지 기준으로 검토 지점을 정한다
오류가 나면 비용이 얼마나 커지는가
오류 비용은 단순히 재작업에 걸리는 시간만 뜻하지 않습니다. 잘못된 안내가 반복되거나, 중요한 요청이 누락되거나, 내부 데이터가 틀어지는 상황까지 포함합니다.
오류가 나도 원본을 보며 쉽게 수정할 수 있는 초안 작성은 자동화 비중을 높일 수 있습니다. 반대로 한 번 잘못 처리하면 거래, 권한, 일정, 대외 커뮤니케이션에 영향을 주는 작업은 실행 전에 사람이 결과를 검토하는 편이 안전합니다.
여기서 중요한 질문은 “AI가 얼마나 자주 틀리는가”만이 아닙니다. 틀렸을 때 누가 발견하는지, 발견까지 얼마나 걸리는지, 수정할 원본과 기록이 남는지도 함께 봐야 합니다.
처리 결과를 되돌릴 수 있는가
자동화 단계의 위험도는 되돌리기 가능성에 따라 크게 달라집니다. 초안 상태로 저장하고 사람이 승인한 뒤 반영할 수 있다면 검토 지점을 만들기 쉽습니다. 반대로 한 번 발송하면 회수할 수 없거나, 외부 시스템에 즉시 반영되어 복구 절차가 복잡하다면 사람 승인을 앞에 둬야 합니다.
되돌리기 가능성은 세 가지로 나눠볼 수 있습니다.
- 쉽게 수정할 수 있는 초안 또는 임시 저장
- 로그를 남기고 관리자 화면에서 되돌릴 수 있는 내부 처리
- 실행 후 회수가 어렵거나 외부에 즉시 전달되는 처리
첫 번째 유형은 AI가 자동 처리하고 사후 샘플 검토를 두는 방식도 가능합니다. 두 번째 유형은 예외가 발생했을 때 관리자에게 전달되도록 설계할 수 있습니다. 세 번째 유형은 AI의 제안과 사람의 승인을 분리하는 편이 적합합니다.
개인정보와 민감한 정보가 포함되는가
업무 데이터에 개인정보가 포함되어 있다면 자동화 가능 여부를 기능만으로 판단하기 어렵습니다. 어떤 데이터를 AI 처리 대상으로 보낼지, 처리 결과를 어디에 저장할지, 접근 권한을 누가 갖는지부터 정해야 합니다.
개인정보가 포함된다고 해서 모든 자동화를 중단해야 하는 것은 아닙니다. 다만 원문 전체를 전달하는 대신 필요한 항목만 추출하거나, 운영자가 검토할 때 일부 정보를 가리는 방식이 필요할 수 있습니다. 관리자 웹에서 누가 어떤 결과를 승인했는지 기록하는 것도 운영 조건에 포함됩니다.
실무에서는 다음 질문을 먼저 정리하는 것이 좋습니다.
- AI가 읽어야 하는 데이터와 읽지 않아도 되는 데이터는 무엇인가
- 결과를 저장해야 하는 기간은 어느 정도인가
- 관리자와 일반 사용자의 접근 범위가 나뉘어 있는가
- 오류나 오판이 발생했을 때 원문과 처리 이력을 추적할 수 있는가
이 기준이 정리되지 않은 상태에서 AI API만 연결하면 나중에 데이터 구조와 관리자 권한을 다시 손봐야 할 가능성이 커집니다.
결과에 사람의 승인이 필요한가
승인은 단순한 버튼 하나가 아닙니다. 승인자가 무엇을 보고 판단해야 하는지, 거절하면 어떤 상태로 돌아가는지, 승인 이후 어떤 API와 데이터가 실행되는지를 정해야 합니다.
사람 승인이 필요한 업무는 대체로 다음 특징을 가집니다.
- 조직의 정책이나 예외 판단이 개입된다
- 결과가 외부 사용자나 거래 상대에게 전달된다
- 금액, 권한, 계약, 일정처럼 영향 범위가 넓다
- 잘못된 처리의 책임 주체를 기록해야 한다
- AI가 참고할 수 없는 맥락을 담당자가 알고 있다
이런 업무에서는 AI를 판단 주체로 두기보다 제안자나 분류자로 두는 구조가 적절합니다. AI가 처리 후보와 근거를 만들고, 담당자가 승인하거나 수정한 뒤 시스템이 다음 단계로 넘어가는 방식입니다.
자동화 수준은 네 단계로 나누면 설계가 쉬워진다
모든 업무를 자동 처리와 수동 처리로만 나누면 중간 단계가 사라집니다. 실제 운영에서는 다음 네 수준을 함께 두는 편이 현실적입니다.
1단계: AI가 초안을 만들고 사람이 직접 실행한다
문서 요약, 답변 초안, 요청 분류처럼 결과를 사람이 읽고 활용하는 단계입니다. 오류가 발생해도 외부 실행으로 바로 이어지지 않는 업무에 적합합니다.
2단계: AI가 처리하고 사람이 승인한다
AI가 필요한 값을 채우거나 실행안을 만든 뒤 관리자 화면에 대기 상태로 저장합니다. 담당자는 원문, AI 결과, 수정 가능한 항목을 보고 승인합니다.
이 단계에서는 승인 화면의 품질이 중요합니다. 결과만 보여주면 담당자는 원문과 다른 화면을 오가며 다시 검토해야 합니다. 판단에 필요한 근거와 예외 사유를 같은 화면에서 볼 수 있어야 합니다.
3단계: 일반 건은 자동 처리하고 예외만 사람에게 보낸다
입력 형식이 일정하고 오류 비용이 낮은 업무라면 예외 기반 운영을 고려할 수 있습니다. 신뢰도가 낮거나 필수 값이 비어 있거나, 기존 규칙과 결과가 충돌하는 건만 검토 대기열로 보내는 방식입니다.
다만 예외 기준을 처음부터 고정된 숫자로만 정하면 운영 중 문제가 생길 수 있습니다. 어떤 이유로 대기 상태가 되었는지 기록하고, 담당자가 예외를 처리한 결과를 다음 기준 개선에 활용할 수 있어야 합니다.
4단계: 사람이 사후 점검하고 시스템은 기록을 남긴다
되돌리기 쉽고 영향 범위가 작은 업무는 매 건 승인보다 사후 점검이 효율적일 수 있습니다. 대신 처리 결과, 입력 데이터, 사용한 규칙, 실패 내역을 남겨야 합니다.
자동화 수준을 높이는 목적은 사람을 업무에서 완전히 빼는 데 있지 않습니다. 사람이 반드시 판단해야 하는 건에 시간을 쓰고, 반복적인 정상 건은 시스템이 처리하도록 역할을 나누는 데 있습니다.
도입 전에 준비할 운영 설계 항목
AI 자동화 상담을 시작하기 전에 현재 업무를 다음 순서로 정리하면 범위가 빨리 좁혀집니다.
관련 항목은 첫째·업무의 시작 조건과 종료 조건을 적습니다. 어떤 API·관리자 입력·파일·메시지가 업무를 시작하게 하는지 구분합니다. 종료 시점에는 데이터 저장·알림·외부 발송 중 무엇이 발생하는지도 적어야 합니다. 등을 함께 보면 됩니다.
둘째, 오류 사례를 유형별로 나눕니다. 값이 비어 있는 경우, 형식이 다른 경우, AI 결과와 기존 규칙이 충돌하는 경우, 사람이 추가 판단해야 하는 경우를 따로 기록합니다. 오류 목록이 있어야 검토 대기열과 관리자 화면의 요구사항을 정할 수 있습니다.
관련 항목은 셋째·승인 권한과 책임 범위를 정합니다. 누구나 승인할 수 있는지·특정 역할만 승인해야 하는지·거절 이후 재처리할 수 있는지 결정합니다. 승인 기록에는 담당자·시각·이전 값과 변경 값·거절 사유가 필요할 수 있습니다. 등을 함께 보면 됩니다.
넷째, 실패 시 운영 절차를 정합니다. AI API가 응답하지 않거나 외부 시스템 반영이 실패했을 때 자동으로 재시도할지, 관리자에게 알릴지, 수동 처리로 전환할지 정해야 합니다.
이 준비가 되어 있으면 Flutter 앱, 관리자 웹, API, 데이터베이스를 각각 따로 만드는 대신 하나의 운영 흐름으로 설계할 수 있습니다. 반대로 승인과 예외 처리를 나중에 붙이면 데이터 상태와 화면 흐름을 다시 구성해야 할 수 있습니다.
자동화율보다 운영 가능한 경계를 먼저 정한다
AI 업무 자동화에서 좋은 출발점은 가장 많은 단계를 자동화하는 업무가 아닙니다. 오류를 발견할 수 있고, 필요할 때 되돌릴 수 있으며, 담당자가 납득할 수 있는 검토 흐름을 만들 수 있는 업무입니다.
초기 범위는 정상 케이스가 비교적 분명하고, 오류 비용이 관리 가능하며, 결과를 기록할 수 있는 업무가 적합합니다. 이후 실제 예외가 쌓이면 자동 처리 범위를 넓히거나 사람 승인 지점을 옮길 수 있습니다.
결국 설계의 질문은 “AI가 어디까지 할 수 있는가”보다 “어디에서 사람이 개입해야 운영 책임을 질 수 있는가”에 가깝습니다. 이 경계를 먼저 정하면 자동화율보다 중요한 유지보수 범위와 관리자 업무까지 함께 보입니다.
반복 업무의 어느 단계까지 자동화하고 승인과 예외 처리를 어디에 둘지 정리하기 어렵다면, 현재 업무 흐름과 관리자 운영 범위를 기준으로 AI 자동화 구조를 함께 진단할 수 있습니다. https://www.universoft.kr/contact