자율 실행과 자율 탐색: 스크립트 없이 돌리는 테스트를 운영 가능한 절차로 만들기

개념

레슨 10에서 무엇을 배웠고, 여기서 무엇을 더하나

레슨 10에서 컴퓨터 사용 에이전트(CUA)가 실행 시점에 화면을 보고 경로를 찾아간다는 것, 그리고 언제 CUA를 쓰고 언제 스크립트를 남길지 판단하는 기준표를 배웠다. 의도 기반 테스트 정의의 thinking 필드도 거기서 다뤘다.

그 사이 이 개념은 테스트 관리 도구 안의 버튼 이 됐다. 2026년 9월 UiPath Test Cloud 웨비나는 두 기능을 시연했다.

버튼이 생기면 새로운 문제가 생긴다. 누구나 누를 수 있으니, 팀 전체가 같은 방식으로 믿고 쓸 수 있는 절차가 필요하다. 이 레슨은 판단 기준(레슨 10)을 운영 절차로 바꾸는 법을 다룬다. 특정 제품의 사용법이 아니라 어느 도구에서나 통하는 절차이고, 실습은 무료 도구로 재현한다.

세 가지 모드 — 레시피 비유

웨비나는 실행 모드를 요리에 빗댔다.

그리고 결론은 "세 영역을 모두 가져가야 한다" 였다. 금융·의료·공공처럼 규제가 엄격한 곳은 자동화와 증강부터 시작하라는 권고도 붙었다. 레슨 10의 판단표와 정확히 같은 결론이다.

사라지는 단계, 옮겨가는 비용

전통적 자동화   ① 수동 TC 정의 → ② 스크립트로 변환 → ③ 실행
자율 실행       ① 수동 TC 정의 ─────────────────→ ③ 에이전트가 읽고 바로 실행
자율 탐색       (요구사항·의도) ─────────────────→ 에이전트가 시나리오까지 만들어 실행

자율 실행은 ②를 없애고, 자율 탐색은 ①까지 없앤다. 그런데 사라진 단계의 일은 없어진 게 아니라 실행 시점으로 옮겨갔다. 매 실행마다 화면을 읽고 판단하므로 느리고, 모델 호출 비용이 들고, 결과가 실행마다 조금씩 다를 수 있다. 발표자도 데모 영상이 실제 속도보다 빠르게 편집됐다고 밝혔다.

이 비용이 이 레슨의 절차 전체를 정한다. 느리고 비싸고 흔들리는 실행을 어떻게 믿을 만하게 만들 것인가.

자율 실행 — 제품 문서로 본 실제 모습

UiPath Test Manager의 Autonomous Test Execution 문서를 보면, 버튼 뒤에 무엇이 필요한지가 드러난다.

그리고 문서에 이런 경고가 있다.

사람 테스터를 위해 쓴 수동 단계는 에이전트에게 충분히 명확하지 않을 수 있다.

웨비나 데모도 이 경고를 그대로 보여줬다. 대출 신청 화면의 수동 TC를 실행하자 에이전트가 단계별로 스크립트를 만들며 값을 입력했고, 일부 단계는 실패 했다. 성공한 단계는 생성된 스크립트와 단계별 스크린샷으로 남았다. 발표 시점은 사람이 옆에서 지켜보는 Assisted 방식이었고, 사람 없이 도는 Unassisted 방식은 곧 제공될 예정이라고 했다.

에이전트가 실행할 수 있는 수동 단계 쓰기

사람은 맥락으로 채우는 빈칸을 에이전트는 추측 으로 채운다. 그리고 추측은 실행마다 달라진다. 모듈 2에서 배운 "테스트 가능한 요구사항"의 조건이 이제 테스트 케이스 자체에 요구되는 것이다.

사람용으로 쓴 단계

1. 대출 신청 페이지로 이동한다
2. 적절한 대출 상품을 선택한다
3. 필수 정보를 입력한다
4. 신청한다
5. 정상 접수되는지 확인한다

에이전트용으로 다시 쓴 단계

사전 조건: 테스트 계정으로 로그인된 상태
 
1. 상단 메뉴에서 "대출 신청"을 클릭한다
   기대: 제목이 "기업 대출 신청"인 화면이 보인다
2. "대출 상품" 드롭다운에서 "운전자금 대출"을 선택한다
   기대: "신청 금액" 입력란이 활성화된다
3. "신청 금액"에 50000000 을 입력한다
4. "자금 용도"에 "원자재 구매"를 입력한다
5. "연 매출"에 1200000000 을 입력한다
6. "신청하기" 버튼을 클릭한다
   기대: "접수가 완료되었습니다" 문구와 "LN-" 로 시작하는 접수번호가 보인다
   기대: 입력 폼이 비워진다

마지막 단계의 두 번째 기대 "입력 폼이 비워진다"를 기억해 두자. 명세에 없던 기대를 사람이 적는 순간 결함 판정이 가능해진다. 뒤의 자율 탐색 데모에서 바로 이 지점이 문제가 된다.

결과 일치율 — 도입 전에 반드시 재는 숫자

모듈 18b(레슨 5)에서 비결정적 출력은 한 번이 아니라 여러 번 돌려서 본다고 배웠다. 자율 실행도 똑같다. 테스트 스위트에 넣기 전에 같은 TC를 3~5회 돌린다.

결과 일치율이 낮은 TC를 자율 실행 스위트에 넣는 것은 플래키 테스트를 대량 생산하는 것과 같다. 모듈 14(레슨 5)에서 CI의 False Alarm이 신호 전체의 신뢰를 무너뜨린다고 배웠다. 자율 실행은 그 위험을 더 키운다. 실패가 났을 때 "에이전트가 흔들린 건지, 제품이 깨진 건지"를 매번 사람이 가려야 하기 때문이다.

실무 기준 하나를 제안하면 이렇다. 5회 중 5회 같은 판정이 나온 TC만 자율 실행 스위트에 넣는다. 4회 이하라면 단계를 다시 쓰거나 스크립트로 옮긴다.

규제 환경의 패턴 — 자율로 초안을 얻고, 스크립트로 증거를 남긴다

레슨 10의 판단표에서 "규제·인증 증거로 제출할 검증은 스크립트"라고 했다. 그렇다고 규제 산업이 자율 실행을 전혀 못 쓰는 것은 아니다. 실무에서 쓰는 패턴은 이렇다.

1. 새 기능의 수동 TC를 에이전트용으로 다듬는다
2. 자율 실행으로 돌려 성공한 실행을 얻는다 (단계별 스크립트·스크린샷이 남는다)
3. 성공한 실행을 결정적 스크립트로 고정한다
4. 고정된 스크립트를 리뷰하고, 기대 결과마다 어서션이 있는지 확인한다
5. 감사 증거로는 고정된 스크립트의 실행 결과를 쓴다

4번이 빠지면 모듈 18c(레슨 3)의 항상 통과하는 가짜 테스트 가 증거로 제출된다. 에이전트가 만든 스크립트는 입력은 꼼꼼히 하는데 확인을 빼먹는 경우가 흔하다. 웨비나의 코드 생성 데모에서도 도구가 먼저 "화면 중간 검증 단계가 없다"고 경고했다.

자율 탐색 — 웨비나 데모 해부

자율 탐색은 한 걸음 더 간다. 단계조차 주지 않는다. 이 기능은 공개 문서에서 설명을 찾지 못했으므로, 아래는 웨비나 데모에서 보여준 흐름이다. 도입을 검토한다면 제공 상태부터 확인해야 한다.

대상       발표자가 만든 테스트용 사이트 (탭 6~7개, 탭마다 별도 기능)
요구사항   "운전자금 대출을 신청할 수 있어야 한다"
추가 지시   핵심 사용자 여정, 경계 조건, 엣지 케이스를 식별하고 스스로 추론해 탐색하라
          + "생성된 시나리오는 한글로 설명해 주세요" (기본 출력이 영어였다)
설정       테스트 URL · 시간 상자 30분(최대 60분) · 모델 · 라이브 스트리밍 · 테스트 로봇
진행       실행 로그와 함께 시나리오 목록이 생성됨
결과       시나리오 6건 — 완료 2, 사람이 건너뜀 3, 나머지에서 발견

모듈 5(레슨 1)에서 배운 시간 상자 안의 탐색 이 에이전트에게 그대로 넘어갔다. 차터(레슨 2)는 요구사항과 추가 지시가 대신한다. 데모에서 소개된 발견 두 가지를 QA 눈으로 다시 보자.

발견 A — 신청 후 폼이 초기화되지 않는다. 결함인가?

에이전트는 "신청 완료 후에도 입력값이 남아 있다 — 초기화 미작동"을 실패로 보고했다. 발표자는 사이트를 만들 때 제출 후 초기화를 넣지 않았다고 설명했다.

그런데 요구사항 원문은 "운전자금 대출을 신청할 수 있어야 한다"뿐이다. 제출 후 폼 상태에 대한 기준이 없다. 입력값을 남기는 것이 의도일 수도 있다 — 비슷한 신청을 연속으로 넣는 사용자를 위한 편의 기능으로.

기대값이 명세에 없으면 결함이 아니라 사양 질문이다. 이것을 결함으로 등록하면 개발팀은 "사양입니다"로 닫고, 에이전트 발견 전체의 신뢰가 깎인다. 그렇다고 무시하면 숨은 위험을 놓친다. 올바른 처리는 이렇다.

유형   사양 질문
질문   신청 완료 후 입력 폼을 비워야 합니까, 유지해야 합니까?
근거   제출 후에도 이전 입력값이 그대로 남아 있음 (스크린샷 첨부)
위험   유지할 경우 같은 내용으로 중복 신청될 수 있음 → 중복 제출 방지 여부도 확인 필요
요청   수용 기준에 제출 후 폼 상태를 명시

모듈 2에서 배운 "요구사항의 빈틈을 질문으로 바꾸는 능력"이 에이전트 발견을 다룰 때 가장 많이 쓰인다. 에이전트는 빈틈을 대량으로 찾아내고, 사람은 그 빈틈을 질문으로 바꾼다.

발견 B — 숫자 필드에 문자가 들어간다. 어느 층의 결함인가?

에이전트는 스스로 "숫자 입력 데이터 형식 유효성 검증" 시나리오를 만들었다. 연 매출에 abc!, 신청 금액에 deff 같은 문자를 넣었더니 접수 완료 화면이 떴다.

이것은 사양 질문이 아니다. 금액 필드가 문자를 받는 것을 의도하는 명세는 없다. 결함이다. 다만 리포트를 쓰기 전에 한 걸음 더 간다 — 에이전트는 화면 까지만 봤다.

□ 화면 검증만 빠졌나, 서버도 받아들였나?   → 같은 값을 API로 직접 전송 (모듈 12)
□ 저장된 값은 무엇인가?                   → 조회 API 또는 DB 확인
□ 다른 숫자 필드도 같은가?                 → 동등 분할로 확장 (모듈 3)

서버까지 문자열을 받아 저장했다면 데이터 정합성 결함 으로 심각도가 올라간다. 화면 검증만 빠졌고 서버가 거절했다면 사용성 결함에 가깝다. 모듈 5(레슨 10)의 "사용자 화면이 없는 곳 탐험"이 에이전트 발견의 후속 확인으로 그대로 쓰인다.

미션 프롬프트 — 요구사항에 닻을 내린다

데모의 추가 지시는 일반적이었다. 실무에서는 모듈 5(레슨 2)의 차터를 요구사항에 묶어 미션 으로 쓴다.

[자율 탐색 미션]
요구사항   REQ-LOAN-003 "운전자금 대출을 신청할 수 있어야 한다"
수용 기준  - 신청 금액 1천만~10억 원
           - 연 매출·금액은 숫자만
           - 신청 완료 시 LN- 접수번호 표시
관점       핵심 여정 / 경계값 / 입력 형식 / 중복 제출 / 새로고침·뒤로가기
제외       다른 탭(세금계산서, 지원사업), 관리자 화면
금지       외부 발송, 운영 URL 접근, 계정 설정 변경
데이터     금액·매출은 테스트용 값만. 실제 개인정보처럼 보이는 값 입력 금지
시나리오    최대 8개. 실행 전에 목록을 먼저 제시하라
출력       시나리오와 발견은 한국어. 발견마다 유형(결함/사양 질문/관찰),
           재현 절차, 기대, 실제, 증거
시간 상자   20분

수용 기준이 있으면 발견 A 같은 애매함이 줄고, 발견 B는 판정이 명확해진다. 요구사항의 품질이 탐색의 품질을 정한다. 에이전트 탐색 전에 요구사항 품질 평가(레슨 12의 테스트 분석)를 먼저 돌리는 것이 순서다.

시간 상자와 시나리오 편집 — 사람은 편집자다

데모에서 발표자는 생성된 시나리오 중 세 개를 건너뛰었다. 이게 사람의 자리다.

시간 상자는 긴 것 하나보다 짧은 것 여러 개 가 낫다. 처음 도입할 때는 1015분으로 돌리고 결과를 본 뒤 미션을 고친다. 요구사항 하나에 2030분이면 데모 수준이다. 기능 영역 전체라면 요구사항별로 세션을 쪼갠다. 모듈 5(레슨 13)의 "언제 충분한가"라는 질문이 세션 단위로 반복된다.

발견을 네 칸으로 나누고, 자산으로 바꾼다

"에이전트에게 결함인지 다시 물어보기"는 분류가 아니다. 명세에 없는 기대값은 같은 에이전트도 모른다. 다시 물으면 그럴듯한 답이 돌아올 뿐이다.

분류가 끝나면 탐색 결과를 한 번 쓰고 버리지 않는다.

자율 탐색 세션
   ├─ 결함 ──────▶ 결함 리포트 ──▶ 수정 후 결정적 회귀 테스트로 고정
   ├─ 사양 질문 ──▶ 수용 기준 보강 ──▶ 다음 미션의 검증 기준으로
   └─ 오탐 ──────▶ 미션·데이터 규칙 수정
 
다음 세션: 이미 회귀로 고정된 영역은 제외하고 새 관점으로 이동

이 순환이 없으면 매 세션이 같은 발견을 비용을 내고 다시 찾는다.

운영 지표

실무에서 왜 필요한가

버튼이 절차를 대신해 주지 않는다. 자율 실행·자율 탐색은 누구나 누를 수 있다. 그래서 팀마다 다른 방식으로 쓰고, 다른 기준으로 결과를 믿는다. "에이전트가 실패라고 했다"는 한 사람의 결함 티켓과 "에이전트가 통과라고 했다"는 다른 사람의 릴리즈 승인이 같은 주에 나온다. 결과 일치율 기준과 발견 분류 절차가 있어야 도구의 결과가 팀의 신호 가 된다.

사양 질문을 잘 쓰는 QA가 협업 병목을 줄인다. 에이전트 탐색은 요구사항의 빈틈을 사람보다 훨씬 많이 찾아낸다. 그 빈틈을 결함으로 던지면 개발팀과의 갈등이 늘고, 무시하면 위험이 묻힌다. 질문·근거·위험·요청의 형식으로 기획에 돌려주는 능력이 에이전트 시대에 오히려 더 자주 쓰인다. 웨비나 Q&A에서도 "요구사항 관리팀·개발팀과의 협업이 늘 병목이었다"는 질문이 나왔다.

비용이 보이지 않게 새는 것을 막는다. 자율 실행은 매 실행마다 모델을 호출한다. 하루 스무 번 도는 회귀를 자율 실행으로 바꾸면 비용과 시간이 조용히 불어난다. 레슨 13의 리드타임 계산과 이 레슨의 실행 시간 지표를 함께 보면, 어디에 쓰는 것이 이득인지 숫자로 말할 수 있다.

감사 증거를 지킨다. 규제 산업에서 "에이전트가 확인했다"는 증거가 되지 않는다. 자율 실행 결과를 결정적 스크립트로 고정하고 어서션을 검토하는 절차가 있어야 새 기능 테스트를 빠르게 하면서도 증거 요구를 맞출 수 있다.

실습 과제

과제 1 — 수동 TC를 에이전트용으로 다시 쓰기 (15분)

우리 서비스(또는 자주 쓰는 웹사이트의 회원가입·검색 기능)의 수동 TC 두 개를 개념 절의 규칙대로 다시 쓴다. 다시 쓰기 전과 후에 모호한 표현 의 개수를 센다 — "적절히", "정상적으로", "확인한다", "필요한 정보".

과제 2 — 결과 일치율 재기 (25분, AI 도구 사용 시)

Claude Code·Cursor 같은 도구에 Playwright MCP를 연결하고(레슨 7), 과제 1에서 다시 쓴 TC를 그대로 준다.

너는 수동 테스트 케이스를 실행하는 에이전트다.
- 단계를 순서대로 수행하고 각 기대 결과를 확인해 PASS/FAIL을 기록하라.
- 단계에 없는 행동은 하지 마라. 막히면 멈추고 이유를 적어라.
- 결과는 step, action, expected, actual, result 필드를 가진 JSON 배열로 출력하라.

같은 TC를 세 번 실행하고 결과 일치율, 경로 차이, 실행 시간을 기록한다. 도구가 없다면 AI 실습 도우미에 TC와 화면 설명을 주고 "다음에 무엇을 하겠느냐"를 묻는 방식으로 한 번만 해 본다.

과제 3 — 미션 쓰고 시나리오 편집하기 (15분)

요구사항 하나를 골라 개념 절의 미션 양식을 모두 채운다. 수용 기준은 화면을 보고 본인이 가정해서 세 개 이상 쓰되, 가정이라고 표시한다. AI 도구에 미션을 주고 실행하지 말고 시나리오 목록만 받은 뒤 건너뛰기 기준으로 편집한다.

과제 4 — 발견 네 칸 분류 (15분)

아래 가상의 탐색 발견 다섯 건을 결함·사양 질문·오탐·환경으로 분류하고, 사양 질문 한 건은 질문·근거·위험·요청 형식으로 쓴다.

F1  신청 금액에 -50000000 입력 시 접수 완료됨
F2  신청 완료 후 브라우저 뒤로가기 → 같은 신청이 한 번 더 접수됨
F3  "대출 상품" 드롭다운을 찾지 못해 시나리오 중단 (다른 탭 화면에서 찾고 있었음)
F4  접수번호 조회 API가 503 응답 (테스트 환경의 조회 서버 점검 공지 있음)
F5  신청 완료 후 입력한 값이 폼에 그대로 남아 있음

자가 체크리스트

• 자율 실행과 자율 탐색이 사람에게서 받는 입력의 차이를 설명할 수 있다
• 자동화·증강·자율 테스트를 사람이 주는 것과 실행 주체로 구분할 수 있다
• 없어진 스크립트 작성 비용이 실행 시점의 속도·비용·비결정성으로 옮겨감을 설명할 수 있다
• 사람용 수동 단계가 에이전트에게는 모호할 수 있다는 문서 경고의 의미를 안다
• 한 단계 한 동작, 보이는 이름, 명시 값, 관찰 가능한 기대 결과로 TC를 다시 쓸 수 있다
• 자율 실행 도입 전에 결과 일치율과 경로 일치율을 측정할 수 있다
• 규제 환경에서 자율 실행 결과를 결정적 스크립트로 고정해 증거로 쓰는 절차를 설명할 수 있다
• 명세에 없는 기대값을 결함이 아니라 사양 질문으로 분류하고 형식에 맞게 쓸 수 있다
• 에이전트의 화면 수준 발견을 API·저장 데이터 층으로 확인할 수 있다
• 요구사항·수용 기준·관점·제외·금지·출력 형식을 갖춘 탐색 미션을 쓸 수 있다
• 생성된 시나리오를 건너뛰기 기준으로 편집할 수 있다
• 발견을 결함·사양 질문·오탐·환경으로 나누고 회귀 자산으로 바꾸는 순환을 그릴 수 있다

흔한 실수

• 사람용 TC를 그대로 자율 실행에 넣는다. 에이전트는 빈칸을 추측으로 채우고, 추측은 실행마다 다르다. 결과가 흔들리면 도구가 아니라 단계부터 의심한다.
• 한 번 통과했다고 스위트에 넣는다. 비결정적 실행은 여러 번 돌려야 믿을 수 있다. 결과 일치율을 재지 않은 자율 실행은 플래키 테스트 공장이 된다.
• 에이전트 발견을 그대로 결함으로 등록한다. 명세에 없는 기대값은 사양 질문이다. "사양입니다"로 닫히는 티켓이 쌓이면 에이전트 발견 전체가 무시당한다.
• 에이전트에게 결함인지 다시 묻는다. 같은 모델은 명세에 없는 정답을 모른다. 판정 기준은 명세와 기획의 답에서 온다.
• 화면에서 멈춘다. 에이전트는 화면을 본다. 서버가 받아들였는지, 무엇이 저장됐는지는 QA가 한 층 더 내려가 확인한다.
• 생성된 시나리오를 전부 돌린다. 편집하지 않으면 이미 커버된 흐름과 위험한 행동에 시간과 비용을 쓴다. 사람은 편집자다.
• 시간 상자를 길게 하나로 잡는다. 60분 한 번보다 15분 네 번이 낫다. 세션마다 미션을 고칠 기회가 생긴다.
• 자율 실행이 만든 스크립트를 리뷰 없이 증거로 쓴다. 입력만 하고 확인하지 않는 가짜 테스트가 흔하다. 기대 결과마다 어서션이 있는지 반드시 본다.

참고 자료

• UiPath Docs — Running Autonomous Test Execution — Run with Autopilot의 입력 항목과 모호한 수동 단계에 대한 경고
• UiPath — Agentic testing with Test Cloud — 자율 실행·자율 탐색을 포함한 제품 개요
• Playwright MCP — 자율 실행 원리를 무료로 재현하는 브라우저 도구
• Playwright — Test Agents — 앱을 탐색해 계획을 쓰는 planner 에이전트
• Session-Based Test Management — 세션·차터·시간 상자의 원전 (모듈 5)