UI 자동화란 무엇인가: 언제, 왜 필요한가

개념

피라미드 꼭대기, 가장 비싼 계층

모듈 11(레슨 1)에서 배운 자동화 피라미드를 떠올려보자. UI 자동화(E2E 테스트)는 피라미드의 가장 위, 가장 적어야 하는 계층이다. 실제 브라우저(또는 모바일 앱)를 띄우고, 사람이 하는 것처럼 클릭하고 입력하며 화면을 통해 검증하기 때문에, 모듈 12(레슨 1)에서 배운 API 테스트보다 훨씬 느리고 불안정하다.

UI 자동화만 확인할 수 있는 것

그런데도 UI 자동화가 필요한 이유는, API 테스트나 컴포넌트 테스트(모듈 10 레슨 6)로는 확인할 수 없는 것이 있기 때문이다.

여러 화면에 걸친 실제 사용자 흐름이 처음부터 끝까지 끊기지 않는가(회원가입 → 로그인 → 장바구니 → 결제)
프런트엔드와 백엔드가 실제로 연동됐을 때 문제가 없는가
브라우저별·디바이스별로 실제 렌더링이 깨지지 않는가

API 테스트는 "서버가 옳은 데이터를 주는가"까지만 확인하고, 그 데이터가 실제로 화면에 올바르게 반영되는지는 확인하지 못한다 — 이 간극을 메우는 것이 UI 자동화의 역할이다.

어떤 흐름을 UI 자동화로 남길 것인가

모듈 11(레슨 2)에서 배운 판단 기준(반복성·안정성·회귀 가치)이 UI 자동화에서는 더 엄격하게 적용돼야 한다 — 비용이 훨씬 크기 때문이다.

UI 자동화 우선순위가 높은 경우:
- 핵심 사용자 여정(회원가입, 로그인, 결제)처럼 리스크가 큰 흐름
- 여러 화면·시스템에 걸친 통합적 확인이 꼭 필요한 시나리오
- 변경이 잦지 않고 안정된 핵심 기능
 
UI 자동화를 피해야 하는 경우:
- API 테스트만으로 충분히 검증 가능한 로직
- 아직 디자인이 자주 바뀌는 기능(모듈 11 레슨 2)
- 미묘한 시각적 디테일(디자인의 "느낌") — 이건 사람의 눈이 낫다

자동화한다고 탐색적 테스팅이 필요 없어지는 게 아니다

핵심 흐름을 UI 자동화로 커버해도, 모듈 5에서 배운 탐색적 테스팅은 여전히 필요하다 — 자동화는 **"이미 알고 있는 시나리오가 계속 맞는지"**를 반복 확인하는 것이고, 탐색적 테스팅은 **"아직 모르는 문제를 찾는 것"**이다. 둘은 대체 관계가 아니라 보완 관계다.

웹과 모바일, 도구는 다르지만 원칙은 같다

이 모듈에서는 웹 자동화에 Playwright를, 모바일 자동화에 Appium을 다룬다. 도구는 다르지만, 이 레슨에서 배운 "언제 UI 자동화가 필요한가"라는 판단 원칙과, 레슨 3~6에서 배울 로케이터· 구조·대기 전략의 원칙은 웹과 모바일 모두에 공통으로 적용된다.

실무에서 왜 필요한가

"이것도 자동화하고 저것도 자동화하자"는 요구가 쌓이면, 어느새 UI 자동화 스위트가 몇 시간씩 걸리고 관리 불가능해진다(모듈 11 레슨 4의 자동화 부채). QA가 "이 시나리오는 API 테스트로 충분하고, 저 시나리오만 진짜 UI 자동화가 필요하다"고 구분할 수 있으면, 건강한 피라미드를 유지하면서도 꼭 필요한 안전망은 확보할 수 있다.

실습 과제

과제 1 — UI 자동화 대상 판단하기 (10분)

다음 세 시나리오 중 어느 것이 UI 자동화로 남기기 가장 적합한지 우선순위를 매기고 이유를 적는다.

"결제 정보 입력 → 결제 승인 → 주문 완료 화면" 전체 흐름
"할인율 계산이 정확한지"(이미 API 테스트로 커버됨)
"새로 리디자인 중인 홈 화면 배너 영역"(디자인이 매주 바뀜)

과제 2 — API 테스트와 UI 자동화 역할 나누기 (10분)

"회원가입" 기능을 검증할 때, API 테스트로 확인할 부분과 UI 자동화로 확인해야만 하는 부분을 각각 나눠 적는다.

자가 체크리스트

UI 자동화가 피라미드에서 가장 비싼 계층인 이유를 설명할 수 있다
UI 자동화만이 확인할 수 있는 것이 무엇인지 설명할 수 있다
UI 자동화 우선순위가 높은 경우와 피해야 하는 경우를 구분할 수 있다
자동화와 탐색적 테스팅이 대체가 아니라 보완 관계라는 것을 설명할 수 있다

흔한 실수

"자동화할 수 있는 건 다 UI 자동화로 만들자"는 태도로 접근한다. 피라미드가 뒤집힌 아이스크림 콘(모듈 11 레슨 1)이 되기 쉽다.
API 테스트로 충분한 로직까지 UI 자동화로 중복 검증한다. 같은 것을 두 계층에서 검증하면 유지보수 비용만 늘어난다.
UI 자동화 스위트가 있으니 탐색적 테스팅은 줄여도 된다고 생각한다. 자동화는 알려진 시나리오만 반복 확인할 뿐이다.

참고 자료

Playwright 공식 문서 — Why Playwright — UI 자동화 도구 도입의 공식 소개
Martin Fowler — TestPyramid — 모듈 11 레슨 1과 동일한 참고 자료, UI 자동화의 위치 재확인