모든 업무에 AI 에이전트가 필요할까: 규칙 자동화·RPA·AI를 고르는 기준

자동화 단위를 먼저 정합니다

“주문 처리를 자동화하자”는 목표에는 몇 가지 다른 일이 들어 있습니다. 메일에 적힌 표현을 읽고 품목과 수량을 파악하는 일, 그 표현을 실제 상품 코드에 매핑하는 일, 계약 단가를 조회하는 일, 주문을 생성하는 일이 한 화면에서 이어져도 각각의 실패 원인은 다릅니다. 품목 추출이 틀리면 담당자가 후보를 수정할 수도 있습니다. 주문을 저장한 뒤 오류가 발견되면 물류와 거래처에 정정이 필요할 수도 있습니다. 같은 오류라도 어느 단계에서 발견했는지에 따라 영향이 달라집니다.

먼저 업무 담당자가 사용하는 입력, 승인된 결정 기준, 결과가 남는 원천 시스템을 작업 한 건의 흐름으로 그립니다. 양식이나 API로 입력을 받을 수 있는지를 확인합니다. 입력이 이미 구조화돼 있다면, AI를 호출하는 복잡성을 추가하기 전에 그 값을 그대로 쓰는 경로의 비용과 검증 방법을 비교할 수도 있습니다. 기존 메일을 유지해야 한다면 요청에 적힌 값과 고객 관리 시스템의 확정 값을 나눕니다. 메일 주소에 적힌 사람과 실제 주문 권한이 있는 사람이 같은지 확인하는 일은 CRM 고객 식별자와 이벤트 연결에서 다루는 데이터 정합성과도 이어집니다.

Google PAIR의 사용자 요구와 성공 정의^[1]는 사용자에게 고유한 가치가 있는 구간을 찾아 자동화와 인간 보조를 비교합니다. 선정 회의에서는 모델 시연이 그럴듯했는지보다 업무 한 건이 어떤 상태에 도달하면 끝나는지 먼저 묻습니다. 구매 주문이라면 주문 번호가 생기고 거래처, 품목, 단가, 수량이 담당자의 기준과 일치해야 합니다. 추출 결과만 화면에 보이면 담당자의 입력 시간이 줄었을 수는 있습니다. 완료된 주문 수는 원천 시스템에서 별도로 확인합니다.

입력과 경로에 따라 실행 방식을 고릅니다

표의 질문은 업무 전체의 점수를 내기 위한 기준이 아닙니다. 흐름의 각 단계에 한 행씩 적용합니다. 마지막 열에 쓸 확인 방법이 없으면 먼저 담당자가 결과를 판단하는 기준을 정합니다.

API는 시스템이 정해진 방식으로 데이터를 주고받는 인터페이스입니다. 조회용 API와 변경용 API를 나누고 권한을 걸면 업무가 허용하는 범위와 기술이 실행할 수 있는 범위를 맞추기 좋습니다. 읽기 전용 흐름에도 대상과 필드의 범위가 필요합니다. 공급사를 조사한다고 모든 거래처의 단가를 조회할 수 있으면 조사 결과에 관계없는 계약 정보가 함께 실릴 수 있습니다. 결과를 다른 곳으로 보내는 기능이 있다면 그 발신도 별도의 쓰기 작업으로 봅니다.

RPA는 화면을 통해 정해진 절차를 수행합니다. 오랫동안 운영한 프로그램에 외부 연동이 없고 담당자도 일정한 순서로 화면을 조작한다면 선택할 수도 있습니다. 팝업, 로그인 만료, 버튼 위치나 필드 규칙 변경으로 경로가 달라질 수 있으므로, 예기치 않은 화면에서는 멈추고 담당자에게 전달할 수 있어야 합니다. 동작 증거는 화면 캡처만으로 부족할 수도 있습니다. 가능한 환경에서는 실행 뒤 확정 데이터의 주문 번호나 원장 상태를 대조하고 화면 이외의 대조 방법이 없으면 자동 실행 범위와 허용 실패 비용을 좁힙니다.

Anthropic의 설계 자료는 코드가 정한 경로로 모델과 도구를 조합하는 워크플로와 모델이 다음 단계를 선택하는 에이전트를 구분합니다. 필요한 복잡성을 가장 작은 단위부터 추가하라는 제안도 함께 제시합니다. 메일 형식이 다양하더라도 순서가 접수, 검증, 승인, 등록으로 고정될 수 있다면 한 번의 추출과 정해진 검증 흐름으로 시도할 수도 있습니다. 반대로 중간 조사 결과에 따라 여러 자료를 비교해야 하고 유효한 경로를 미리 열거하기 어렵다면 다음 단계 선택을 맡기는 실험이 의미가 있습니다. Anthropic — Building effective agents^[2]

가상 사례에서 주문을 두 번 저장하지 않는 흐름을 그립니다

가상의 산업 자재 유통사에 “평소 사는 소형 브래킷 3박스, 지난번과 같은 조건”이라는 메일이 옵니다. 거래처별 품목 별칭, 박스 입수량, 계약 단가의 적용 시점은 다를 수 있다고 가정합니다. 같은 메일이 전달되거나, 회신 속에 직전 주문의 본문이 인용되거나, 새 메일로 기존 발주서를 정정하는 상황도 생깁니다. 모델은 “소형 브래킷”과 “3박스”를 추출하고 “평소”, “지난번” 같은 확인 필요 표현을 표시합니다. 현재 메일과 인용된 과거 문단의 출처를 분리해서 보여 주면 담당자가 후보 값을 빠르게 판단할 수도 있습니다.

상품 코드와 거래처 매핑은 관리된 기준 데이터에서 찾습니다. 조회 결과가 둘이면 담당자에게 두 후보와 차이를 보여 줍니다. 납품 규격이 다른데 이름이 비슷한 상품을 고르거나, 포장 단위를 임의 환산하면 검토자가 문장만 봐서는 문제를 발견하기 어렵습니다. 입력값에서 사용자 판단이 필요한 필드와 시스템에서 확정할 수 있는 필드의 종류를 고정합니다.

동일한 요청의 재전송을 구분할 때 이메일 메시지 ID만으로 처리하면 별도 메시지로 다시 보낸 동일 발주를 놓칠 수 있습니다. 주문 등록 요청의 의도를 구분할 업무 식별자는 거래처가 발급한 발주번호, 내부 접수 ID, 정정 차수처럼 실제 운영 규칙에 맞춰 정의합니다. 같은 작업 ID에서 내용이 바뀌면 재시도와 수정 요청을 구별할 정책이 있어야 합니다. 공급자가 멱등성 키를 지원하면 어떤 요청 범위와 기간에 동일 의도를 식별하는지 확인합니다. 키가 없거나 답이 유실됐을 때는 기존 주문 조회나 담당자 대사 경로가 있어야 합니다. AWS Builders’ Library — Making retries safe with idempotent APIs^[3]

새 요청과 이전 주문을 구별하려면 승인 화면에서도 담당자가 같은 버전의 상품, 수량, 가격, 배송 정보를 보고 승인해야 합니다. 고객이 승인 직후 수량을 다시 보냈다면 새 변경을 승인 경로로 보내고 이전 승인은 원래 값에만 유효하게 둡니다. 검증 시에는 등록 전에 계약 단가가 변경되거나 주문자가 권한을 잃는 상황을 함께 넣습니다. 화면에서 읽었던 예전 값이 남아도 실행 API가 당시의 조건을 다시 판단하도록 구현하면, 승인 당시와 저장 당시의 상태가 달라진 일을 발견할 수도 있습니다.

같은 문제를 다른 방식으로 풀어 봅니다

이 유통사가 거래처마다 입력 필드를 통일할 수 있다면 필수 항목을 요구하는 주문 양식과 API가 가장 먼저 비교할 대안입니다. 정형 입력은 누락을 제출 시점에 발견할 수 있고 담당자 수정 단계를 줄입니다. 반면 일부 거래처가 모바일에서 메일로 보내거나 별도 양식을 바꾸기 어렵다면 AI 초안을 선택할 수도 있습니다. 기존 업무 시스템에 외부 API가 없어 RPA를 검토할 경우 우선 내부 화면에서 확인 자료를 읽는 작업부터 시작합니다. 화면 기반 등록까지 확대하려면 저장 직전과 직후 상태를 담당자가 확인하는 절차가 필요합니다.

대체품 조사에서 에이전트를 검토한다면 기준이 달라집니다. 단종 확인 뒤에 사양서 검색, 호환 조건 대조, 제공 가능한 후보 표시가 상황별로 달라질 수 있습니다. 이때 읽을 수 있는 문서와 조회 도구를 제한하고 어떤 사양 문서의 어느 구절을 근거로 골랐는지 남깁니다. 대체품을 실제 주문으로 저장하는 단계에는 기존 승인과 별도의 변경 확인이 적용됩니다. 에이전트가 추가 단계를 고를 수 있어도 승인과 실행 권한을 발급하는 주체는 업무 시스템입니다. OWASP — AI Agent Security Cheat Sheet^[4]

도입 회의에서 확인할 질문 일곱 가지

1. 어떤 상태가 되면 일 한 건을 끝낸 것으로 봅니까? 준비된 초안, 담당자 승인, 원천 시스템의 확정 상태 중 업무가 요구하는 마지막 증거를 정합니다.
2. 입력의 모호함을 줄이는 더 단순한 방법이 있습니까? 입력 양식, 마스터 데이터 정비, 공식 인터페이스를 먼저 비교하고 상대방이 변경을 받아들일 수 있는지도 확인합니다.
3. 업무 순서가 바뀝니까, 아니면 한 단계의 입력만 다릅니까? 순서가 고정되면 추출이나 분류에만 모델을 넣는 선택이 가능합니다. 작업자가 어떤 경로를 왜 고르는지 설명할 수 있으면 먼저 규칙으로 나타내 봅니다.
4. 가격·권한·고객 상태를 판정하는 원천과 책임자는 누구입니까? 같은 필드가 메일과 원장에 함께 있을 때 무엇을 신뢰하고 버전이 다르면 누구에게 확인할지 합의합니다.
5. 이 단계는 조회입니까, 실제 상태를 바꿉니까? 변경을 시작하는 주체, 적용 가능한 데이터 범위, 승인값과 실행값의 일치, 실패 시 결과 대조 방법을 적습니다.
6. 잘못됐거나 모르는 상태가 어디로 갑니까? 담당 큐, 인수자, 처리 기한, 되돌리기 또는 보정 수단을 지정합니다. 실행이 멈췄을 때 고객이나 거래처에게 어떤 안내가 나가는지도 정합니다.
7. 실패를 포함해 기존 방식보다 무엇이 좋아지는지 어떻게 비교합니까? 평균 처리 시간 외에 승인 대기, 재작업, 장애 시 수동 전환, 연동 유지와 교육 비용을 함께 봅니다.

답이 비어 있는 질문은 기능을 추가할 근거보다 먼저 확보할 업무 증거에 가깝습니다. 예를 들어 신규 주문의 적절한 거래처를 반복해서 사람이 수정한다면 별칭 기준을 관리하도록 만드는 것이 다음 실험입니다. 정해진 기준이 있고 시스템으로 대조하기 어렵다면 테스트 환경과 검증 데이터부터 마련합니다. 테스트 자동화 포트폴리오의 실행 빈도, 실패 영향, 기대 결과, 환경과 데이터의 반복 재현 기준을 적용하면 자동화 후보와 검증 준비가 된 후보를 구별할 수도 있습니다.

작은 실험에서 검토 부담까지 계산합니다

실험 범위를 실제 화면을 쓰되 확정 주문을 저장하지 않는 기간으로 시작할 수도 있습니다. 이전에 승인된 샘플에서 일반 주문, 단위가 모호한 주문, 계약 없는 품목, 누락과 정정을 골라 업무 책임자가 기준 결과를 먼저 적습니다. 민감한 거래처 정보는 승인된 테스트 데이터로 대체하고 새로 도입할 계정과 모델로 어떤 값이 전송되는지를 확인합니다. 현재 방식은 숙련자 한 명의 시연이 아니라 같은 유형의 작업을 실제 담당자가 수행할 때의 기록으로 비교합니다. 두 방식에서 사람이 사용한 시간과 실패로 돌아간 시간을 나눠 적습니다. 위험 조건과 사전 평가의 관계는 NIST AI 600-1^[5]의 배포 전 시험과 위험 추적 권고를 참고할 수도 있습니다.

가상으로 접수 100건을 사용해 초안 70건을 만들고 그중 60건이 수정 없이 다음 단계로 이동했다고 가정합니다. 초안 생성 가능 비율은 70건을 100건으로 나눈 70%입니다. 수정 없이 이동한 비율은 접수 기준으로 60%이고 초안 건만 보면 약 85.7%입니다. 운영 인력의 부담을 판단하려면 초안 확인에 들어간 시간과 나머지 40건의 수동 처리나 추가 검토를 포함합니다. 그중 10건은 생성된 초안의 수정이 필요했고 30건은 초안이 생성되지 않았습니다. 모델 호출이나 RPA 작업 성공만 집계하면 비용을 쓰면서 담당자는 업무를 두 번 보게 되는 경우를 놓칩니다.

실험으로 확보된 시간은 운영 항목별로 해석합니다. 하루 종일 여러 명에게 1분씩 줄어든 시간이 즉시 예산 절감으로 이어지는지는 업무 배치와 계약 구조에 달려 있습니다. 바쁜 시간대에 누적되던 접수 지연이 줄었다면 처리 기한이나 초과근무가 어떻게 바뀌었는지 확인합니다. 화면 자동화의 경우 월별 화면 변경과 운영 계정 관리, 모델 사용 흐름은 분류 규칙 정비와 프롬프트·모델 변경 뒤 회귀 검증에 드는 시간을 포함합니다. 기존 작업에 없던 검토가 일정 시점에 한 담당자에게 몰리면 대기열과 인수 절차도 비용에 속합니다.

범위를 늘리는 기점은 어떤 오류를 발견했고 처리할 수 있는지가 확인되는 때입니다. 첫 단계에서 수량과 품목 후보만 제안하고 다음 단계에서 표준 입력과 일치하는 주문의 저장을 승인된 사람에게 허용할 수도 있습니다. 그다음 실험 대상에는 승인 가능한 소수의 거래처와 품목군을 포함하고 실패 알림과 수동 복귀를 검증합니다. 승인 가능한 범위 밖에서 한 건이라도 저장됐거나 운영 담당자가 원인을 찾아 재처리할 수 없다면 확대 전에 그 경로부터 확인합니다.