개념
개념에서 상품으로
모듈 18-A(레슨 3)에서 셀프힐링 로케이터의 동작 원리를 배웠다. 원래 로케이터로 요소를 못 찾으면 AI가 화면의 다른 요소들을 분석해 "가장 비슷한 것"을 추정해 대신 실행한다는 개념이었다. Autify 는 이 개념을 완전 노코드 SaaS 제품으로 구현한 도구다.
모듈 24 레슨 1의 Katalon이 "녹화 + 필요하면 코드로 내려가는" 하이브리드 포지셔닝이었다면, Autify는 코드로 내려갈 필요를 거의 없애는 쪽을 지향한다. 브라우저 조작을 녹화해 테스트를 만들고, 화면이 바뀌면 AI가 알아서 로케이터를 갱신하는 흐름을 사람의 개입 없이 최대한 자동으로 돌아가게 설계했다.
| Katalon (레슨 1) | Autify | |
|---|---|---|
| 코드 접근 | 스크립트 모드로 언제든 내려갈 수 있다 | 코드 없이 완결되는 걸 지향 |
| 유지보수 방식 | Object Repository를 사람이 관리 | AI가 로케이터 변경을 자동 감지·제안 |
| 잘 맞는 팀 | 코딩 역량이 자라날 여지가 있는 팀 | 유지보수 인력을 최소화하고 싶은 팀 |
셀프힐링이 실제로 뭘 하는 것처럼 보이는가
배포마다 화면이 조금씩 바뀌는 서비스를 생각해보자. 버튼의 CSS 클래스가
바뀌거나, DOM 구조에 div가 하나 더 끼워지는 정도의 변화는 흔하다.
이런 변화가 생기면:
1. Autify가 저장된 로케이터로 요소를 찾으려 시도한다
2. 실패하면, 텍스트·위치·역할이 비슷한 요소를 AI가 탐색한다
3. 후보를 찾으면 그걸로 실행을 이어가고, "이 단계에서 로케이터가
자동으로 갱신됐다"는 표시를 결과 화면에 남긴다
4. 사람이 그 갱신을 검토하고 승인하거나 되돌릴 수 있다이 흐름은 모듈 18-A(레슨 3)에서 배운 동작 원리와 구조적으로 같다. 차이는 이게 로그 파일 안의 개념이 아니라, 실행이 끝난 뒤 바로 볼 수 있는 화면 UI로 제공된다는 점이다 — "몇 번째 실행에서, 어느 단계가, 어떻게 갱신됐는지"를 사람이 클릭 몇 번으로 확인할 수 있다.
AI가 "고쳤다"는 걸 무조건 믿으면 안 되는 이유
모듈 18-A(레슨 3)에서 이미 배운 원칙 — AI가 비슷한 요소를 찾았다는 것이, 그게 진짜 맞는 요소라는 보장은 아니다 — 이 Autify 같은 상용 도구에서는 더 조용히, 더 자주 일어날 수 있다. 왜냐하면 노코드 제품일수록 "이번에도 통과했다"는 초록불만 보고 넘어가기 쉽고, 그 초록불 뒤에서 로케이터가 몇 번이나 자동으로 바뀌었는지는 일부러 클릭해서 들여다보지 않으면 드러나지 않기 때문이다.
> "장바구니 담기" 버튼이 사라지고 그 자리에 "찜하기" 버튼이 새로
> 생겼다고 하자. 두 버튼 모두 같은 위치, 비슷한 크기, 파란 배경이다.
> Autify는 위치·스타일 유사성을 근거로 이걸 "장바구니 담기"의
> 대체품으로 판단하고 계속 클릭할 수 있다 — 테스트는 초록불로
> 남지만, 실제로는 전혀 다른 기능을 누르고 있는 것이다.이런 상황에서 진짜 위험한 건 테스트가 실패하는 게 아니라 아무도 실패를 보지 못한다는 것 이다. 로케이터가 자동으로 "복구"되는 순간, 원래 있어야 할 버튼이 사라졌다는 진짜 문제 자체가 조용히 묻힌다.
안전하게 쓰는 법
- 실행 결과에서 "자동 갱신됨" 표시가 있는 단계를 정기적으로 훑어본다
(매 실행마다는 못 하더라도, 최소 주 1회는 검토 루틴을 정한다)
- 결제·로그인처럼 핵심적인 흐름에는 자동 갱신을 그대로 반영하지 않고,
사람이 승인해야만 적용되도록 설정을 둔다
- 자동 갱신 이력이 특정 화면에서 반복해서 발생한다면, 그건 셀프힐링이
잘 작동하고 있다는 신호가 아니라 그 화면의 로케이터 설계 자체가
불안정하다는 신호로 읽는다Autify가 셀프힐링이라는 기능 하나 를 상품화했다면, 다음 레슨의 UiPath Test Cloud는 설계·자동화·실행·관리 라이프사이클 전체 에 AI 에이전트를 얹은 플랫폼이다. 범위가 넓어질수록 "AI가 고쳤다"를 검증하는 원칙은 도구 평가와 도입 판단의 원칙으로 커진다.
실무에서 왜 필요한가
노코드 AI 자동화는 유지보수 인력이 부족한 팀에서 회귀 테스트의 반복적인 깨짐 대응 부담을 크게 줄여준다. 화면이 자주 바뀌는 초기 스타트업이나, QA 인력 대비 자동화해야 할 화면 수가 많은 조직에서 특히 효과가 크다.
다만 복잡한 비즈니스 로직 검증 — 예를 들어 할인 쿠폰 세 개가 동시에 적용될 때의 계산 결과 검증 같은 것 — 은 여전히 사람이 시나리오를 설계해야 한다. AI가 대신해주는 건 "화면이 바뀌어도 실행이 끊기지 않게 하는 것"이지, "무엇을 검증할지 판단하는 것"이 아니다. 이 경계를 명확히 아는 QA는 Autify 같은 도구를 도입하되, 검증 설계까지 도구에 맡기는 실수를 피할 수 있다.