에이전트 기반 테스트: E2E 테스트 스택에서 에이전트가 적합한 위치 (새 탭에서 열림)
에이전트 기반 E2E 테스트는 기존의 결정적 테스트를 대체하기보다, 사용자의 목표 달성 여부를 탐색적으로 검증하는 별도의 계층으로 활용해야 한다. 200회 이상 실험한 결과 Playwright MCP 기반 에이전트가 복잡한 흐름에서도 가장 안정적이었고, 생성된 Playwright 테스트는 단순한 흐름에서는 빠르지만 복잡도가 높아질수록 실패율이 크게 증가했다. 따라서 전통적 테스트는 핵심 회귀 검증에, 에이전트 테스트는 유연한 탐색과 목표 중심 검증에 배치하는 것이 적절하다. ## 여정 검증에서 목표 검증으로 - 전통적인 E2E 테스트는 `클릭 → 클릭 → 입력 → 검증`처럼 미리 정해진 UI 경로를 검증한다. - 에이전트 기반 테스트는 “스레드 메시지를 보내라”처럼 목표를 제시하고, 에이전트가 현재 UI 상태에 따라 경로를 선택하게 한다. - 동일한 결과에 도달하더라도 다음과 같은 차이가 발생했다. - 검색 제안 클릭 또는 Enter 키 사용 - 검색 화면을 다시 열거나 기존 상태 재사용 - 중간 클릭, 스냅샷 확인 등의 추가·생략 - 에이전트는 중간 단계도 검증할 수 있지만, 경로의 유연성 때문에 실행 시간·비용·신뢰성 관리가 필요하다. ## 실험 구성과 비교 대상 - 200회 이상의 자동 실행으로 신뢰성, 속도, 비용을 비교했다. - 비교한 실행 방식은 세 가지다. - **에이전트 + Playwright MCP**: 브라우저 액션과 DOM 상태·로그를 지속적인 컨텍스트로 사용 - **에이전트 + Playwright CLI**: 셸에서 명령을 한 단계씩 실행하고 매번 UI 상태를 바탕으로 다음 행동 결정 - **생성된 Playwright 테스트**: 자연어 설명으로 결정적 테스트 코드를 생성한 뒤 실행·수정 - Claude Sonnet 4.5와 Opus 4.6을 사용했으며, 비운영 데이터가 있는 테스트 워크스페이스에서 실행했다. - 입력 형식은 다음 두 가지였다. - 자연어 지시: 사람이 읽기 쉬운 단계별 설명 - 구조화된 YAML: 단계, 액션, 대상, 기대 결과를 명시 - 각 설정은 20회씩 실행했다. ## 테스트한 사용자 흐름 - **Thread Reply** - 약 15~20단계의 단순한 흐름 - 채널 생성, 메시지 전송, 스레드 답글 작성, 스레드 상태 확인 - **Search Discovery** - 약 25~30단계의 중간 복잡도 흐름 - 검색어 입력, 검색 결과 탐색, 채널·스레드·검색 화면 간 이동, 결과 검증 ## 측정 결과 | 방식 | Thread Reply 실패율 | Search Discovery 실패율 | 평균 실행 시간 | |---|---:|---:|---:| | 에이전트 + Playwright MCP | 0% | 약 12% | 약 5~8분 | | 에이전트 + Playwright CLI | 약 12% | 약 20% | 약 9~11분 | | 생성된 Playwright 테스트 | 약 8% | 약 48% | 약 3분 | - 에이전트 테스트는 실행당 15~30달러가 들고 10분 이상 걸릴 수 있어, 일반적인 빠른 회귀 테스트를 그대로 대체하기에는 부담이 있다. - 그러나 전통적 테스트와 목적이 다르므로 단순한 실패율만으로 비교해서는 안 된다. ## 복잡도가 높아질수록 벌어지는 신뢰성 차이 - Playwright MCP는 단순한 시나리오에서 거의 실패하지 않았고, 복잡한 흐름에서도 실패율이 0~12% 수준이었다. - Playwright CLI는 인증 처리, 탐색 타이밍, 세션 불안정 등 실행 환경 문제로 약 12~20%의 실패율을 보였다. - 생성된 Playwright 테스트는 단순한 흐름에서는 약 8% 실패했지만, 복잡한 검색 흐름에서는 약 48%까지 악화됐다. - 생성 테스트는 대체로 전체 흐름의 70~80%까지 진행한 뒤 마지막 상호작용이나 assertion에서 실패했다. - 주요 원인은 다음과 같다. - UI 상태의 변동성 - 자연어 명세와 실제 요소 선택 간의 추상화 불일치 - 기존 Page Object 추상화가 복잡한 상황에서 정확한 요소 지정을 방해 - MCP는 애플리케이션의 실시간 상태를 안정적으로 유지하는 반면, CLI는 단계마다 스냅샷을 다시 구성한다. - 긴 흐름에서는 상태 해석과 타이밍의 작은 차이가 누적되어 CLI 방식의 실패 가능성이 커질 수 있다. ## 테스트 스택에서의 적절한 역할 - 전통적인 결정적 Playwright 테스트는 빠르고 반복 가능하므로 핵심 회귀 테스트와 CI의 기본 검증에 적합하다. - 에이전트 기반 테스트는 특정 클릭 순서가 아니라 “사용자가 목표를 달성할 수 있는가”를 검증하는 데 적합하다. - 특히 다음 영역에서 활용 가치가 있다. - 다양한 UI 경로를 허용해야 하는 사용자 여정 - 사전에 모든 경로를 코드로 작성하기 어려운 탐색적 테스트 - 복잡한 화면 상태와 실제 사용자 행동에 가까운 검증 - 에이전트 방식 중에서는 실시간 브라우저 컨텍스트를 유지하는 Playwright MCP가 복잡한 시나리오에 더 적합한 것으로 나타났다. - 다만 높은 비용과 긴 실행 시간을 고려해 모든 커밋에서 실행하기보다는, 야간 테스트나 릴리스 전 검증 등 별도 계층에 배치하는 것이 현실적이다. 에이전트 기반 E2E 테스트는 결정적 테스트의 대체재가 아니라 보완재로 도입하는 것이 좋다. 빠르고 안정적인 핵심 회귀 검증은 기존 Playwright 테스트로 유지하고, MCP 기반 에이전트 테스트를 목표 중심·탐색적 검증에 제한적으로 추가하는 구성이 가장 실용적이다.