UiPath Agentic Automation Associate 자격증: UiAAA 시험에서 구별해야 할 7가지 쌍
요약
본 글은 UiPath Agentic Automation Associate 자격증(UiAAA) 시험을 준비하는 가이드입니다. 이 자격증은 생성형 AI와 에이전트 기반 AI, 에이전트와 로봇 등 유사한 개념들을 구별하는 능력을 평가합니다. 개발자부터 비기술직 역할까지 폭넓게 다루며, 프롬프팅 및 기본적인 에이전트 구축 실습 경험을 요구합니다.
핵심 포인트
- UiAAA 시험은 90분 동안 진행되며 합격 점수는 70%입니다.
- 시험의 핵심은 유사한 개념들(예: 생성형 AI vs. 에이전트적 AI)을 구별하는 것입니다.
- 대상 역할이 넓어 비즈니스 분석가부터 개발자까지 모두 준비해야 합니다.
- 프롬프팅, 기본적인 에이전트 구축 등 실습 경험이 중요합니다.
UiPath Agentic Automation Associate 자격증(시험 번호 UiPath-AAAv1, 보통 UiAAA로 약칭됨)은 90분 동안 진행되며 합격 점수는 70%이고 응시료는 $150입니다. 사전 요구 사항은 없으며, 시험에서 다루는 내용은 한 가지 기술, 즉 비슷하게 들리는 두 아이디어를 구별하는 것에 달려 있습니다.
이 수치는 UiPath 자체의 Agentic Automation Associate exam description (2025년 8월 날짜, 버전 1.1)에서 가져온 것입니다. 같은 문서에 따르면 이 자격증은 3년간 유효하며 UiPath Certified Professional 프로그램의 Agentic Automation 트랙에 속합니다. 따라서 문제 개수나 섹션별 비중을 공개하지 않으므로, 여기에 제시된 수치는 누군가의 추정치입니다.
해당 문서의 과제 목록을 읽어보면 '구분하다(differentiate)'라는 동사가 계속 등장합니다. 생성형 AI와 에이전트 기반 AI를 구분하는 것, 에이전트와 로봇을 구분하는 것, 시스템 프롬프트와 사용자 프롬프트를 구분하는 것, 결정론적 평가와 모델 기반 평가를 구분하는 것입니다. 따라서 이 가이드는 섹션 순서대로 진행되지 않습니다. 대신 시험을 일곱 쌍으로 분류하여 각 쌍의 두 부분을 구별하는 방법을 보여줍니다.
UiPath Agentic Automation Associate 자격증은 무엇을 다루나요?
이 자격증은 10개의 시험 섹션과 세 가지 제품, 즉 UiPath Studio Web, UiPath Maestro 및 Autopilot for Everyone에 대해 다룹니다. UiPath는 이를 비즈니스 분석가, 프로젝트 관리자부터 자동화 개발자, 솔루션 아키텍트까지 기술직과 비기술직 역할 모두를 대상으로 합니다.
시험 설명서에 언급된 '최소한의 자격을 갖춘 후보자(minimally qualified candidate)'는 권장되는 UiPath Academy 교육(Agentic Automation Developer Associate 학습 계획)을 이수했으며 독립적으로 작업할 수 있습니다. 실습 경험 측면에서 문서는 세 가지를 나열합니다: 프롬프팅, 기본적인 에이전트 구축, 그리고 대규모 언어 모델(LLM) 사용입니다.
다음은 10개 섹션이 본 가이드의 쌍과 어떻게 연결되는지 보여줍니다.
| 시험 섹션 | 구별해야 할 것 |
|---|---|
| Agentic AI 및 에이전트 자동화 개념 | 생성형 AI 대 에이전트적 AI, 그리고 에이전트 대 로봇 |
| ... | |
| 네 쌍의 경우 UiPath의 과제 목록에 '구별하다(differentiate)'라는 단어가 포함되어 있습니다. 나머지 세 가지(프롬프트 스타일, 접지 출처(grounding sources), Maestro 호출)는 두 가지 옵션을 나란히 언급하는 과제라고 제가 해석한 것입니다. |
생성형 AI인가 에이전트적 AI인가?
생성형 AI는 요청받았을 때 콘텐츠를 생성합니다. 에이전트적 AI는 목표를 향해 작동합니다. 첫 번째 시험 섹션에서는 ML, LLM 및 생성형 AI를 정의하고, 이어서 '에이전트를 정의하고 생성형 AI와 에이전트적 AI를 구별하는 것'을 요구합니다.
단순한 테스트가 도움이 됩니다: 시스템이 단순히 무언가를 반환하기만 하는지, 아니면 다음에 무엇을 할지 결정하는지가 중요합니다. 고객 이메일에 대한 답장을 작성하는 모델은 생성하고 있습니다. 이메일을 읽고, 주문 정보를 조회하며, 환불이 정책 내에 있는지 확인한 다음, 답변을 보내거나 사례를 사람에게 넘기는 시스템은 에이전트처럼 행동하고 있습니다. UiPath의 문서는 에이전트를 LLM에 의해 구동되며 추론(reason), 실행(act) 및 목표를 향해 적응할 수 있는 소프트웨어 시스템으로 설명합니다.
시나리오 질문에서의 함정은 'AI'라는 단어가 느슨하게 사용된다는 점입니다. 만약 시나리오에 목표, 도구, 결정이 없다면, 출력 결과가 아무리 인상적으로 들려도 그것은 생성을 설명하는 것입니다.
이 단계는 에이전트로 가야 할까 아니면 로봇으로 가야 할까?
로봇에게는 예측 가능하고 규칙 기반의 단계를, 에이전트에게는 모호하고 판단력이 필요한 단계를 전송합니다. UiPath의 에이전트와 로봇 비교는 에이전트를 확률적이고 적응성이 높은(probabilistic and adaptive) 것으로, 로봇을 결정론적이고 규칙 기반인(deterministic and rule-based) 것으로 설명합니다.
- **로봇 (Robots)**은 구조화된 실행과 신뢰성을 제공합니다. 반복적인 작업에 적합하며 스케줄, 트리거 또는 원격 운영(attended runs)부터 시작합니다.
- **에이전트 (Agents)**는 계획 수립, 의사 결정 및 자연어 처리를 제공합니다. 비정형적인 작업에 적합하며 사용자 요청이나 시스템 이벤트로부터 시작합니다.
같은 시험 섹션에서는 전통적인 자동화의 문제점("로봇과 인간만으로 수행되는" 경우)과 에이전트를 추가했을 때의 이점(지능형 의사 결정, 적응성, 목표 지향적 실행 및 다중 작업 조정)을 명시하도록 요구합니다. 이 네 가지 구절은 그대로 외우는 것이 좋습니다.
여기에 또 하나의 아이디어가 있습니다: 에이전트 기반 오케스트레이션(agentic orchestration). UiPath는 에이전트를 로봇의 대체재로 제시하지 않습니다. 대신, 에이전트 기반 자동화는 에이전트, 로봇, 그리고 인간이 함께 조율되는 것(orchestrated together)으로 정의합니다. 따라서 에이전트가 로봇을 쓸모없게 만든다고 주장하는 선택지는 UiPath 자체의 관점에서는 틀린 설명입니다.
종이에 해볼 수 있는 연습: 공급업체 송장과 같은 자신이 아는 프로세스를 가져와서 모든 단계를 R, A 또는 H로 라벨링해 보세요. ERP에 송장 필드를 입력하는 것은 R(로봇)입니다. 모호한 공급업체 이메일이 무엇을 요구하는지 파악하는 것은 A(에이전트)입니다. 설정된 한도를 초과하는 결제를 승인하는 것은 H(인간)입니다.
이 문장은 시스템 프롬프트에 속해야 할까요, 아니면 사용자 프롬프트에 속해야 할까요?
시스템 프롬프트는 에이전트의 역할, 목표, 규칙 및 도구 사용 시점에 대한 지침을 담고 있습니다. 사용자 프롬프트는 해당 실행(run)을 위한 입력을 담고 있습니다. UiPath의 에이전트 프롬프트 문서에서는 다음과 같이 설명합니다: 시스템 프롬프트는 자연어로 역할, 목표 및 제약 조건을 설명하며, 사용자 프롬프트는 입력과 인수가 에이전트에게 전달되는 방식을 구조화합니다.
예시가 정의보다 분할을 더 잘 보여줍니다.
SYSTEM PROMPT
You are a leave-request agent for the HR team.
1. Read the request and find the employee ID and the dates.
...
매번 실행해도 변하지 않는 것은 시스템 프롬프트(system prompt)에 위치합니다. 변경되는 모든 것은 사용자 프롬프트(user prompt)의 인자(arguments)를 통해 도착하며, 이 인자는 이중 중괄호로 작성됩니다.
UiPath 페이지는 시험에서 좋은 사실이 될 세부 사항을 추가합니다: 에이전트는 사용자 프롬프트에 명시적으로 참조된 인자만 볼 수 있습니다. 입력 인자를 정의했지만 참조하는 것을 잊으면, 에이전트는 그 값을 절대 받지 못합니다.
레이블(labels)도 중요합니다. Employee email: {{employee_email}}라고 작성하면 에이전트에게 어떤 값이 무엇인지 알려줍니다. 단순히 플레이스홀더 목록만 나열하면 원시 값(raw values)이 전달되고, 에이전트는 추측해야 합니다.
제로샷(Zero-shot) 또는 퓨샷(Few-shot): 작업에 필요한 프롬프트는?
간단한 작업에는 제로샷 프롬프트를 사용하고, 출력이 특정 패턴을 따라야 할 때는 퓨샷 프롬프트를 사용합니다. 프롬프트 엔지니어링 섹션에서는
스토리지 버킷 또는 통합 서비스: 컨텍스트는 어디에서 오는가?
Context Grounding은 두 가지 종류의 소스에서 데이터를 읽어옵니다: Orchestrator 스토리지 버킷, 또는 Integration Service 커넥터를 통해 접근하는 문서 시스템입니다. 시험에서는 '컨텍스트 그라운딩 소스(스토리지 버킷, 통합 서비스)와 구성 옵션'을 정의하도록 요구합니다.
Context Grounding은 UiPath의 검색 계층(retrieval layer)입니다. 비즈니스 문서를 인덱싱하여 모델이 답변하기 전에 프롬프트가 해당 문서에 기반할 수 있도록 합니다. 인덱스를 구축할 때 데이터 출처를 선택하며, UiPath Context Grounding 인덱스 생성 단계는 Data Settings에서 정확히 두 가지 선택지(Storage Bucket 또는 Connector)를 보여줍니다.
- Storage bucket: 공유 Orchestrator 폴더에 업로드하는 파일들입니다.
- Connector: Confluence Cloud, Dropbox, Google Drive 또는 Microsoft OneDrive 및 SharePoint에 그대로 남아 있으며, Integration Service 연결을 통해 읽어오는 파일들입니다.
시나리오에서 빠르게 파악할 수 있는 팁은 문서가 어디에 존재하는지입니다. '정책들은 SharePoint에 있고 매주 변경된다'는 것은 커넥터를 가리킵니다. '팀이 전달해야 할 PDF가 40개 있다'는 것은 버킷을 가리킵니다.
구성 옵션의 경우, 에이전트가 인덱스에 적용하는 검색 설정을 알아야 합니다: 의미론적 검색 전략(semantic search strategy), 관련성 점수 임계값(relevance score threshold) (높이면 가장 잘 일치하는 청크만 반환됨), 그리고 최대 결과 개수입니다.
결정론적 또는 모델 기반: 이 출력은 어떻게 점수를 매겨야 하는가?
답변이 정확히 일치해야 할 때는 결정론적 평가(deterministic evaluation)를 사용하고, 단어 선택보다 의미가 더 중요할 때는 모델 기반 평가(model-graded one)를 사용합니다. 평가는 에이전트가 프로덕션에 근접하기 전에 신뢰할 수 있는지 보여주는 방법입니다.
Agents 사용자 가이드의 Evaluations 페이지에서 결정론적 평가기(deterministic evaluators)(정확히 일치, JSON 유사성, CSV 열 정확히 일치)는 규칙 기반 매칭을 사용하며, 언어 모델을 호출하지 않고 항상 동일한 입력을 같은 결과로 반환합니다. 모델 등급의 종류는 제품에서는 "LLM as a judge"로 나타나며, 이는 출력을 점수화하는 데 모델을 사용하는 의미적 유사성(semantic similarity), 컨텍스트 정밀도(context precision), 충실도 평가기(faithfulness evaluators)이며 언어에서 합리적인 변화를 허용합니다.
명칭의 차이에 주목하세요. 시험 설명에는 "model-graded"라고 되어 있고 제품 화면에는 "LLM as a judge"라고 되어 있습니다. 둘은 같은 개념입니다. 세 번째 범주인 트래젝토리(trajectory)는 중간 단계와 도구 사용을 포함하여 에이전트의 전체 실행 과정을 평가합니다.
오른쪽 열을 읽기 전에 몇 가지 출력을 직접 분류해 보세요.
| Agent output | Better evaluator | Why |
|---|---|---|
approved: true | Deterministic | 부울 값은 일치하거나 그렇지 않습니다 |
| ... | ||
| 각 평가(evaluation)는 입력과 출력에 대한 단언(assertion)을 쌍으로 묶으며, 결과는 0점에서 100점 사이의 척도로 점수화됩니다. |
Maestro 작업이 에이전트를 시작해야 할까요, 아니면 워크플로우를 시작해야 할까요?
UiPath Maestro에서는 Service 작업을 통해 에이전트를 시작하거나 RPA 워크플로우를 시작할 수 있으며, 누가 해당 단계를 수행해야 하는지 질문하여 선택합니다. 시험은 옵션을 직접 명시합니다: Service 작업을 구성하여 "Start and wait for agent"로 에이전트를 호출하고, Service 작업을 구성하여 Orchestrator에서 자동화 워크플로우를 호출하도록 합니다.
Maestro는 비즈니스 프로세스를 BPMN으로 모델링하고 각 작업을 로봇, 에이전트 또는 인간에게 매핑합니다. Maestro용 Service 작업 참조에서 여기서 중요한 두 가지 동작은 "Start and wait for agent"와 "Start and wait for RPA workflow"입니다. 둘 다 호출된 항목이 완료될 때까지 프로세스를 일시 중지시키며, 각각 별도의 Orchestrator 작업으로 실행됩니다.
따라서 이 쌍은 정의에 관한 것보다는 다이어그램을 읽는 것에 가깝습니다. 프로세스 상자 안에 '폼 필드를 추출하여 ERP로 게시하라'고 되어 있다면, 서비스(Service) 작업은 워크플로우를 시작해야 합니다. 만약 '고객이 무엇을 요청하는지 파악하라'고 되어 있다면, 에이전트(agent)를 시작해야 합니다. 그리고 '매니저가 승인한다'고 되어 있다면, 그것은 사람의 단계(human step)이며 다른 유형의 작업입니다.
쌍이 아닌 시험 섹션에 대해서는 어떨까요?
네 가지 영역은 비교가 아니라 순수한 회상(recall)을 요구하며, 배우기 쉽습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기