AI를 사용하여 브라우저 테스트를 생성하는 것은 거의 코믹할 정도로 쉬워졌습니다.

Claude, ChatGPT, Copilot 또는 다른 코딩 어시스턴트(coding assistant)에 요구 사항을 붙여넣기만 하면 됩니다. 몇 초 후면 Playwright 테스트, 픽스처(fixtures), 페이지 오브젝트(page objects), 그리고 설정 파일(configuration files)로 가득 찬 폴더를 갖게 됩니다.

심지어 테스트가 통과할 수도 있습니다.

이는 위험한 순간을 초래하는데, 그 이유는 출력물이 실제보다 훨씬 더 완성된 시스템처럼 보이기 때문입니다.

생성된 테스트 스위트(test suite)가 가치 있는 이유는 많은 테스트를 포함하고 있기 때문이 아닙니다. 팀이 이를 이해하고, 신뢰하며, 유지 관리하고, 그 결과를 사용하여 릴리스 결정을 내릴 수 있을 때 비로소 가치가 있습니다.

이것들은 매우 다른 개념입니다.

데모는 제품이 아니다

대부분의 AI 테스트 생성 데모는 동일한 경로를 따릅니다:

1. 모델에 사용자 스토리(user story)를 제공합니다.
2. 테스트 생성을 요청합니다.
3. 테스트를 실행합니다.
4. 여러 개의 초록색 체크 표시를 보여줍니다.

이는 모델이 실행 가능한 코드(executable code)를 생성할 수 있음을 증명합니다. 하지만 결과물인 스위트가 올바른 리스크(risks)를 커버하고 있다는 것을 증명하지는 않습니다.

생성된 스위트를 신뢰하기 전에, QA 팀은 테스트의 개수나 초기 통과율보다 훨씬 더 많은 것을 측정해야 합니다. Claude 또는 다른 코딩 어시스턴트에 의해 생성된 테스트 스위트를 신뢰하기 전에 QA 팀이 측정해야 할 사항에 관한 이 가이드는 중요한 신호들을 다룹니다: 유용한 커버리지(coverage), 잘못된 확신(false confidence), 유지 관리성(maintainability), 실패의 명확성(failure clarity), 그리고 실제 회귀(regressions)를 탐지하는 스위트의 능력입니다.

300개의 생성된 테스트가 포함된 스위트가 신중하게 선택된 30개의 테스트보다 덜 유용할 수 있습니다.

더 큰 스위트는 더 많은 노이즈, 더 많은 중복된 설정(setup), 더 취약한 셀렉터(selectors), 그리고 아무도 이해하지 못하는 실패의 기회들을 만들어낼 수 있습니다.

AI는 당신이 이미 가지고 있는 프로세스를 확장할 뿐이다

AI는 약한 테스트 전략을 자동으로 고쳐주지 않습니다.

그것은 단지 그 전략을 확장(scale)할 뿐입니다.

요구사항이 모호하면 생성된 테스트도 모호합니다. 애플리케이션의 테스트 데이터가 일관되지 않으면, AI는 일관되지 않은 데이터를 중심으로 더 많은 코드를 생성합니다. 팀이 무엇을 테스트해야 할지에 대해 합의하지 못하면, 모델은 그 공백을 추측(assumptions)으로 채워버립니다.

이것이 테스트 자동화에서의 환각 (hallucinations)이 단순히 모델 품질의 문제만이 아닌 이유입니다. 그것은 종종 입력 품질 (input-quality) 및 아키텍처 (architecture)의 문제입니다.

테스트 자동화에서 AI 환각을 줄이는 방법에 관한 실무 가이드는 중요한 차이점을 설명합니다. 즉, 더 많은 컨텍스트 (context)를 보낼수록, 그리고 그 컨텍스트가 구조화되어 있지 않을수록, 모델이 세부 사항을 지어낼 기회는 더 많아집니다.

당연한 대응책은 프롬프트 (prompt)를 개선하는 것입니다. 그것도 도움이 되지만, 어느 정도까지만 그렇습니다.

더 나은 장기적 접근 방식은 모델이 추론 (infer)해야 하는 양을 줄이는 것입니다.

AI 어시스턴트에게 거대한 Playwright 프레임워크를 반복해서 재구성해 달라고 요청하는 대신, 팀은 테스트를 구조화된 인간 가독성 형식 (human-readable format)으로 저장할 수 있습니다. AI는 전체 구현을 다시 생성할 필요 없이 개별 동작을 생성하거나 수정하는 데 도움을 줄 수 있습니다.

이것이 AI 테스트 자동화 실무 가이드에서 제시하는 더 유용한 아이디어 중 하나입니다. 즉, AI를 사용하여 작업량을 줄이되, 결과물인 테스트는 가시적이고 편집 가능하게 유지하는 것입니다.

시스템이 자율적일수록 로깅 (Logging)이 더 중요해집니다

사람이 작성한 브라우저 테스트는 일반적으로 알려진 일련의 동작을 수행합니다.

반면 AI 에이전트 (agent)는 페이지를 검사하고, 동작을 선택하고, 실패하고, 화면을 재해석하고, 재시도하고, 다른 로케이터 (locator)를 선택하며 계속 진행할 수 있습니다.

그러한 유연성은 에이전트를 더 탄력적 (resilient)으로 만들 수 있습니다. 하지만 동시에 실패 원인을 파악하기 훨씬 어렵게 만들 수도 있습니다.

에이전트가 버튼을 세 번 클릭하려고 시도한다고 가정해 봅시다. 네 번째 시도에서 유사한 레이블을 가진 텍스트 링크를 선택하여 다음 페이지에 도달했습니다.

테스트가 지능적으로 복구된 것일까요?

아니면 의도된 경로에 대한 테스트를 중단한 것일까요?

적절한 증거가 없다면, 당신은 알 수 없습니다.

최소한, 실행(run) 시 다음 사항들이 보존되어야 합니다:

• 원래의 목표 (The original goal)
• 선택된 동작 (The chosen action)
• 로케이터(locator) 또는 대상 (The target)
• 동작 전의 페이지 상태 (The page state before the action)
• 브라우저가 반환한 에러 (The error returned by the browser)
• 모든 재시도와 그 이유 (Every retry and the reason for it)
• 선택된 대안 전략 (The alternative strategy selected)
• 스크린샷 및 DOM 증거 (Screenshots and DOM evidence)
• 최종 결과 (The final outcome)

AI 테스트 에이전트가 브라우저 단계를 재시도했음에도 여전히 실패할 때 무엇을 로그로 남겨야 하는가에 관한 이 기사는 유용한 시작점을 제공합니다.

더 복잡한 시스템의 경우, 일반적인 텍스트 로그만으로는 충분한 경우가 거의 없습니다. OpenTelemetry 스팬(spans), 구조화된 로그(structured logs), 그리고 재현 가능한 아티팩트(replayable artifacts)를 사용하여 AI 테스트 에이전트를 계측(instrumenting)하는 것은 팀이 에이전트의 결정을 재구성(reconstruct)할 수 있는 더 나은 방법을 제공합니다.

중요한 단어는 **재구성(reconstruct)**입니다.

자율 테스트가 실패했을 때, 조사하는 사람은 에이전트가 무엇을 하고 있다고 믿었는지 추측해야만 해서는 안 됩니다.

프롬프트 드리프트(Prompt drift)는 테스트 드리프트(test drift)가 된다

전통적인 브라우저 테스트는 보통 애플리케이션이 변경되기 때문에 실패합니다.

AI 보조 테스트는 또 다른 변화의 원인을 도입합니다: 바로 프롬프트(prompt)입니다.

작은 프롬프트 수정만으로도 어떤 경로가 선택될지, 어서션(assertion)이 어떻게 해석될지, 그리고 시스템이 무엇을 성공적인 결과로 간주할지를 변경할 수 있습니다.

프롬프트가 변경되지 않더라도, 기반이 되는 모델(model)이 변경될 때 동일한 현상이 발생합니다.

이는 팀이 테스트 코드 이상의 것에 대한 버전 관리(versioning)가 필요함을 의미합니다. 다음 사항들을 보존해야 할 수도 있습니다:

• 프롬프트 버전 (Prompt versions)
• 모델 또는 에이전트 설정 (Model or agent configuration)
• 입력 데이터셋 (Input datasets)
• 생성된 단계 (Generated steps)
• 인간의 승인 (Human approvals)
• 예상 출력 (Expected outputs)
• 스크린샷 및 증거 (Screenshots and evidence)
• 생성된 변경 사항이 수락된 이유 (The reason a generated change was accepted)

프롬프트 재생(prompt replay), 인간 검토(human review), 그리고 증거 보존(evidence retention)에 관한 기사는 AI가 생성한 동작이 릴리스 프로세스(release process)에 진입했을 때 왜 이러한 기능들이 중요한지를 설명합니다.

마찬가지로, 프롬프트 변경으로 인해 UI 신호를 신뢰하기 어려워질 때 AI 테스트 플랫폼을 선택하는 방법에 대한 이 가이드는 많은 팀이 뒤늦게 발견하는 문제를 강조합니다. 즉, 실행 간에 무엇이 일관되게 유지되었는지 이해하지 못한다면 통과(passing) 결과는 유용하지 않다는 점입니다.

AI 인터페이스는 새로운 범주의 어설션(assertions)을 생성합니다

AI 기능을 테스트하는 것은 결정론적(deterministic)인 형태를 테스트하는 것과 같지 않습니다.

전통적인 애플리케이션은 고정된 검증 메시지를 반환할 수 있습니다. 반면 AI 어시스턴트는 서로 다른 문구로 여러 개의 유효한 답변을 생성할 수 있습니다.

이로 인해 질문의 성격이 다음과 같이 변합니다:

출력이 이 문자열과 정확히 일치했는가?

에서:

출력이 중요한 제약 조건(constraints)을 위반하지 않으면서 사용자의 목표를 충족했는가?

로 바뀝니다.

AI가 생성한 카피(copy)를 생각해 보십시오. 텍스트는 의미론적으로(semantically)는 정확할 수 있지만, 지나치게 긴 문장, 지원되지 않는 문자, 누락된 접근성 레이블(accessible labels), 또는 불량한 현지화(localization)를 통해 인터페이스를 망가뜨릴 수 있습니다. 웹 인터페이스에서 AI 생성 카피를 테스트하는 것에 관한 기사는 이러한 덜 명확한 실패 모드(failure modes)를 다룹니다.

폼 어시스턴트(Form assistants)도 유사한 복잡성을 유발합니다. 단순히 제안이 나타나는지 여부뿐만 아니라, 사용자가 이를 거부할 수 있는지, 편집할 수 있는지, 잘못된 제안으로부터 복구할 수 있는지, 그리고 상태(state)를 재설정할 수 있는지도 테스트해야 합니다. AI 기반 폼 어시스턴트 테스트에 대한 이 실무적인 관점은 그러한 흐름(flows)을 더 깊이 있게 다룹니다.

플로팅 코파일럿(Floating copilots)과 AI 사이드바(AI sidebars)는 또 다른 문제들을 도입합니다. 이들은 제어 장치를 가리거나, 오래된 컨텍스트를 유지하거나, 다시 열릴 때 다르게 작동할 수 있습니다. Endtest와 Playwright를 사용한 AI 사이드바 및 플로팅 명령어 패널 테스트 비교는 겉보기에 간단해 보이는 채팅 패널이 얼마나 빨리 상태 관리(state-management) 문제로 변할 수 있는지 보여줍니다.

RAG 테스트에는 신뢰도보다 증거가 필요하다

검색 증강 생성(Retrieval-augmented generation, RAG) 애플리케이션은 특히 잘못 테스트하기 쉽습니다.

챗봇이 다듬어진 답변을 제공하고, 그 답변이 합리적으로 들리며, 테스트가 통과합니다.

하지만 진짜 질문들은 다음과 같습니다:

• 올바른 문서들이 검색되었는가?
• 답변이 해당 문서들을 반영했는가?
• 인용(citation)이 올바른 주장에 첨부되었는가?
• 시스템이 오래되거나 승인되지 않은 출처를 무시했는가?
• 랭킹 변화가 답변을 변경했는가?
• 결과를 재현할 수 있는가?

RAG 챗봇, 검색 드리프트(retrieval drift), 및 출처-인용 흐름 테스트에 대한 실질적인 검토는 최종 텍스트만으로는 충분하지 않은 이유를 보여줍니다.

더 넓은 관점에서, AI 검색 및 재랭킹 검증을 위한 브라우저 테스트 플랫폼 시장 지도는 사용 가능한 도구에 대해 생각하는 데 유용한 방법을 제공합니다.

시스템은 모델 문제인지, 검색 문제인지, 랭킹 문제인지, 권한 문제인지, 아니면 프론트엔드 문제인지를 구별할 수 있을 만큼 충분한 증거를 기록해야 합니다. 그렇지 않으면 모든 실패가 “AI가 잘못된 답변을 했다”는 것이 되어 조치가 불가능합니다.

저렴한 옵션이 항상 무료 프레임워크는 아니다

오픈 소스 라이브러리는 다운로드하기에 비용이 적게 듭니다. 하지만 그 주변을 구축하는 시스템은 전혀 저렴하지 않을 수도 있습니다.

테스트 생성 (test generation), 프레임워크 설계 (framework design), 코드 리뷰 (code review), CI 통합 (CI integration), 디버깅 (debugging), 리포팅 (reporting), 테스트 데이터 관리 (test-data management), 브라우저 인프라 (browser infrastructure), 재시도 (retries), 아티팩트 저장소 (artifact storage), 그리고 지속적인 유지보수 (ongoing maintenance)가 존재합니다.

AI는 그 작업 중 일부를 줄여줄 수 있습니다. 하지만 AI는 팀이 현실적으로 리뷰할 수 있는 것보다 더 많은 코드를 생성할 수도 있습니다.

이것이 바로 affordable AI test automation에 관한 논의가 라이선스 비용 (licence cost)보다는 총 비용 (total cost)에 집중해야 하는 이유입니다.

생성된 Playwright 리포지토리 (repository)는 가장 좁은 의미에서는 무료일 수 있습니다. 하지만 여러 명의 엔지니어가 매 스프린트(sprint)마다 이를 수리하고, 설명하고, 인프라를 재구축하는 데 시간을 보낸다면, 비즈니스적인 관점에서는 결코 무료가 아닙니다.

테스트가 지원해야 할 결정부터 시작하십시오

가장 유용한 질문은 다음과 같은 것이 아닙니다:

AI가 우리를 위해 얼마나 많은 테스트를 생성할 수 있는가?

진정으로 유용한 질문은 다음과 같습니다:

이 테스트들이 우리가 어떤 릴리스 결정 (release decision)을 내리는 데 도움을 줄 것인가?

이 점이 명확해지면 나머지는 더 쉬워집니다.

가장 작고 유용한 범위 (scope)를 선택하고, 필요한 증거를 정의하며, 에이전트의 자율성 (agent autonomy)을 제한하고, 생성된 단계 (steps)를 보존하며, 인간의 리뷰 (human review)가 어디에 위치해야 할지를 결정할 수 있습니다.

AI는 테스트를 만드는 데 필요한 작업을 극적으로 줄여줄 수 있습니다.

하지만 AI는 당신의 조직이 무엇을 신뢰해야 하는지 결정할 수는 없습니다.

그것은 여전히 팀의 몫으로 남아 있습니다.