AI는 테스트 자동화의 첫 한 시간을 극적으로 저렴하게 만들었습니다.

워크플로우를 설명하거나, 요구사항을 붙여넣거나, 에이전트(Agent)를 애플리케이션으로 안내하기만 하면, AI는 준수한 초안을 만들어낼 수 있습니다. 생성된 코드에는 페이지 오브젝트(Page Objects), 픽스처(Fixtures), 어설션(Assertions), 그리고 주석이 포함될 수 있습니다. 이는 진전처럼 보이며, 실제로 진전이기 때문입니다.

하지만 생성은 결코 전체 비용이 아니었습니다.

비싼 부분은 테스트가 저장소(Repository)에 합류한 이후에 시작됩니다.

이제 팀은 어설션(Assertions)이 의미가 있는지, 셀렉터(Selectors)가 내구성이 있는지, 데이터가 안전한지, 테스트가 올바른 이유로 실패하는지, 그리고 6개월 후 인터페이스가 변경되었을 때 누가 이를 수정할 것인지를 결정해야 합니다.

AI는 테스트를 생성하는 비용을 낮춰줍니다. 하지만 동시에 여러분이 책임져야 할 테스트의 수를 늘릴 수도 있습니다.

이것이 팀이 이해해야 할 트레이드오프(Trade-off)입니다.

생성된 코드는 생성된 테스트가 실행되기도 전에 실패할 수 있습니다

AI가 생성한 프론트엔드 변경 사항은 로컬 환경에서는 잘 작동하다가 CI(지속적 통합) 환경에서는 실패하는 경우가 빈번합니다. 문제는 항상 생성된 코드의 품질 때문만은 아닙니다. 그 주변에 결여된 컨텍스트(Context)가 문제입니다.

CI 환경은 다른 Node 버전, 패키지 락(Package lock) 상태, 브라우저 빌드, 환경 변수 설정, 피처 플래그(Feature flag), 운영 체제 또는 리소스 제한을 사용할 수 있습니다.

로컬 실행은 통과하더라도 AI가 생성한 프론트엔드 변경 사항이 CI에서 실패하는 이유에 대한 이 분석은 중요한 원칙을 강조합니다: AI는 자신이 볼 수 있는 컨텍스트를 최적화하는 경향이 있다는 점입니다.

만약 모델이 컴포넌트(Component)는 보지만 파이프라인(Pipeline)을 보지 못한다면, 보이지 않는 제약 조건을 위반하는 로컬에서만 유효한 솔루션을 만들 수 있습니다.

생성된 테스트에서도 동일한 일이 발생합니다. 모델은 다음과 같은 상황을 가정할 수 있습니다:

• 깨끗한 데이터베이스
• 하나의 브라우저 워커(Browser worker)
• 안정적인 테스트 ID
• 즉각적인 API 응답
• 임의의 사용자를 생성할 수 있는 권한
• CI에는 존재하지 않는 비밀값(Secrets)에 대한 접근 권한
• 데스크톱 뷰포트(Viewport)
• 영어 문구

유용한 생성 프롬프트(Generation prompt)는 사용자 여정(User journey)뿐만 아니라 운영 제약 사항(Operational constraints)도 포함해야 합니다.

모델에게 테스트가 어디서 실행되는지, 데이터가 어떻게 생성되는지, 무엇이 병렬로 실행될 수 있는지, 어떤 셀렉터(Selector)가 선호되는지, 그리고 실패 시 어떤 증거(Evidence)를 캡처해야 하는지를 알려주어야 합니다.

프롬프트는 테스트 아키텍처(Test architecture)의 일부입니다.

Claude는 Playwright를 작성할 수 있습니다. 하지만 그것이 결정 사항은 아닙니다

최신 코딩 모델은 Playwright 테스트를 빠르게 생성할 수 있습니다. 또한 헬퍼(Helper)를 리팩터링하고, 에러 로그를 해석하며, 대안 셀렉터를 제안할 수도 있습니다.

흥미로운 질문은 모델이 코드를 작성할 수 있는지 여부가 아닙니다. 작성할 수 있습니다.

더 나은 질문은 생성이 풍부해진 이후에 유지보수(Maintenance), 리뷰(Review), 그리고 신호 품질(Signal quality) 측면에서 무엇이 변하는가입니다.

When Claude Writes Your Playwright Tests라는 기사는 이러한 변화를 잘 설명하고 있습니다. 리뷰어는 구문(Syntax) 이상의 것을 평가해야 합니다.

생성된 테스트는 완벽하게 유효한 TypeScript일 수 있지만, 다음과 같은 이유로 형편없는 테스트가 될 수 있습니다:

• 부수적인 문구(Incidental copy)를 단언(Assert)함
• 여러 요소와 일치하는 셀렉터를 사용함
• 신뢰할 수 없는 동작을 재시도(Retries) 뒤로 숨김
• 이미 존재하는 커버리지(Coverage)를 중복함
• 부정적 동작(Negative behaviour)을 건너뜀
• 낙관적 업데이트(Optimistic update) 이후 서버 확인 전에 통과함
• 생성한 데이터를 전혀 정리(Clean up)하지 않음

생성된 테스트에 대한 코드 리뷰는 의도(Intent)에서 시작해야 합니다:

1. 이 테스트가 줄이는 제품 리스크(Product risk)는 무엇인가?
2. 어떤 실패를 잡아낼 수 있는가?
3. 왜 브라우저(Browser) 계층이 적절한가?
4. 제품이 고장 났을 때 테스트가 실패하는가?
5. 팀이 실패 보고서(Failure report)를 이해할 수 있는가?

그다음에야 리뷰어는 포맷팅(Formatting)과 헬퍼 재사용(Helper reuse)에 신경을 써야 합니다.

테스트 개수는 허영 지표(Vanity metric)가 될 수 있습니다

생성 비용이 많이 들 때는 팀이 선택적으로 테스트를 만듭니다. 하지만 생성이 거의 무료가 되면, 절제(Restraint)가 더욱 중요해집니다.

요구사항, 티켓, 그리고 녹화된 세션으로부터 200개의 테스트를 만들어내는 것은 쉽습니다. 그 숫자는 인상적으로 보입니다. 그러다 제품이 변경되면 47개의 테스트가 실패하고, 그중 어떤 실패가 중요한지 아무도 알지 못하게 됩니다.

Claude로 생성된 Playwright 테스트 스위트를 신뢰하기 전에 측정해야 할 것에 관한 이 프레임워크는 테스트 스위트를 코드 출력물(code output)이 아닌 하나의 운영 체제(operating system)로서 측정할 것을 권장합니다.

유용한 지표는 다음과 같습니다:

• 실제 결함(defects)을 나타내는 실패의 비율;
• 중앙값 진단 시간(median diagnosis time);
• 월간 유지보수 시간;
• 동일한 원인으로 인한 반복적인 실패;
• 핵심 워크플로우(critical workflows)의 커버리지;
• 의미 있는 실패를 한 번도 겪지 않은 테스트;
• 그린 파이프라인(green pipeline)을 위해 필요한 재시도(retries) 횟수;
• 생성된 테스트당 리뷰어의 노력.

마지막 지표가 중요합니다. 모델은 몇 초 만에 코드를 생성할 수 있지만, 시니어 엔지니어는 그 코드가 안전하고 유용한지 증명하는 데 20분을 소비할 수도 있습니다.

AI는 리뷰 비용을 없애지 않습니다. 단지 업무의 위치를 옮길 뿐입니다.

AI 테스트 플랫폼에도 인간의 업무가 포함되어 있습니다

어떤 플랫폼은 AI 생성 테스트, 셀프 힐링(self-healing), 자연어 지침, 또는 자율 유지보수를 광고할 수 있습니다. 이러한 기능들은 노력을 줄여줄 수 있습니다. 하지만 동시에 다음과 같은 새로운 운영 작업들을 유발할 수도 있습니다:

• 생성된 단계(steps) 검토;
• 프롬프트(prompts) 검증;
• 트레이스(traces) 조사;
• 제안된 수정 사항 승인;
• 모호한 어설션(assertions) 해결;
• 모델 사용량 모니터링;
• 잘못된 복구(false repairs) 처리.

프롬프트 리뷰, 트레이스, 그리고 인간의 승인이 쌓일 때 AI 테스트 플랫폼의 실제 비용을 추정하는 방법에 관한 기사는 더 건강한 비용 모델을 제시합니다.

구독 가격만을 오픈 소스 라이선스 가격과 비교하지 마십시오.

전체 워크플로우를 비교하십시오:

총 비용 = 플랫폼 비용
           + 테스트 생성 시간
           + 리뷰 시간
...

자체 구축한 프레임워크(home-grown framework)에도 동일한 방정식을 적용해야 합니다.

전문 엔지니어들이 매 스프린트(sprint)의 상당 부분을 유지보수에 소비한다면, "무료" 소프트웨어는 비쌀 수 있습니다. 유료 플랫폼 또한 지속적인 인간의 감독이 필요하다면 비쌀 수 있습니다.

올바른 단위는 라이선스 비용(licence cost)이 아닙니다. 신뢰할 수 있는 결과당 비용(cost per trustworthy result)입니다.

구축(Build) 대 구매(Buy)는 대부분 인력 배치(staffing)의 결정입니다

빠르게 변화하는 프론트엔드를 위한 Endtest와 직접 만든 Playwright의 비교는 이 결정을 소유권(ownership)의 관점에서 구성합니다.

커스텀 Playwright 프레임워크는 탁월한 제어력을 제공할 수 있습니다. 팀은 피스처(fixtures), 추상화(abstractions), 리포터(reporters), 환경 관리(environment management), 그리고 CI 동작을 필요한 방식 그대로 정의할 수 있습니다.

하지만 누군가가 이 모든 것을 책임져야 합니다.

그 소유권에는 다음 사항들이 포함됩니다:

• 브라우저 및 의존성(dependency) 업그레이드
• 인증 헬퍼(authentication helpers)
• 테스트 데이터 유틸리티(test-data utilities)
• 병렬 실행 규칙(parallel execution rules)
• 재시도 전략(retry strategy)
• 스크린샷, 비디오, 트레이스(traces) 및 로그
• 이메일, SMS 및 스토리지와의 통합
• 온보딩 문서(onboarding documentation)
• 기술적 숙련도가 낮은 기여자(contributors)를 위한 지원

Endtest와 같은 관리형 시스템(managed system)은 프레임워크 수준의 자유도를 일부 양보하는 대신, 내부 유지보수 범위를 줄이고 접근성을 넓힙니다.

어느 모델이 자동으로 더 낫다고 할 수는 없습니다.

실수는 초기 개념 증명(proof of concept)이 쉬웠다는 이유로 코드 우선(code-first) 프레임워크를 선택한 다음, 팀이 의도치 않게 내부 제품을 만들어냈다는 사실을 뒤늦게 깨닫는 것입니다.

유용한 질문은 다음과 같습니다:

우리는 테스트를 구축하고 싶은 것인가, 아니면 테스트 플랫폼을 구축하고 운영하는 것까지 원하는 것인가?

어떤 조직은 "예"라고 답해야 하겠지만, 많은 조직은 그렇지 않을 것입니다.

스트리밍 AI 애플리케이션의 신뢰성은 다릅니다

AI 애플리케이션은 전통적인 CRUD 테스트에서는 자주 접하지 못하는 동작들을 도입합니다:

• 스트리밍된 텍스트가 점진적으로 도착함;
• 응답이 진행되는 동안 UI가 변경됨;
• 중간 상태(intermediate state)가 불완전할 수 있지만 유효함;
• 모델 출력(model outputs)이 가변적임;
• 취소(cancellations) 및 재시도(retries)가 중요함;
• 네트워크 지연(network latency)이 렌더링 순서를 변경함.

취약한(brittle) 테스트는 정확한 텍스트를 기다리거나, 고정된 업데이트 횟수를 가정하거나, 스트림이 완료되기 전에 상호작용을 시도할 수 있습니다.

응답을 스트리밍하고 상태를 점진적으로 업데이트하는 AI 앱을 위한 브라우저 테스트 신뢰성 벤치마킹 가이드에서는 정밀한 출력(precise output)보다는 상태 머신(state machine)을 테스트할 것을 권장합니다.

예를 들어, 다음 사항들을 검증하십시오:

• 응답이 허용 가능한 기간 내에 시작되는지;
• 로딩 또는 스트리밍 상태가 보이는지;
• 콘텐츠가 잘못 교체되는 대신 점진적으로 늘어나는지;
• 컨트롤이 적절한 시점에 활성화 또는 비활성화되는지;
• 취소 시 스트림이 중단되는지;
• 최종 상태가 올바르게 유지(persisted)되는지;
• 에러 발생 시 복구 작업(recovery action)을 제공하는지.

비결정론적(non-deterministic) 콘텐츠의 경우, 완전한 문장 대신 구조와 제약 조건(constraints)을 단언(assert)하십시오.

응답이 비어 있지 않은지, 필요한 사실을 포함하는지, 스키마(schema)를 따르는지, 금지된 콘텐츠를 피하는지, 또는 허용 가능한 평가 점수를 받는지 확인할 수 있습니다.

제품이 더 가변적일수록, 오라클(oracle)은 더 의도적(deliberate)이어야 합니다.

안정적인 커버리지에는 무거운 프레임워크가 필요하지 않습니다

어떤 팀은 프레임워크에 대한 깊은 제어가 필요합니다. 반면, 다른 팀들은 테스트 인프라에 여러 명의 엔지니어를 투입하지 않고도 비즈니스 핵심 여정(business-critical journeys)에 대한 신뢰할 수 있는 커버리지만을 주로 필요로 합니다.

무거운 프레임워크 없이 안정적인 커버리지가 필요한 팀을 위한 Endtest 실무 리뷰는 두 번째 그룹을 대변합니다.

이 가치 제안(value proposition)은 코드가 나쁘다는 것이 아닙니다. 인프라 작업에는 기회비용(opportunity cost)이 따른다는 것입니다.

자체적인 리포팅(reporting), 테스트 에디터(test editor), 실행 그리드(execution grid), 협업 레이어(collaboration layer), 그리고 통합(integrations) 기능을 구축하는 것을 피하는 팀은 그 시간을 제품 커버리지(product coverage)를 개선하는 데 사용할 수 있습니다.

그 대가(trade-off)는 플랫폼의 모델과 한계를 수용하는 것입니다. 이것이 바로 개념 증명(proof of concept) 단계에서 단순히 로그인뿐만 아니라 까다로운 워크플로(workflows)를 테스트해야 하는 이유입니다.

다음 사항들을 시도해 보세요:

• 다단계 인증 (multi-step authentication)
• 파일 업로드 및 다운로드
• 동적 테이블 (dynamic tables)
• 교차 도메인 탐색 (cross-domain navigation)
• 이메일 및 SMS 인증
• 실패 진단 (failure diagnosis)
• 역할 기반 협업 (role-based collaboration)
• 실제 병렬성(parallelism) 환경에서의 CI 실행

데모가 "페이지를 열고 버튼을 클릭하는 것"뿐이라면 어떤 도구든 좋아 보입니다.

인간의 승인은 리스크에 집중해야 합니다

AI가 생성한 테스트가 위원회 회의를 필요로 해서는 안 됩니다. 하지만 그 영향력(impact)에 비례하는 검토를 받아야 합니다.

내부 페이지에 대한 저위험 시각적 확인(visual check)은 빠른 점검만으로 충분할 수 있습니다. 하지만 결제, 액세스 제어(access-control), 삭제, 또는 규제 관련 워크플로는 더 깊은 검토를 거쳐야 합니다.

가벼운 승인 체크리스트로 다음을 질문할 수 있습니다:

• 이 워크플로가 브라우저 레이어(browser layer)에서 테스트할 가치가 있는가?
• 비밀 정보(secrets)와 개인 데이터가 안전하게 처리되는가?
• 테스트를 병렬로 실행할 수 있는가?
• 어설션(assertions)이 사용자 결과(user outcomes)와 연결되어 있는가?
• 실패 시 충분한 증거를 생성하는가?
• 정리(cleanup) 작업이 정의되어 있는가?
• 향후 유지보수의 책임은 누구에게 있는가?

이는 두 가지 흔한 극단적인 상황, 즉 생성된 코드를 맹목적으로 수용하거나 AI 지원을 너무 관료적으로 만들어 아무도 사용하지 않게 되는 상황을 방지합니다.

목표는 완벽한 생성이 아닙니다.

목표는 통제된 레버리지(controlled leverage)입니다.

새로운 병목 구간은 판단력입니다

수년 동안 브라우저 자동화의 병목 구간(bottleneck)은 코드를 작성하는 것이었습니다.

AI는 그 병목 구간의 일부를 제거하고 있습니다.

남아 있는 것은 판단력(judgement)입니다:

• 적절한 리스크 선택
• 적절한 테스트 레이어 결정
• 안정적인 어설션(assertions) 정의
• 테스트 데이터 제어
• 실패 평가
• 가치가 낮은 커버리지 삭제
• 어떤 인프라를 직접 소유할지 선택

이는 좋은 소식입니다. 이것들은 로케이터(locator)의 구문을 기억하는 것보다 훨씬 더 가치 있는 문제들입니다.

하지만 이것들은 자동으로 이루어지지 않습니다.

AI는 테스트를 작성할 수 있습니다.

하지만 그것을 신뢰할 수 있는지 여부는 여전히 여러분의 팀이 책임져야 할 몫입니다.