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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 이들은 인간이 하던 일 — 클릭하기, 복사하기, 전사하기 — 을 자동화하는 데 집중하는 반면, 실제 운영 환경에서 문제를 일으키는 요소, 즉 아무도 설계하지 않은 시스템 간의 조정(coordination) 문제는 무시합니다. 그 결과, 이전에도 실패했던 똑같이 취약한 배관 구조 위에 번지르르한 AI 기술 계층을 덧붙이는 꼴이 되며, 결국 기존 시스템이 실패했던 것과 동일한 이유로 실패하게 됩니다.

레거시 RPA — UiPath, Automation Anywhere, Blue Prism — 에서 벗어나는 것은 현재 진행 중인 실질적인 조달 결정 사항이며, 이를 대체하는 AI 기술은 에이전틱(agentic)합니다: LangGraph, AutoGen, CrewAI, 그리고 Anthropic의 MCP를 통해 연결된 오케스트레이션(orchestration) 계층이 그 예입니다. 이것이 중요한 이유는 여러분의 책상 위에 놓인 RPA 라이선스 갱신 비용이 그것보다 성능이 뛰어난 AI 스택의 비용보다 더 많이 들기 때문입니다.

이 글을 다 읽을 때쯤이면, 여러분은 AI 조정 격차(AI Coordination Gap)가 무엇인지, 이를 어떻게 설계로 해결할 수 있는지, 그리고 60%의 프로세스 비용 절감 뒤에 숨겨진 실제 수치가 무엇인지 이해하게 될 것입니다. 예측치가 아닙니다. 우리가 직접 실행한 배포에서 나온 수치입니다.

레거시 RPA 봇은 UI 요소가 변경되면 조용히 실패하지만, AI 에이전트는 그 변화를 고려하여 추론합니다. 이것이 마이그레이션을 이끄는 핵심적인 구조적 이점입니다. 출처

개요: 기업들이 RPA를 뽑아내는 이유

로봇 프로세스 자동화 (Robotic Process Automation, RPA)는 취약성 (brittleness)에 대한 10년 동안의 도박이었습니다. RPA 봇은 기록된 스크립트입니다. 즉, 고정된 화면 레이아웃에 맞춰 마우스 움직임과 키스트로크 (keystrokes)를 재생합니다. 기반이 되는 애플리케이션이 버튼을 업데이트하거나, 필드 이름을 변경하거나, 로딩 스피너 (loading spinner)를 추가하면 봇은 중단됩니다. 조용히 말이죠. 프로세스 도중에, 그리고 종종 새벽 2시에 말입니다.

업계는 이를 알고 시작했습니다. Gartner는 RPA 구현의 상당 부분이 유지보수 오버헤드 (maintenance overhead)로 인해 예산을 초과하고 일정이 지연된다고 추정해 왔습니다. 모든 UI 변경은 변경 요청 (change request)을 발생시킵니다. 모든 변경 요청은 개발자 티켓 (developer ticket)을 발생시킵니다. 노동력을 줄여주기로 되어 있던 봇들이, 아무도 예산을 책정하지 않았던 완전히 새로운 유지보수 노동 카테고리를 조용히 만들어낸 것입니다. Forrester와 McKinsey의 QuantumBlack은 대규모 자동화 프로그램에서 발생하는 동일한 유지보수 저해 요인 (maintenance drag)을 기록했습니다.

현대적인 AI 기술은 이 모델을 뒤집습니다. 고정된 스크립트를 재생하는 대신, 에이전트 (agent)는 시스템의 현재 상태를 인지하고, 목표에 대해 추론하며, 행동을 선택합니다. 필드가 이동하면 에이전트는 적응합니다. 예외 (exception)가 발생하면, 에이전트는 오류를 읽고 재시도할지, 에스컬레이션 (escalate)할지, 아니면 우회할지를 결정합니다. 이것이 매크로 (macro)와 동료의 차이입니다. 더 광범위한 입문서를 원하신다면, 당사의 기업용 AI 도입 (enterprise AI adoption) 개요를 참조하십시오.

RPA는 키스트로크를 자동화했습니다. AI 에이전트는 판단 (judgment)을 자동화합니다. 가장 빠르게 전환하는 기업들은 판단이야말로 항상 비용이 많이 드는 부분이었다는 사실을 깨달았습니다.

하지만 — 그리고 대부분의 운영자가 이 점을 완전히 놓치고 있는데 — RPA 봇을 AI 에이전트로 일대일 교체하는 것은 실망스러운 결과를 초래합니다. 엔드 투 엔드 (end-to-end) 프로세스를 처리하는 단일 에이전트는 종종 그것이 대체한 RPA 스크립트보다 신뢰성이 낮은 경우가 많은데, 이는 추론 (reasoning)이 변동성 (variance)을 유발하기 때문입니다. 승리는 완전히 다른 아키텍처에서 옵니다. 즉, 오케스트레이션 레이어 (orchestration layer)를 통해 조정되는 여러 개의 특화된 에이전트들과, 모든 핸드오프 (handoff) 단계에서의 결정론적 가드레일 (deterministic guardrails)을 갖춘 구조에서 승리가 나옵니다.

Coined Framework

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)는 단일 AI 단계 내부가 아니라, 아무도 명시적으로 설계하지 않은 단계, 시스템, 그리고 에이전트 간의 핸드오프 (handoff) 과정에서 발생하는 신뢰성 손실을 의미합니다. 이것이 바로 개별적으로는 뛰어난 컴포넌트들로 구축된 워크플로우가 전체 프로세스(end-to-end) 관점에서는 여전히 실패하는 이유입니다.

다단계 AI를 배포하려는 사람이라면 공포를 느낄만한 계산식이 있습니다. 각 단계의 신뢰도가 97%인 6단계 파이프라인의 경우, 전체 프로세스의 신뢰도는 약 83% (0.97^6)에 불과합니다. 여기에 3단계를 더 추가하면 76% 미만으로 떨어집니다. 대부분의 팀은 대량의 트랜잭션이 유출되기 시작하는, 즉 이미 제품을 출시한 후에야 이 사실을 깨닫습니다. 저는 이런 일이 발생하는 것을 여러 번 목격했습니다.

~50%
의 RPA 프로젝트가 예산이나 일정을 초과하며, 이는 주로 유지보수 오버헤드 때문입니다.
[Gartner, 2024](https://www.gartner.com/en/newsroom)
...

이 글에서는 조정 격차 (Coordination Gap)를 핵심 설계 문제로 다룹니다. 아래 프레임워크의 모든 계층은 이 격차를 해소하기 위해 존재합니다. 이제 시스템을 구축해 보겠습니다.

에이전틱 대체 스택: 5계층 프레임워크 (The Agentic Replacement Stack: A 5-Layer Framework)

RPA를 대체하는 것은 단순히 도구를 바꾸는 것이 아니라, 아키텍처를 재설계하는 것입니다. 아래는 중견 이커머스 운영사를 Automation Anywhere에서 전환시키고 프로세스 비용을 60% 절감하기 위해 우리가 배포한 5계층 스택입니다. 각 계층은 AI 조정 격차 (AI Coordination Gap)의 특정 부분을 목표로 하며, 각각은 현대 AI 기술 내에서 별개의 전문 분야를 나타냅니다.

에이전틱 RPA 대체 스택 — 트리거에서 검증된 결과까지 (The Agentic RPA Replacement Stack — From Trigger to Verified Outcome)

  1

    **수집 및 트리거 계층 (Ingestion & Trigger Layer (n8n))**

이벤트가 도착합니다: 새로운 주문 웹훅 (webhook), 수신 이메일, Slack 메시지, 또는 예약된 배치 (batch) 작업 등입니다. n8n은 이를 구조화된 이벤트 객체로 정규화 (normalize) 합니다. 지연 시간 (latency) 목표는 1초 미만입니다. 이는 과거에 화면을 폴링 (poll) 하던 RPA의 '워처 (watcher)'를 대체합니다.

↓

  2
...

에이전트가 행동하기 전에, 벡터 데이터베이스 (vector database)로부터 관련 컨텍스트(context) — SOP, 이전 티켓, 제품 데이터, 고객 이력 등 — 를 검색합니다. 이는 의사결정의 근거를 회사의 실제 데이터에 두게 하며(grounding), 도메인 특화 작업에서의 환각 (hallucination) 현상을 줄여줍니다.

↓

  3
...

상태 유지 그래프 (stateful graph)가 작업을 전문 에이전트 (specialized agents)에게 라우팅하고, 재시도 (retries)를 관리하며, 공유 상태 (shared state)를 유지합니다. 이곳이 바로 조정 격차 (Coordination Gap)가 해소되는 지점입니다. 모든 핸드오프 (handoff)는 암시적인 가정이 아닌, 명시적이고 타입이 지정된 엣지 (typed edge)로 이루어집니다.

↓

  4
...

에이전트들은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP) 서버를 통해 ERP, CRM, 결제 게이트웨이 (payment gateway), 배송 API와 같은 시스템을 호출합니다. MCP는 도구 접근 방식을 표준화하므로, 에이전트가 시스템마다 별도의 맞춤형 글루 코드 (glue code)를 작성할 필요가 없습니다.

↓

  5
...

결정론적 검사기 (deterministic checker)가 비즈니스 규칙(합계 일치, SKU 존재 여부, 필드 Null 여부 등)에 따라 출력을 검증합니다. 실패 시에는 전체 컨텍스트와 함께 인간 대기열 (human queue)로 에스컬레이션됩니다. 이것이 바로 기존 RPA에는 없었던 가드레일 (guardrail)입니다.

이 시퀀스가 중요한 이유는 신뢰성이 복리로 쌓이기 때문입니다. 실행 전의 그라운딩 (grounding)과 실행 후의 검증 (verification)은 83%의 파이프라인을 99%로 바꾸는 핵심 요소입니다.

레이어 1: 인제스션 및 트리거 레이어 (The Ingestion & Trigger Layer)

전통적인 RPA 봇은 폴링 (polling) 방식을 통해 화면이나 편지함을 '감시'해 왔는데, 이는 본질적으로 취약하고 느린 방식입니다. 현대적인 대응책은 이벤트 기반 인제스션 (event-driven ingestion) 레이어입니다. 우리는 n8n (프로덕션 준비 완료, 셀프 호스팅 가능, GitHub 별점 약 9만 개)을 프런트 도어로 사용했습니다. n8n은 각 시스템을 위한 글루 코드를 작성하지 않아도 웹훅 (webhook), 이메일, 데이터베이스 트리거, 크론 (cron)을 네이티브하게 지원하기 때문입니다.

핵심적인 설계 선택은 모든 트리거를 에이전트에 닿기 전에 단일한 구조화된 이벤트 스키마 (structured event schema)로 정규화하는 것입니다. 오케스트레이션 (orchestration) 레이어는 작업이 Shopify 웹훅에서 시작되었는지 고객 이메일에서 시작되었는지 신경 쓸 필요가 없습니다. 어떤 경우든 동일하고 깨끗한 객체를 전달받기 때문입니다. n8n을 활용한 워크플로 자동화 가이드에서 더 자세히 알아보세요.

우리 배포 과정에서 얻은 가장 큰 지연 시간 (latency) 개선 사항은 RPA의 30초 폴링 루프를 n8n 웹훅으로 교체한 것이었습니다. AI가 실행되기도 전 단계에서 트리거부터 실행까지의 시간이 약 40초에서 2초 미만으로 단축되었으며, 이는 20배의 성능 향상을 의미합니다.

레이어 2: 컨텍스트 레이어 (RAG)

컨텍스트 (Context)가 없는 에이전트는 추측하는 기계에 불과합니다. 어떤 결정을 내리기 전에, 우리의 에이전트들은 Pinecone 벡터 데이터베이스로부터 근거 데이터 (grounding data)를 검색합니다: 표준 운영 절차 (SOP), 과거 해결 사례, 제품 카탈로그, 고객 기록 등입니다. 이것이 바로 검색 증강 생성 (Retrieval-Augmented Generation, RAG)이며, 이는 귀사의 비즈니스 규칙을 따르는 에이전트와 즉흥적으로 규칙을 만들어내는 에이전트를 가르는 차이점입니다. 이 기술의 원형은 Lewis et al. (2020)의 기초 RAG 논문에 기술되어 있습니다.

이커머스 환불 프로세스의 경우, 컨텍스트 레이어는 반품 정책, 고객의 주문 내역, 그리고 이전의 유사 사례들을 가져옵니다. 그런 다음 에이전트는 일반적인 학습 데이터가 아닌, 해당 제약 조건 내에서 추론합니다. 기업용 RAG 아키텍처 (RAG architecture for enterprise)에 대한 당사의 심층 분석을 참조하세요.

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

이곳은 조정 격차 (Coordination Gap)가 성패를 가르는 지점입니다. 우리는 LangGraph를 사용했는데, 그 이유는 이 도구가 워크플로우를 명시적인 상태 기반 그래프 (stateful graphs)로 모델링하기 때문입니다. 모든 에이전트는 노드 (node)이며, 모든 핸드오프 (handoff)는 타입이 지정된 엣지 (edge)입니다. 모든 재시도 (retry), 타임아웃 (timeout), 그리고 조건부 경로 (conditional route)는 가정되는 것이 아니라 사전에 선언됩니다.

새롭게 정의된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 왜 '에이전트를 더 추가하는 것'이 신뢰성을 높이는 것이 아니라 오히려 악화시키는 경우가 많은지를 설명해 줍니다. 설계되지 않은 각 핸드오프는 실패 확률을 배가시키기 때문입니다. LangGraph와 같은 오케스트레이션 프레임워크는 모든 핸드오프를 명시적이고 복구 가능하게 만들기 위해 존재합니다.

Python — LangGraph 오케스트레이션 스켈레톤 (skeleton)

주문 처리 워크플로우를 위한 최소한의 LangGraph 상태 머신 (state machine)

from langgraph.graph import StateGraph, END
from typing import TypedDict

class OrderState(TypedDict):
order: dict
context: str # Pinecone에서 검색됨 (레이어 2)
validated: bool
escalate: bool

def retrieve_context(state):
# RAG 단계: SOP 및 이력을 바탕으로 결정의 근거를 마련함
state['context'] = vector_store.query(state['order']['id'])
return state

def classify_order(state):

전문 에이전트가 라우팅 경로를 결정합니다

state['order']['type'] = classifier_agent.run(state)
return state

def verify(state):

결정론적 가드레일 (Layer 5)

state['validated'] = state['order']['total'] == recompute(state['order'])
state['escalate'] = not state['validated']
return state

graph = StateGraph(OrderState)
graph.add_node('retrieve', retrieve_context')
graph.add_node('classify', classify_order')
graph.add_node('verify', verify')
graph.set_entry_point('retrieve')
graph.add_edge('retrieve', 'classify')
graph.add_edge('classify', 'verify')

명시적 조건부 핸드오프 — 이것이 조정 격차(Coordination Gap)를 닫습니다.

graph.add_conditional_edges(
'verify',
lambda s: 'human_queue' if s['escalate'] else END
)
app = graph.compile()

AutoGen이나 CrewAI와 LangGraph를 결합하여 토론하거나 협업하는 에이전트가 필요할 때 사용할 수 있습니다. 하지만 대부분의 RPA 대체 워크플로우에서는 좁고 단일 목적의 에이전트로 구성된 방향성 그래프(directed graph)가 군집(swarm)보다 우수합니다. 왜냐하면 예측 가능성이 높고, 새벽 2시에 문제가 발생했을 때 디버깅하기가 훨씬 쉽기 때문입니다. 오케스트레이션 템플릿을 위해 AI 에이전트 라이브러리에서 바로 사용할 수 있는 패턴들을 탐색해 보세요.

A LangGraph 상태 머신은 모든 핸드오프를 명시적으로 만듭니다 — 이는 AI 조정 격차(AI Coordination Gap)를 닫는 시각적 모델입니다. 출처

Layer 4: 도구/액션 레이어 (Tool/Action Layer, MCP)

RPA 봇은 UI를 클릭하며 시스템과 상호작용했습니다. 그것은 항상 취약한 부분이었으며, 많은 팀이 AI 에이전트로 성급하게 전환할 때 가장 많이 재현하는 문제이기도 합니다. AI 에이전트는 API와 표준화된 도구 인터페이스(tool interfaces)를 통해 상호작용해야 합니다. 2024년 말 Anthropic에서 도입한 Model Context Protocol (MCP)는 에이전트가 도구 및 데이터 소스에 연결하는 방식을 표준화합니다. 모든 시스템에 대해 맞춤형 통합 코드를 작성하는 대신, 공통 프로토콜을 통해 ERP, CRM 및 배송 플랫폼을 노출하는 MCP 서버를 실행하면 됩니다.