브라우저 테스트가 실패했습니다. 실제로 그 이유를 증명할 수 있나요?

CI(지속적 통합)에서의 빨간색 테스트 결과는 명확해 보입니다.

무언가 실패했습니다. 파이프라인이 중단되었습니다. 스크린샷, 스택 트레이스 (stack trace), 그리고 아마도 영상이 있을 것입니다.

하지만 누군가 스크린샷을 열었을 때 로딩 스피너 (loading spinner)가 보입니다. 트레이스 (trace)에는 로케이터 (locator)를 찾을 수 없다고 나옵니다. 동일한 테스트가 로컬 (locally)에서는 통과합니다. 작업을 다시 실행하면 초록색으로 변합니다.

그 시점에서 팀은 실제로 실패한 테스트를 가진 것이 아닙니다. 해결되지 않은 이벤트를 가진 것입니다.

이러한 차이는 몇 년 전보다 지금 더 중요합니다. 브라우저 애플리케이션은 더 동적이고, CI 환경은 더 일회용이며, 테스트 스위트 (test suites)에는 AI가 생성한 단계, 어서션 (assertions), 로케이터 (locators), 그리고 복구 제안이 점점 더 많이 포함되고 있습니다.

또 다른 테스트를 생성하는 것은 쉽습니다. 그 결과가 릴리스 (release)를 차단해야 하는지 결정하는 것은 더 어렵습니다.

따라서 브라우저 테스트 시스템의 품질은 통과율 (pass rate)이나 실행 속도 그 이상으로 측정되어야 합니다. 무언가 잘못되었을 때 생성하는 증거에 의해서도 측정되어야 합니다.

이 기사에서는 팀이 실제로 그 증거를 신뢰할 수 있는지 여부를 결정하는 영역들을 살펴봅.

빠른 피드백은 실패를 이해할 수 있을 때만 유용합니다

팀들은 종종 실행 시간이라는 하나의 숫자를 중심으로 브라우저 테스트를 최적화합니다.

그것은 일리가 있습니다. 3시간이 걸리는 회귀 테스트 스위트 (regression suite)는 결국 무시되거나, 야간 스케줄로 옮겨지거나, 릴리스 경로에서 제거될 것입니다.

하지만 속도만으로는 충분하지 않습니다.

모호한 실패를 생성하는 10분짜리 스위트는 훌륭한 진단 기능을 갖춘 30분짜리 스위트보다 더 많은 엔지니어링 시간을 낭비할 수 있습니다. 진정한 피드백 루프 (feedback loop)에는 실행과 조사가 모두 포함됩니다:

테스트가 얼마나 빨리 실패했는가?
누군가가 실패를 얼마나 빨리 이해할 수 있었는가?
팀이 제품, 테스트, 데이터, 또는 환경 중 무엇이 원인인지 얼마나 빨리 결정할 수 있었는가?

유용한 시작점은 CI에서 빠른 실패 증거가 필요한 팀을 위한 최고의 브라우저 테스트 도구에 대한 개요입니다. 여기서 중요한 문구는 단순히 "빠른 브라우저 테스트"가 아니라, "빠른 실패 증거 (fast failure evidence)"입니다.

좋은 증거에는 다음이 포함될 수 있습니다:

실제 실패 시점에 촬영된 스크린샷 (Screenshot)
해당 순간의 DOM 또는 접근성 상태 (Accessibility state)
브라우저 콘솔 에러 (Browser console errors)
네트워크 요청 및 응답 (Network requests and responses)
단계별 타이밍 (Step-level timing)
이전의 성공한 시도들
명확한 타임라인이 포함된 비디오
시도된 로케이터 전략 (Locator strategy)
환경 및 브라우저 메타데이터 (Metadata)
테스트 실행과 연관된 애플리케이션 로그 (Application logs)

그러한 컨텍스트 (Context) 없이는, 실패는 종종 추측 게임이 되어버립니다.

먼저 무엇이 변했는지 물으세요: 애플리케이션, 테스트, 아니면 환경인가?

브라우저 테스트가 실패하면 보통 즉각적인 가정이 만들어집니다: 제품이 변했다는 것입니다.

때로는 실제로 그렇기도 합니다.

하지만 대부분의 자동화된 테스트 실행에는 최소한 세 가지의 움직이는 시스템이 있습니다:

애플리케이션 (The application)
테스트 또는 AI 에이전트 (The test or AI agent)
실행 환경 (The execution environment)

애플리케이션은 레이아웃, 카피 (Copy), 타이밍, API 동작, 또는 인증 흐름 (Authentication flow)을 변경했을 수 있습니다.

테스트는 누군가 이를 편집했거나, AI 시스템이 일부를 재생성했거나, 셀프 힐링 (Self-healing) 메커니즘이 새로운 로케이터를 선택했거나, 또는 의존성 (Dependency)이 런타임 동작을 변경했기 때문에 변했을 수 있습니다.

환경은 브라우저 업데이트, 캐시 복구, 컨테이너 이미지, 로케일 (Locale), 시간대 (Timezone), 네트워크 정책, 패키지 버전, 또는 머신 용량 때문에 변했을 수 있습니다.

이것이 AI 테스트 드리프트와 UI 드리프트의 차이를 구분하는 것이 매우 유용한 이유입니다.

만약 변경되지 않은 인터페이스에서 AI 에이전트가 다른 결정을 내리기 시작한다면, 그것은 UI 드리프트가 아닙니다. 그것은 에이전트 드리프트 (Agent drift)입니다.

그 차이는 증거에서 명확히 보여야 합니다. 팀은 다음을 알아야 합니다:

어떤 프롬프트(Prompt)나 지시 사항(Instruction)이 사용되었는지
어떤 모델과 모델 버전이 해당 단계를 처리했는지
모델이 어떤 페이지 상태(Page state)를 전달받았는지
모델이 어떤 동작(Action)을 선택했는지
동일한 입력이 이전에 다른 결과를 생성했었는지
폴백(Fallback) 또는 복구 메커니즘(Repair mechanism)이 트리거되었는지

이 중 어느 것도 기록되지 않는다면, AI 기반의 실패는 재현하기 어려워집니다.

AI가 생성한 UI 변경 사항에는 더 낮은 기준이 아닌, 더 강력한 증거가 필요합니다

AI 코딩 도구는 인터페이스 변경 사항을 빠르게 생성할 수 있습니다. 개발자가 디자인을 새로 한 폼(Form), 새로운 결제 컴포넌트(Checkout component), 또는 반응형 네비게이션 시스템(Responsive navigation system)을 요청하면 몇 분 내에 방대한 패치(Patch)를 받을 수 있습니다.

이러한 속도에 맞춰 똑같이 빠른 자동 승인으로 대응하고 싶은 유혹이 생깁니다.

하지만 생성된 코드는 미묘한 문제들을 유발할 수 있습니다:

폼은 여전히 올바르게 보이지만 유효성 검사 로직(Validation logic)이 변경될 수 있음
시맨틱 레이블(Semantic labels)이 사라질 수 있음
로딩 상태(Loading states)가 생략될 수 있음
에러 메시지가 더 이상 실패 원인과 일치하지 않을 수 있음
모바일 동작이 불완전할 수 있음
인증 상태(Authentication state)가 잘못 처리될 수 있음
기존의 분석(Analytics) 또는 접근성(Accessibility) 속성이 제거될 수 있음

따라서 팀은 릴리스 결정을 늦추지 않으면서 AI가 생성한 UI 변경 사항에 대한 테스트 증거를 평가하는 실질적인 방법이 필요합니다.

목표는 AI가 생성하는 모든 것을 수동으로 검사하는 것이 아닙니다. 목표는 다양한 위험 수준에 따라 어떤 증거가 필요한지 결정하는 것입니다.

작은 문구(Copy) 변경은 시각적 확인과 몇 가지 타겟팅된 어설션(Assertions)이 필요할 수 있습니다.

생성된 결제 흐름(Payment-flow) 변경에는 다음이 필요할 수 있습니다:

기능적 브라우저 테스트 (Functional browser tests)
네트워크 응답 검증 (Network-response validation)
접근성 체크 (Accessibility checks)
교차 브라우저 커버리지 (Cross-browser coverage)
네거티브 시나리오 (Negative scenarios)
세션 만료 동작 (Session-expiry behavior)
중요한 어설션(Assertions)에 실제로 도달했다는 증거

릴리스 프로세스는 보편적으로 느려지는 것이 아니라, 비례적으로 이루어져야 합니다.

일부 브라우저 상호작용은 취약한 자동화를 즉각적으로 드러냅니다

많은 브라우저 테스트 (browser-testing) 데모는 클릭, 텍스트 입력, 그리고 단순한 내비게이션 (navigation)에 집중합니다.

이러한 요소들은 필수적이지만, 도구의 한계를 일반적으로 드러내는 상호작용은 아닙니다.

드래그 앤 드롭 (Drag-and-drop) 보드, 캔버스 (canvas) 에디터, 타임라인 (timeline) 컴포넌트, 지도 인터페이스, 그리고 파일 드롭존 (file dropzones)이 훨씬 더 많은 것을 보여줍니다.

드래그 작업은 포인터 좌표, 스크롤링, 요소 기하학 (element geometry), 브라우저 이벤트, 애니메이션 상태, 그리고 드롭존 활성화에 의존할 수 있습니다. 테스트는 제스처를 올바르게 수행하는 것처럼 보일 수 있지만, 애플리케이션은 이를 거부할 수 있습니다.

드래그 앤 드롭 보드, 캔버스 상호작용 및 드롭존 엣지 케이스 테스트하기에 관한 이 가이드는 진지한 평가에 포함되어야 할 시나리오 유형을 다룹니다.

이러한 워크플로 (workflows)는 왜 스크린샷만으로는 충분하지 않은지도 보여줍니다.

스크린샷은 카드가 다른 열로 이동했다는 것을 보여줄 수는 있지만, 다음 사항들을 증명하지는 못할 수 있습니다:

올바른 백엔드 (backend) 업데이트가 발생했는지
키보드 접근 가능한 경로 (keyboard-accessible path)가 여전히 작동하는지
드롭 이벤트 (drop event)가 한 번 발생했는지
해당 동작이 페이지 새로고침 (page refresh) 후에도 유지되었는지
아이템이 예상된 인덱스 (index)로 이동했는지
애플리케이션이 유효하지 않은 드롭존을 거부했는지

복잡한 브라우저 상호작용의 경우, 증거는 외관 (appearance)과 상태 (state)를 모두 포함해야 합니다.

휘발성 CI는 "동일한 테스트"의 의미를 변화시킵니다

개발자의 노트북에서 실행되는 브라우저 테스트는 종종 축적된 상태 (accumulated state)의 이점을 얻습니다.

의존성 (Dependencies)이 이미 설치되어 있습니다. 브라우저 바이너리 (Browser binaries)가 존재합니다. 폰트가 캐시 (cached)되어 있습니다. 머신에는 메모리가 충분합니다. DNS가 워밍업 (warm)되어 있습니다. 개발자는 심지어 이전 실행에서 남겨진 인증 상태 (authentication state)를 가지고 있을 수도 있습니다.

휘발성 CI (ephemeral CI) 작업은 훨씬 더 통제된 환경에서 시작되지만, 동시에 다른 위험 요소들을 도입합니다.

컨테이너 (container) 또는 가상 머신 (virtual machine)에는 다음과 같은 것들이 있을 수 있습니다:

서로 다른 CPU 가용성 (CPU availability)
서로 다른 폰트 (fonts)
서로 다른 시간대 (timezone) 또는 로케일 (locale)
콜드 브라우저 시작 (Cold browser startup)
누락된 운영체제 패키지 (operating-system packages)
복구된 의존성 캐시 (dependency cache)
서로 다른 네트워크 지연 시간 (network latency)
유지되지 않은 인증 상태 (persisted authentication state)
감소된 공유 메모리 (shared memory)
예상보다 최신인 브라우저 이미지 (browser image)

이러한 실행 결과들을 신뢰할 수 있는 것으로 취급하기 전에, 휘발성 CI 환경에서 브라우저 테스트를 신뢰하기 전에 확인해야 할 사항을 검토할 가치가 있습니다.

신뢰할 수 있는 결과라면 해당 결과를 생성한 환경을 식별할 수 있어야 합니다.

의존성 락파일 (Dependency lockfiles)
캐시 키 및 복구 키 (Cache keys and restore keys)
설치된 패키지 버전 (Installed package versions)
브라우저 버전 (Browser versions)
생성된 파일 (Generated files)
환경 변수 (Environment variables)
클린 및 캐시된 실행 (Clean and cached runs)
아티팩트 타임스탬프 (Artifact timestamps)

환경 차이를 이해하기 전에 적용된 테스트 수정은 단순히 실제 문제를 숨길 뿐일 수 있습니다.

유지보수 결과로 AI 코딩 도구를 측정하세요

AI 코딩 도구는 Playwright, Selenium 또는 Cypress 테스트를 빠르게 생성할 수 있습니다. 이로 인해 "생성된 테스트 수"는 매력적인 지표가 됩니다.

하지만 이는 장기적으로 가장 유용하지 않은 지표 중 하나이기도 합니다.

엔지니어링 리더는 테스트가 생성된 이후에 발생하는 일들에 관심을 가져야 합니다:

제품 결함 없이 테스트가 실패하는 빈도는 어느 정도인가?
생성된 코드에 어느 정도의 리뷰가 필요한가?
생성된 로케이터 (locators)가 얼마나 자주 교체되는가?
생성된 헬퍼 (helpers) 중 기존 추상화 (abstractions)를 중복하는 것이 얼마나 되는가?
실패 조사에 시간이 얼마나 걸리는가?
원작자 이외의 다른 사람이 이를 유지보수할 수 있는가?
테스트 스위트 (suite)가 시간이 지남에 따라 빨라지는가, 아니면 느려지는가?
중요한 비즈니스 리스크 주변의 테스트 커버리지 (test coverage)가 개선되는가?

테스트 자동화 워크플로우를 위해 AI 코딩 도구를 도입하기 전 엔지니어링 리더가 측정해야 할 사항에 관한 이 기사는 생성된 코드 라인을 세는 것보다 더 나은 프레임워크를 제공합니다.

핵심 질문은 AI가 테스트를 작성할 수 있느냐가 아닙니다.

결과적으로 만들어진 시스템이 운영하기에 더 저렴하고 더 신뢰할 수 있게 되는가입니다.

탭 전환 및 팝업 워크플로우는 별도의 평가가 필요합니다

많은 브라우저 테스트가 하나의 탭 안에서만 머무릅니다.

실제 애플리케이션은 항상 협조적이지 않습니다.

인증 제공업체는 팝업을 엽니다. 결제 페이지는 외부 도메인으로 리다이렉트(redirect)됩니다. 보고서는 새 탭에서 열립니다. 이메일 링크는 별도의 세션을 생성합니다. 워크플로우는 관리자 인터페이스와 고객용 페이지 사이를 전환해야 할 수도 있습니다.

멀티 윈도우 (Multi-window) 테스트는 추가적인 상태 (state)를 도입합니다:

어떤 창이 활성화되어 있는가?
마지막 동작에 의해 생성된 창은 무엇인가?
팝업 (Pop-up)이 차단되었는가?
원래 창에서 인증 (Authentication)이 완료되었는가?
새 탭이 예상된 도메인 (Domain)에 있는가?
두 탭의 제목이 유사할 경우 어떤 일이 발생하는가?
하나의 창을 닫는 것이 다른 세션 (Session)을 무효화하는가?

멀티 윈도우, 팝업, 그리고 크로스 탭 브라우저 흐름을 위한 Endtest와 Playwright 비교는 도구 비교 시 팀이 실제로 사용하는 워크플로 (Workflow)를 사용해야 한다는 점을 유용한 시사점으로 제공합니다.

프레임워크 (Framework)는 완전한 기술적 제어권을 제공할 수 있지만, 팀이 추상화 (Abstraction)를 직접 설계하고 유지 관리해야 할 수도 있습니다.

플랫폼 (Platform)은 일반적인 흐름을 단순화할 수 있지만, 다른 형태의 한계를 드러낼 수 있습니다.

어떤 방식도 단일 탭 로그인 데모만으로 판단해서는 안 됩니다.

AI 코딩 어시스턴트 테스트는 두 번째 계층의 테스트를 생성합니다

AI 코딩 어시스턴트 (AI coding assistant)에 의해 프론트엔드 (Frontend)가 부분적으로 생성되거나 수정될 때, 팀은 애플리케이션 (Application)만 테스트하는 것이 아닙니다.

그들은 또한 또 다른 확률적 시스템 (Probabilistic system)의 결과물을 테스트하고 있는 것입니다.

이는 새로운 범주의 질문들을 만들어냅니다: