이미 RPA 봇이 돌고 있는 회사라면 AI 에이전트 전환을 봇 단위로 하지 않습니다. 봇은 통째로 두고, 봇이 멈춘 뒤 사람이 대신 처리해 온 칸만 후보로 봅니다. 그 칸을 옮길 때도 한동안은 기존 방식과 나란히 돌립니다.
「우리도 이제 RPA를 AI로 바꿔야 하나요?」 RPA를 몇 해째 운영해 온 회사의 담당자가 임원에게서 이런 질문을 받으면, 답하려고 먼저 펼치는 자료는 봇 목록 한 장입니다. 봇 이름, 하는 일, 도는 시간, 관리하는 사람이 적힌 표죠.
그 표만으로는 답이 나오지 않습니다. 봇이 하는 일을 적은 칸은 전부 「자동으로 입력」, 「자동으로 조회」처럼 비슷하게 적혀 있어서입니다. 필요한 것은 봇이 한 일이 아니라 봇이 하지 못한 일의 기록입니다.
봇 목록 옆에 무엇을 붙여야 판단이 서나요?
봇마다 최근 몇 달 치 실패 기록을 붙입니다. RPA(사람이 화면에서 하던 클릭과 입력을 그대로 흉내 내 반복하는 프로그램)는 처리하지 못한 건을 오류로 남기는데, 그 오류의 종류가 봇을 남길지 옮길지를 알려 줍니다.
POC(본도입 전에 작게 해 보는 검증) 설계를 맡을 때 저는 봇 설명서보다 이 기록을 먼저 요청합니다. 설명서는 봇이 설계된 모습을 보여 주고, 실패 기록은 현장에서 실제로 막힌 자리를 보여 주기 때문입니다.
기록을 뽑을 때 챙길 항목은 네 가지입니다.
- 봇이 처리한 전체 건수와 실패 건수
- 실패 건마다 남은 오류 종류와 메시지
- 실패 건을 사람이 어떻게 마무리했는지(다시 돌림, 직접 입력, 거래처에 문의 등)
- 사람이 마무리하는 데 걸린 시간이나 담당자
셋째 항목이 가장 중요합니다. 사람이 무엇을 보고 어떻게 고쳤는지가 곧 에이전트에게 맡길 수 있는 일의 윤곽이 됩니다. 이 칸이 비어 있다면 운영 담당자에게 한 주만 적어 달라고 부탁해도 충분합니다.
기록을 뽑는 기간에는 월말이 한 번 이상 들어가게 합니다. 마감 주간에 처리 건수가 늘거나 처음 보는 양식이 섞여 들어오면, 평일 기록에는 드러나지 않던 업무 예외가 그 주에 한꺼번에 나타납니다. 기록이 짧아 월말이 빠졌다면 담당자에게 지난 마감 때 손이 가장 많이 간 봇이 무엇이었는지 물어 임시로 적어 두고, 다음 마감의 기록으로 확인합니다.
실패 기록에서 RPA와 AI 에이전트의 차이는 어디서 드러나나요?
실패는 두 갈래로 나뉩니다. 대상 프로그램이 응답하지 않는 기술 문제와, 봇이 기대한 데이터가 비었거나 불완전한 업무 문제입니다. 앞의 것은 에이전트로 옮겨도 풀리지 않고, 뒤의 것 가운데 일부가 옮길 후보입니다.
RPA 제품군 가운데 UiPath는 이 구분을 공식 문서에 적어 두었습니다. 애플리케이션 예외는 응답하지 않는 프로그램 같은 기술 원인의 오류이고, 비즈니스 예외는 자동화가 기대는 데이터가 불완전하거나 빠져서 생기는 오류라고 설명합니다. 문서의 예로는 직원 전화번호에서 한 자리가 빠져 입력란이 받아 주지 않는 경우가 나옵니다.
두 예외는 기본 처리도 다릅니다. 같은 문서에 따르면 작업 대기열(처리할 건을 줄 세운 목록)에서 애플리케이션 예외로 실패한 건은 자동 재시도를 켜 두면 다시 돌지만, 비즈니스 예외로 실패한 건은 기본적으로 재시도하지 않습니다. 문서는 그 이유로 대기열 항목을 만든 처음 데이터에 오류가 있을 수 있다는 점을 듭니다.
다른 RPA 제품은 이름이 다를 수 있지만, 기록을 이 두 갈래로 다시 묶는 방식은 다른 제품의 기록에도 적용해 볼 수 있습니다.
비즈니스 예외로 멈춘 건은 결국 사람의 손으로 갑니다. 여기서 한 번 더 나눠 봅니다. 빠진 값이 원래 어디에도 없어서 거래처에 물어야 했다면 에이전트도 채울 수 없습니다. 반대로 값이 메일 본문이나 첨부 문서 어딘가에 있었고 사람이 읽어서 찾아냈다면, 그 읽는 일이 에이전트가 맡을 수 있는 몫입니다.
봇 목록은 어떤 표로 나누나요?
봇마다 실패 기록에서 세 가지를 뽑아 한 줄에 적습니다. 실패 중 업무 문제의 비중, 사람이 마무리할 때 한 일, 결과가 돈이나 계약에 곧바로 반영되는지입니다. 이 세 칸의 조합으로 봇의 자리가 정해집니다.
아래 봇 목록은 설명을 위해 꾸민 가상 예시이며, 실제 고객사의 목록이 아닙니다.
| 봇이 하는 일(가상) | 실패의 주된 종류 | 사람이 마무리할 때 한 일 | 판정 |
|---|---|---|---|
| 매일 아침 택배사 사이트에서 배송 현황을 내려받아 표로 정리하기 | 사이트 접속 지연(기술) | 시간을 두고 다시 실행 | 남김 — 재시도 설정과 접속 경로 정비 |
| 협력사 포털에 로그인해 납기 회신을 조회하고 표로 옮기기 | 포털 화면 개편 뒤 입력란을 못 찾음(기술) | 봇 담당자가 설정 수정 | 남김 — 포털이 연동 수단을 주는지 먼저 확인 |
| 은행 입금 내역을 받아 매출 채권(거래처에게서 받을 돈)과 짝지어 입금 처리하기 | 입금자명이 거래처명과 달라 짝을 못 찾음(업무) | 입금 메모와 거래처가 보낸 송금 안내 메일을 읽고 거래처·청구서를 찾아 연결 | 짝을 찾는 단계만 옮김 — 입금 처리는 봇이 계속 |
| 거래처가 보낸 단가표로 시스템 단가를 갱신하기 | 단가표 파일이 오지 않았거나 일부 품목이 빠짐(업무) | 거래처에 다시 요청 | 보류 — 받는 양식과 요청 절차부터 정리 |
| 법인카드 사용 내역을 경비 시스템에 올리기 | 적요(사용 내역에 붙은 짧은 설명)가 모호해 비용 항목을 못 정함(업무) | 사용처와 금액을 보고 항목 선택, 애매하면 사용자에게 문의 | 항목 제안만 옮김 — 확정은 사람 |
| 월말 급여 이체 파일을 만들어 은행에 올리기 | 실패가 거의 없음 | 해당 없음 | 남김 — 결과가 곧 돈이라 매번 같은 결과가 우선 |
표에서 보듯 옮기는 대상은 봇이 아니라 칸 하나입니다. 입금 봇은 입금 처리 동작을 그대로 두고, 사람이 메모와 메일을 읽어 짝을 찾던 자리만 에이전트가 맡습니다. 경비 봇은 에이전트가 항목을 제안하고 사람이 확정하는 형태로 옮깁니다.
판정은 셋째 열에서 갈립니다. 사람이 마무리할 때 사내 문서나 메일을 읽어 값을 찾아냈다면 그 읽기가 옮길 몫입니다. 셋째 열이 「거래처에 다시 요청」이라면 값이 사내 어디에도 없었다는 뜻이라 보류로 둡니다.
단가표 봇이 이 경우로, 멈추는 이유가 읽기 어려운 문서가 아니라 오지 않은 문서입니다. 에이전트가 할 수 있는 일은 독촉 메일을 쓰는 정도라서, 거래처에 받는 양식과 마감일을 먼저 정해 달라고 요청하는 편이 실패를 더 크게 줄입니다.
실패가 「다시 실행」으로 끝나는 봇도 RPA 대체 대상인가요?
아닙니다. 실패 기록이 애플리케이션 예외 위주이고, 사람의 마무리가 「다시 실행」이나 「설정 수정」뿐인 봇은 남깁니다. 기록 어디에도 사람이 무언가를 읽고 판단한 흔적이 없으니 에이전트에게 넘길 몫이 없습니다.
표의 택배사 봇과 협력사 포털 봇이 이 경우입니다. 담당자가 한 일은 시간을 두고 다시 돌리거나 바뀐 화면에 맞춰 설정을 고친 것뿐입니다. 이런 봇을 에이전트로 바꾸면 멈추는 원인은 그대로 남고, 판단하는 층만 하나 더 얹힙니다. 손볼 곳은 재시도 설정과 접속 경로, 화면이 바뀔 때 알려 줄 담당자입니다.
실패가 거의 없는 급여 이체 봇도 같은 결론입니다. 기록에 사람이 끼어든 건이 없고, 결과가 곧바로 돈이 되는 일이라 지금처럼 정해진 순서대로 도는 것이 그 봇의 가치입니다.
남기는 판정은 봇을 낮춰 보는 결정이 아닙니다. 판단이 필요 없는 일을 판단 없이 해내는 것이 그 봇의 역할이고, 그 역할은 에이전트가 들어온 뒤에도 필요합니다. 두 방식의 일반적인 성질 비교는 AI 에이전트와 RPA의 반복업무 유형별 선택 기준에서 먼저 다뤘습니다.
옮기는 단계는 기존 봇과 어떻게 이어 붙이나요?
사람에게 넘어가던 대기함을 연결 지점으로 삼습니다. 여기서 대기함은 봇이 처리하지 못해 담당자에게 넘어온 건이 쌓이는 목록이고, 봇이 일감을 꺼내 가는 작업 대기열과는 다른 목록입니다.
봇이 업무 예외로 멈춘 건을 사람 대신 에이전트가 먼저 받아 읽고, 결과를 다시 봇이 가져가는 구조입니다. 봇의 기존 동작은 손대지 않습니다.
UiPath 문서가 설명하는 것은 두 가지입니다. 에이전트가 그때그때 필요한 결정을 맡은 뒤 예측 가능한 흐름에 실행을 넘기는 구성, 그리고 에이전트가 사람에게 승인이나 결정을 요청하는 「에스컬레이션」 기능입니다. 에스컬레이션의 쓰임새로는 업무 예외가 난 과정을 듭니다.
사람 대기함을 에이전트가 먼저 받는 연결은 제가 여기서 제안하는 구성이고, UiPath 문서가 이 형태를 그대로 적은 것은 아닙니다. 다만 문서의 두 기능은 이 구성의 앞뒤 끝, 곧 봇에게 실행을 넘기는 자리와 사람에게 결정을 묻는 자리에 놓입니다.
대기함을 연결 지점으로 삼을 때 얻는 것이 또 있습니다. 에이전트를 붙이기 전과 후에 봇이 받는 입력의 모양이 같습니다. 봇 입장에서는 사람이 채워 넣던 값을 이제 에이전트가 채워 넣을 뿐이라, 봇 담당자가 봇을 다시 시험할 범위가 크게 줄어듭니다.
이어 붙일 때 따로 확인할 조건은 기다리는 시간입니다. 마이크로소프트 Copilot Studio 문서는 에이전트가 도구로 부르는 흐름(에이전트가 일하는 도중 실행을 맡기는 자동화 흐름)이 100초 동작 제한 안에 응답해야 한다고 적습니다.
몇 분씩 도는 봇을 에이전트가 직접 부르고 결과를 기다리게 짜면 이런 제한에 걸릴 수 있습니다. 그래서 에이전트는 판단 결과를 대기열에 넣고, 봇은 평소처럼 대기열에서 건을 꺼내 처리하는 방식이 기존 봇을 덜 건드립니다.
AI 에이전트 전환 중 병행 기간은 어떻게 돌리나요?
에이전트가 결과를 내더라도 한동안은 사람이 기존 방식대로 처리하고, 두 결과를 나란히 비교합니다. 비교가 쌓이는 동안 에이전트의 결과는 어디에도 반영하지 않습니다. 이 기간이 끝나야 에이전트에게 실제 처리를 넘깁니다.
순서는 네 단계로 잡습니다.
- 기준 기록: 옮길 단계에서 사람이 처리한 건과 그 결과를 한 달 이상 모아 둡니다. 나중에 에이전트 결과를 견줄 정답지가 됩니다.
- 제안만 받기: 에이전트가 같은 건을 읽고 결과를 내되, 반영은 사람이 기존대로 합니다. 담당자는 두 결과가 다를 때만 표시합니다.
- 유형별로 넘기기: 비교에서 사람과 거의 같은 결과를 낸 건 유형부터 에이전트 결과를 봇에 넘깁니다. 나머지 유형은 계속 사람이 처리합니다.
- 사람 대기함 유지: 전부 넘긴 뒤에도 에이전트가 판단하지 못한 건이 갈 사람의 자리를 없애지 않습니다.
병행 기간의 길이는 날짜가 아니라 업무 주기로 정합니다. 월말 마감, 분기 결산, 거래처 단가가 바뀌는 시기처럼 평소와 다른 건이 몰리는 때를 한 번 이상 지나야 합니다. 평온한 두 주의 비교 결과는 마감 주간의 예외를 말해 주지 않습니다.
「같은 결과」의 뜻도 미리 정합니다. 입금 건이라면 거래처와 청구서 번호가 모두 맞아야 같다고 볼지, 거래처만 맞으면 같다고 볼지에 따라 비교 결과가 크게 달라집니다. 봇이 그 값을 받아 그대로 입력하는 칸은 전부 맞아야 한다는 기준이 무난합니다. 봇은 받은 값을 의심하지 않고 입력하기 때문입니다.
비교 기록은 제안과 실제 처리가 달랐던 건을 중심으로 남깁니다. 다른 건마다 누가 맞았는지, 틀린 쪽이 무엇을 놓쳤는지를 한 줄씩 적어 두면 3단계에서 넘길 유형을 고르는 근거가 됩니다. 파일럿 결과로 본도입을 정하는 기준은 파일럿 뒤 본도입 결정 기준이 이어지는 글입니다.
에이전트가 틀리거나 멈추면 어디로 되돌아가나요?
되돌아갈 곳은 원래의 사람 대기함입니다. 에이전트가 판단하지 못했거나, 판단했지만 확신이 낮거나, 에이전트 자체가 응답하지 않는 경우 모두 그 건은 전환 전과 똑같이 담당자에게 갑니다. 이 길이 있어야 옮기는 일을 되돌릴 수 있습니다.
어느 신호가 보이면 한 단계 물러설지는 병행을 시작하기 전에 정해 둡니다.
| 보이는 신호 | 물러서는 방식 |
|---|---|
| 넘긴 유형에서 사람이 고쳐야 하는 건이 기준 기록 때보다 늘어남 | 그 유형을 다시 「제안만 받기」로 돌림 |
| 같은 착오가 같은 거래처나 같은 양식에서 반복됨 | 해당 거래처·양식만 사람 처리로 되돌림 |
| 판단 근거가 기록에 남지 않은 건이 나옴 | 기록이 남도록 고칠 때까지 넘기기 중단 |
| 봇이 대상 시스템에서 멈춤(기술 문제) | 에이전트는 그대로 두고 봇을 정비 |
마지막 줄을 따로 둔 이유가 있습니다. 전환 기간에 무언가 멈추면 새로 들어온 에이전트를 먼저 의심하기 쉬운데, 실패 기록의 종류를 보면 원인이 봇 쪽 기술 문제인 경우를 가를 수 있습니다. 원인을 가리지 않고 전부 되돌리면 병행 기간이 끝나지 않습니다.
물러설 때 필요한 준비물은 스위치 하나입니다. 유형별로 에이전트 결과를 봇에 넘길지 사람 대기함으로 보낼지를 설정 값 하나로 바꿀 수 있게 만들어 두면, 되돌리기가 개발 작업이 아니라 운영 담당자의 판단이 됩니다. 되돌리는 데 며칠이 걸리는 구조라면 담당자는 신호를 보고도 망설이게 됩니다.
전환 뒤에는 누가 무엇을 관리하나요?
봇은 지금의 봇 담당자가 계속 맡고, 에이전트의 판단 기준은 그 단계를 처리하던 업무 담당자가 맡습니다. 두 사람이 한 건의 결과를 함께 책임지는 구조라 경계를 문서로 적어 둡니다.
나누는 이유는 고칠 거리가 다르기 때문입니다. 봇이 멈추면 화면이나 접속 경로를 고쳐야 하고, 에이전트가 틀리면 어떤 문서를 보고 무엇을 기준으로 골라야 하는지를 고쳐야 합니다. 앞의 것은 설정을 아는 사람이, 뒤의 것은 업무를 아는 사람이 잘 압니다. 입금 단계라면 짝을 찾던 재무 담당자가 에이전트의 기준표를 가장 빨리 고칠 수 있습니다.
적어 둘 경계는 세 가지면 됩니다. 에이전트 결과가 대기열에 들어가기 전까지는 업무 담당자 몫, 대기열에서 봇이 꺼낸 뒤부터는 봇 담당자 몫, 사람 대기함으로 되돌아온 건은 원래 처리하던 담당자 몫입니다. 이 경계가 없으면 문제가 생길 때마다 두 사람이 서로의 영역이라고 여겨 대기함이 쌓입니다.
첫 대상은 어떤 봇의 어떤 단계로 고르나요?
봇 목록에서 업무 예외가 가장 많이 쌓인 봇 하나, 그 봇에서 사람이 문서를 읽어 값을 찾던 단계 하나로 시작합니다.
첫 대상이 작을수록 병행 기간의 비교 기록을 담당자 한 사람이 끝까지 챙길 수 있고, 그 기록이 다음 봇을 고를 때의 기준표가 됩니다. 임원이 처음 던진 「RPA를 AI로 바꾸나요?」라는 질문에도 「봇은 남기고 이 단계 하나를 옮겨 봅니다」라는 구체적인 답을 드릴 수 있습니다.
정해진 흐름으로 짤지 에이전트 빌더로 짤지 도구 부류를 먼저 가려야 한다면 n8n·Make 부류와 에이전트 빌더 부류의 구분과 나란히 읽으면 도구를 고르기가 한결 쉽습니다.
봇 목록과 실패 기록, 사람이 마무리한 방식을 적은 표가 준비되어 있다면 하마다랩스 솔루션 비교 상담에서 어느 칸부터 옮길지를 그 표 위에서 함께 고릅니다.
자주 묻는 질문
봇을 만든 담당자가 회사를 떠나 봇이 어떻게 짜였는지 아무도 모르면 어떻게 하나요?
실패 기록과 입력·출력 파일부터 확보합니다. 봇 내부 구조를 몰라도 무엇을 받아 무엇을 내놓는지, 어디서 멈추는지는 기록으로 알 수 있습니다. 옮길 단계가 봇의 앞단이라면 봇 내부를 고치지 않고도 연결할 수 있어, 구조를 전부 파악하기 전에 판정을 시작할 수 있습니다.
쓰고 있는 RPA 제품에 에이전트 기능이 생겼다면 그 제품 안에서 옮기는 편이 낫나요?
기존 봇과 대기열을 다시 만들지 않아도 된다는 점은 장점입니다. 다만 에이전트가 읽어야 할 문서가 어디에 있는지, 그 제품이 사내 시스템과 어떻게 연결되는지, 에이전트 기능의 과금 방식이 어떤지는 따로 확인해야 합니다. 같은 제품이라는 이유만으로 정하지 말고 다른 도구와 같은 기준으로 견주는 편이 안전합니다.
개인정보가 들어 있는 문서를 에이전트가 읽어도 되나요?
회사의 개인정보 처리 기준과 에이전트가 쓰는 모델이 어디서 동작하는지를 먼저 확인해야 합니다. 외부 서비스로 문서가 나가는 구성인지, 사내 서버 안에서 처리되는 구성인지에 따라 검토할 항목이 달라집니다. 이 확인은 병행 기간을 시작하기 전에 끝내 둡니다.
에이전트로 옮기면 RPA 라이선스 비용이 줄어드나요?
봇을 없애는 것이 아니라 봇 앞에 판단 단계를 붙이는 방식이라면 RPA 비용은 그대로이고 에이전트 비용이 더해집니다. 대신 사람이 예외를 처리하던 시간이 줄어드는지를 봐야 합니다. 어느 쪽이 큰지는 회사마다 달라서, 병행 기간의 기록으로 확인하는 것이 정확합니다.
봇이 거의 실패하지 않는데도 에이전트를 붙일 이유가 있나요?
실패가 적다면 그 봇은 제 역할을 하고 있는 것입니다. 다만 봇이 처리하기 전에 사람이 입력 자료를 미리 손봐 주고 있어서 실패가 적은 경우가 있습니다. 봇 앞 단계에서 사람이 하는 준비 작업이 있는지 담당자에게 물어보면, 기록에 드러나지 않은 후보가 보이기도 합니다.
병행 기간 중에 담당자 업무가 오히려 늘지 않나요?
늘어납니다. 기존 처리를 그대로 하면서 에이전트 결과와 다를 때 표시하는 일이 더해지기 때문입니다. 그래서 병행 대상을 봇 하나의 단계 하나로 좁히고, 표시는 다른 건에만 하도록 정해 두면 부담을 줄일 수 있습니다.
참고 자료
- UiPath Documentation, Orchestrator 「Business Exception Vs Application Exception」 — 두 예외의 정의와 예시, 작업 대기열의 재시도 기본 동작(2026-10-01 확인): https://docs.uipath.com/orchestrator/docs/business-exception-vs-application-exception
- UiPath Documentation, Agents 「Agents and workflows」 — 정해진 흐름과 에이전트의 성격 비교, 에이전트가 결정 뒤 흐름에 실행을 넘기는 구성(2026-10-01 확인): https://docs.uipath.com/agents/automation-cloud/latest/user-guide/agent-vs-workflows
- UiPath Documentation, Agents 「Escalations」 — 에이전트 실행 중 사람의 승인·결정을 요청하는 기능과 업무 예외 쓰임새(2026-10-01 확인): https://docs.uipath.com/agents/automation-cloud/latest/user-guide/agent-escalations
- Microsoft Learn, Copilot Studio 「Add an agent flow as a tool to an agent」 — 에이전트 도구로 쓰는 흐름의 조건과 100초 동작 제한(2026-10-01 확인): https://learn.microsoft.com/en-us/microsoft-copilot-studio/flow-agent
작성자
안효준 — 하마다랩스 윈디플로 프로덕트 매니저. 윈디플로와 n8n·Dify 등 노코드 빌더를 같은 선택 기준으로 비교하고, 소규모 POC·파일럿으로 도입을 검증하는 절차를 다룹니다. 회사 소개: https://www.hamadalabs.com/
