RPA와 Agentic AI의 핵심 차이는 실패 구조에 있다. 결정론적 RPA와 달리 Agentic AI는 비결정론적으로 실패하며, 이 차이가 도입 전략을 바꾼다.
이하는 실제 운영 환경에서 반복적으로 관찰되는 패턴을 바탕으로 구성한 가상 시나리오다.
국내 한 금융사의 여신심사 자동화 봇은 3년간 안정적으로 작동했다. 주중 하루 평균 400건의 서류를 처리했고, 오류율은 0.3%였다. 2024년 1월, 코어뱅킹 시스템이 UI를 업데이트했다. 다음 날 아침 봇은 멈췄다. 이유는 명확했다. "고객번호" 입력란의 HTML element ID가 cust-no에서 customer-id로 바뀌었기 때문이었다.
IT팀은 이틀 만에 복구했다. 총 피해: 처리 지연 800건, 내부 공수 32시간, 고객 민원 47건.
이 봇은 "실패했다"고 볼 수 있을까? 엄밀히 말하면 그렇다. 그러나 이 실패는 예측 가능했고, 재현 가능했으며, 원인이 명확했다. IT팀은 정확히 어느 줄의 코드를 수정해야 하는지 알고 있었다.
Ernst & Young의 글로벌 RPA 실사 데이터에 따르면 최초 RPA 구현 시도의 30~50%가 실패한다[1]. 이 수치는 RPA 도입 초기(2017~2019년)의 데이터로, 기술 성숙도가 낮던 시기를 반영한다. 지금도 여전히 인용되는 이유는 하나다. 이 실패들이 공통적으로 한 가지 특성을 공유하기 때문이다. 언제, 어디서, 왜 실패했는지 사후에 정확히 파악할 수 있다는 것이다.
Agentic AI가 실패할 때는 다르다.
Agentic AI를 RPA처럼 도입한 조직들은 예상치 못한 문제에 부딪힌다. 봇이 멈추는 게 아니라 봇이 계속 돌아가면서 틀린 일을 한다.
AI 에이전트가 제품 카탈로그를 자동으로 업데이트하는 업무를 맡는다고 하자. 에이전트가 SKU-4821이라는 존재하지 않는 제품 코드를 "생성"한다. 기묘한 점은 이 단계에서 시스템은 아무런 오류를 반환하지 않는다는 것이다. API 응답은 HTTP 200 OK다. 페이로드 내부에 환각으로 만들어진 쓰레기값이 들어있지만, 외부 모니터링은 정상으로 판정한다. 다음 단계의 에이전트들이 이 코드를 사실로 받아들여 가격 업데이트, 재고 조회, 라벨 생성, 고객 알림 발송까지 진행한다. 여기서 한 가지 설계 질문이 생긴다. 에이전트에게 4개 시스템에 대한 무조건적인 쓰기 권한을 준 것 자체가 문제였다. 문제가 감지될 때쯤 이 허구의 SKU는 4개 시스템에 기록되어 있다.
Galileo.ai가 분석한 다중 에이전트 실패 패턴 연구에 따르면, 이런 오류 전파(Error Propagation) 현상은 에이전트가 다른 에이전트의 오출력을 검증 없이 사실로 저장할 때 발생한다[2]. 오류가 일어나는 시점과 오류가 감지되는 시점 사이에 상당한 시간 차이가 존재한다.
엔지니어링 팀은 이 문제를 통제하려 한다. Temperature를 0으로 설정하고, JSON Schema를 강제하고, 프롬프트에 제약을 촘촘히 건다. 이런 통제 기법은 분명히 효과가 있다. 그러나 여기서 끝이 아니다. 입력 분포가 기대 범위를 벗어나거나, 컨텍스트 창 내 토큰 순서가 달라지거나, 도구 호출 응답이 예상 포맷을 벗어나는 순간 — 에이전트 워크플로우는 예측 불가한 방식으로 실패한다.
더 심각한 문제도 있다. 에이전트가 오류에 부딪혔을 때 스스로 복구하려다 무한 루프에 빠지는 경우다. 의미 없는 API 호출을 수십~수백 번 반복하면서 막대한 토큰 비용이 발생한다. RPA가 멈추면서 실패를 드러내는 것과 달리, 에이전트는 "열심히 돌아가면서" 비용만 소진하다가 뒤늦게 실패를 드러낸다.
테스트 환경에서 100번 돌려서 95번 성공했다고 해서 운영 환경에서도 같다고 보장할 수 없다. RPA처럼 결정론적 경로를 테스트하는 방식으로는 이 엣지 케이스를 커버할 수 없다.
Gartner의 2025년 예측은 이 맥락에서 나왔다. 2027년까지 Agentic AI 프로젝트의 40% 이상이 취소될 것이라는 전망은 기술의 한계가 아니라 예측 불가능한 실패를 다루는 준비의 부재를 반영한다[3].
두 시스템을 같은 기준으로 평가하면 판단 오류로 이어질 수 있다.
참고: 최신 RPA 플랫폼 중에는 IDP, OCR 등 AI 모델을 결합한 사례도 있다. 그러나 핵심 제어 흐름이 규칙 기반의 결정론적 구조를 유지하는 한, 아래 구분은 여전히 유효하다.
실패 유형
실패 감지
원인 파악
위험 범위
복구 방법
테스트 충분성
RAND Corporation 연구에 따르면 AI 프로젝트의 80% 이상이 의미 있는 생산 단계에 도달하지 못한다. 이는 일반 IT 프로젝트 실패율의 약 2배다[4]. MIT의 GenAI Divide 보고서(2025)는 더 냉혹하다. 엔터프라이즈 생성형 AI 파일럿의 95%가 측정 가능한 P&L 임팩트를 만들어내지 못했다[5].
이 실패의 공통 원인은 "RPA를 도입할 때 쓰던 사고방식으로 Agentic AI를 도입했기 때문"이다. 기능 요구사항을 나열하고, 파일럿을 돌리고, 성공률을 측정하고, 롤아웃하는 방식. Agentic AI에서는 이 방식만으로는 불충분하다.
Agentic AI가 가져오는 이점 — 복잡한 판단 분기 처리, 자연어 기반 유연성, 멀티스텝 자율 실행 — 은 비결정론을 수용할 때만 얻을 수 있다. 이 tradeoff를 명확히 해야 한다.
비결정론을 택하면: 복잡한 업무 자동화, 예외 처리 유연성, 맥락 기반 판단
비결정론의 대가: 실패가 언제 어디서 발생할지 사전에 특정 불가, 모니터링과 Execution trace 없이는 운영 불가, 전통적 QA 방식으로 검증 불충분
엔터프라이즈에서 이 tradeoff를 감당하려면 세 가지 역량이 선행되어야 한다.
RPA를 성공적으로 운영하는 조직도 이 세 가지가 없으면 Agentic AI 운영에서 심각한 어려움에 처할 수 있다.
Agentic AI 도입을 검토 중이라면, 다음 중 해당하는 항목을 확인하라:
3개 이상 해당한다면, 지금 도입 방식을 재검토할 시점이다. 기술 도입보다 "실패를 다루는 구조"를 먼저 설계해야 한다.
어떻게 접근해야 할지 구체적으로 논의하고 싶다면 →
