테스트 실패에서 근본 원인까지: AI 지원 Playwright 실패 분석 파이프라인 구축

이 블로그는 AI가 지원하는 Playwright 파이프라인이 테스트 실패 증거를 분석하고, 발생 가능한 근본 원인을 식별하며, 인간 검증을 거치는 디버깅을 지원할 수 있는 방법을 설명합니다.

서론

현대 애플리케이션은 자동화된 CI/CD 파이프라인을 통해 테스트되는 경우가 늘고 있습니다. Playwright와 같은 도구는 팀이 다양한 환경에서 수백 또는 수천 개의 브라우저 테스트를 일관되게 실행할 수 있도록 합니다. 하지만 자동화는 문제의 한 부분, 즉 무언가가 실패했다는 사실을 감지하는 것만을 해결해 줍니다.

더 많은 시간과 노력이 필요한 문제는 종종 실패 이후에 시작됩니다.

CI 파이프라인은 다음과 같이 보고할 수 있습니다:

FAILED checkout.spec.ts 

TimeoutError: 
...

하지만 이 메시지는 엔지니어에게 실제로 무엇이 잘못되었는지 즉시 알려주지 않습니다.

• 애플리케이션에 문제가 있었나요?

• API를 사용할 수 없었나요?

• 테스트 데이터가 잘못되었나요?

• 네트워크 요청이 실패했나요?

• 로케이터(locator)가 구식이 되었나요?

• 경쟁 조건(race condition)이 있었나요?

자동화 스위트가 커짐에 따라, 엔지니어들은 스크린샷을 수집하고, 로그를 확인하고, 트레이스(trace)를 열고, 네트워크 요청을 검사하며, 로컬에서 실패를 재현하는 데 상당한 시간을 할애할 수 있습니다.

이것은 AI에게 기회를 만듭니다.

AI가 테스트를 자율적으로 실행하거나 수정하도록 허용하기보다는, Playwright가 이미 생성한 증거를 소비하고 엔지니어가 검증할 수 있는 증거 기반의 진단을 생성하는 실패 분석 계층으로 사용하는 것이 가능합니다.

결과적인 워크플로우는 다음과 같습니다:

목표는 QA 엔지니어를 대체하는 것이 아니라, ‘테스트가 실패했다’와 ‘왜 실패했을 가능성이 높은지’ 사이의 간극을 줄이는 것입니다.

전통적인 테스트 실패 분석의 문제점

일반적인 Playwright 테스트는 다음과 같을 수 있습니다:

test("사용자가 결제를 완료할 수 있음", async ({ page }) => {

await page.goto("/checkout");
...

만약 테스트가 실패한다고 가정해 봅시다. CI 시스템은 다음 내용만을 보여줄 수 있습니다:

TimeoutError:

"Order confirmed"가 보이지 않음

근본적인 원인은 여러 계층에 존재할 수 있습니다:

따라서 유용한 실패 분석 시스템은 최종 단언(assertion) 메시지보다 더 많은 컨텍스트를 필요로 합니다.

Playwright를 증거 출처로 활용하기

Playwright는 이미 심층 진단을 위해 필요한 여러 아티팩트를 제공합니다.

Trace Viewer를 사용하면 테스트 실행과 관련된 액션 타임라인, DOM 스냅샷, 스크린샷, 콘솔 출력, 네트워크 활동, 소스 정보 및 기타 메타데이터를 노출할 수 있습니다.

실패한 테스트를 다음과 같이 취급하는 대신:

PASS / FAIL

다음과 같이 취급할 수 있습니다:

CI 환경에서 Playwright는 재시도(retry) 시 트레이스 수집과 실패 발생 시 스크린샷을 지원하여, 모든 성공적인 테스트에 대한 전체 진단 아티팩트 세트를 수집하지 않으면서 유용한 디버깅 정보를 제공합니다.

실용적인 설정은 다음과 같습니다:

import { defineConfig } from "@playwright/test"; 

export default defineConfig({
...

그 결과는 훨씬 풍부한 실패 패키지입니다.

AI 지원 실패 분석 아키텍처

제안된 아키텍처는 실행(execution)과 추론(reasoning)을 분리합니다.

이 아키텍처는 Playwright의 역할을 결정론적(deterministic)으로 유지합니다.

AI가 테스트가 통과했는지 실패했는지를 결정하지 않습니다. Playwright가 그 결정을 내립니다. AI는 왜 실패했을 수 있는지 설명하는 데 도움을 줍니다.

구조화된 실패 패키지 구축

전체 CI 작업 공간(CI workspace)을 AI 모델로 전송하는 것은 비효율적이고 잠재적으로 안전하지 않습니다. 대신, 파이프라인은 구조화된 실패 객체(structured failure object)를 생성할 수 있습니다:

interface FailureEvidence {

testName: string; 
...
}

예를 들어:

{

"testName": "checkout payment", 
...
}

이제 AI는 단순히 다음만 받는 대신 구조화된 컨텍스트(structured context)를 갖게 됩니다:

테스트 실패.

왜?

AI가 분석해야 할 내용

AI 계층은 실패를 제어된 범주 세트로 분류할 수 있습니다:

• 애플리케이션 (Application)

• 테스트 (Test)

• 네트워크 (Network)

• 테스트 데이터 (Test Data)

• 환경 (Environment)

• 알 수 없음 (Unknown)

분석 흐름은 다음과 같습니다:

구조화된 프롬프트는 일관된 출력 형식을 장려할 수 있습니다:

제공된 증거만을 사용하여 Playwright 실패를 분석하십시오. 다음 중 하나로 실패를 분류하십시오:

애플리케이션 (APPLICATION)

테스트 (TEST)

네트워크 (NETWORK)

데이터 (DATA)

환경 (ENVIRONMENT)

알 수 없음 (UNKNOWN)

다음 형식으로 반환하십시오:

• 분류 (Classification)

• 개연성 있는 근본 원인 (Probable root cause)

• 뒷받침하는 증거 (Supporting evidence)

• 신뢰도 (Confidence)

• 권장되는 다음 조사 항목 (Recommended next investigation)

정보를 지어내지 마십시오.

테스트를 수정하지 마십시오.

애플리케이션 코드를 수정하지 마십시오.

그러면 AI는 다음과 같은 내용을 반환할 수 있습니다:

증거(evidence)와 AI 해석(interpretation)을 구분하는 것이 중요합니다:

관찰된 증거 (Observed Evidence)

≠

AI 가설 (AI Hypothesis)

예시: 결제 실패 진단하기

Playwright가 다음과 같이 보고한다고 상상해 보세요:

Timeout:

"Order confirmed"가 보이지 않음

전통적인 디버깅 과정은 다음과 같을 수 있습니다:

AI 지원 워크플로우 (AI-assisted workflow)는 이를 통합할 수 있습니다:

엔지니어는 여전히 진단을 검증하지만, 조사는 더 집중된 가설에서 시작됩니다.

AI가 테스트를 자동으로 수정해서는 안 되는 이유

자연스러운 확장 기능은 다음과 같을 것입니다:

이는 심각한 테스트 위험을 초래할 수 있습니다. 애플리케이션에 실제 회귀(regression)가 발생했음에도 불구하고, AI가 로케이터(locator)가 오래되었다고 잘못 결론 내린다고 가정해 봅시다. AI는 테스트를 수정합니다. 테스트는 통과합니다. 하지만 애플리케이션의 결함은 그대로 남아있습니다.

더 안전한 아키텍처는 다음과 같습니다:

따라서 AI는 자율적인 테스트 유지 관리자(autonomous test maintainer)라기보다는 진단 보조 도구(diagnostic assistant)가 되어야 합니다.

보안 및 민감 테스트 데이터 처리

실패 아티팩트(Failure artifacts)에는 민감 정보가 포함될 수 있습니다:

• 액세스 토큰 (Access tokens)
• 쿠키 (Cookies)
• 사용자 정보 (User information)
• API 페이로드 (API payloads)
• 인가 헤더 (Authorization headers)
• 스크린샷 (Screenshots)

따라서 증거(evidence)는 AI 서비스에 도달하기 전에 정제(sanitize)되어야 합니다. 간단한 예시:

function sanitize(value: string): string {

return value 
...

완전한 흐름은 다음과 같습니다:

프로덕션 구현(production implementations)의 경우, 정제는 선택적 개선 사항이라기보다는 아키텍처(architecture)의 일부로 취급되어야 합니다.

AI가 실제로 도움이 되는지 측정하기

이 시스템을 평가하는 핵심 부분은 실험입니다.

AI가 생성한 요약본을 만드는 것은 간단합니다. 더 유용한 질문은 시스템이 허용 가능한 진단 정확도(diagnostic accuracy)를 유지하면서 엔지니어링 노력(engineering effort)을 줄여주는지 여부입니다.

통제된 실험(controlled experiment)에는 다음 내용이 포함될 수 있습니다:

• 10개의 로케이터 실패 (locator failures)
• 10개의 API 실패 (API failures)
• 10개의 네트워크 실패 (network failures)
• 10개의 데이터 실패 (data failures)
• 10개의 환경 실패 (environment failures)

다음 항목들을 비교합니다:

특히 유용한 지표 중 하나는 진단 시간 평균 (Mean Time to Diagnose, MTTD)입니다. 예를 들면 다음과 같습니다:

전통적인 방식:

실패 → 조사 → 근본 원인 분석

18분

AI 지원 방식:

실패 → AI 분석 → 검증 → 근본 원인 분석

5분 2분

이러한 수치들은 가정이 아닌 실제 실험에서 나온 것이어야 합니다.

AI 지원 진단의 실패 모드

AI가 디버깅 문제를 완전히 없애주는 것은 아닙니다. 오히려 또 다른 종류의 잠재적 실패 계층을 도입합니다.

• 시스템이 애플리케이션 결함을 테스트 결함으로 분류할 수 있습니다.

• 충분한 증거가 없을 때 그럴듯한 설명을 생성할 수 있습니다.

• 애플리케이션에 존재하지 않았던 동작을 추론할 수 있습니다.

• 사용 가능한 증거가 불완전할 때 과도하게 자신감을 가질 수 있습니다.

따라서 시스템은 명시적인 알 수 없는 상태(unknown state)를 지원해야 합니다: