"그래서 결국 RPA를 사야 합니까, AI 에이전트를 사야 합니까?"
지난달 한 중견 물류사 팀장님과 마주 앉았을 때 받은 질문입니다. 저는 잠시 말문이 막혔습니다. 정답이 하나가 아니라서요.
지난 회에서 자동화 개념과 도입 로드맵을 정리했습니다. 진단이 끝나고 나면 다음 관문은 도구 선정입니다. 그리고 그 앞에서 대부분의 실무자가 세 개의 이름을 두고 헤맵니다. RPA, 워크플로우 자동화, AI 에이전트.
이름은 자주 들리지만, 차이는 흐릿합니다. 특히 벤더 자료 몇 개를 읽고 나면 오히려 더 헷갈립니다. 하나씩 벗겨봅니다.
세 가지 접근의 성격부터 다시
RPA(Robotic Process Automation)는 규칙 기반 자동화입니다. 사람이 하던 마우스·키보드 조작을 그대로 흉내 냅니다. 판단하지 않고, 학습하지 않습니다. 대신 정확하고 예측 가능합니다. API가 없는 오래된 사내 시스템을 다뤄야 할 때, 감사 로그가 반드시 필요한 회계·재무 업무에서 여전히 강력합니다.
워크플로우 자동화는 조금 다른 층입니다. n8n, Make, Zapier, kintone 같은 도구들이 여기에 속합니다. 시스템 간 데이터를 API로 연결하고, 조건 분기와 파이프라인을 짜는 방식입니다. UI를 흉내 내는 대신 데이터를 흐르게 합니다. 신규 SaaS 환경, 마케팅·CS 툴 스택이 복잡한 회사에 잘 맞습니다.
AI 에이전트는 판단이 필요한 지점을 담당합니다. 언어를 이해하고, 비정형 데이터를 읽고, 상황을 해석합니다. 다만 결정론적이지 않습니다. 같은 입력이라도 결과가 조금씩 달라질 수 있습니다. 그래서 감사·거버넌스를 반드시 병행해야 합니다.
간단히 말하면 이렇습니다. RPA는 손, 워크플로우 자동화는 배관, AI 에이전트는 뇌.
한눈에 보는 비교표
말로만 설명하면 여전히 흐릿합니다. 회의 자리에서 꺼내 쓸 수 있는 표로 정리해둡니다.
| 구분 | RPA | 워크플로우 자동화 | AI 에이전트 |
|---|---|---|---|
| 판단 유무 | 없음 (규칙 기반) | 조건 분기 수준 | 있음 (맥락 해석) |
| 학습 유무 | 없음 | 없음 | 모델 성능에 의존 |
| 결과 예측성 | 매우 높음 | 높음 | 변동 있음 |
| 주요 대상 | UI 조작·레거시 | SaaS 간 데이터 연계 | 비정형·언어 업무 |
| 유지보수 부담 | 화면 변경 시 재작업 | API 변경 대응 | 프롬프트·감사 지속 |
| 초기 도입 난이도 | 중간 | 낮음 | 중~높음 |
업무 유형별 매칭 가이드
경험상, 도구를 먼저 정하면 대부분 실패합니다. 업무 성격을 먼저 봅니다.
첫째, 정형·반복·규칙이 명확한 업무. 급여 명세서 발행, 세금계산서 대사, ERP와 엑셀 사이의 데이터 전송 같은 일입니다. 이건 RPA가 가장 안정적입니다. 굳이 AI를 얹지 않아도 됩니다.
둘째, 여러 SaaS를 오가는 데이터 연계. 쇼핑몰 주문이 들어오면 재고 시스템에 반영하고, 슬랙으로 알림을 보내고, 스프레드시트에 로그를 쌓는 흐름을 떠올려보시면 됩니다. 이 영역은 워크플로우 자동화가 가장 빠릅니다. 몇 시간이면 프로토타입이 나옵니다.
셋째, 판단·언어·비정형 데이터가 섞인 업무. 고객 문의 분류, 이메일 답변 초안, 계약서 리스크 스캔, 리뷰 요약. 여기서만 AI 에이전트를 씁니다. 그리고 처음엔 결과를 사람이 감독하는 구조로 시작합니다. 이건 타협이 아니라 원칙입니다.
실제 프로젝트에서 저희가 자주 만나는 조합은 이 세 가지가 섞인 형태입니다. 결정론적 뼈대를 워크플로우 자동화로 잡고, 판단이 필요한 지점에만 에이전트를 얹고, 오래된 사내 시스템에는 RPA가 다리를 놓는 식입니다. 2026년 현재 이 하이브리드 구조가 사실상 표준이 되어가고 있습니다.
잘못된 조합이 만드는 비용 함정
가장 흔한 실패는 이런 겁니다. 유행하는 이름 하나를 정해두고, 그 안에 모든 업무를 우겨 넣는 방식.
"우리도 AI 에이전트 도입해야 한다"는 결정이 위에서 내려오면, 실무는 결정론적이어야 할 업무까지 에이전트로 감쌉니다. 결과 품질에 변동이 생기고, 감사 요구가 늘고, 유지보수 부담이 커집니다. 반대로 "AI는 위험하니 RPA만"이라는 결정은, 판단이 필요한 지점에서 사람 손을 계속 부르게 됩니다. 자동화라는 명목이 슬며시 사라집니다.
업계 조사들을 훑어보면 AI 프로젝트의 상당 비율이 기대 성과에 못 미친다는 언급이 반복해서 등장합니다. 이유의 상당 부분은 기술 자체가 아니라 조합 오류입니다. 문제 정의가 없거나, 프로세스 분석이 얕거나, 유지보수 부담을 과소평가하거나.
정직하게 말하면, 세 접근 중 어느 하나가 정답인 회사는 거의 없습니다. 진짜 질문은 "무엇을 살 것인가"가 아니라 "우리 업무의 어느 지점에 무엇을 놓을 것인가"입니다.
여기까지 읽고도 여전히 판단이 어렵다면, 그건 자연스러운 반응입니다. 도구 선정은 자사 프로세스 지도를 그린 뒤에야 답이 나오는 문제이니까요.
저희 5years+는 한국·일본 중소기업의 자동화 도입을 함께 설계해왔습니다. 자사 어느 업무에 어떤 접근이 맞을지, 하이브리드 구조를 어떻게 짤지 정리해드립니다. 처음엔 프로세스 진단부터, 이후 작은 PoC로 시작하는 방식을 권합니다. 솔루션 매칭 컨설팅이 필요하시면 편하게 말씀 주세요.
다음 회에서는 도입 후 효과를 어떻게 측정할지, ROI와 KPI 설계 방법을 다룰 예정입니다.