개념
경로를 미리 정하는 실행 vs 찾아가는 실행
앞 레슨에서 절차를 의도로 바꾼 테스트 정의를 만들었다. 그런데 그 정의는 스스로 실행되지 않는다. "주문을 확정한다"를 실제 클릭으로 옮기는 무언가 가 필요하다.
그 역할을 하는 것이 CUA(Computer Use Agent, 컴퓨터 사용 에이전트) 다. 화면을 보고, 맥락을 해석하고, 어떤 컨트롤을 조작할지 판단하고, 예상치 못한 상황에서 복구를 시도하면서 목표를 향해 가는 AI 시스템이다.
기존 자동화 프레임워크와의 차이는 결정이 일어나는 시점 하나로 요약된다.
| Selenium·Playwright | CUA | |
|---|---|---|
| 경로 결정 시점 | 작성 시점(코드에 새겨짐) | 실행 시점(그때 화면을 보고 결정) |
| 화면이 바뀌면 | 실패 → 사람이 코드 수정 | 다시 보고 다른 경로 시도 |
| 예상 못한 팝업 | 실패(명시적으로 처리해둔 것만 통과) | 닫고 계속 진행 가능 |
| 실행 결과 재현성 | 높음(같은 경로) | 낮음(경로가 매번 다를 수 있음) |
| 실행 비용 | 낮음 | 높음 |
| 판단의 폭 | 코드에 쓴 것만 | 넓음(대신 예측이 어려움) |
Selenium이 지도를 미리 그려놓고 그대로 걷는 것 이라면, CUA는 목적지만 알려주고 길은 그때그때 찾게 하는 것 이다. 이 비유는 장점과 단점을 동시에 설명한다. 길이 막혀도 돌아갈 수 있지만, 어제와 오늘 다른 길로 갔을 수 있다.
셀프힐링과는 무엇이 다른가
레슨 3에서 셀프힐링 로케이터 를 배웠다. 셀렉터가 깨지면 AI가 비슷한 요소를 찾아 복구를 시도하는 기술이다. 얼핏 CUA와 비슷해 보이는데, 계층이 다르다.
셀프힐링: [ 절차는 그대로 ] → 깨진 한 단계만 AI가 대체
click(#submit-btn) 실패 → 유사 요소 탐색 → click
CUA: [ 절차 자체가 없음 ] → 목표만 주고 매 단계를 AI가 결정
"주문을 확정한다" → 화면 관찰 → 무엇을 눌러야 할지 판단 → 실행즉 셀프힐링은 기존 절차의 구멍을 메우는 보수 공사 이고, CUA는 절차를 없애고 목표만 남기는 구조 변경 이다. 셀프힐링에는 여전히 "원래 무엇을 클릭하려 했는지"가 코드에 남아 있어서 복구의 기준이 되지만, CUA에는 그 기준이 테스트 정의의 의도 밖에 없다. 그래서 의도를 얼마나 잘 썼는지가 곧 실행 품질이 된다.
레슨 5의 Agentic Testing 과의 관계도 정리해두자. Agentic Testing은 관찰-계획-실행-검증 루프라는 사고 틀 이고, CUA는 그 루프를 실제 화면 위에서 돌리는 실행 주체 다. 개념과 구현체의 관계다.
의도 기반 테스트 정의는 어떻게 생겼나
CUA에게 넘길 산출물은 테스트 코드가 아니라 구조화된 테스트 정의 다. 이 형식을 표준화하려는 시도가 있고, 오픈소스 스키마(OpenTest.AI 형식 등)는 대체로 다음 필드들로 테스트를 쪼갠다.
| 필드 | 담는 것 |
|---|---|
| Title | 테스트의 이름 |
| Goal | 이 테스트가 달성하려는 결과 |
| Description | 맥락·배경 설명 |
| Thinking | 이 단계를 왜 이렇게 하는지에 대한 추론 |
| Action | 수행할 동작(의도 수준) |
| Target | 동작의 대상 |
| Value | 입력할 값·파라미터 |
| Expected Outcome | 무엇을 보면 성공인가 |
실제로 써보면 이런 모양이 된다.
title: 신규 고객이 첫 주문을 완료한다
goal: 회원가입한 신규 고객이 장바구니에 담은 상품을 결제까지 마칠 수 있다
description: >
프로모션 기간에 신규 가입 쿠폰이 자동 적용되는 흐름을 포함한다.
쿠폰은 회원가입 후 24시간 내에만 유효하다.
steps:
- thinking: >
신규 고객은 배송지가 없는 상태이므로 결제 단계에서 배송지 입력
화면이 먼저 뜬다. 기존 고객 흐름과 여기서 갈라진다.
action: 결제를 진행한다
target: 장바구니 화면의 결제 진행 수단
value: null
expected_outcome: 배송지 입력 화면이 나타난다
- thinking: >
쿠폰이 자동 적용되는지가 이 테스트의 핵심이다. 사용자가 직접
쿠폰을 선택하지 않아도 총액에 반영되어야 한다.
action: 주문을 확정한다
target: 결제 확인 화면
value: null
expected_outcome: >
주문 완료 화면이 나타나고, 결제 금액은 상품 합계에서 신규 가입
쿠폰 할인이 빠진 값이며, 정확히 계산된 금액과 일치한다.Thinking 필드가 이 형식의 핵심이다
여덟 개 필드 중 가장 낯선 것이 thinking이다. 그리고 가장 중요하다.
전통적인 자동화는 행동을 기록 한다. 의도 기반 정의는 추론을 기록 한다. 이 차이가 실행 시점에 드러난다.
배송지 입력 화면이 뜨지 않고 바로 결제 화면이 떴다고 하자.
thinking이 없으면: CUA는 "어? 예상과 다르네" 하고 그냥 진행하거나 실패로 처리한다.thinking이 있으면: "신규 고객이라 배송지가 없어야 하는데 배송지 화면이 안 떴다 → 이 계정이 신규가 아니거나, 배송지가 이미 있다 → 테스트 전제가 깨졌다"고 판단할 수 있다.
즉 thinking은 실패의 원인을 가르는 근거 를 실행 시점에 제공한다.
모듈 6에서 배운 좋은 버그 리포트의 조건 — "무엇을 기대했고 왜 그렇게
기대했는가" — 이 테스트 정의 안으로 들어온 것으로 봐도 된다.
QA 실무에서 이 필드가 갖는 또 다른 값은 인수인계 다. 3년 뒤에 이 테스트를 보는 사람은 코드가 아니라 이 문장을 읽는다.
검증이 넓어진다 — 그리고 흐려진다
CUA 기반 실행은 검증의 폭을 넓힌다. 기존 자동화가 하기 어려웠던 판정이 가능해지기 때문이다.
| 판정 유형 | 기존 자동화 | CUA |
|---|---|---|
| 텍스트 정확 일치 | 쉬움 | 가능 |
| 숫자 계산 검증 | 쉬움 | 가능(단, 정확 비교로 지시해야) |
| "이 화면이 시각적으로 깨져 보이는가" | 시각 회귀 도구 필요, 오탐 많음 | 판정 가능 |
| "이 흐름이 사용자에게 혼란스러운가" | 사실상 불가능 | 판정 가능(주관적) |
| "성공한 것처럼 보이는가" | 불가능 | 가능 |
마지막 두 줄이 새로 열리는 영역이다. 이전에는 사람이 직접 봐야만 알 수 있어서 자동화 대상이 아니었던 것들이다.
그런데 여기에 함정이 있다. 넓어진 만큼 흐려진다. "혼란스러운가"는 판정 기준이 사람마다 다르고, 같은 모델도 실행마다 다르게 답할 수 있다. 모듈 18b(레슨 5)에서 배운 원칙이 그대로 필요하다 — 판단이 개입하는 검증은 한 번의 결과로 확정하지 않고, 반복 실행과 통과율로 다룬다.
실무 규칙으로 정리하면 이렇다.
정확해야 하는 것은 정확히 지시하고, 판단이 필요한 것만 판단에 맡긴다. 금액·재고 수량·권한 여부는
expected_outcome에 정확한 비교로 쓴다. 레이아웃 붕괴·문구의 자연스러움은 판단에 맡기되, 실패했을 때 곧바로 빌드를 깨지 말고 사람 확인 큐로 보낸다.
이건 모듈 18b 레슨 8에서 만든 정량 게이트와 정성 게이트의 분리 와 정확히 같은 구조다.
언제 CUA를 쓰고 언제 쓰지 말아야 하는가
가장 중요한 실무 판단이다. 전부를 CUA로 옮기는 것도, 전부를 스크립트로 남기는 것도 답이 아니다.
| 상황 | 권장 | 이유 |
|---|---|---|
| UI가 자주 바뀌는 화면의 회귀 테스트 | CUA | 유지보수 비용이 가장 큰 영역 |
| 탐색적 테스트의 자동 확장 | CUA | 경로를 미리 정할 수 없는 성격 |
| 접근성·시각적 이상 점검 | CUA | 기존에 자동화가 어려웠던 판정 |
| 금액·정산·세금 계산 검증 | 스크립트 | 정확성이 절대적, 판단 여지가 없어야 함 |
| 매 커밋 실행되는 스모크 테스트 | 스크립트 | 속도·비용·재현성이 지배적 |
| 규제·인증 증거로 제출할 검증 | 스크립트 | 실행 경로의 추적 가능성이 요구됨 |
| 성능 측정 | 스크립트 | 에이전트의 판단 시간이 측정값을 오염시킴 |
| 장애 재현·디버깅 | 스크립트 | 같은 경로를 반복해야 원인을 좁힐 수 있음 |
표의 오른쪽 열을 관통하는 기준은 하나다. 재현성과 정확성이 중요할수록 스크립트, 변화 적응력과 판단의 폭이 중요할수록 CUA.
모듈 11에서 배운 자동화 피라미드에 얹어 생각하면 이해가 쉽다. 피라미드 아래쪽(단위·API)은 결정적이어야 하고, 위로 갈수록 사람의 판단에 가까운 검증이 필요해진다. CUA는 피라미드 꼭대기를 넓히는 도구이지, 피라미드 전체를 대체하는 것이 아니다.
도구 지형은 계속 바뀐다
CUA 영역의 도구는 빠르게 바뀌는 중이다. 상용·오픈소스 도구가 계속 등장하고 사라진다. 그래서 특정 도구 이름을 외우는 것은 의미가 적다.
중요한 것은 실행 모델 자체가 바뀌고 있다 는 사실이다. 어떤 도구가 이기든, "경로를 코드에 새기는 방식"과 "목표를 주고 런타임에 판단하게 하는 방식"이 공존하는 구도는 유지될 가능성이 높다. 그렇다면 QA가 준비할 것은 도구 사용법이 아니라 둘을 가르는 판단 기준과, 판단에 맡긴 검증을 신뢰할 수 있게 만드는 방법 이다.
그래서 자동화 엔지니어는 사라지는가
이 질문을 정면으로 다루자. 이 흐름이 없애는 것과 남기는 것은 분명하다.
줄어드는 일
- 셀렉터를 고치는 일
- 대기 시간을 조정하는 일
- UI 변경마다 페이지 객체를 갱신하는 일
- 오탐(false failure)을 조사하는 일
늘어나는 일
- 무엇이 중요한지 정의하는 일 — 어떤 시나리오가 사업에 치명적인가
- "성공"을 판정 가능한 문장으로 만드는 일
- 정확해야 할 것과 판단에 맡길 것을 가르는 일
- AI의 판정을 검증하는 일 — 모듈 18c 전체가 이 능력을 다룬다
- 비결정적 결과를 통계로 다루고 신뢰 구간을 말하는 일
앞의 목록은 도구가 대신할 수 있는 일 이고, 뒤의 목록은 제품과 도메인을 이해해야만 할 수 있는 일 이다. 개발 쪽에서 "코드만 쓰는 개발자에서 제품 맥락을 이해하는 개발자로"라는 말이 도는 것과 같은 이동이, 테스트 쪽에서는 이렇게 나타난다.
자동화 엔지니어의 정의가 "테스트를 실행하는 코드를 쓰는 사람" 에서 "무엇을 신뢰할 수 있다고 말할지 정의하고, 그 판단을 검증하는 사람" 으로 이동한다.
주의할 것은 이 이동이 모두에게 좋은 소식은 아니라는 점 이다. 스크립트 작성 숙련도만으로 경쟁하던 자리는 실제로 줄어든다. 반면 도메인 이해, 리스크 판단, 검증 설계 능력을 갖춘 사람의 자리는 넓어진다. 이 커리큘럼이 자동화 도구보다 테스트 설계(모듈 3)와 리스크(모듈 4), 개발 지식(모듈 9) 을 앞에 둔 이유가 여기에 있다.
레슨 14는 이 판단을 제품화된 두 실행 모드 — 수동 테스트 단계를 에이전트가 읽고 바로 실행하는 자율 실행 과, 요구사항만 받고 시나리오까지 만드는 자율 탐색 — 를 팀이 운영하는 절차로 이어간다. 결과 일치율을 재고, 명세에 없는 기대값을 사양 질문으로 돌리는 법이 거기서 나온다.
실무에서 왜 필요한가
당장 CUA를 도입하지 않더라도 이 레슨의 사고 틀은 바로 쓸 수 있다.
테스트를 쓸 때 thinking에 해당하는 내용을 주석이나 문서로 남기는
습관 이 그것이다. "왜 이 단계가 필요한지"가 남아 있는 테스트는 사람이
유지보수할 때도 훨씬 오래 산다.
판단 기준 표도 즉시 유용하다. 팀에서 "이건 AI에게 맡길까"라는 논의가 나올 때, 재현성·정확성·비용이라는 세 축으로 나눠 얘기하면 취향 논쟁이 설계 논의로 바뀐다.
그리고 이 레슨은 비용 구조를 미리 계산해두라는 경고 이기도 하다. CUA 기반 실행은 실행마다 판단이 들어가므로 CI에서 수천 개를 매 커밋 돌리는 용도로는 대개 맞지 않는다. 야간 회귀, 릴리즈 전 확인, 탐색적 확장처럼 빈도가 낮고 가치가 높은 실행 에 배치하는 것이 현실적인 출발점이다.