원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽어보세요.

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 기존 RPA — UiPath, Automation Anywhere, Blue Prism — 에서 벗어나려는 움직임은 단순한 도구 업그레이드가 아닙니다. 이는 취약한 스크린 스크래핑 (screen-scraping) 봇들이 결코 자동화가 아니었음을 인정하는 것입니다. 그것들은 지능인 척하는 비싸고 취약한 스크립트였으며, 이제 그들을 대체하고 있는 AI 기술은 근본적으로 다른 존재입니다.

에이전틱 레이어 (agentic layer) — LangGraph, AutoGen, CrewAI, 그리고 Model Context Protocol (MCP) — 가 마침내 결정론적 (deterministic) 봇을 추론하고, 복구하며, 적응하는 시스템으로 대체할 수 있을 만큼 성숙했습니다. 구매자들은 움직이고 있습니다. 대부분의 벤더들은 아직 따라잡지 못했습니다. 그 격차가 바로 여러분의 기회입니다.

이 글을 마칠 때쯤 여러분은 여러분의 RPA 함대보다 뛰어난 성능을 발휘하는 에이전틱 스택 (agentic stack)을 어떻게 감사(audit), 마이그레이션, 운영할 수 있는지, 그리고 특정 레이어를 건너뛸 경우 어디에서 조용히 문제가 발생할지를 정확히 알게 될 것입니다.

기존 RPA와 에이전틱 스택의 구조적 차이: RPA는 고정된 좌표를 따르는 반면, AI 에이전트는 의도(intent)를 바탕으로 추론합니다. 이것이 우리가 AI 조정 격차 (AI Coordination Gap)라고 부르는 것의 핵심입니다. 출처

왜 2026년에 RPA가 붕괴하고 있으며, 무엇이 그것을 대체하는가?

로봇 프로세스 자동화 (Robotic Process Automation, RPA)는 디지털 노동 (digital labor)으로 판매되었습니다. 실제로 그것은 레거시 UI (legacy UI) 상의 픽셀을 클릭하는 봇들의 함대였으며, 버튼의 위치가 바뀌거나 벤더 (vendor)가 업데이트를 배포하는 순간 무너져 버렸습니다. Gartner (Market Guide for Robotic Process Automation, 2024)는 초기 RPA 프로젝트의 30-50%가 실패하거나 상당한 재작업을 필요로 한다고 추정합니다. 이는 비전이 틀렸기 때문이 아니라, 실행 모델 (execution model)이 근본적으로 취약했기 때문입니다. RPA는 _단계 (steps)_를 자동화합니다. 그것은 결코 _목표 (goal)_를 이해하지 못했습니다.

에이전틱 (agentic) 대안은 이를 뒤집습니다. '여기를 클릭하고, 이것을 입력하고, 3초간 대기하라'는 식의 코딩 대신, AI 에이전트 (AI agent)에게 '이 송장들을 구매 주문 (PO) 시스템과 대조하여 불일치 항목을 표시하라'는 목적을 부여하고, 에이전트가 스스로 계획을 세우고, 도구 (tools)를 호출하며, 자기 수정 (self-correct)을 하도록 합니다. 레거시 RPA 봇이 예상치 못한 모달 대화 상자 (modal dialog)를 만나면 작동을 멈춥니다. 하지만 잘 설계된 에이전트가 동일한 대화 상자를 만나면, 이를 우회하기 위해 추론하거나 깔끔하게 에스컬레이션 (escalate)합니다. 이러한 실패 동작의 차이가 모든 것을 결정합니다.

하지만 대부분의 운영 리더들이 놓치는 직관에 반하는 진실이 있습니다: 봇을 에이전트로 교체한다고 해서 자동으로 신뢰성이 높아지는 것은 아닙니다. 조정 (coordination) 문제를 해결하지 못한다면 신뢰성이 극적으로 낮아질 수도 있습니다. 단일 LLM 에이전트는 확률적 (probabilistic)입니다. 6개의 에이전트를 아무런 고려 없이 체인 (chain)으로 연결하면 작은 오류율이 재앙적인 수준으로 누적됩니다. 저는 프롬프트 (prompts)가 잘 작동한다고 해서 작업이 끝났다고 생각했던 팀들에게 이런 일이 발생하는 것을 목격해 왔습니다.

각 단계의 신뢰도가 97%인 6단계 파이프라인 (pipeline)의 엔드 투 엔드 (end-to-end) 신뢰도는 단 83% (0.97^6)에 불과합니다. 대부분의 기업은 제품을 이미 출시한 후에, 그리고 기존에 99.9%로 작동하던 RPA 봇들을 폐기한 후에야 이 사실을 깨닫게 됩니다.

RPA에서 에이전틱으로의 마이그레이션 (migration)에서 승리하는 팀은 최고의 프롬프트를 가졌거나 가장 큰 모델을 사용하는 팀이 아닙니다. 그들은 조정을 주요 엔지니어링 문제로 취급한 팀들입니다. 이 과제는 이 가이드 전체를 관통하는 핵심 주제입니다.

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

정의: AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (The AI Coordination Gap)는 자율적인 AI 에이전트들이 거버넌스 오케스트레이션 레이어 (governing orchestration layer) 없이 서로에게, 혹은 레거시 시스템 (legacy systems)이나 인간에게 업무를 인계할 때 발생하는 복합적인 신뢰성 손실을 의미합니다. 이는 개별적으로는 유능한 에이전트들이 모여 집합적으로는 신뢰할 수 없는 시스템을 만들어내는 시스템적 실패 모드 (systemic failure mode)를 지칭합니다. 이 격차는 더 똑똑한 모델을 도입한다고 해서 메워지는 것이 아니라, 모든 확률적 단계 (probabilistic step) 사이에 결정론적 검증 (deterministic validation)을 삽입함으로써 해결할 수 있습니다.

앞으로 이어질 4,000단어 분량의 본문에서, 우리는 에이전틱 마이그레이션 (agentic migration)을 명명된 6개의 레이어로 나누어 살펴보고, 각 레이어가 실제 운영 환경에서 어떻게 작동하는지 보여줄 것입니다. 또한 구체적인 수치를 포함한 세 가지 명명된 패턴 (named-pattern) 배포 사례를 살펴보고, 에이전틱 프로젝트를 조용히 망가뜨리는 실수들을 짚어보며 마무리하겠습니다. 이 자료는 우리가 첫 번째 RPA 플릿 (RPA fleet)을 제거했을 때 존재했으면 하고 바랐던 바로 그 리소스입니다. 더 폭넓은 입문서를 원하신다면, 우리의 AI 에이전트 (AI agents) 가이드부터 시작하십시오.

30-50%
초기 RPA 구현 사례 중 실패하거나 대대적인 재작업이 필요한 비율
[Gartner, Market Guide for RPA, 2024](https://www.gartner.com/en/newsroom/press-releases)
...

에이전틱 자동화 (Agentic Automation)란 무엇이며, 이 AI 기술은 RPA와 어떻게 다른가?

레거시 RPA는 **결정론적이고 명령적 (deterministic and imperative)**입니다. 즉, 당신이 스크립트로 작성한 그대로, 작성한 순서 그대로, 작성한 인터페이스를 대상으로 정확히 수행합니다. 반면 에이전틱 AI 기술은 **확률적이고 목표 지향적 (probabilistic and goal-directed)**입니다. 당신은 결과만을 지정하며, 에이전트는 추론 (reasoning), 도구 호출 (tool calls), 그리고 메모리 (memory)를 사용하여 경로를 결정합니다.

운영 책임자(operations leader)에게 미치는 실질적인 영향은 극명합니다:

    차원 (Dimension)
    레거시 RPA (UiPath, Blue Prism)
    에이전틱 스택 (Agentic Stack) (LangGraph, CrewAI)
...

마지막 두 행을 주의 깊게 살펴보십시오. RPA는 이진적(binary)이고 파괴적인 방식으로 실패합니다. 즉, 무언가가 변하기 전까지는 완벽하게 작동하다가, 변하는 순간 아무것도 생성하지 못합니다. 에이전틱 시스템은 조정(coordination) 기능을 구축한다면 우아하게 성능이 저하(degrade gracefully)되지만, 그렇지 않다면 예측 불가능하게 실패합니다. 이 트레이드오프 (trade-off)가 바로 게임의 핵심입니다.

RPA는 어느 날 갑자기 작동을 멈추기 전까지는 99.9% 신뢰할 수 있는 봇을 제공했습니다. 에이전틱 AI (Agentic AI) 기술은 기본적으로 83%의 신뢰도를 가진 시스템을 제공하며, 핸드오프 (handoffs)를 설계했을 때만 99.5%의 신뢰도를 제공합니다. 이 두 수치 사이의 간극이 바로 수익이 발생하는 지점입니다.

따라서 마이그레이션은 '봇을 에이전트로 교체하는 것'이 아닙니다. 그것은 '취약한 결정론적 시스템 (deterministic system)을 탄력적인 확률론적 시스템 (probabilistic system)으로 교체한 다음, 조정 계층 (coordination layer)에서 결정론을 다시 추가하는 것'입니다. 이를 실행 가능한 조각들로 나누는 방법은 다음과 같습니다.

6계층 에이전틱 마이그레이션 스택. 각 계층은 레거시 RPA 봇을 퇴출할 때 나타나는 특정 실패 모드 (failure mode)를 해결합니다. 출처

에이전틱 마이그레이션 스택의 6개 계층

제가 직접 수행하거나 자문했던 모든 성공적인 RPA-to-agentic 마이그레이션은 이 6개 계층에 대응됩니다. 하나라도 건너뛰면 AI 조정 간극 (AI Coordination Gap)이 넓어져 시스템을 신뢰할 수 없게 됩니다.

계층 1: 프로세스 인텔리전스 계층 (The Process Intelligence Layer)

단 하나의 에이전트 프레임워크 (agent framework)를 건드리기 전에, 여러분은 RPA 봇이 실제로 무엇을 하는지 알아야 합니다. 문서에 적힌 내용이 아니라 말입니다. 이 차이는 생각보다 중요합니다. 대부분의 RPA 플릿 (fleets)에는 이미 퇴사한 엔지니어들이 덧붙여 놓은 문서화되지 않은 예외 처리, 특수 사례, 2021년에 변경된 벤더 API에 대한 임시 방편 등이 수년간 축적되어 있습니다. 프로세스 마이닝 (process mining) (Celonis 또는 기존 봇의 open telemetry)을 사용하여, 유지보수 시간의 80%를 소비하는 20%의 에지 케이스 (edge cases)를 포함한 실제 실행 경로를 매핑하십시오.

이 계층의 결과물은 **역량 지도 (capability map)**입니다. 즉, 어떤 프로세스가 결정론적인지 (스크립트 기반 도구로 유지), 어떤 프로세스가 판단을 필요로 하는지 (에이전트 후보), 그리고 어떤 프로세스가 순수한 데이터 이동인지 (n8n과 같은 단순 워크플로 엔진의 후보)를 정의하는 것입니다.

직관에 반하는 규칙: 결정론적 작업(Deterministic tasks)을 에이전트화하지 마십시오. 만약 프로세스가 '필드 C가 참일 때 파일 A를 시스템 B로 이동'하는 것이라면, LLM 에이전트는 일반적인 n8n 워크플로보다 더 느리고, 비용이 많이 들며, 신뢰도가 낮습니다. 에이전트는 판단(Judgment)이 필요한 영역에서만 그 가치를 증명합니다.

레이어 2: 도구 및 통합 레이어 (MCP)

이곳에 가장 큰 아키텍처적 변화가 존재합니다. 레거시 RPA는 화면을 클릭하는 인간인 척하며 통합되었습니다. 에이전틱 시스템은 에이전트가 호출할 수 있는 잘 정의된 함수인 **도구 (Tools)**를 통해 통합됩니다. 여기서 부상하고 있는 표준은 Model Context Protocol (MCP)로, 에이전트를 데이터 소스 및 도구에 균일한 방식으로 연결하기 위한 Anthropic의 오픈 표준입니다.

취약한 UI 셀렉터(Selectors)를 유지 관리하는 대신, ERP, CRM 및 내부 데이터베이스를 MCP 서버 또는 타입이 지정된 도구 스키마(Typed tool schemas)로 노출합니다. 에이전트는 테이블을 스크래핑(Scraping)하는 대신 get_open_invoices()를 호출합니다. UI가 변경되어도 아무것도 깨지지 않습니다. API 계약(Contract)이 안정적이기 때문입니다. 저는 한 팀이 하룻밤 사이에 탐색 메뉴를 조용히 재배치한 벤더 포털에서 깨진 셀렉터를 찾느라 3주를 허비하는 것을 본 후, 비싼 대가를 치르고 이 가치를 배웠습니다.

Python — LangGraph 에이전트를 위한 도구 정의

타입이 지정된 도구는 취약한 RPA UI 스크래핑을 대체합니다

from langchain_core.tools import tool

@tool
def get_open_invoices(vendor_id: str) -> list[dict]:
"""ERP API에서 특정 벤더의 미결제 송장(Open invoices)을 가져옵니다.
구조화된 데이터를 반환합니다 — 화면 스크래핑이나 깨진 셀렉터가 필요 없습니다."""
# 안정적인 ERP REST 엔드포인트를 호출합니다
return erp_client.invoices.list(vendor=vendor_id, status='open')

이제 에이전트는 픽셀을 클릭하는 대신 송장에 대해 추론(REASONS)합니다

레이어 3: 에이전트 추론 레이어

이 레이어는 모든 사람이 프로젝트의 전부라고 생각하는 단계입니다. 하지만 그렇지 않습니다. 이것은 추론(reasoning)을 수행하는 모델, 즉 다음에 무엇을 할지 결정하는 Claude, GPT 또는 Gemini를 의미합니다. 이 단계의 프레임워크로는 LangGraph (프로덕션 준비 완료, 그래프 기반 제어 흐름), AutoGen (Microsoft 개발, GitHub 별점 약 35K, 대화형 멀티 에이전트에 강력함), 그리고 CrewAI (역할 기반 에이전트 팀, 빠른 프로토타이핑에 인기 있음)가 있습니다.

이 레이어에서의 핵심 결정 사항은 **단일 에이전트(single-agent) 대 멀티 에이전트(multi-agent)**입니다. 대부분의 팀이 이 단계에서 과도한 엔지니어링(over-engineer)을 범합니다. 마이그레이션된 RPA 프로세스의 대다수는 좋은 도구를 갖춘 명확한 범위를 가진 단일 에이전트가 5개의 에이전트로 구성된 '크루(crew)'보다 더 낫습니다. 멀티 에이전트 아키텍처는 발표 자료(slide deck)에서 더 인상적으로 보이기 때문이 아니라, 진정으로 병렬적이거나 전문화된 도메인 작업이 필요한 경우에만 남겨두어야 합니다. 우리의 멀티 에이전트 시스템(multi-agent systems) 가이드는 추가적인 복잡성이 실제로 이득을 주는 시점이 언제인지 다룹니다.

레이어 4: 오케스트레이션 레이어 (The Orchestration Layer)

이 레이어는 AI 조정 격차(AI Coordination Gap)를 메우는 레이어입니다. 그리고 RPA 벤더들이 가장 느리게 구축하고 있는 레이어이기도 합니다. 오케스트레이션(Orchestration)은 재시도(retries), 타임아웃(timeouts), 검증 게이트(validation gates), 상태 지속성(state persistence), 결정론적 체크포인트(deterministic checkpoints) 등 에이전트, 도구, 인간 사이에서 작업이 어떻게 이동하는지를 제어합니다.

정립된 프레임워크

AI 조정 격차(The AI Coordination Gap) 재정의

AI 조정 격차는 개별적으로는 똑똑한 에이전트 시스템이 전체적으로는 어리석게 행동하는 이유입니다. 이 격차는 더 나은 모델에 의해 메워지는 것이 아니라, 모든 확률적 단계(probabilistic step) 사이에 결정론적 검증(deterministic validation)을 추가하는 오케스트레이션 레이어에 의해 메워집니다. 이 격차는 지능의 문제가 아니라 엔지니어링의 문제입니다.

실제로 LangGraph의 상태 유지 그래프 모델(stateful graph model)은 이 지점에서 빛을 발합니다. 노드(에이전트 작업)와 엣지(전환)를 정의하며, 추론 단계 사이에 명시적인 검증 노드(validation nodes)를 배치합니다. 모든 핸드오프(handoff)는 결정론적 체크(deterministic check)를 거칩니다: '에이전트가 유효한 JSON을 반환했는가? 총액이 허용 오차 범위 내에 있는가? 이것이 인간의 승인을 필요로 하는가?' 이러한 체크들이 바로 83%에 불과한 엔드 투 엔드(end-to-end) 신뢰도를 99%에 가깝게 끌어올리는 핵심입니다. 이것이 없다면, 여러분은 그저 운에 맡기고 있는 것과 다름없습니다. 패턴에 대한 자세한 내용은 당사의 orchestration 가이드를 참조하십시오.

에이전틱 송장 대조(Agentic Invoice Reconciliation): 오케스트레이션이 조정 격차를 메우는 지점

  1

    **MCP 도구 레이어 — get_open_invoices()**

에이전트가 안정적인 API를 통해 구조화된 송장(invoice) 및 구매 주문(PO) 데이터를 가져옵니다. 지연 시간(Latency)은 약 200ms입니다. UI 스크래핑(scraping)을 사용하지 않습니다. 입력: vendor_id. 출력: 타입이 지정된 송장 목록.

↓

  2
...

에이전트가 송장과 PO를 매칭하고, 불일치 사항을 표시하며, 설명 초안을 작성합니다. 확률적 단계(Probabilistic step)이며, 단독으로는 약 97%의 정확도를 보입니다.

↓

  3
...