자동화를 검토할 때 “RPA는 옛 기술이고 AI 에이전트가 새 기술이니 교체해야 한다”는 식으로 접근하면 선택을 그르치기 쉽습니다. 두 기술은 세대가 아니라 맡기려는 판단의 성격이 다릅니다.
30초 요약
정해진 반복은 RPA, 달라지는 판단은 AI, 실제 업무는 혼합형입니다.
실제 흐름신청서 도착→AI가 읽기→규칙 확인→RPA 입력→예외만 사람 승인
| 용어 | 쉬운 뜻 |
|---|---|
| RPA | 사람이 정한 화면 조작과 입력 순서를 그대로 반복하는 자동화 |
| AI 에이전트 | 목표를 받고 상황에 따라 다음 작업이나 도구를 고르는 시스템 |
| 워크플로 | 사람이 미리 정한 순서대로 여러 작업을 이어 놓은 흐름 |
| 혼합형 | AI의 읽기·판단과 규칙·RPA의 실행을 나눠 쓰는 방식 |
정해진 화면에서 정해진 값을 옮기고, 조건에 따라 예외를 나눌 수 있다면 RPA가 더 단순하고 예측 가능할 수 있습니다. 반대로 이메일·계약서·상담 기록처럼 형식과 표현이 제각각인 자료를 읽고, 다음에 사용할 도구나 작업 순서를 상황에 따라 골라야 한다면 AI 에이전트를 검토할 이유가 생깁니다. 실제 업무에서는 둘 중 하나만 쓰기보다 AI가 읽고 판단 후보를 만들고, 규칙 기반 업무 흐름과 RPA가 확인된 동작을 실행하며, 사람이 영향이 큰 지점에서 승인하는 혼합형이 더 현실적인 경우가 많습니다.
이 글은 RPA 공급사와 AI 모델 공급사의 공식 기술 설명, 미국 국립표준기술연구소(NIST)의 AI 위험관리 자료, EU 인공지능법 원문을 참고했습니다. IBM과 Anthropic 자료는 각각 관련 제품·모델을 공급하는 기업이 작성한 자료이므로 기술 개념과 설계 관점을 이해하는 데 사용했으며, 그들이 제시하는 효율·성과 주장을 Morrow가 독립 검증한 것으로 취급하지 않습니다.
먼저 결론
- 경로와 규칙을 사전에 쓸 수 있으면 RPA 또는 일반 워크플로부터 검토하세요. 같은 입력에 같은 절차와 결과가 요구되는 대량·반복 업무에 맞습니다.
- 입력이 비정형이고 다음 단계를 미리 고정하기 어렵다면 AI 에이전트를 검토하세요. 단, 에이전트가 행동할 수 있는 도구·데이터·횟수·금액의 범위를 제한해야 합니다.
- AI 에이전트가 항상 RPA보다 상위 선택지는 아닙니다. 에이전트는 유연성을 얻는 대신 결과 변동, 평가 부담, 모델 사용료, 지연, 누적 오류 가능성을 추가합니다.[s1]
- 대부분의 기업 업무는 혼합형으로 나누는 편이 실용적입니다. AI는 문서 이해·분류·초안·예외 설명을, 결정론적 코드나 RPA는 형식 검증·정책 확인·시스템 입력을 맡고, 결제·환불·발송·삭제·권한 변경 전에는 사람 승인을 둡니다.
- 제품명을 고르기 전에 “어떤 입력을 받고, 어떤 판단을 하며, 어떤 외부 변화를 만들고, 틀리면 어떻게 되돌릴 것인가”를 먼저 적어야 합니다.
RPA와 AI 에이전트, 한 문장으로 구분하면
RPA(Robotic Process Automation)는 사람이 정한 절차를 소프트웨어 로봇이 반복 실행하는 방식입니다. IBM은 RPA를 API와 사용자 인터페이스(UI) 상호작용을 이용해 데이터 추출, 양식 입력, 파일 이동 같은 반복 업무를 수행하는 규칙 기반 소프트웨어로 설명합니다.[s2] 이 정의는 RPA 제품 공급사의 설명이지만, RPA가 사전에 정의된 과정의 실행에 초점을 둔다는 점을 파악하는 데 유용합니다.
AI 에이전트는 목표를 받고, 현재 상황과 도구 실행 결과를 바탕으로 다음 단계와 도구 사용을 동적으로 정하는 시스템을 가리킵니다. 다만 업계 전체가 합의한 단일 정의는 없습니다. Anthropic은 넓은 의미의 ‘에이전틱 시스템’ 안에서도, LLM과 도구가 미리 정한 코드 경로를 따르는 워크플로와 LLM이 자신의 과정과 도구 사용을 동적으로 지휘하는 에이전트를 구분합니다.[s1] 이 역시 모델 공급사의 설계 관점이며 법적·산업 표준 정의는 아닙니다.
따라서 핵심 차이는 ‘AI가 들어갔는가’만이 아닙니다. OCR이나 분류 모델을 붙인 RPA도 있을 수 있고, LLM을 사용하지만 고정된 세 단계만 수행하는 워크플로도 있을 수 있습니다. 실무에서는 다음 질문이 더 정확합니다.
실행 경로를 사람이 미리 결정하는가, 아니면 모델이 상황에 따라 다음 경로를 선택하는가?
결정론적 규칙과 비정형 판단의 차이
1. RPA: “정해진 절차를 그대로 수행하라”
전형적인 RPA는 다음과 같은 지시와 잘 맞습니다.
- 매일 오전 9시에 ERP에 로그인한다.
- 전일 주문 목록을 내려받는다.
- 상태가 ‘결제 완료’인 행만 선택한다.
- 정해진 열을 회계 시스템 양식에 복사한다.
- 실패한 행은 오류 목록에 기록한다.
입력 위치, 필드, 분기 조건, 출력 위치가 정해져 있습니다. 같은 조건이라면 같은 경로를 타도록 설계할 수 있고, 어느 단계에서 실패했는지 추적하기도 비교적 쉽습니다. API가 없는 오래된 시스템을 UI로 조작해야 할 때도 RPA가 연결 수단이 될 수 있습니다.[s2]
하지만 ‘거래처가 보낸 자유 형식 이메일을 읽고 긴급도와 의도를 해석한 뒤, 필요한 자료를 추론해 요청하라’는 지시는 규칙만으로 모두 열거하기 어렵습니다. 화면 위치나 문서 형식이 바뀌면 UI 기반 자동화가 깨질 수 있고, 예외 규칙이 계속 늘어나면 유지보수 부담도 커집니다. 그렇다고 바로 에이전트로 바꾸기보다, 화면 자동화가 아니라 안정적인 API 연동이 가능한지, 업무 표준화로 예외를 줄일 수 있는지를 먼저 확인해야 합니다.
2. AI 에이전트: “목표 안에서 다음 수를 선택하라”
AI 에이전트가 필요한 상황은 단계의 수나 순서를 사전에 완전히 고정하기 어려울 때입니다. 예를 들어 고객 문의 해결이라는 목표를 받으면 다음과 같은 경로를 상황에 따라 고를 수 있습니다.
- 문의 의도와 제품명을 파악한다.
- 필요한 경우 주문 조회 도구를 사용한다.
- 사내 정책 문서에서 관련 규정을 찾는다.
- 정보가 부족하면 고객에게 추가 질문 초안을 만든다.
- 해결 가능한 문의는 답변 초안을 만들고, 환불 요청은 승인 대기열로 보낸다.
여기서 에이전트의 가치는 문장을 그럴듯하게 쓰는 것보다 어떤 정보를 더 찾을지, 어느 도구를 쓸지, 언제 사람에게 넘길지 선택하는 능력에 있습니다. Anthropic은 고정 경로를 하드코딩하기 어렵고 필요한 단계 수를 예측하기 힘든 개방형 문제에서 에이전트를 검토할 수 있다고 설명합니다. 동시에 자율성이 비용 증가와 오류 누적 가능성을 가져오므로 샌드박스 테스트와 가드레일이 필요하다고 경고합니다.[s1]
3. 결정론과 확률론을 너무 단순하게 나누지 말 것
‘RPA는 100% 정확하고 AI는 항상 틀린다’거나 ‘AI는 스스로 배우므로 규칙이 필요 없다’는 설명은 모두 과도합니다.
- RPA도 잘못된 규칙, 바뀐 화면, 불완전한 입력, 권한 만료 때문에 실패할 수 있습니다.
- AI 에이전트도 스키마 검증, 허용 도구 목록, 금액 한도, 정지 조건 같은 결정론적 통제 안에서 운영할 수 있습니다.
- 생성형 AI의 출력은 표현과 판단이 달라질 수 있으므로 단순 성공·실패 로그만이 아니라 입력, 사용한 자료, 도구 호출, 승인, 최종 결과를 함께 평가해야 합니다.
- ‘학습한다’는 표현도 주의해야 합니다. 모든 에이전트가 운영 중 자동으로 모델을 재학습하는 것은 아닙니다. 대화 맥락이나 저장된 메모리를 사용하는 것과 모델 자체가 학습되는 것은 구분해야 합니다.
좋은 설계는 두 방식을 대립시키지 않습니다. 판단이 필요한 곳에만 확률적 모델을 쓰고, 지켜야 할 정책과 실행 경계는 결정론적으로 고정합니다.
핵심 차이 비교표
| 비교 항목 | RPA·결정론적 워크플로 | AI 에이전트 | 선택 시 확인할 점 |
|---|---|---|---|
| 주된 역할 | 미리 정의된 절차 실행 | 목표에 맞춰 다음 단계·도구 선택 | 경로를 사전에 전부 쓸 수 있는가? |
| 입력 | 표, 필드, 정형 데이터에 유리 | 이메일, 문서, 대화 등 비정형 입력 처리에 유리 | 입력 형식의 변동이 얼마나 큰가? |
| 분기 | 명시적 조건문 | 문맥 기반 분류·추론과 도구 선택 | 판단 근거를 검토할 수 있는가? |
| 결과 일관성 | 규칙과 환경이 같으면 높게 설계 가능 | 모델·프롬프트·맥락에 따라 달라질 수 있음 | 허용 가능한 오차는 얼마인가? |
| 예외 처리 | 예상 예외를 코드로 작성 | 예상하지 못한 상황을 해석할 여지가 있음 | 예외 시 멈춤·사람 이관 조건은? |
| 시스템 연결 | API 또는 화면 조작 | API·검색·데이터베이스·RPA를 도구로 사용 | 최소 권한과 도구별 한도가 있는가? |
| 테스트 | 경로·조건·입출력 대조 중심 | 대표·경계·공격 입력 평가와 도구 실행 검증 필요 | 출시 전 평가 세트를 만들 수 있는가? |
| 운영비 | 라이선스, 봇 인프라, 시나리오 유지보수 | 모델 호출, 검색·도구, 평가, 관측, 안전 운영 | 건당 총비용을 계산했는가? |
| 주요 취약점 | UI·업무 규칙 변경, 예외 폭증 | 환각, 잘못된 도구 선택, 오류 누적, 데이터 노출 | 실패 영향과 복구 절차는? |
| 적합한 첫 업무 | 대량 입력, 파일 이동, 정기 보고, 시스템 간 전사 | 문서 분류·요약, 문의 라우팅, 조사·초안, 복합 예외 분석 | 더 단순한 방식으로 충분한가? |
이 표는 제품별 성능을 보장하는 벤치마크가 아니라 업무를 나누기 위한 판단 틀입니다. 최근 자동화 제품들은 RPA, 문서 AI, 생성형 AI, 에이전트 기능을 함께 제공하기 때문에 제품 이름만으로 기술 경계를 판단해서는 안 됩니다.
어떤 업무에 무엇을 선택할까: 업무 선택표
| 업무 예시 | 업무 특성 | 우선 선택 | 권장 경계 | 이유 |
|---|---|---|---|---|
| 정해진 양식의 매출 데이터를 ERP에 입력 | 필드와 규칙이 고정됨 | RPA 또는 API 워크플로 | 오류 행만 사람 확인 | 모델 판단이 거의 필요 없음 |
| 여러 시스템에서 수치를 모아 정기 보고서 생성 | 조회 위치와 계산식이 고정됨 | API/워크플로, 필요 시 RPA | 수치 대조 후 배포 | 계산과 이동은 결정론적으로 처리 가능 |
| 자유 형식 이메일을 문의 유형별 분류 | 표현은 다양하고 출력 범주는 정해짐 | 단일 LLM 분류 또는 고정 AI 워크플로 | 낮은 신뢰도만 사람 이관 | 자율 에이전트까지는 과할 수 있음 |
| 계약서에서 지정 조항을 찾아 검토표 초안 작성 | 비정형 문서, 확인 기준 존재 | AI 워크플로 | 원문 위치 표시, 법무 담당자 확정 | 추출·비교에는 AI가 유용하나 법적 판단은 사람 몫 |
| 고객 문의를 조사해 답변 초안 작성 | 문맥 이해와 여러 자료 조회 필요 | 제한된 AI 에이전트 | 발송 전 담당자 승인 | 필요한 조회 순서가 문의마다 달라짐 |
| 공급사 서류 검토 후 ERP 등록 | 문서 이해와 정형 입력이 결합됨 | AI + 규칙 + RPA 혼합형 | 원문 대조 승인 후 등록 | AI는 추출, 규칙은 검증, RPA는 입력에 적합 |
| 환불 승인 및 실제 송금 | 정책 판단과 금전 영향이 큼 | 혼합형 보조만 | 에이전트는 자료·추천, 사람이 승인, 결정론적 실행 | 오판의 외부 영향과 복구 비용이 큼 |
| 임직원 계정 권한 변경 | 보안 영향이 매우 큼 | 승인형 워크플로 | 권한 요청 검증과 이중 승인, 제한된 실행 | 완전 자율 실행의 초기 후보로 부적합 |
| 경쟁사·시장 자료 조사와 요약 | 검색 경로와 자료 수가 가변적 | 제한된 AI 에이전트 | 출처 목록과 인용 근거를 사람이 검토 | 경로를 미리 정하기 어렵지만 결과 검증은 가능 |
| 채용·신용·의료·법률상 권리에 영향을 주는 결정 | 고영향 판단 | 자동 결정 대상으로 먼저 선택하지 않음 | 전문가 검토와 법적 요구사항 별도 확인 | 단순 효율 문제가 아니라 권리·규제·책임 문제 |
업무 선택에서 중요한 것은 ‘AI를 얼마나 많이 넣었는가’가 아닙니다. 가장 단순하면서 요구 성능과 통제 수준을 충족하는 구조가 우선입니다. Anthropic도 단일 LLM 호출이나 고정 워크플로로 충분하다면 복잡한 에이전트를 만들지 말고, 복잡성이 결과를 실제로 개선할 때만 추가하라고 권고합니다.[s1]
가장 현실적인 답: AI + 규칙 + RPA 혼합 아키텍처
기업의 실제 프로세스는 문서 이해와 시스템 실행이 한 흐름에 섞여 있습니다. 이때 하나의 에이전트에 모든 권한을 주기보다 역할을 분리할 수 있습니다.
예시: 거래처 신청서 등록
```text 1. 접수 이메일과 첨부파일을 격리된 대기열에 저장
-
AI 이해 문서 종류 분류 → 회사명·사업자번호·계좌 등 지정 항목 추출 → 각 값의 원문 페이지·근거와 신뢰도 표시
-
결정론적 검증 필수 항목 존재 여부 → 형식·자리수 → 중복 거래처 → 허용 국가·계정 규칙 확인
-
사람 승인 담당자가 원문과 추출값, 검증 결과, 변경 예정 시스템을 확인 → 승인·수정·거절
-
실행 승인된 구조화 값만 API 또는 RPA가 ERP 테스트/운영 환경에 입력
-
확인과 복구 생성된 레코드 ID와 실행 로그 기록 → 후속 조회로 반영 확인 → 오류 시 레코드 비활성화 또는 수기 대기열 복귀 ```
이 구조에서 AI 에이전트는 모든 것을 직접 처리하는 ‘디지털 직원’이 아닙니다. 문서를 읽고 필요한 검사를 선택하거나 예외를 설명하는 제한된 판단 계층입니다. 정책 검증은 코드로 고정하고, 실제 시스템 변경은 승인된 값만 받는 실행 계층으로 분리합니다.
혼합형 설계의 다섯 가지 원칙
- 읽기와 쓰기 권한을 분리합니다. 조사·조회 도구와 결제·발송·삭제 도구를 같은 권한으로 제공하지 않습니다.
- AI의 자연어 결과를 바로 실행 명령으로 쓰지 않습니다. 정해진 스키마로 변환하고 필수 값, 허용 값, 금액 한도를 검증합니다.
- 실행은 가능하면 API를 우선 검토합니다. RPA의 UI 조작은 API가 없거나 연결 비용이 과도한 구간에서 사용하고, 화면 변경 감지와 실패 처리를 둡니다.
- 고위험 행동 앞에 승인 게이트를 둡니다. 승인자는 요약만이 아니라 원문 근거, 변경 전후 값, 대상 시스템을 확인할 수 있어야 합니다.
- 종료 조건을 만듭니다. 최대 도구 호출 수, 최대 처리 시간, 재시도 횟수, 비용 한도, 사람 이관 조건이 없으면 오류가 반복될 수 있습니다.[s1]
위험과 비용을 묻는 12가지 질문
도입 견적에서 라이선스나 모델 토큰 가격만 비교하면 총비용을 놓칩니다. 아래 질문에 답하면서 후보 구조를 비교하세요.
업무와 품질
- 정답을 무엇과 대조할 것인가? 원문, ERP 기준값, 승인 정책처럼 확인 가능한 기준이 없으면 품질 측정이 어렵습니다.
- 허용 가능한 오류는 무엇인가? 오탈자와 잘못된 송금은 같은 오류율로 비교할 수 없습니다.
- 대표 입력뿐 아니라 예외 입력이 준비되어 있는가? 빈 문서, 중복 파일, 다른 언어, 모순된 값, 악의적 지시가 포함된 문서도 시험해야 합니다.
권한과 보안
- 에이전트가 볼 수 있는 데이터는 어디까지인가? 업무에 불필요한 개인정보와 전체 데이터베이스 접근을 기본값으로 주지 않습니다.
- 무엇을 실제로 변경할 수 있는가? 조회, 초안, 등록, 발송, 결제, 삭제, 권한 변경을 각각 분리합니다.
- 외부 문서 안의 지시를 데이터로 취급하는가? 이메일이나 웹 문서의 ‘이 지시를 따르라’는 문장이 에이전트의 운영 규칙을 덮어쓰지 못하도록 설계하고 시험해야 합니다.
통제와 책임
- 누가 언제 승인하는가? 승인자가 부재할 때 자동 통과시키는지, 멈추는지 정해야 합니다.
- 무엇을 기록할 것인가? 입력 버전, 사용 모델, 참조 자료, 도구 호출, 승인자, 실행 결과, 오류와 복구를 연결할 수 있어야 합니다.
- 누가 중단하고 되돌릴 수 있는가? 운영팀이 즉시 권한을 회수하고 수작업으로 복귀할 수 있어야 합니다.
총비용
- 구축비 외 운영비는 얼마인가? RPA는 화면·규칙 변경 대응과 봇 운영, 에이전트는 모델 호출·검색·평가·로그·보안 검토 비용이 발생합니다.
- 사람 검토 시간까지 포함했는가? 초안 생성 시간이 줄어도 검토 화면이 나쁘거나 근거가 없으면 총 처리시간은 줄지 않을 수 있습니다.
- 복잡성을 추가한 만큼 성과가 개선되는가? 단일 프롬프트, 고정 워크플로, 제한된 에이전트를 같은 평가 세트로 비교해야 합니다. 에이전트는 지연과 비용을 더 쓰고도 실제 업무 결과를 개선하지 못할 수 있습니다.[s1]
NIST의 AI 위험관리 프레임워크(AI RMF)는 특정 제품을 고르는 규격이 아니라 자발적으로 활용하는 위험관리 틀입니다. 현재 공개 페이지는 AI RMF 1.0의 개정판이 준비 중이라고 명시하며, 핵심 기능을 Govern, Map, Measure, Manage로 제시합니다.[s3] 실무적으로는 책임과 정책을 정하고(Govern), 업무 맥락과 피해 가능성을 파악하고(Map), 실제 데이터로 성능과 위험을 측정하고(Measure), 제한·승인·개선 조치를 운영하는(Manage) 순서로 적용할 수 있습니다.
규제 자료는 어떻게 읽어야 하나
EU 인공지능법(Regulation (EU) 2024/1689)은 위험 수준과 사용 맥락에 따라 의무를 구분합니다.[s4] 예를 들어 고위험 AI 시스템에는 위험관리, 기록, 인간 감독 등 구체적 요구가 연결될 수 있습니다. 그러나 모든 사내 RPA나 AI 에이전트가 자동으로 같은 의무를 지는 것은 아니며, 한국 기업이라도 EU 시장·사용자·공급망과의 관계 및 시스템의 역할에 따라 적용 여부가 달라질 수 있습니다.
따라서 이 글의 승인·로그 권고를 “모든 경우에 EU 법이 요구한다”는 법률 판단으로 읽어서는 안 됩니다. 국내 개인정보보호법, 산업별 규정, 계약상 의무와 함께 법무·보안 담당자가 실제 적용 범위를 확인해야 합니다. 다만 적용 의무와 별개로, 고영향 행동의 사람 감독과 추적 가능한 기록은 사고 조사와 책임 분담을 위해 검토할 가치가 있습니다.
도입 체크리스트
1단계: 업무를 기술과 분리해 적기
- [ ] 시작 조건, 입력, 처리 단계, 출력, 종료 조건을 한 장에 적었다.
- [ ] 현재 담당자가 실제로 사용하는 예외 처리 방법을 확인했다.
- [ ] 업무량, 평균 처리시간, 재작업률 등 현재 기준선을 측정했다.
- [ ] 자동화하지 않을 범위를 명시했다.
2단계: 가장 단순한 기술 선택하기
- [ ] API나 기존 SaaS 기능만으로 해결 가능한지 확인했다.
- [ ] 고정 규칙이면 일반 워크플로 또는 RPA부터 비교했다.
- [ ] 비정형 입력 처리만 필요하면 단일 LLM 호출이나 고정 AI 워크플로를 먼저 시험했다.
- [ ] 경로와 단계 수가 실제로 가변적일 때만 에이전트를 후보에 넣었다.
- [ ] AI 판단과 결정론적 검증·실행을 분리했다.
3단계: 권한과 승인 경계 만들기
- [ ] 조회와 변경 권한을 분리했다.
- [ ] 서비스 계정에 최소 권한과 만료 정책을 적용했다.
- [ ] 발송·결제·환불·삭제·권한 변경 전에 사람 승인을 둔다.
- [ ] 승인자가 원문 근거와 변경 전후 값을 볼 수 있다.
- [ ] 호출 횟수, 시간, 비용, 금액, 대상 시스템의 상한을 정했다.
4단계: 평가와 실패 처리 설계하기
- [ ] 정상·경계·오류·공격 입력을 포함한 평가 세트를 만들었다.
- [ ] 정확도뿐 아니라 미처리율, 사람 수정률, 외부 영향 오류를 구분한다.
- [ ] 모델·프롬프트·규칙 변경 전후를 같은 기준으로 비교한다.
- [ ] 실패 시 중단, 사람 이관, 재시도, 복구 절차가 있다.
- [ ] 기존 수작업으로 돌아가는 방법을 실제로 시험했다.
5단계: 운영 책임 정하기
- [ ] 업무 책임자, 기술 운영자, 보안 담당자, 최종 승인자를 지정했다.
- [ ] 입력·근거·도구 호출·승인·실행·복구 로그의 보존 범위를 정했다.
- [ ] 개인정보·기밀정보의 저장 위치와 보존 기간을 검토했다.
- [ ] 공급사 장애, 모델 변경, 가격 변경, 계약 종료 시 대안을 마련했다.
- [ ] 파일럿의 성공 기준과 중단 기준을 모두 합의했다.
흔한 선택 오류 5가지
“비정형 문서가 있으니 전 과정을 에이전트로 만들자”
문서 읽기만 AI가 필요하고 이후 검증과 입력은 고정 규칙일 수 있습니다. AI가 필요한 구간을 좁히면 평가와 복구가 쉬워집니다.
“RPA가 이미 있으니 AI 에이전트는 필요 없다”
반복되는 수작업 예외의 원인이 자유 형식 이메일이나 문서 해석이라면, 기존 RPA 앞에 AI 분류·추출 계층을 붙여 자동화 범위를 넓힐 수 있습니다. 기존 투자를 모두 버릴 필요는 없습니다.
“사람 승인을 넣으면 자동화 효과가 없다”
모든 단계에 승인할 필요는 없습니다. 외부 영향이 큰 지점, 낮은 신뢰도, 정책 예외에만 승인을 집중할 수 있습니다. 파일럿 초기의 승인 기록은 어떤 조건을 향후 자동 통과시킬지 판단할 데이터가 됩니다.
“벤더 데모가 잘되면 우리 데이터에서도 잘된다”
공급사 데모와 사례는 후보 탐색 자료이지 독립 검증 결과가 아닙니다. 우리 문서, 약어, 예외, 권한, 시스템 지연을 반영한 테스트가 필요합니다. 특히 공급사가 제시하는 ROI·시간 절감 수치는 산정 범위와 이해관계를 확인해야 합니다.
“에이전트가 판단했으니 책임도 에이전트에 있다”
시스템은 법적·운영적 책임 주체를 대신하지 않습니다. 누가 배포를 승인하고, 누가 예외를 검토하고, 사고 시 누가 중단할지를 조직이 정해야 합니다.
FAQ
Q1. RPA와 매크로는 같은가요?
둘 다 정해진 동작을 반복할 수 있지만, 일반적으로 RPA 플랫폼은 여러 업무 시스템 연결, 자격증명 관리, 스케줄링, 실행 모니터링과 봇 운영 기능을 함께 제공합니다. 다만 제품마다 범위가 다르므로 ‘RPA’라는 이름만 보고 기능을 가정하지 말고 실제 운영·보안 기능을 확인해야 합니다.
Q2. 생성형 AI를 쓰면 모두 AI 에이전트인가요?
아닙니다. 한 번의 요청으로 요약문을 만드는 기능이나, 미리 정한 세 단계를 차례로 수행하는 시스템은 AI를 사용해도 자율적으로 다음 경로를 선택하는 에이전트와 다릅니다. Anthropic의 구분처럼 고정 코드 경로의 워크플로와 동적으로 과정·도구를 지휘하는 에이전트를 나눠 보는 것이 실무에 유용합니다.[s1]
Q3. AI 에이전트가 RPA를 대체하나요?
일괄 대체 관계로 보기 어렵습니다. 에이전트가 RPA를 하나의 실행 도구로 호출할 수도 있고, RPA 앞단에서 비정형 문서를 구조화할 수도 있습니다. 정해진 시스템 입력은 여전히 결정론적 실행이 유리할 수 있습니다.
Q4. 어떤 업무가 첫 파일럿에 가장 적합한가요?
반복 빈도가 높고, 입력과 출력이 명확하며, 원문이나 기준값으로 결과를 확인할 수 있고, 실행 전에 사람이 검토할 수 있으며, 실패 시 기존 방식으로 복귀 가능한 업무가 적합합니다. 문서 분류, 지정 항목 추출, 문의 라우팅, 보고서 초안처럼 외부 영향을 통제할 수 있는 범위부터 검토하세요.
Q5. 고객 응대에는 RPA와 에이전트 중 무엇이 맞나요?
문의 유형이 몇 가지이고 답변 템플릿이 고정되어 있다면 분류 모델과 워크플로로 충분할 수 있습니다. 문의마다 주문·정책·기술 자료를 서로 다른 순서로 조회해야 한다면 제한된 에이전트를 검토할 수 있습니다. 환불 실행이나 대외 발송은 초기에는 사람 승인 뒤 결정론적으로 처리하는 편이 안전합니다.
Q6. 정확도를 몇 퍼센트까지 확보해야 하나요?
모든 업무에 적용되는 숫자는 없습니다. 오류의 종류와 영향, 사람 검토 여부, 미처리 허용량에 따라 기준이 달라집니다. 전체 정확도 하나보다 잘못된 자동 실행, 사람에게 넘긴 비율, 수정률, 처리시간, 복구시간을 분리해 측정하세요.
Q7. 비용은 어떻게 비교해야 하나요?
RPA 라이선스나 모델 호출료만 보지 말고 연결 개발, 테스트 데이터 준비, 보안 검토, 승인자 시간, 모니터링, 화면·규칙·모델 변경 대응, 장애 복구를 포함한 건당 총비용을 비교해야 합니다. 단순 워크플로와 에이전트를 같은 평가 세트로 시험해 추가 복잡성이 실제 가치를 만드는지도 확인하세요.
Q8. 사람 승인은 어디에 둬야 하나요?
AI가 읽거나 초안을 만드는 모든 단계보다 되돌리기 어렵거나 외부 효과를 만드는 직전이 우선입니다. 고객 발송, 계약 확정, 결제·환불, 데이터 삭제, 계정 권한 변경이 대표적입니다. 낮은 신뢰도나 정책 예외도 승인 대기열로 보낼 수 있습니다.
Q9. 로그만 남기면 안전한가요?
아닙니다. 로그는 사고를 막는 통제 자체가 아니라 추적과 개선을 돕는 수단입니다. 최소 권한, 입력 검증, 도구별 한도, 승인, 정지 조건, 복구 절차와 함께 설계해야 합니다. 로그에 개인정보나 비밀정보를 과도하게 남기지 않도록 접근권한과 보존 기간도 정해야 합니다.
Q10. 법률·채용·신용 같은 고영향 업무에도 쓸 수 있나요?
자료 검색, 누락 확인, 초안 작성처럼 전문가를 보조하는 좁은 범위는 검토할 수 있습니다. 그러나 개인의 권리와 기회에 영향을 주는 최종 판단을 일반적인 첫 자동화 대상으로 삼아서는 안 됩니다. 관할 법률과 산업 규제, 차별·설명·이의제기 절차를 별도로 검토하고 담당 전문가의 승인을 받아야 합니다.
우리 회사에 맞는 선택은 제품 비교보다 업무 분해에서 시작한다
RPA와 AI 에이전트 중 하나를 회사의 표준 답으로 정할 필요는 없습니다. 한 업무 안에서도 ‘읽기, 판단, 검증, 승인, 실행, 복구’를 나누면 각 단계에 맞는 기술이 보입니다.
- 규칙이 명확한 이동과 입력은 API·워크플로·RPA
- 비정형 자료의 분류·추출·초안은 AI
- 다음 단계가 가변적인 제한된 조사·조정은 AI 에이전트
- 정책과 형식 검증은 결정론적 코드
- 고영향 실행은 사람 승인 후 제한된 실행 계층
기술을 고르기 전에 현재 업무 한 건이 실제로 어떻게 흘러가는지 그려보세요. 가장 단순한 구조부터 시험하고, 결과가 충분하지 않을 때만 복잡성을 추가하는 것이 비용과 위험을 함께 관리하는 출발점입니다.
CTA: 무료 업무 자동화 자가진단
RPA가 맞는지, AI 에이전트가 필요한지, 두 방식을 어디서 나눠야 할지 판단하기 어렵다면 Morrow 무료 업무 자동화 자가진단으로 후보 업무를 먼저 정리해 보세요.
진단에서는 다음 항목을 함께 살펴봅니다.
- 업무의 반복성과 입력 형식
- 결정론적 규칙으로 표현 가능한 범위
- 비정형 판단과 도구 선택이 필요한 구간
- 사람 승인과 실행 권한의 경계
- 실패 영향과 복구 가능성
- 파일럿에서 측정할 품질·시간·비용 지표
진단 결과 자동화 적합성이 확인된 경우, 한 업무를 대상으로 AI + 규칙 + RPA의 승인형 파일럿 구조를 구체화하는 상담으로 연결할 수 있습니다. 진단이나 상담이 성과를 보장하는 것은 아니며, 실제 도입 여부는 데이터·시스템·보안·규제 조건을 검토한 뒤 결정해야 합니다.
출처와 접근 기록 보기
출처 및 접근 기록
-
[s1] Anthropic, “Building effective agents”
URL: https://www.anthropic.com/engineering/building-effective-agents
게시일: 2024-12-19 · 접근일: 2026-07-19
출처 성격: AI 모델·에이전트 기술 공급사의 공식 엔지니어링 글. 워크플로와 에이전트의 구분, 단순한 구조 우선, 비용·지연·오류 누적·샌드박스 테스트에 관한 공급사 설계 관점으로 사용했다. 고객 성과나 제품 우위를 독립 검증하는 자료로 사용하지 않았다. -
[s2] IBM, “What is Robotic Process Automation (RPA)?”
URL: https://www.ibm.com/think/topics/rpa
접근일: 2026-07-19
출처 성격: RPA 제품·서비스 공급사의 공식 설명 자료. RPA의 규칙 기반 실행, API·UI 상호작용, 반복 업무라는 기술 정의에 한정해 참고했다. 페이지의 ROI, 생산성, 고객 사례 및 시장 수치는 공급사 마케팅 또는 제3자 보고서 재인용 성격이 있어 본문의 성과 근거로 사용하지 않았다. -
[s3] National Institute of Standards and Technology (NIST), “AI Risk Management Framework”
URL: https://airc.nist.gov/airmf-resources/airmf/
접근일: 2026-07-19
출처 성격: 미국 정부기관의 공식 위험관리 자료. AI RMF가 자발적 프레임워크라는 점과 Govern·Map·Measure·Manage의 네 기능을 참고했다. 접근 시점 페이지는 AI RMF 1.0 개정판이 준비 중이라고 명시한다. -
[s4] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 (Artificial Intelligence Act)”
URL: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
공포일: 2024-07-12 · 접근일: 2026-07-19
출처 성격: EU 공식 법령 원문. 위험 기반 의무, 고위험 AI 시스템의 기록·인간 감독 논의의 배경으로 참고했다. 개별 기업·시스템에 대한 법률 적용 판단이나 한국 법률 자문을 대신하지 않는다.