에이전트 테스트: E2E 테스트 스택에서 에이전트의 위치

Source: Slack Engineering

요약

에이전트 기반 엔드‑투‑엔드(E2E) 테스트는 테스트에 새로운 탐색 레이어를 추가하지만, 기존의 결정론적 테스트를 대체해야 할까요? 우리는 Playwright MCP, Playwright CLI, 그리고 에이전트가 생성한 Playwright 테스트를 사용해 비생산 데이터가 있는 테스트 워크스페이스에서 200개가 넘는 에이전트 기반 E2E 워크플로를 실행했습니다. 이를 통해 에이전트 테스트가 우리와 여러분의 테스트 스택에 어떻게 들어맞을 수 있는지 살펴보았습니다.

1. 여정에서 목표로

전통적인 엔드‑투‑엔드 테스트는 UI를 통한 특정 여정을 검증합니다.

클릭 → 클릭 → 입력 → 검증

에이전트 기반 테스트는 대신 목표가 달성될 수 있는지를 검증합니다(예: “스레드 메시지 보내기”와 같은 명령어 형태).

목표 → 에이전트 적용 → 결과 검증

이 차이는 간단히 요약할 수 있습니다.

테스트는 여정을 강제하고, 에이전트는 목표를 검증한다.

우리의 에이전트 테스트 실행 전반에 걸쳐 전체 흐름은 일관되었습니다(예: 로그인 → 검색 → 결과 → 정리). 하지만 정확한 행동 순서는 달라졌습니다. 실제로 에이전트는 같은 결과에 도달하기 위해 다양한 경로를 택했습니다.

• 서로 다른 입력 방식(검색 제안을 클릭 vs 엔터키 누르기)
• 서로 다른 네비게이션 패턴(검색을 다시 열기 vs 기존 상태 재사용)
• 추가하거나 건너뛴 단계(추가 클릭, 스냅샷, 중간 액션 등)

필요할 경우 에이전트는 중간 단계도 검증할 수 있지만, 이러한 유연성은 신뢰성, 비용, 실행 시간 측면에서 트레이드오프를 동반합니다. 다음 섹션에서 이를 자세히 살펴보겠습니다.

문제점

에이전트 기반 E2E 테스트는 매력적으로 보이지만, 실행당 $15–30의 비용과 10분 이상의 소요 시간이 현대 테스트 워크플로에 실제로 들어맞을 수 있을지 의문이 듭니다.

첫눈에 보기엔 답이 ‘아니다’라고 생각될 수 있습니다. 하지만 200번 이상의 실행을 통해 우리는 에이전트 테스트가 전통적인 테스트와 근본적으로 다르며, 높은 신뢰성을 가질 수 있고 테스트 스택에서 명확한 위치를 차지한다는 것을 발견했습니다.

이는 최근 대형 언어 모델(LLM)의 발전 덕분인데, 에이전트가 코드를 작성하고, 실패를 디버깅하며, UI와 직접 상호작용할 수 있게 되었습니다. 이러한 능력은 새로운 실행 모델을 만들지만, 기존 E2E 워크플로에 어디에 들어맞는지는 아직 명확하지 않습니다.

2. 우리의 실험

에이전트 기반 테스트가 E2E 워크플로에 어떻게 들어맞는지 이해하기 위해, 우리는 200번 이상의 자동 실행을 다양한 구성으로 진행해 신뢰성, 실행 속도, 비용을 측정했습니다.

실행 모델

세 가지 접근 방식을 평가했습니다.

Agent + Playwright MCP
에이전트가 Playwright MCP를 통해 브라우저와 상호작용합니다. 미리 정의된 브라우저 동작(요소 클릭, 입력, DOM 상태 읽기 등)을 사용하고, DOM 스냅샷 및 로그와 같은 지속 컨텍스트를 유지합니다.

Agent + Playwright CLI
에이전트가 셸을 통해 Playwright CLI 명령을 실행합니다. 한 단계씩 수행하고, UI 상태 변화에 따라 다음 행동을 결정합니다.

Generated Playwright Tests
AI 에이전트가 자연어 설명으로부터 결정론적 Playwright 테스트 코드를 생성하고, 이를 표준 E2E 테스트처럼 실행합니다. 테스트가 통과할 때까지 반복적으로 개선합니다.

실험 설정

• 에이전트 모델(Playwright MCP / CLI): Claude Sonnet 4.5
• 생성된 Playwright 테스트 모델: Claude Opus 4.6
• 실행 방식: 비대화형 Claude Code (claude -p)

브라우저 도구:

• Playwright MCP
• Playwright CLI

환경 설정:

• Slack Dev API MCP
• 모든 실험은 비생산 데이터를 사용한 테스트 워크스페이스에서 수행되었습니다.

테스트 흐름

복잡도 수준을 다루기 위해 두 가지 흐름을 사용했으며, 모든 실험에서 동일하게 유지해 직접 비교가 가능하도록 했습니다.

Thread Reply (단순)
채널 생성 → 메시지 전송 → 스레드에 답글 달기 → 스레드 상태 검증 등 약 15–20단계의 짧은 워크플로.

Search Discovery (중간 복잡도)
검색어 입력 → 결과 탐색 → 뷰 전환(검색, 채널, 스레드) → 기대 결과 검증 등 약 25–30단계의 긴 워크플로.

입력 형식

에이전트 기반 접근법에 대해 두 가지 입력 타입을 평가했습니다.

• Natural language (NL)
  워크플로와 기대 결과를 인간이 읽기 쉬운 상세 지시문으로 기술(예: “스레드에 답글을 달고 All Threads에 나타나는지 확인”). 보통 단계별 리스트 형태로 작성됩니다.

• Structured YAML
  동일한 워크플로를 구조화된 형식으로 표현. 단계, 동작, 대상, 기대 결과를 명시적으로 기술합니다.

차이는 상세함의 수준이 아니라 표현 방식입니다. 자연어는 에이전트가 지시를 해석해 행동으로 매핑해야 하는 반면, YAML은 그 매핑을 명시적으로 제공합니다.

각 구성은 20회씩 실행했습니다. 전체 실험 매트릭스는 다음과 같습니다.

실험 매트릭스

3. 관찰 결과

결과 요약

개별 지표를 살펴보기 전에, 자연어와 YAML 실행 모두에 대한 전반적인 성과를 한눈에 보여드립니다.

아래 섹션에서는 각 지표별로 자세히 분석합니다.

신뢰성

가장 뚜렷한 패턴은 흐름이 복잡해질수록 신뢰성이 변한다는 점입니다.

• Playwright MCP 기반 에이전트 흐름은 가장 신뢰성이 높았습니다. 단순 시나리오에서는 거의 0% 실패율을 기록했고, 복잡한 흐름에서도 0–12% 수준을 유지했습니다.
• Playwright CLI는 실패율이 더 높았으며(대략 12–20%), 주된 원인은 인증 처리, 네비게이션 타이밍, 세션 불안정 등 실행 단계의 문제였습니다. 모델 자체의 추론 오류라기보다는 환경적인 요인 때문이었습니다.
• Generated Playwright Tests는 단순 흐름에서는 비교적 괜찮은 편(~8% 실패)했지만, 복잡한 흐름에서는 크게 악화되었습니다(~48% 실패). 이 테스트들은 전체 흐름의 70–80% 정도는 진행했지만, 마지막 상호작용이나 어설션 단계에서 깨지는 경우가 많았습니다. 실패 원인은 UI 상태 변동성과 추상화 불일치였습니다. 자연어로 느슨하게 지정된 흐름을 기반으로 기존 페이지 객체 추상화를 재사용했기 때문에, 복잡한 시나리오에서 정확한 요소 타깃팅에 방해가 되었습니다.

전반적으로 복잡도가 증가할수록 신뢰성 격차가 벌어졌으며, 이는 MCP와 같은 에이전트‑네이티브 실행 모델이 복잡한 흐름에서도 더 안정적인 동작을 제공한다는 점을 시사합니다. 주요 이유는 상태 관리 방식에 있습니다. MCP는 앱의 살아있는, 안정적인 뷰를 유지하는 반면, CLI는 각 단계마다 스냅샷으로부터 상태를 재구성합니다. 흐름이 길어질수록 UI 해석이나 타이밍 차이가 누적돼 실패로 이어질 가능성이 커집니다. 또한 세션 컨텍스트 차이도 영향을 미칩니다. MCP 기반 실행에서는 에이전트가 이전 단계의 성공적인 상호작용을 재사용하는 반면, CLI는 매 단계마다 처음부터 시작하는 느낌을 줍니다. 우리는 이를 직접 측정하지는 않았지만, 신뢰성 차이에 기여했을 가능성이 높습니다.

속도

속도 면에서는 생성된 테스트가 일관적으로 가장 빨랐습니다.

생성된 테스트의 실행 시간에는 테스트 생성과 실행 모두가 포함됩니다. 각 테스트는