원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽어보세요.

최종 업데이트: 2026년 7월 7일

2026년 AI 에이전트(AI agents)를 활용한 가장 실행 가능한 RPA 대안은 더 나은 봇이 아닙니다. 그것은 근본적으로 다른 실행 모델입니다. 왜냐하면 현재 귀하의 RPA 봇은 이미 쉬웠던 비즈니스 부분만을 자동화하고 있으며, 그 외의 모든 부분에서는 조용히 실패하고 있기 때문입니다. 40%에 달하는 RPA 프로젝트 실패율은 배포의 문제가 아닙니다. 이는 스크립트 기반 자동화(scripted automation)가 현대 운영의 역동적이고 예외가 가득한 현실을 위해 설계되지 않았음을 증명하는 것이며, AI 에이전트는 실제로 이를 위해 설계된 첫 번째 기술입니다.

이 글은 자동화 팀 대역폭의 절반을 조용히 소모하고 있는 UiPath, Automation Anywhere 또는 Blue Prism 배포를 운영하는 운영 리더들을 위한 시스템 해체 분석입니다. 우리는 프로덕션 준비가 된 도구들인 — LangGraph, AutoGen, CrewAI, n8n, 그리고 Model Context Protocol (MCP) — 를 명시하고 각각이 어디에 적합한지 보여줄 것입니다.

글을 마칠 때쯤이면, 귀하는 의사 결정 프레임워크를 통해 자체 RPA 자산을 평가하고, 마이그레이션 후보를 선정하며, 에이전트가 기존 문제의 더 비싼 버전이 되는 것을 방지하는 인간 참여형(human-in-the-loop) 아키텍처를 구축할 수 있게 될 것입니다. 만약 근본적인 패턴에 대해 먼저 더 깊이 알고 싶다면, AI 에이전트가 실제로 무엇인지에 대한 우리의 입문서가 기초를 다져줄 것입니다.

실제 사례에서의 취약성 천장(Brittleness Ceiling): RPA 커버리지는 비정형 입력(unstructured inputs)과 예외가 시작되는 지점에서 정확히 평탄해집니다. AI 에이전트는 자동화 가능한 표면 영역을 그 선 너머로 확장합니다.

2026년 RPA가 취약성의 한계(Brittleness Ceiling)에 부딪히는 이유

로봇 프로세스 자동화 (RPA)는 지난 10년 동안 가장 과장된 기업용 기술 중 하나였습니다. 이는 RPA가 작동하지 않기 때문이 아니라, 구조적으로는 매우 뛰어난 스크린 스크래핑 (screen-scraping) 매크로 기록기임에도 불구하고 범용 자동화 계층 (general-purpose automation layer)인 것처럼 마케팅되었기 때문입니다. 이러한 마케팅(pitch)과 물리적 실체(physics) 사이의 간극이 수많은 프로그램이 정체되는 이유입니다. 먼저 기초적인 정의를 알고 싶다면, RPA의 실제 정의에 대한 설명이 이 분석글과 잘 어우러질 것입니다.

40%의 실패율은 실행의 문제가 아닌 구조적 문제입니다

RPA 프로그램 결과에 대한 Gartner의 연구에 따르면, 기업의 RPA 이니셔티브 중 약 40%가 성과를 내지 못하며, 추가적인 그룹은 예상 ROI (투자 대비 수익)에 훨씬 못 미치는 것으로 지속적으로 나타났습니다. 운영 리더들은 이를 거버넌스 (governance)나 변화 관리 (change-management)의 문제, 즉 더 나은 COE (Centers of Excellence), 더 엄격한 봇 거버넌스, 더 많은 교육의 문제로 취급하는 경향이 있습니다. 하지만 그렇지 않습니다. 실패는 매번 정확히 동일한 세 가지 특성 주변에 집중됩니다: 비정형 입력 (unstructured inputs), 높은 예외 발생률 (high exception rates), 그리고 다중 시스템 의사결정 로직 (multi-system decision logic)입니다. 이것들은 실행상의 실수가 아닙니다. 이는 결정론적 (deterministic) if-then 자동화가 물리적으로 수행할 수 있는 한계입니다. Deloitte의 자동화 연구에서 실시한 독립적인 설문 조사도 동일한 군집 현상을 반영하며, 이를 통해 이것이 단순히 한 분석가의 프레임워크가 아님을 알 수 있습니다.

~40%
범위 내 성과를 달성하지 못하는 기업 RPA 프로젝트
[Gartner, 2023](https://www.gartner.com/en/documents)
...

RPA가 실제로 설계된 목적 (그리고 결코 구축되지 않은 목적)

RPA는 기록 → 재생 (Record → Replay) 모델로 작동합니다. 개발자가 하나 이상의 애플리케이션 UI를 통해 결정론적 (deterministic) 경로를 기록하고, 몇몇 필드를 매개변수화하면, 봇은 해당 클릭과 키 입력(keystrokes)을 영구적으로 그대로 재생합니다. 이는 안정적이고 구조화된 대량 작업에는 진정으로 탁월합니다. 예를 들어, 두 레거시 시스템 간에 고정된 스키마 (fixed-schema) 데이터를 이동하거나, 표준 양식을 다시 입력하거나, 동일한 열을 가진 두 스프레드시트를 대조하는 작업 등이 이에 해당합니다.

RPA가 결코 구축되지 않은 목적은 다음과 같습니다: 의도(intent)를 해석하거나, 약간 다른 레이아웃으로 도착한 문서를 처리하거나, 4단계가 실패하여 5단계가 그에 의존해야 할 때 계획을 재수립하는 일입니다. 봇은 추론할 수 없습니다. 오직 재생할 수 있을 뿐입니다. 현실이 기록된 내용과 달라질 때 — 즉, 공급업체가 송장 형식을 변경하거나, 앱이 UI 업데이트를 배포하거나, 고객이 요청을 특이하게 표현할 때 — 봇은 충돌(crash)하거나, 더 나쁜 경우에는 잘못된 데이터를 대상으로 자신 있게 실행해 버립니다. 저는 차라리 충돌하는 쪽을 택하겠습니다. 적어도 그 사실은 알 수 있으니까요.

숨겨진 비용: 자동화 팀 대역폭의 30~60%를 소비하는 봇 유지보수

성숙한 RPA 프로그램의 추악한 비밀은 자동화 팀이 새로운 것을 구축하는 대신 화재 진압(firefighting)을 시작한다는 점입니다. Salesforce, SAP 또는 내부 포털에서 발생하는 모든 애플리케이션 업데이트는 봇 자산의 일부를 망가뜨립니다. Forrester의 유지보수 수치 — 봇 100개당 연간 5만 달러에서 20만 달러 — 는 실제 인적 비용을 오히려 과소평가하고 있습니다. 시니어 자동화 엔지니어들은 새로운 프로세스를 자동화하는 대신 셀렉터(selector)를 패치하고 경로를 다시 기록하는 데 주를 보냅니다. 저는 6명으로 구성된 팀이 기존 자산을 유지하는 일 외에는 아무것도 하지 못한 채 분기 전체를 보내는 것을 목격해 왔습니다.

RPA는 운영 팀의 규모를 확장(scale)시켜주지 않습니다. 오히려 아무것도 변하지 않을 때만 작동하는 자동화를 위한 유지보수 팀으로 서서히 전환시킬 뿐입니다.

정립된 프레임워크 (Coined Framework)

취약성의 천장 (The Brittleness Ceiling)

비정형 입력(unstructured inputs), UI 드리프트(UI drift), 또는 다중 시스템 의사결정 로직이 인간의 개입 없이 규칙 기반 봇(rule-based bots)이 처리할 수 있는 범위를 넘어설 때, 모든 RPA 배포 환경이 직면하게 되는 자동화 커버리지의 보이지 않는 상한선입니다. AI 에이전트(AI agents)는 결정론적 스크립트(deterministic scripts)를 스스로 수정하고, 재계획하며, 조용히 충돌하는 대신 문맥(context)과 함께 에스컬레이션(escalate)하는 목표 지향적 추론 루프(goal-directed reasoning loops)로 대체함으로써 이 한계를 돌파합니다.

취약성의 천장(The Brittleness Ceiling)은 세 가지 계층으로 구성되며, 여러분의 프로그램이 어떤 계층에 의해 제한되고 있는지 진단할 수 있습니다: 입력 경직성 (Input Rigidity) (봇이 완벽하게 포맷된 데이터에서만 작동함), 의사결정 얕음 (Decision Shallowness) (모든 모호한 케이스가 인간에게 전달됨), 그리고 복구 불능 (Recovery Blindness) (실패한 단계가 조용한 오류를 발생시키거나 문맥 없는 티켓을 생성함). 섹션 3에서 이를 점수화 시스템으로 변환할 것입니다.

AI 에이전트를 활용한 RPA 대안의 실제 의미

'AI 에이전트(AI agent)'라는 문구는 마케팅으로 인해 의미가 퇴색되었으므로, 아키텍처 관점에서 정의해 보겠습니다. AI 에이전트는 추론 루프(reasoning loop) — 인지(Perceive) → 추론(Reason) → 행동(Act) → 관찰(Observe) — 를 중심으로 구축된 시스템입니다. 가장 흔하게는 ReAct 패턴으로 구현되는데, 여기서 대규모 언어 모델(LLM)은 추론 단계와 도구 호출(tool calls)을 교차하며 수행한 뒤, 다음 행동을 결정하기 전에 결과를 관찰합니다. 이는 RPA의 선형적 재생(linear replay)과는 범주적으로 다릅니다. 조금 다른 수준이 아닙니다. 근본적으로 다릅니다. 만약 AI 에이전트를 활용한 RPA 대안을 평가하고 있다면, 이 루프가 이해해야 할 가장 중요한 단일 요소입니다. 왜냐하면 비용, 안전성, 회복탄력성(resilience)과 같은 모든 하위 요소가 이 루프로부터 파생되기 때문입니다. 벤더의 요약본 대신 원문을 보고 싶다면 원문 ReAct 논문을 읽어볼 가치가 있습니다.

RPA 봇과 AI 에이전트의 네 가지 아키텍처 차이점

차원	RPA 봇	AI 에이전트
실행 모델	기록 → 재생 (결정론적 스크립트)	인지 → 추론 → 행동 → 관찰 (목표 지향적 루프)
입력 처리	구조화된, 고정된 스키마(fixed-schema)만 가능	LLM + RAG를 통한 비정형 텍스트, PDF, 이메일, 이미지

실패 동작 (Failure behavior) | 충돌(Crashes) 또는 조용히 데이터 오염 | 컨텍스트와 함께 재계획(Re-plans), 재시도(Retries) 또는 에스컬레이션(Escalates)

변경 허용치 (Change tolerance) | UI 드리프트(UI drift) 발생 시 중단 | 레이아웃 및 문구 변경에 적응

목표 지향적(Goal-directed) vs. 스크립트 지향적(script-directed) 실행: 이것이 모든 것을 바꾸는 이유

RPA 봇은 어떻게(how) 할지를 지시받습니다: 여기를 클릭하고, 저기에 입력하고, 엔터를 누르라는 식입니다. 반면 AI 에이전트는 _무엇(what)_을 할지를 지시받습니다: '이 송장(invoice)을 일치하는 구매 주문서(purchase order)와 대조하여 2%를 초과하는 불일치를 표시하라'는 식입니다. 에이전트는 실행 시점(runtime)에 자신이 접근할 수 있는 도구들을 사용하여 '어떻게' 할지를 스스로 결정합니다. 송장이 구조화된 EDI 대신 스캔된 PDF로 도착하더라도, 에이전트는 이를 읽어냅니다. 이번 분기에 구매 주문서(PO) 번호 형식이 달라지더라도, 에이전트는 여전히 이를 찾아냅니다. 이것이 바로 취약성의 한계(Brittleness Ceiling)를 돌파하는 차이점이며, 실제 운영 환경(production)에서 이를 한 번 경험하고 나면 그 차이는 결코 미미하지 않습니다.

현재 실제 운영 환경에서 이를 수행하는 명명된 프레임워크들: 명시적인 상태(state)를 가진 제어 가능한 다단계 워크플로우를 위한 LangChain의 상태 유지 에이전트 오케스트레이션인 LangGraph (v0.1부터 안정화); 멀티 에이전트 대화 네트워크를 위한 Microsoft의 AutoGen (v0.4); 그리고 역할 기반 에이전트 팀을 위한 오픈 소스 프레임워크인 CrewAI가 있습니다. 이들을 연결하는 결합 조직(connective tissue)은 MCP — 2024년 말 Anthropic이 도입한 Model Context Protocol — 로, 에이전트와 외부 도구 사이의 표준 인터페이스 계층이 되어가고 있습니다. 이는 RPA 미들웨어가 결코 갖지 못했던 것, 즉 추론을 인지하는(reasoning-aware) 깔끔한 도구 계약(tool contract)입니다.

AI 에이전트가 비정형 송장을 처리하는 방식 (vs. RPA가 충돌하는 방식)

  1

    **인지(Perceive) — Claude 3.5 Sonnet / GPT-4o가 PDF를 읽음**

에이전트가 스캔되었거나 수기로 작성된 송장을 흡수(ingest)합니다. 비전(Vision) + OCR이 레이아웃에 관계없이 품목(line items)을 추출합니다. 지연 시간(Latency): 약 2~5초.

↓

  2
...

에이전트가 공급업체(vendor)를 식별하고, 예상되는 PO를 추론하며, 조회(lookup) 계획을 세웁니다. 감사 가능성(auditability)을 위해 추론 과정(Reasoning trace)이 로그로 기록됩니다.

↓

  3
...

에이전트가 MCP(Model Context Protocol)로 래핑된 SAP 도구를 호출하여 일치하는 구매 주문(purchase order)을 가져옵니다. 취약한 UI 클릭(UI clicks)은 필요하지 않습니다.

↓

  4
...

벡터 DB (Pinecone/Weaviate)가 이전 공급업체 컨텍스트(context)를 제공합니다. 에이전트는 차이(variance)를 계산하며, 만약 2%를 초과하면 에스컬레이션(escalation)을 향해 재계획(re-plans)을 수행합니다.

↓

  5
...

불일치 사항은 빈 티켓(blank ticket)이 아니라, 전체 추론 과정(reasoning trace), 추출된 데이터, 그리고 권장 사항과 함께 사람에게 전달됩니다.

관찰(Observe) 단계는 RPA가 완전히 결여하고 있는 부분입니다. 이곳이 바로 자기 수정(self-correction)과 맥락적 에스컬레이션(contextual escalation)이 일어나는 지점입니다.

AI 에이전트가 여전히 실패하는 지점: 환각(hallucination), 지연 시간(latency), 그리고 작업당 비용

정직함이야말로 이 프레임워크를 유용하게 만드는 요소입니다. 2026년의 AI 에이전트들은 인간 참여(human-in-the-loop) 체크포인트 없이는 중대한 금융 결정에서 무시할 수 없는 수준의 환각(hallucination) 발생률을 보입니다. 이들은 최적화된 RPA 봇보다 트랜잭션당 속도가 느리며(밀리초 단위가 아닌 초 단위), 모든 단계에서 LLM을 호출할 수 있기 때문에 작업당 비용이 더 많이 듭니다. 대규모 프로덕션 배포 시에는 자금 이동, 기록 수정, 외부 통신에 대한 승인 게이트(approval gates)를 반드시 포함해야 합니다. 잘못된 송장을 자신 있게 대조하는 에이전트는 눈에 띄게 충돌(crash)하는 봇보다 더 위험합니다. 저는 엄격한 게이트(hard gate) 없이는 자율적인 금융 대조(financial reconciliation)를 출시하지 않을 것입니다. 결론입니다. 이러한 안전장치를 설계하는 방법에 대한 자세한 내용은 우리의 AI 에이전트 가드레일(AI agent guardrails) 심층 분석을 참조하십시오.

역설적인 진실: AI 에이전트는 RPA 봇보다 더 크게, 그리고 더 안전하게 실패합니다. 잘 설계된 에이전트는 신뢰도가 낮은 케이스를 에스컬레이션하지만, RPA 봇은 잘못된 데이터를 조용히 입력하며, 당신은 월말 결산 때에야 이를 발견하게 됩니다.

LangGraph와 AutoGen의 기반이 되는 ReAct 루프: RPA의 선형적 재생(linear replay)과 달리, 에이전트는 결과를 관찰하고 재계획(re-plans)하며, 이것이 UI 드리프트(UI drift)와 비정형 입력(unstructured inputs) 속에서도 살아남는 방식입니다.

취약성 천장 프레임워크 (The Brittleness Ceiling Framework): 운영 팀을 위한 의사결정 지도

이제 실무적인 부분입니다. 현재의 RPA 배포 상태를 세 가지 계층 모두에서 1~5점 척도로 평가해 보십시오. 만약 여러 계층에서 3점 이상의 점수를 받는다면, 귀하는 취약성 천장 (Brittleness Ceiling)에 도달한 것이며, RPA는 이를 조정(tuning)을 통해 극복할 수 없습니다. 즉, 이 천장은 설정(configurational)의 문제가 아니라 구조적(structural)인 문제입니다.

계층 1 — 입력 경직성 (Input Rigidity): 귀하의 자동화는 비정형 데이터 (unstructured data)를 처리할 수 있습니까?