자가 치유 테스트 자동화
AI 기반 자가 치유 로케이터, 비주얼 테스팅, 스마트 웨이트로 QA 시간의 60-70%를 차지하는 깨진 테스트 수정을 제거하세요.
프리미엄 강좌 콘텐츠
이 레슨은 프리미엄 강좌의 일부예요. Pro로 업그레이드하면 모든 프리미엄 강좌와 콘텐츠를 이용할 수 있어요.
- 모든 프리미엄 강좌 이용
- 1000개 이상의 AI 스킬 템플릿 포함
- 매주 새로운 콘텐츠 추가
유지보수 세금
🔄 Quick Recall: 이전 레슨에서 AI 코드 리뷰가 PR 단계에서 — 개발 주기에서 가장 저렴한 시점에 — 버그를 잡는 법을 배웠어요. 하지만 코드가 리뷰를 통과하고 배포된 후에도 테스트는 계속 작동해야 해요. 대부분의 QA 팀이 여기서 가장 큰 병목에 부딪혀요: 테스트 유지보수.
놀라운 숫자가 있어요: QA 팀이 시간의 60-70%를 기존 테스트 유지보수에 쓰고, 새 테스트 작성에는 나머지만 투자해요.
버튼 이름이 바뀌어요. 폼 필드가 다른 섹션으로 옮겨져요. 로딩 스피너가 스켈레톤 스크린으로 교체돼요. 이건 버그가 아니라 정상적인 UI 진화예요. 그런데 특정 CSS 클래스로 특정 위치의 특정 요소를 찾는 Selenium 테스트는 매번 깨져요.
결과는? 테스트 스위트가 개발 속도에 세금을 부과하는 거예요. UI 변경마다 테스트 실패가 쏟아지고 누군가가 분류, 진단, 수정을 해야 해요. 결국 개발 속도를 늦추거나(테스트 깨짐 방지), 테스트 자동화를 포기하거나(유지보수 비용이 가치를 초과) 둘 중 하나를 선택하게 돼요.
자가 치유 테스트 자동화가 이 트레이드오프를 깨요.
자가 치유의 작동 원리
전통적 테스트 로케이터는 설계부터 취약해요. 하나의 속성으로 요소를 식별하거든요:
# 클래스명이 바뀌면 깨짐
driver.find_element(By.CSS_SELECTOR, ".btn-primary-submit")
# ID가 바뀌면 깨짐
driver.find_element(By.ID, "checkout-submit-btn")
# DOM 구조가 바뀌면 깨짐
driver.find_element(By.XPATH, "//div[@class='checkout']/form/button[2]")
이 속성 중 하나만 바뀌어도 테스트가 실패해요 — 버튼은 완벽히 작동하는데도요.
자가 치유 로케이터는 다중 식별 전략을 동시에 사용해요:
| 전략 | 확인 내용 | 회복력 |
|---|---|---|
| 시각적 외관 | 화면에서 요소가 어떻게 보이는지 | 코드 리팩터링에 생존 |
| 텍스트 콘텐츠 | “주문 완료” 같은 보이는 라벨 | 구조 변경에 생존 |
| 접근성 역할 | ARIA 라벨과 시맨틱 HTML | CSS 변경에 생존 |
| DOM 관계 | 주변 요소와의 상대 위치 | 클래스명 변경에 생존 |
| 데이터 속성 | data-testid 같은 마커 | 비주얼 리디자인에 생존 |
기본 로케이터가 실패하면 AI가 다음 전략을 시도해요. 버튼의 CSS 클래스가 바뀌었지만 텍스트가 여전히 “주문 완료"이고 결제 폼 안에 있으면, 테스트가 스스로 치유하고 계속 실행돼요.
✅ Quick Check: 자가 치유 테스트가 하나의 확실한 로케이터 대신 여러 전략을 사용하는 이유는? 어떤 단일 전략도 모든 유형의 변경에 생존하지 못하기 때문이에요. 5-6가지 전략을 동시에 유지하면 어떤 한 유형의 변경에도 적응하고, 보통 여러 변경이 동시에 일어나도 대응해요.
자가 치유 실전 도구
Katalon SmartWait
Katalon의 SmartWait는 자가 치유 로케이터를 넘어서 타이밍 이슈까지 처리해요 — 플레이키 테스트의 두 번째 주요 원인이에요.
전통적 접근:
# 하드코딩된 대기 — 너무 짧으면 실패, 너무 길면 시간 낭비
time.sleep(5)
driver.find_element(By.ID, "results-table")
SmartWait 접근:
- DOM 변화를 실시간 모니터링
- 요소가 인터랙티브할 때까지 대기 (단순 존재가 아니라)
- 관찰된 페이지 동작에 기반해 대기 시간 적응
- 하드코딩된 sleep 불필요
효과: 하드코딩 대기에서 SmartWait로 전환한 팀이 플레이키 테스트 실패를 30-50% 감소해요.
Virtuoso QA: 노코드 자가 치유
Virtuoso는 비주얼 퍼스트 접근이에요. 코드가 아니라 화면에 보이는 것으로 테스트를 정의해요:
결제 페이지로 이동
이름 필드에 "테스트 유저" 입력
카드 번호 필드에 "4242 4242 4242 4242" 입력
"주문하기" 버튼 클릭
확인 페이지에 주문 번호 표시 확인
AI가 각 페이지의 비주얼 모델을 유지해요. 디자인이 바뀌면 실패하는 대신 모델을 업데이트해요. 비기술 이해관계자(PM, 비즈니스 분석가)가 테스트를 만들고 유지해야 하는 팀에 최적이에요.
mabl 자동 치유
mabl은 테스트 인터랙션을 녹화하고 행동 모델을 구축해요. 요소가 바뀌면:
- 실패를 감지
- 다중 전략으로 동등한 요소를 검색
- 신뢰도가 임계값 이상이면 테스트 치유
- 인간 리뷰를 위해 치유 내역 로깅
- 중단 없이 테스트 실행 계속
핵심 지표: mabl은 자동 치유로 **로케이터 실패의 70-90%**를 인간 개입 없이 해결한다고 보고해요.
✅ Quick Check: 자가 치유 테스트를 신뢰하면 안 되는 경우는? 치유가 요소를 찾는 방법이 아니라 테스트의 동작 자체를 바꿨을 때예요. AI가 “주문 완료” 테스트를 “임시 저장” 버튼 클릭으로 치유하면 테스트는 통과하지만 잘못된 것을 검증하고 있어요.
비주얼 테스팅: 빠진 레이어
기능 테스트는 동작을 검증해요 (버튼 클릭이 액션을 트리거). 비주얼 테스트는 외관을 검증해요 (페이지가 올바르게 보이는지).
작동 방식:
- 테스트 스위트 실행 → 도구가 핵심 단계에서 스크린샷 캡처
- 새 스크린샷을 베이스라인 이미지와 비교
- AI가 의미 있는 시각 변화 vs 허용 가능한 변동 식별
- 리그레션 플래그: 요소 겹침, 텍스트 잘림, 레이아웃 깨짐
AI가 중요한 이유: 전통적 픽셀 비교는 안티앨리어싱, 서브픽셀 렌더링 차이로 오탐이 쏟아져요. AI 비주얼 테스팅은 인간이 눈치챌 것을 이해해요: 버튼이 200픽셀 이동하면 문제이고, 보더가 1픽셀 다르면 문제가 아니에요.
주요 도구:
- Percy (BrowserStack): CI/CD 통합 스냅샷 비교
- Applitools Eyes: 레이아웃 의도를 이해하는 AI 비주얼 분석
- Chromatic: 컴포넌트 라이브러리용 비주얼 테스팅 (Storybook 연동)
자가 치유 전략 세우기
모든 테스트에 자가 치유가 필요한 건 아니에요:
| 테스트 유형 | 자가 치유 가치 | 추천 |
|---|---|---|
| 스모크 테스트 (핵심 경로) | 매우 높음 | 자가 치유 + 비주얼 테스팅 |
| 리그레션 스위트 | 높음 | 자가 치유 + 리뷰 임계값 |
| 엣지 케이스 테스트 | 중간 | 자가 치유 + 낮은 신뢰도 임계값 |
| 유닛 테스트 | 낮음 | 자가 치유 불필요 (코드 레벨) |
| API 테스트 | 낮음 | 자가 치유 해당 없음 (UI 없음) |
스모크 테스트부터 시작하세요. 핵심 사용자 여정(로그인, 결제, 주요 워크플로우)을 커버하는 10-20개 테스트예요. 가장 자주 실행되고 UI 업데이트에 가장 자주 깨져요. 여기서 자가 치유가 가장 높은 ROI를 줘요.
핵심 정리
- QA 팀이 시간의 60-70%를 기존 테스트 유지보수에 소비 — 자가 치유 자동화가 이 시간을 되찾아줘요
- 자가 치유 로케이터가 다중 식별 전략(시각, 텍스트, DOM, 접근성)을 사용해서 UI 변경에도 테스트 생존
- SmartWait가 타이밍 이슈로 인한 플레이키 테스트를 30-50% 감소
- 비주얼 테스팅이 기능 테스트가 놓치는 레이아웃 리그레션을 잡아요 — 화면 밖 버튼, 요소 겹침, 디자인 드리프트
- 스모크 테스트부터 자가 치유를 시작하세요 — 가장 자주 실행되고 가장 자주 깨져요
Up next: 다음 레슨에서 AI가 성능 및 부하 테스팅을 어떻게 변혁하는지 — 현실적 트래픽 패턴을 생성하고 전통적 부하 테스트가 놓치는 병목을 찾는 법을 배워요.
이해도 체크
먼저 위의 퀴즈를 완료하세요
레슨 완료!