UI 자동화에서 불안정한 테스트 다루기

개념

UI 자동화가 특히 플래키해지기 쉬운 이유

모듈 7(레슨 3)에서 플래키 테스트를 배웠고, 모듈 10(레슨 4)에서 비결정적 요소를, 레슨 5에서 대기 전략을 배웠다. UI 자동화는 이 모든 원인이 겹치는 지점이다 — 실제 브라우저, 실제 네트워크, 실제 렌더링 타이밍까지 관여하기 때문에, 다른 어떤 테스트 계층보다 불안정해지기 쉽다.

네 가지 관점으로 원인을 좁히기

1. 로케이터 문제 (레슨 3)

같은 텍스트를 가진 요소가 화면에 여러 개 나타나거나, 동적으로 생성되는 요소의 속성이 매번 바뀌는 경우.

증상: "여러 요소가 발견됨" 에러가 가끔 발생
확인: 로케이터가 충분히 구체적인 범위(스코프)로 좁혀져 있는가?

2. 대기 문제 (레슨 5)

조건 기반이 아니라 고정 시간 대기를 쓰고 있거나, 특정 API 응답을 기다려야 하는데 놓친 경우.

증상: 로컬에서는 항상 통과, CI에서만 가끔 실패
확인: 이 단계에 sleep()이 남아있지 않은가? 명시적 대기가 필요한 지점은 없는가?

3. 환경·데이터 문제 (모듈 7 레슨 2, 3)

테스트 환경이 다른 테스트와 공유되어 데이터가 오염되거나, 병렬 실행 시 서로 다른 테스트가 같은 데이터를 건드리는 경우.

증상: 순서를 바꾸거나 혼자 실행하면 통과하는데, 전체를 같이 돌리면 실패
확인: 각 테스트가 독립된 데이터로 실행되는가(모듈 7 레슨 2의 격리)?

4. 애플리케이션 자체의 비결정성 (모듈 10 레슨 4)

테스트 코드가 아니라 애플리케이션 자체가 현재 시각·랜덤 값에 의존해서 매번 다르게 동작하는 경우.

증상: 특정 시간대나 특정 데이터 조합에서만 실패
확인: 애플리케이션 코드가 통제되지 않은 값에 의존하고 있지 않은가?

재시도(Retry)는 임시방편이지 해결책이 아니다

CI 설정에서 "실패하면 자동으로 2번 더 재시도"하는 기능을 흔히 쓴다. 이건 일시적으로 파이프라인을 안 막히게 하는 응급처치일 뿐, 근본 원인을 고친 게 아니다. 재시도로 통과율을 올려놓고 원인 분석을 미루면, 모듈 11(레슨 4)에서 배운 자동화 부채가 조용히 쌓인다 — "이 테스트는 원래 재시도해야 통과해요"가 당연해지는 순간이 위험 신호다.

격리해서 원인을 좁히는 절차

플래키 테스트를 진단할 때는 다음 순서로 범위를 좁혀가는 것이 효율적이다.

1. 그 테스트만 단독으로 여러 번 반복 실행해본다
   → 단독으로도 가끔 실패하면 (1)(2)(4) 쪽 문제
   → 단독으로는 항상 통과하면 (3) 환경·데이터 공유 문제일 가능성이 높음
2. 실패 시점의 트레이스·스크린샷(레슨 2)을 확인한다
   → 어느 단계에서 무엇을 기다리다 실패했는지 직접 눈으로 본다
3. 위 네 가지 관점에 하나씩 대입해 가설을 세우고 검증한다

실무에서 왜 필요한가

"이 테스트 원래 가끔 그래요"라는 말이 팀에 당연해지면, 자동화 스위트 전체의 신뢰도가 무너진다(모듈 11 레슨 4). 네 가지 관점으로 체계적으로 원인을 좁히는 QA는, 막연히 "환경 탓"으로 넘기지 않고 실제 근본 원인을 찾아 고침으로써 팀이 자동화 결과를 다시 신뢰하게 만들 수 있다.

실습 과제

과제 1 — 원인 범주 진단하기 (15분)

다음 세 증상을 네 가지 관점(로케이터/대기/환경·데이터/애플리케이션 비결정성) 중 가장 가능성 높은 원인과 짝짓는다.

"테스트를 혼자 실행하면 통과하는데, 전체 스위트와 같이 돌리면 실패한다"
"월말에만(정산 관련 화면에서) 가끔 실패한다"
"상품 목록 화면에서 '삭제' 버튼을 찾다가 가끔 에러가 난다. 상품이 여러 개인 화면에서만 그렇다"

과제 2 — 재시도 남용 여부 점검하기 (10분)

"이 테스트는 통과할 때까지 최대 3번 재시도한다"는 설정이 되어 있는 테스트가 있다고 하자. 이게 문제가 될 수 있는 이유와, 이 설정을 유지하더라도 함께 해야 할 조치를 적는다.

자가 체크리스트

UI 자동화가 다른 계층보다 플래키해지기 쉬운 이유를 설명할 수 있다
플래키 원인을 네 가지 관점으로 나눠 진단할 수 있다
재시도가 근본 해결책이 아닌 이유를 설명할 수 있다
단독 실행 vs 전체 실행 비교로 원인 범위를 좁히는 절차를 설명할 수 있다

흔한 실수

플래키 테스트를 발견하면 바로 재시도 횟수부터 늘린다. 근본 원인을 찾는 절차를 생략하면 문제가 계속 누적된다.
모든 플래키 원인을 "환경이 불안정해서"로 뭉뚱그린다. 로케이터, 대기, 환경, 애플리케이션 중 어디인지 구체적으로 좁혀야 실제 수정이 가능하다.
트레이스·스크린샷 없이 로그 메시지만으로 원인을 추측한다. 실패 시점의 화면을 직접 보는 것이 가장 빠른 진단 방법인 경우가 많다.

참고 자료

Martin Fowler — Eradicating Non-Determinism in Tests — 플래키 테스트 진단의 대표 아티클
Playwright 공식 문서 — Debugging Tests — 트레이스·스크린샷을 활용한 디버깅 공식 가이드