UiPath Test Cloud — 에이전틱 테스트 플랫폼을 해부하고 도입을 평가하기

개념

Katalon과 Autify 다음에 이 도구를 보는 이유

이 모듈은 한 방향으로 넓어져 왔다. 레슨 1의 Katalon은 코드 없이 자동화를 만드는 편의 를, 레슨 2의 Autify는 셀프힐링이라는 AI 기능 하나 를 상품화했다. 이 레슨의 UiPath Test Cloud는 설계·자동화·실행·관리 라이프사이클 전체 에 AI 에이전트를 얹은 플랫폼이다.

UiPath라는 이름은 모듈 15(레슨 1)에서 RPA 도구로 이미 만났다. 같은 회사가 업무 자동화에서 쌓은 화면 조작·오케스트레이션 기술을 테스트 영역으로 가져온 것이 Test Cloud다. SAP·Oracle 같은 업무 시스템 테스트에 강하다는 주장도 그 배경에서 나온다.

범위가 넓어질수록 레슨 2에서 배운 태도 — AI가 "고쳤다"는 것을 무조건 믿지 않는다 — 는 더 큰 질문으로 바뀐다. "이 플랫폼이 우리 조직을 몇 배 빠르게 해 준다는 주장을 믿어도 되는가." 그래서 이 레슨은 두 부분이다. 앞부분은 해부, 뒷부분은 도입 평가 다.

이 레슨은 2026년 9월 한국어 웨비나를 출발점으로 삼고, 공개 문서·보도자료로 확인한 사실과 웨비나 발표로만 들은 내용 을 구분해 적었다. 제품은 빠르게 바뀌므로, 실제 도입 검토 시점에 문서를 다시 확인한다.

테스트 클라우드는 무엇으로 이루어졌나

Test Cloud는 한 제품이 아니라 묶음 이다.

플랫폼을 볼 때 "AI 기능이 몇 개인가"보다 "이 조각들이 서로 연결돼 있는가" 를 먼저 본다. 연결이 끊긴 곳마다 사람이 결과를 복사해 옮기고, 거기서 대기 시간이 생긴다. 모듈 18a(레슨 13)에서 리드타임의 큰 몫이 이 대기라는 것을 봤다.

공개 자료로 확인한 타임라인

라이프사이클 네 단계의 유스케이스 지도

웨비나는 "20개 이상의 유스케이스가 네 단계 전부에 제품화돼 있다"고 설명했다. 문서로 확인되는 것과 웨비나에서만 본 것을 나눈다.

퍼지 검증은 편리하지만 비결정적 이다. 금액·상태처럼 정답이 하나인 값에는 결정적 어서션을 함께 둔다. 모듈 18b(레슨 5)의 통계적 검증 원칙이 여기 적용된다. 자율 실행·자율 탐색을 운영하는 절차는 모듈 18a(레슨 14)에서 따로 다뤘다.

웨비나는 "경쟁사는 테스트 생성 같은 특정 지점에만 AI가 있다"고 말했는데, 이는 발표자의 주장 이다. Tricentis도 에이전틱 테스트 자동화와 원격 MCP 서버를 내놓는 등 시장 전체가 라이프사이클 전반으로 넓히는 중이다. 비교는 뒤의 평가표로 직접 한다.

데모 1 — Test Manager에서 Autopilot과 대화하기

1. "소유자별로 요구사항이 몇 개인지 파이 차트로 보여줘"   → 담당자별 요구사항 차트
2. "특정 소유자의 요구사항을 나열해줘"                  → 3건 검색
3. "이 요구사항의 품질을 평가해줘"                      → 정해진 품질 요소별 평가
4. "실행 결과를 분석해줘"                              → 5건 요약
     - 한 건은 반복 실패
     - 한 건은 검증 단계에서 기대 결과와 실제 결과가 다름

4번의 두 실패는 성격이 다르다. 반복 실패는 플래키·환경·결함 중 무엇인지 더 봐야 하고, 기대값 불일치는 제품 결함이거나 사양 변경이다. 모듈 18a(레슨 2)에서 배운 결함 분류가 여기서 필요하다. AI 요약이 두 실패를 다른 조치로 안내하는지 확인하는 것이 사람의 몫이다.

발표자는 데모용 요구사항과 테스트 케이스 40~50개도 전부 Autopilot으로 만들었다고 밝혔다. 만드는 일은 싸졌다. 그만큼 무엇이 맞는지 판단하는 일의 비중이 커졌다.

데모 2 — 바이브 코딩으로 코디드 테스트 만들기

1. "테스트 매니저의 모든 테스트 케이스를 가져와"
2. "TC-301 수동 테스트 단계를 보여줘"        → 11단계 (메뉴 선택 → 신청 → 데이터 입력 …)
3. "코드를 생성해줘"                        → C# 코디드 테스트, 오브젝트 리포지토리 요소 자동 매핑
4. Autopilot 완료 요약: "화면 중간 검증 단계가 없습니다"
5. "실행해줘"                              → 값이 입력되는 화면 확인 후 종료

4번이 이 데모에서 가장 중요한 장면이다. 입력만 하고 확인하지 않는 테스트는 항상 통과한다. 모듈 18c(레슨 3)의 가짜 테스트 다. 도구가 먼저 경고해 준 것은 좋은 설계지만, 5번에서 검증을 채우지 않고 실행으로 넘어갔다는 점도 함께 봐야 한다. 경고를 읽고 어서션을 넣는 것은 여전히 사람의 일이다.

커스텀 에이전트 — Agent Builder와 코디드 에이전트

내장 기능으로 부족한 조직 고유의 일 — "대출 심사 화면이 내부 규정을 지키는지 판정" 같은 — 은 에이전트를 직접 만든다. 두 경로가 있다.

어느 경로든 에이전트를 이루는 요소는 같다. 프롬프트, 인수, 컨텍스트(메모리·문서 그라운딩), 도구(UI·API 자동화, MCP), 평가 , 에스컬레이션. 가드레일은 세 층에 건다.

에이전트를 파이프라인 노드로 넣을 때 쓰는 스펙 카드와 오류 비용 설계는 모듈 18c(레슨 7)에서 다뤘다. 도구가 로우코드 캔버스를 주더라도 금지 행동과 에스컬레이션 조건을 비워 두면 그 에이전트는 완성된 것이 아니다.

사내망이라면 — 온프레미스와 셀프호스팅 모델

웨비나 Q&A에서 나온 질문이다. "사내 보안 때문에 외부 클라우드 접속이 막혀 있는데 쓸 수 있나요?" 금융·공공·제조 QA가 가장 먼저 부딪히는 벽이다.

공개 문서(2.2510 기준)로 확인한 내용은 이렇다.

온프레미스 제품      Automation Suite · Private Test Cloud 2.2510 에 Autopilot for Testers 도입
셀프호스팅 모델      데이터 주권·규제 요건을 위한 권장 오픈소스 모델 목록 지원
연결 방식           OpenAI V1 표준 API를 노출해야 함 → Integration Service 커넥터로 연결
검증               모델마다 AI Trust Layer 검증 테스트 통과 후 사용
추론 엔진           vLLM, SGLang
제약               셀프호스팅 모델은 에이전틱 기능의 일부만 호환

웨비나 발표로는 매년 10월 메이저 릴리즈를 발표하고 11월경 소프트웨어가 나오며, 온프레미스에서 셀프호스팅 모델과 연결되는 AI 기능 범위를 넓혀 가는 중이라고 했다.

그래서 물어야 할 질문은 "온프레미스 되나요?"가 아니다.

□ 우리가 쓰려는 기능이 셀프호스팅 모델에서 호환되는 "일부"에 들어가는가
□ 클라우드 버전과 온프레미스 버전의 기능 차이표를 받을 수 있는가
□ 셀프호스팅 모델로도 데모와 같은 품질이 나오는가 → 우리 평가셋으로 직접 비교
□ GPU·추론 서버 비용과 운영 담당은 누구인가

데이터가 모델로 나가는 경로와 섀도우 AI 대응은 모델 18b(레슨 9·10)의 내용을 그대로 보안 심의 답변서로 옮기면 된다.

같은 원리를 무료로 — Playwright Test Agents

도입 평가에는 비교 대상 이 필요하다. 오픈소스 쪽에서 가장 가까운 것이 Playwright 1.56부터 제공되는 세 에이전트 정의다.

npx playwright init-agents --loop=claude    # vscode · claude · codex · opencode

무료 조합이 채우지 못하는 영역도 정직하게 적어 둔다.

비교 대상이 있어야 비용을 설명할 수 있다. "도입 전보다 좋아졌다"가 아니라 "무료 대안보다 이만큼 더 좋다"를 보여야 한다.

애널리스트 리포트 읽는 법

웨비나는 "세 애널리스트가 동시에 리더로 지정한 소수 벤더"라고 강조했다. 확인한 사실은 이렇다.

리포트를 읽을 때 확인할 것이다.

□ 리더는 한 곳이 아니다 — 같은 리포트에 여러 리더가 있다
□ 발행 연도와 시장 정의를 확인한다 (클라우드 테스팅과 자율 테스팅 플랫폼은 다른 시장이다)
□ 평가 기준의 가중치가 우리 우선순위와 같은가
□ 무료로 받는 사본은 대개 해당 벤더가 배포권을 산 것이다
□ 리포트는 후보를 줄이는 도구다. 선택은 우리 PoC가 한다

고객 사례 수치 — 확인한 것과 확인하지 못한 것

공개 자료로 확인한 수치

웨비나에서 소개됐지만 원자료를 찾지 못한 수치

• 글로벌 기업 사례 — 6개월 만에 테스트 자동화율 95% (발표 음성에서 기업명이 명확하지 않았다)
• Micron — 스프린트 회귀 주기를 수 주에서 수 시간으로
• PepsiCo — HR 채용·온보딩 다중 페르소나 회귀 테스트 소요 시간 80% 이상 단축
• "190개 이상 기술 지원", "50개 이상 ALM 커넥터"

찾지 못했다고 틀린 것은 아니다. 도입 검토에 쓰려면 원자료를 요청한다. 질문은 수치마다 같다.

□ 기준선(Before)은 무엇이고 언제 쟀나
□ 측정 기간과 대상 범위(앱·테스트 수)는
□ "자동화율"의 분모는 무엇인가 (전체 TC인가, 자동화 대상 TC인가)
□ 인력 구성과 외부 컨설팅 투입은 어떻게 변했나
□ 유지보수 비용이 포함됐나
□ 규모·업종이 비슷한 레퍼런스 고객과 통화할 수 있나

세 번째 질문이 특히 강하다. 자동화율 95%의 분모가 "자동화하기로 고른 TC"라면, 전체 TC 기준으로는 절반이 안 될 수도 있다.

기존 자산 이관 — 폐기 재구축이 아니라 흡수

웨비나 Q&A의 답변 원칙은 "버리고 다시 짓지 않고 흡수해서 재활용한다" 였다.

모듈 22(레슨 12)의 이사 비용 판단이 그대로 적용된다. 웨비나가 권한 방법도 같다 — 우리 시스템 목록을 세 그룹으로 나눠 매트릭스를 만든다.

지원 기술의 개수가 아니라 우리 목록의 그룹 분포 가 이관 범위와 비용을 정한다.

PoC 설계 — 비교군이 핵심이다

[PoC 계획서]
목적       야간 회귀 리드타임을 줄일 수 있는지 검증
대상       실제 회귀 세트 1개 (웹 30 TC + SAP 10 TC) — 데모 앱 금지
기준선      시작 전 AS-IS 리드타임을 2회 이상 측정 (모듈 18a 레슨 13 형식)
성공 기준   시작 전에 합의
           - 리드타임 50% 이상 단축
           - AI 생성 자동화의 어서션 누락 0건 (감사 후)
           - 자율 실행 결과 일치율: 5회 반복 중 5회 같은 판정 비율 90% 이상
           - 보안 심의 질문 답변 완료
실패 주입   UI 변경 1회, 데이터 변동, 네트워크 지연
비교군      같은 세트를 Playwright Test Agents 조합으로도 수행
비용       라이선스 + 모델 호출 + 인프라 + 투입 인력 시간
종료 기준   2주차 중간 점검에서 성공 기준 2개 이상이 불가능하면 조기 종료
산출물      측정표, 발견된 제약 목록, 12개월 로드맵 초안

평가표의 가중치는 점수를 보기 전에 정하고 합의한다. 점수를 본 뒤 가중치를 바꾸는 순간 평가표는 결론을 정당화하는 도구가 된다.

다크 테스팅 팩토리 — 성숙도와 사람의 자리

웨비나 로드맵과 UiPath 자료를 합치면 성숙도는 다섯 단계다.

이름은 불을 끄고 돌아가는 무인 공장에서 왔다. UiPath 설명의 요점은 에이전트가 변경 발견·설계·실행·실패 분류·치유·라우팅을 맡고, 사람은 허용 가능한 리스크, 승인 요건, 릴리즈별 완료 정의, 에스컬레이션 조건 을 정한다는 것이다. 테스터를 대체하지 않고 실행에서 품질 리더십으로 역할을 옮긴다고 설명한다. 웨비나는 이 개념을 다음 해 1분기 제품으로 출시할 예정 이라고 했다 — 로드맵이다.

단계를 건너뛸 수는 없다. 2단계의 안정적인 스크립트 자산과 모듈 18c(레슨 7)의 결정 테이블·승인 게이트 없이 5단계로 가면, 공장이 아니라 사고 발생기가 된다.

실무에서 왜 필요한가

도구 도입 결정에 QA가 평가자로 들어간다. 엔터프라이즈 테스트 플랫폼은 금액이 크고 교체 비용도 크다. 데모에 감탄하는 사람이 아니라 기준선·비교군·종료 기준을 갖춘 PoC를 설계하는 사람 이 필요하다. 이 역할을 QA가 맡지 않으면 구매는 벤더 발표와 영업 관계로 결정된다.

확인한 사실과 발표를 구분하는 습관이 신뢰를 만든다. 웨비나 수치 중에는 원자료가 공개된 것과 아닌 것이 섞여 있다. 보고서에서 둘을 섞으면 도입 뒤 기대치가 어긋났을 때 책임이 QA에게 돌아온다. "확인함 / 발표만 들음 / 로드맵" 세 칸을 나눠 쓰는 것만으로 그 위험이 사라진다.

사내망 조직일수록 기능별 확인이 중요하다. "온프레미스 지원"이라는 한 줄 뒤에는 "셀프호스팅 모델은 일부 기능만"이라는 제약이 붙어 있다. 도입 후에 알게 되면 계약은 끝났고 기능은 없다.

이미 가진 자산을 지킨다. 수년간 쌓은 Selenium·Playwright 자산과 테스트 케이스를 버리고 새 플랫폼에 다시 짓자는 제안은 흔하다. 흡수 매트릭스를 들고 가면 이관 비용을 숫자로 비교할 수 있고, 불필요한 재작성을 막을 수 있다.

채용시장에서의 위치

"AI 기반 테스트 자동화 도구 도입 경험", "테스트 도구 선정·PoC 수행" 같은 문구가 QA 리드·자동화 엔지니어 공고에 늘고 있다. 대기업·금융권은 UiPath·Tricentis 같은 엔터프라이즈 플랫폼을, 스타트업은 오픈소스 조합을 쓰는 경우가 많아 양쪽의 동작 원리를 대응시켜 설명할 수 있으면 어느 조직에도 빠르게 적응한다.

면접에서는 이렇게 묻는다. "새 테스트 도구 도입을 제안한다면 어떻게 진행하겠습니까?" 좋은 답은 기준선 측정 → 사전 합의된 성공 기준 → 실패 주입 → 무료 비교군 → 조기 종료 기준 의 순서로 말하는 것이다. 여기에 "벤더 수치는 분모와 측정 조건을 확인한다" 한 문장을 더하면 리드 수준의 답이 된다. UiPath Academy에는 Agentic Testing Specialist 러닝 플랜이 있어 제품 실무를 증명할 수단도 있다.

실습 과제

과제 1 — 우리 팀 유스케이스 지도 (15분)

개념 절의 유스케이스 지도를 우리 팀 상황으로 다시 채운다.

효과는 크고 승인 부담은 작은 것 두 개에 표시한다. 그 둘이 PoC의 대상 후보다.

과제 2 — 벤더 질문 메일 (15분)

웨비나 수치 세 개(현재 6배·12개월 뒤 12배, 자동화율 95%, 회귀 주기 수 주→수 시간)에 사례 수치 검증 질문을 적용해 벤더에게 보낼 질문 메일을 쓴다. 요청과 기한을 맨 위에 둔다.

과제 3 — 이관 매트릭스 (15분)

가상의 은행을 대상으로 매트릭스를 채운다. 시스템은 웹뱅킹, 모바일 앱, SAP 회계, 사내 레거시 대출 심사(전용 클라이언트), Jira. 자산은 엑셀 수동 TC 1,200건, Selenium 스크립트 400개, JMeter 시나리오 15개.

과제 4 — PoC 계획서 (20분)

개념 절의 양식을 과제 3의 은행 기준으로 채운다. 성공 기준은 숫자로, 비교군은 반드시 넣고, 과제 3에서 가장 비싼 칸을 대상에 포함한다.

과제 5 — 비교군 한 조각 체험 (25분, Node 필요)

npm init playwright@latest agents-lab
cd agents-lab
npx playwright init-agents --loop=claude

1. 대상은 https://demo.playwright.dev/todomvc
2. planner에게 "할 일 추가·완료·필터의 핵심 흐름과 경계 조건 테스트 계획"을 요청한다
3. specs/ 의 계획을 사람이 먼저 검토 하고 한 항목을 고친다
4. generator로 코드를 만들고, 테스트마다 동작 수와 expect 수를 센다

어서션이 없거나 "보인다"만 확인하는 테스트가 있다면, 데모 2의 "검증 단계 없음" 경고와 같은 문제가 무료 도구에서도 생긴다는 뜻이다. 도구가 바뀌어도 검토 절차는 같다.

자가 체크리스트

• Katalon·Autify·Test Cloud가 각각 무엇을 상품화했는지 범위로 비교할 수 있다
• Test Cloud를 이루는 구성 요소를 여섯 가지 이상 말할 수 있다
• 라이프사이클 단계별 유스케이스를 문서로 확인된 것과 웨비나에서만 본 것으로 구분할 수 있다
• 데모에서 "검증 단계가 없다"는 경고가 왜 가장 중요한 장면인지 설명할 수 있다
• 로우코드 Agent Builder와 프로코드 에이전트의 대상·도구·공통점을 비교할 수 있다
• 에이전트 가드레일을 에이전트·LLM·도구 세 층으로 설명할 수 있다
• 셀프호스팅 모델 요건(OpenAI V1 호환 API, 검증 통과, 일부 기능만 호환)을 도입 질문으로 바꿀 수 있다
• Playwright Test Agents를 비교군으로 두는 이유와 무료 조합의 한계를 말할 수 있다
• 애널리스트 리포트의 이름·연도·다른 리더를 구분하고 읽는 기준을 적용할 수 있다
• 공개 자료로 확인한 사례 수치와 원자료를 찾지 못한 수치를 구분해 보고할 수 있다
• 시스템 목록을 기본 지원·커넥터 필요·커스텀으로 나눈 이관 매트릭스를 만들 수 있다
• 기준선·사전 성공 기준·실패 주입·비교군·종료 기준을 갖춘 PoC를 설계할 수 있다
• 다크 테스팅 팩토리에서 사람이 정하는 네 가지와, 단계를 건너뛸 수 없는 이유를 설명할 수 있다

흔한 실수

• 데모 앱으로 PoC를 한다. 벤더가 준비한 화면은 잘 돌아가게 만들어져 있다. 우리 회귀 세트, 특히 가장 비싼 레거시 화면으로 한다.
• 기준선 없이 시작한다. 도입 후 숫자만 있으면 개선인지 알 수 없다. AS-IS를 먼저 잰다.
• 리더라는 말만 옮긴다. 같은 리포트에 리더가 여럿이고 시장 정의와 연도가 다르다. 리포트 이름과 발행 시점을 함께 적는다.
• 자동화율의 분모를 묻지 않는다. 95%가 "고른 TC 중 95%"일 수 있다.
• "온프레미스 지원"에서 멈춘다. 셀프호스팅 모델에서 되는 기능이 무엇인지 기능 단위로 확인한다.
• 비교군을 두지 않는다. 무료 대안 대비 얼마나 나은지 보여 주지 못하면 비용을 설명할 수 없다.
• 점수를 본 뒤 가중치를 바꾼다. 평가표가 결론을 정당화하는 도구가 된다.
• 기존 자산을 버리고 다시 짓는다. 흡수 매트릭스로 이관 비용을 먼저 계산한다.
• 로드맵 기능을 계약 근거로 삼는다. 다크 테스팅 팩토리 같은 예정 기능은 출시 여부를 다시 확인하기 전까지 계획에 조건부로만 넣는다.

참고 자료

• UiPath — Agentic testing with Test Cloud — 제품 개요
• UiPath — Test Cloud 출시 보도자료 (2025-03-25) — Cisco 사례와 IDC 조사 수치
• UiPath — Test Cloud 2025.10 release updates — 정식 제공 기능 목록
• UiPath Docs — Autopilot for Testers — 단계별 AI 기능
• UiPath — Agent Builder · Agent guardrails 문서 — 커스텀 에이전트와 가드레일
• UiPath Docs — Automation Suite LLM 지원 — 셀프호스팅 모델 요건
• UiPath — The dark testing factory — 성숙도와 사람의 역할
• UiPath — Gartner MQ 발표 · Forrester Wave 발표 — 애널리스트 평가
• Playwright — Test Agents — 비교군으로 쓰는 planner·generator·healer
• UiPath Academy — Agentic Testing Specialist — 제품 학습 경로