테스트 스위트가 당신에게 거짓말을 할 때

QA 엔지니어들이 잘 알고 있는 특정한 좌절감이 있습니다. 누군가 새로운 코드를 푸시할 때마다 테스트를 실행하는 자동화 시스템인 CI 대시보드를 열었는데, 빨간색이 보입니다. 곳곳에 실패(Failures)가 발생해 있습니다. 실제 버그를 예상하며 로그를 확인하지만, 대신 깨진 로케이터(locator)를 발견하게 됩니다. 로케이터는 테스트 스크립트가 웹페이지의 요소(element), 즉 버튼, 필드, 드롭다운 등을 찾는 방식입니다. 예를 들어 "ID가 submit-btn인 요소를 찾으시오"라고 되어 있을 수 있습니다. 하지만 개발자가 지난 화요일에 그 버튼의 이름을 변경했습니다. 기능은 정상적으로 작동합니다. 단지 당신의 테스트가 아직 그 사실을 모를 뿐입니다. 그래서 당신은 고장 나지 않은 것을 고치는 데 40분을 소비합니다. 그러고 나서 내용을 작성하고 다시 실행하지만, 3주 후에 다른 곳에서 똑같은 일이 발생합니다. 이것이 일상적인 자동화 QA 업무입니다. 그리고 이것은 기술의 문제가 아니라 유지보수 오버헤드(maintenance overhead)의 문제입니다.

테스트에서 무엇이 깨지는가 (그리고 왜)
자동화 테스트(Automated testing)란 앱의 동작을 확인하는 스크립트를 작성하는 것을 의미하며, 이를 통해 무언가를 배포할 때마다 매번 UI를 수동으로 클릭할 필요가 없게 해줍니다. 그 약속은 속도와 신뢰성입니다. 하지만 현실은 더 복잡합니다. 테스트 스크립트는 DOM(웹페이지 HTML의 구조)이 작고 미적인 방식으로 변경될 때 깨집니다. 클래스 이름(class name)이 업데이트되거나, 버튼이 이동하는 식입니다. 이 중 어느 것도 버그는 아니지만, 실패를 유발합니다. 새로운 테스트를 작성하는 것도 느립니다. QA 엔지니어는 요구사항을 테스트 시나리오로 변환하는 데 며칠을 보낼 수 있고, 이를 코드로 바꾸는 데 또 며칠을 보낼 수 있습니다. 그리고 무언가 실패했을 때, 재현(reproduce), 조사(inspect), 추적(trace), 수정(fix), 재실행(re-run)으로 이어지는 디버깅 루프(debugging loop)는 몇 시간을 잡아먹습니다. 이것이 바로 AI 지원 도구들이 진입하고 있는 격차입니다.

Playwright 에이전트가 하는 일
Playwright는 안정성과 스마트한 요소 탐지(element detection)로 알려진 오픈 소스 브라우저 테스트 프레임워크입니다. 버전 1.56에서 테스트 라이프사이클(testing lifecycle)에 내장된 세 가지 AI 지원 워크플로우인 Test Agents를 도입했습니다. 이것들은 마법이 아닙니다. 당신이 직접 작성해야 했을 것들을 초안으로 작성하고, 자신의 작업물을 스스로 확인하는 유능한 조수와 더 비슷합니다.

Planner는 당신이 무엇을 테스트하고 싶은지에 대한 평이한 영어 설명을 받아 구조화된 테스트 계획 (test plan)을 생성합니다. 코드가 작성되기 전에, Planner는 작은 "시드 테스트 (seed test)"를 사용하여 적절한 시작 지점으로 이동하고, 발견된 흐름을 문서화하며 애플리케이션의 라이브 버전과 상호작용합니다. 출력물은 사람이 코드가 생성되기 전에 검토하고 편집할 수 있는 읽기 쉬운 Markdown 파일입니다. 그 검토 단계는 매우 중요합니다. 계획은 체크포인트이지, 최종 정답이 아닙니다. Generator는 승인된 계획을 실행 가능한 Playwright 스크립트로 변환합니다. ChatGPT에 프롬프트를 붙여넣는 것과 달리, Generator는 작성하는 동안 실제로 당신의 애플리케이션과 상호작용하며, 로케이터 (locator)가 존재하는지 확인하고, 어설션 (assertion)이 실제 동작을 반영하는지 검증합니다. 또한 Page Object Model과 같은 아키텍처 패턴을 따르도록 지시할 수도 있습니다. 이는 로케이터 정의를 별도의 "페이지 (page)" 파일에 두어 테스트 로직을 깔끔하고 유지보수 가능하게 유지하는 일반적인 접근 방식입니다. Healer는 아마도 가장 즉각적으로 유용한 부분일 것입니다. 테스트가 실패하면, Healer는 디버그 모드 (debug mode)로 테스트를 재실행하고, 실패 지점의 DOM을 조사하여 무엇이 변경되었는지 식별하려고 시도합니다. 만약 클래스 이름이 업데이트되어 로케이터가 깨졌다면, Healer는 동등한 요소를 찾아 수정안을 제안합니다. 만약 실패가 실제 버그를 반영하는 것이라면, 조용히 패치하는 대신 이를 플래그 (flag)합니다. Healer를 1차 디버깅 도구라고 생각하십시오. Healer는 사람이 반복적으로 20분을 소비해야 하는 단순한 케이스들을 처리하므로, 엔지니어들은 실제 판단이 필요한 케이스들에 집중할 수 있습니다.

도움이 되는 부분과 그렇지 않은 부분
이 세 가지 에이전트를 함께 사용하면 하나의 루프가 형성됩니다: 시드 테스트 + 설명 → Planner → Generator → Healer → 초안 테스트 스위트 (draft test suite). 핵심 단어는 "초안"입니다. AI가 생성한 테스트는 CI 파이프라인 (CI pipeline)에 커밋되어 권위 있는 것으로 취급되기 전에 반드시 사람의 검토를 거쳐야 합니다. AI 테스트에는 미묘한 문제, 잘못된 어설션 (assertion), 커버리지 공백, 오늘은 작동하지만 내일은 깨질 로케이터 (locator) 등이 있을 수 있습니다.

그 가치는 "AI가 QA를 대체한다"가 아닙니다. 오히려 다음과 가깝습니다: AI가 반복적인 설정의 첫 70%를 처리함으로써, 인간이 실제 이해가 필요한 나머지 30%에 집중할 수 있게 합니다. 에이전트 (agents)는 안정적이고 잘 이해된 흐름, 로그인 화면, 결제 프로세스, 검색 결과 등에 가장 효과적입니다. 복잡한 비즈니스 로직, 보안 테스트, 또는 도메인 지식 (domain knowledge)이 중요한 영역에서는 유용성이 떨어집니다. 만약 이미 플래키니스 (flakiness)가 낮은 잘 관리된 테스트 스위트 (test suite)를 보유하고 있다면, 점진적인 이점은 크지 않을 것입니다.

시작하는 방법: 전체 워크플로우 (workflow)를 재구조화하지 않고 이를 시도해보고 싶다면, Healer로 시작하십시오. 이는 이미 보유하고 있는 테스트에 바로 연결할 수 있습니다. 이미 알고 있는 몇 가지 플래키 (flaky)한 테스트를 찾아 Healer를 실행해 보고, 그것이 실패를 어떻게 처리하는지 확인하십시오. 이는 새로운 프로젝트 설정을 약속하거나 처음부터 시드 테스트 (seed tests)를 작성하지 않고도, 더 나아갈 가치가 있는지 평가할 수 있는 구체적이고 리스크가 낮은 방법입니다. 만약 이것이 매주 한 시간의 디버깅 (debugging) 시간을 아껴준다면, 그것은 의미 있는 일입니다. 만약 실패를 잘못 진단하거나 회귀 (regressions)를 유발한다면, 그 또한 초기 단계에서 저렴한 비용으로 알게 될 것입니다.

AI 지원 테스트는 반복적인 오버헤드 (overhead)를 제거합니다. 하지만 자신이 실제로 무엇을 테스트하고 있는지 이해하는 엔지니어의 필요성을 제거하지는 않습니다. 그러한 기대치를 현실적으로 유지한다면, 이는 워크플로우에 진정으로 유용한 추가 요소가 될 것입니다.

GeekyAnts의 Bodavula Ashwini가 작성한 Playwright Test Agents에 관한 기술 글 (2026년 4월)에서 영감을 받았습니다.