에이전틱 테스팅의 실행 모델별 신뢰성과 비용 수치
Slack 엔지니어링 팀은 200건 이상의 에이전틱 워크플로를 실행해 실행 모델별 신뢰성과 비용을 측정했다. 이번 실험의 핵심은 정해진 UI 경로를 강제하는 '여정(Journey)' 중심의 기존 E2E(End-to-End) 테스트를, 목표 달성 여부를 검증하는 '목표(Goal)' 중심의 에이전트 방식으로 전환했을 때의 효율성을 확인하는 것이다.
실험에는 세 가지 실행 모델이 사용됐다. 첫째는 에이전트가 사전 정의된 브라우저 동작으로 상호작용하는 'Agent + Playwright MCP' 방식(Claude Sonnet 4.5 사용)이다. 둘째는 셸에서 명령어를 한 단계씩 처리하는 'Agent + Playwright CLI' 방식(Claude Sonnet 4.5 사용)이며, 셋째는 자연어 설명에서 결정론적 코드를 생성해 실행하는 'Generated Playwright Tests' 방식(Claude Opus 4.6 사용)이다.
워크플로 복잡도에 따른 실패율 측정 결과, Playwright MCP 방식이 가장 높은 신뢰성을 보였다. 단순 시나리오인 'Thread Reply'에서 MCP는 실패율 0%를 기록했고, 복잡도가 높은 'Search Discovery'에서도 약 12%의 실패율을 유지했다. 반면 Playwright CLI는 각각 약 12%와 20%의 실패율을 보였으며, 생성형 테스트는 단순 플로에서 8%였으나 복잡 플로에서는 48%까지 실패율이 치솟았다.
실행 속도와 비용 면에서는 뚜렷한 트레이드오프가 관찰됐다. 생성형 테스트는 평균 3분으로 가장 빨랐으나, MCP는 5~8분, CLI는 9~11분이 소요됐다. 특히 에이전트 기반 실행은 회당 15~30달러의 비용이 발생해 기존 테스트 방식보다 현저히 높게 측정됐다.
MCP와 CLI의 작동 구조 및 토큰 소모 메커니즘
실행 모델 간의 신뢰성 격차는 모델의 추론 능력보다 브라우저와 상호작용하는 인프라 구조에서 발생한다. Playwright MCP(Model Context Protocol)는 브라우저 프리미티브와 에이전트 도구 호출 워크플로가 긴밀하게 통합되어 있다. MCP는 상호작용과 상태 반환을 단일 왕복으로 결합하고, 세션 내에서 접근성 트리(Accessibility Tree) 스냅샷을 유지하며 앞 단계의 성공적인 상호작용을 재사용하는 특성을 보인다.
반면 Playwright CLI 방식은 에이전트와 브라우저 사이에 추가 계층이 존재한다. 각 브라우저 상호작용이 '동작 $\rightarrow$ 대기 $\rightarrow$ 스냅샷 $\rightarrow$ 읽기 $\rightarrow$ 요소 조회' 등 여러 명령으로 분할되어 실행된다. 이로 인해 'Search Discovery' 플로 기준 MCP(Opus/Sonnet)가 평균 40턴을 사용하는 반면, CLI(Opus)는 평균 85턴을 소모한다.
비용 상승의 주원인은 모델의 출력량이 아니라 컨텍스트 누적 속도와 턴 수에 있다. 기반 API가 무상태(stateless)로 작동하기 때문에, 매 턴마다 전체 시스템 프롬프트와 이전 대화 이력이 재전송된다. 특히 CLI 방식은 턴 수가 많아질수록 재전송되는 컨텍스트 양이 급증하며, 이는 토큰 사용량 증가로 이어진다. 실제로 MCP 방식은 모델 종류와 관계없이 CLI나 코드 생성 방식보다 적은 토큰을 사용했다.
테스트 피라미드 내 도입 전략과 실무적 판단 기준
개발자와 실무자가 에이전틱 테스팅을 도입할 때 고려해야 할 핵심은 기존 결정론적 테스트의 대체가 아닌 '계층의 추가'다. 실험 결과, 에이전트는 동일한 목표에 도달하기 위해 매번 서로 다른 UI 경로를 발견하는 적응성을 보였다. 동일한 동작 순서를 따른 실행은 약 20%에 불과했으며, 이는 에이전트가 인터페이스를 탐색하며 목표 상태를 검증하는 데 강점이 있음을 의미한다.
따라서 테스트 피라미드의 구성은 다음과 같이 이원화해야 한다. CI(지속적 통합) 환경에서 빠르고 반복 가능한 회귀 검사가 필요할 때는 운영 비용이 낮고 실행 속도가 빠른 '결정론적 E2E 테스트'를 유지한다. 반면 다음과 같은 특정 상황에서는 에이전틱 테스팅 계층을 최상단에 배치해 활용한다.
1. 복잡한 UI 동작의 탐색적 검증이 필요할 때
2. 간헐적으로 발생하는 불안정한(flaky) 워크플로의 원인을 디버깅할 때
3. 프로덕션 환경에서 보고된 버그를 재현해야 할 때
결론적으로 현재의 에이전틱 테스팅은 회당 비용과 지연시간으로 인해 고빈도 CI 실행에는 부적합하다. 다만 프롬프트 캐싱, 컨텍스트 압축, 스냅샷 빈도 축소와 같은 최적화가 이루어진다면, 사람이 직접 작성하기 어려운 복잡한 사용자 시나리오를 검증하는 강력한 디버깅 도구로 기능할 수 있다.
