AI Agent vs Assistant,
RPA vs Orchestration
AI가 IT 산업을 바꾼다는 말은 이제 익숙하지만, Agent와 Assistant가 무엇이 다른지, 기존 RPA와 Orchestration은 어떻게 구분되는지 명확하게 설명하기는 쉽지 않다. 하루에 11,000개 이상의 AI 에이전트가 새로 생성된다는 통계가 있을 만큼, 실무에서 에이전트 개발을 맡게 될 가능성은 점점 높아지고 있다. 아래에 두 가지 핵심 개념 비교를 실제 예시와 함께 정리했다.
참고 영상: Agent Orchestration — How It Fits Into the IT Ecosystem (YouTube)
01 Assistant vs Agent — 무엇이 다른가
LLM 기반 소프트웨어는 크게 두 가지 형태로 나뉜다. 같은 LLM을 쓰더라도 설계 방식에 따라 동작 방식이 전혀 달라진다.
프롬프트-응답 구조로 작동한다. 사용자가 질문(prompt)을 입력하면 그에 대한 응답(response)을 반환한다. 프롬프트가 없으면 대기 상태를 유지하며, 스스로 행동을 시작하지 않는다.
목표-결과 구조로 작동한다. 목표(goal)를 부여받으면 결과(outcome)를 향해 스스로 판단하고 행동한다. 매번 프롬프트를 받을 필요 없이, 주어진 범위 안에서 재량껏 조치를 취한다.
| 구분 | 입력 | 출력 | 자율성 |
|---|---|---|---|
| Assistant | 프롬프트 (Prompt) | 응답 (Response) | 없음 — 항상 대기 |
| Agent | 목표 (Goal) | 결과 (Outcome) | 있음 — 범위 내 재량 행동 |
어시스턴트와 에이전트는 구조적으로 유사하지만, 설계 철학이 다르다. 에이전트를 설계할 때는 범위를 좁게 잡는 것이 중요하다. 너무 넓은 권한을 주면 불필요한 행동을 할 가능성이 높아진다.
02 RPA vs Agent Orchestration — 무엇이 다른가
기존의 RPA(Robotic Process Automation)와 에이전트 오케스트레이션은 둘 다 반복 업무를 자동화해 생산성을 높이려는 목적을 공유한다. 그러나 접근 방식과 처리 가능한 복잡도가 근본적으로 다르다.
API 호출과 구조화된 데이터(데이터 테이블, 키-값 쌍)에 의존한다. 명확한 트리거와 사전 정의된 흐름이 있어야 작동하며, 모호한 맥락을 스스로 해석하지 못한다. 시스템이 엄격하게 구성되지 않으면 구현 난이도가 급격히 올라간다.
LLM을 탑재한 에이전트들이 자연어 맥락을 해석하며 협력한다. 모호한 상황에서도 목표를 향해 스스로 판단하고, 여러 에이전트가 분업·협업하는 구조로 풍부한 비즈니스 로직을 처리할 수 있다.
03 예시로 이해하는 오케스트레이션 — 고객 견적서 생성
강의에서 사용한 예시다. 영업팀이 고객에게 보낼 상업 견적서(Commercial Quote)를 자동으로 생성하는 프로세스를 RPA와 Orchestration 두 가지 방식으로 비교한다.
이 프로세스는 크게 세 단계로 구성된다.
RPA 방식의 한계
-
명시적 트리거 필요 견적을 생성해야 할 시점을 API가 자동으로 판단하기 어렵다. "견적 생성" 버튼처럼 명확한 프로그래밍 트리거가 있어야만 동작한다.
-
고도로 구조화된 데이터 전제 CRM, 제품 DB, 금융 시스템이 모두 RPA가 이해할 수 있는 정형 데이터 형식으로 구성되어 있어야 한다. 비정형 정보나 첨부 문서는 처리하기 힘들다.
-
비즈니스 로직 표현의 한계 SKU 간 호환성 검사, 영업 목표 대비 적합성 판단, 고객별 특수 조건 반영 같은 고차원적 판단을 코드로 모두 사전 정의하는 것은 현실적으로 매우 어렵다.
Agent Orchestration 방식
오케스트레이션 방식에서는 각 리소스(CRM, 제품 DB, 금융 시스템)가 MCP(Model Context Protocol) 서비스로 노출된다. 에이전트들은 MCP를 통해 해당 리소스와 대화하듯 상호작용한다.
Agent 2 — 고객명, 주소, CRM에 첨부된 문서에서 필요한 제품/서비스 정보를 수집한다.
Agent 4 — 제품 카탈로그를 탐색해 SKU 간 호환성, 배송 가능 여부, 영업 목표 부합 여부를 검증한다.
Agent 6 — 법률 카탈로그에서 해당 SKU 조합에 맞는 이용 약관(T&C)을 적용한다.
04 기존 개발자가 알아야 할 것
에이전트 오케스트레이션은 완전히 새로운 세계가 아니다. 클라이언트-서버 아키텍처, API 설계, 워크플로우 자동화 등 기존 소프트웨어 공학의 개념들이 그대로 적용된다.
-
이것도 결국 소프트웨어다 LLM, Agent, MCP 같은 새 용어에 위축될 필요 없다. 기존 모범 사례와 프로젝트 경험이 에이전트 설계에서도 그대로 유효하다.
-
에이전트 범위는 좁게 하나의 에이전트에 너무 많은 역할을 부여하면 예측할 수 없는 동작이 발생한다. Job Story를 촘촘하게 정의할수록 결과가 안정적이다.
-
MCP가 연결 표준이다 에이전트가 외부 리소스와 대화하려면 해당 리소스가 MCP 서비스로 노출되어 있어야 한다. 기존 RPA에서 API가 하던 역할을 MCP가 대신한다고 생각하면 쉽다.
-
패러다임 전환, 단순 업그레이드가 아니다 에이전트 오케스트레이션이 RPA에 LLM을 얹은 것에 불과하다는 시각도 있지만, 처리할 수 있는 비즈니스 로직의 깊이와 풍부함은 비교 자체가 어렵다.
Assistant는 프롬프트를 기다리고, Agent는 목표를 받아 스스로 움직인다. RPA는 모든 흐름을 사전에 정의해야 하지만, Agent Orchestration은 LLM 기반 에이전트들이 맥락을 이해하며 분업·협력한다. 고객 견적서 생성 예시처럼, 에이전트는 CRM 판독 → SKU 선별 → 가격 책정 → 약관 적용 → 문서 생성의 각 단계를 좁은 역할로 나눠 처리하고 컨텍스트를 축적해 나간다. 이미 소프트웨어 엔지니어링 경험이 있다면, 에이전트 개발도 그 연장선에서 접근할 수 있다.
'AI 학습' 카테고리의 다른 글
| Anthropic "Building Effective Agents" 공부 노트 (0) | 2026.05.16 |
|---|---|
| AI 필수 용어 7가지 (1) | 2026.05.09 |
| 피지컬 AI (Physical AI) (0) | 2026.04.21 |
| AI 에이전트 개발을 위한 7가지 기술 (1) | 2026.04.19 |