# 에이전틱 테스팅 - E2E 테스트 스택에서 에이전트의 역할

> Clean Markdown view of GeekNews topic #30744. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30744](https://news.hada.io/topic?id=30744)
- GeekNews Markdown: [https://news.hada.io/topic/30744.md](https://news.hada.io/topic/30744.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-23T09:21:02+09:00
- Updated: 2026-06-23T09:21:02+09:00
- Original source: [slack.engineering](https://slack.engineering/agentic-testing-where-agents-fit-in-the-e2e-testing-stack/)
- Points: 6
- Comments: 0

## Topic Body

- Slack 엔지니어링팀이 에이전트 기반 **E2E(End-to-End) 테스트**가 기존 결정론적(deterministic) 테스트를 대체할지 검증하기 위해 **200건 이상의 에이전틱 워크플로**를 실행한 실험 결과  
- 전통적 E2E 테스트가 정해진 UI 경로를 강제하는 반면, 에이전트는 **목표(goal) 달성 여부**를 검증하며 동일 결과에 서로 다른 경로로 도달  
- 에이전트 실행은 **회당 $15–30, 10분 이상** 소요되지만, 신뢰성 측면에서 분명한 활용처 존재  
- **Playwright MCP** 방식이 CLI·코드 생성 방식보다 낮은 실패율과 적은 토큰 사용량을 기록, 실행 환경 안정성이 결과를 좌우  
- 에이전틱 테스팅은 기존 테스트를 대체하지 않고 **테스트 피라미드 최상단**에 탐색·디버깅·복잡 동작 검증 계층으로 추가됨  
  
---  
  
### 여정에서 목표로 (From Journeys to Goals)  
  
- 전통적 E2E 테스트는 UI를 따라가는 특정 **여정(journey)** 을 검증 → `클릭 → 클릭 → 입력 → 단언(assert)`  
- 에이전트 기반 테스트는 "스레드 메시지 보내기" 같은 지시로 표현된 **목표 달성 가능 여부**를 검증 → `목표 → 에이전트 적응 → 결과 검증`  
  - 핵심 차이: "테스트는 여정을 강제하고, 에이전트는 목표를 검증함"  
- 전체 워크플로(로그인 → 검색 → 결과 → 초기화)는 일정했으나 실제 동작 순서는 매번 달라짐  
  - 서로 다른 입력 방식(검색 추천 클릭 vs Enter 입력)  
  - 서로 다른 탐색 패턴(검색 재실행 vs 기존 상태 재사용)  
  - 추가되거나 생략된 단계(추가 클릭, 스냅샷, 중간 동작)  
- 유연성에는 **신뢰성·비용·실행 시간** 측면의 트레이드오프 동반  
- ## 문제 제기  
  - 회당 **$15–30, 10분 이상** 걸리는 방식이 현대적 테스트 워크플로에 들어갈 수 있는지가 핵심 질문  
  - 200건 이상 실행 결과, 전통적 테스트와 근본적으로 다르면서도 높은 신뢰성과 명확한 활용처 확인  
  - 코드 작성·실패 디버깅·UI 직접 조작을 가능케 한 **대규모 언어 모델(LLM)** 의 발전이 새로운 실행 모델을 가능하게 함  
  
### 실험 구성 (Our Experiment)  
- 신뢰성·실행 속도·비용을 측정하기 위해 여러 구성에서 **200건 이상**의 자동 실행 수행  
- ## 실행 모델 (세 가지 방식)  
  - **Agent + Playwright MCP**: 에이전트가 사전 정의된 브라우저 동작(요소 클릭, 입력, DOM 상태 읽기 등)으로 브라우저와 상호작용, **지속적 컨텍스트**(DOM 스냅샷·로그) 유지  
  - **Agent + Playwright CLI**: 셸에서 Playwright CLI 명령을 실행해 한 번에 한 단계씩 처리, 갱신된 UI 상태를 보고 다음 동작 결정  
  - **Generated Playwright Tests**: AI 에이전트가 자연어 설명에서 **결정론적 Playwright 코드**를 생성, 표준 E2E 테스트로 실행하고 통과할 때까지 반복 개선  
- ## 실험 환경  
  - 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단계 워크플로  
- ## 입력 형식  
  - **자연어(NL)**: 워크플로와 예상 결과를 단계별 목록으로 서술한 사람이 읽기 쉬운 지시  
  - **구조화 YAML**: 동일 워크플로를 단계·동작·대상·예상 결과로 명시한 구조적 형식  
    - 차이는 상세 정도가 아니라 표현 방식 — 자연어는 에이전트가 해석·매핑해야 하고, YAML은 매핑을 더 명시적으로 정의  
- ## 실험 매트릭스  
  - 각 구성을 **20회씩** 실행, 총 5개 실험(MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, 생성 테스트-NL)을 Thread Reply·Search Discovery 두 플로에 적용  
  
### 관찰 결과 (What We Observed)  
- ## 결과 요약  
  - Agent (Playwright MCP): 실패율 **0%(thread reply) / 약 12%(search discovery)**, 평균 5–8분  
  - Agent (Playwright CLI): 실패율 약 12% / 약 20%, 평균 9–11분  
  - Generated Playwright Tests: 실패율 약 8% / **약 48%**, 평균 3분  
- ## 신뢰성 (Reliability)  
  - 플로가 복잡해질수록 신뢰성 변화가 가장 뚜렷하게 나타남  
  - **Playwright MCP**가 가장 안정적 — 단순 시나리오에서 거의 0% 실패율, 복잡 플로에서도 0–12% 유지  
  - **Playwright CLI**는 실패율이 더 높음(약 12–20%), 대부분 모델 추론이 아닌 인증 처리·내비게이션 타이밍·세션 불안정 같은 실행 문제에서 발생  
  - 생성 테스트는 단순 플로에서 양호(약 8%)했으나 복잡 워크플로에서 크게 악화(약 48%)  
    - 완전히 틀린 것은 아니며 보통 플로의 **70–80%까지 진행** 후 마지막 상호작용·단언에서 실패  
    - 실패 원인은 UI 상태 변동성과 추상화 불일치 — 느슨하게 명세된 자연어 플로에서 생성되고 기존 페이지 오브젝트 추상화를 재사용해 정밀한 요소 타깃팅을 방해  
  - 복잡도가 커질수록 신뢰성 격차 확대, **MCP 같은 에이전트 네이티브 실행 모델**이 더 안정적  
    - MCP는 앱의 실시간·안정적 뷰를 유지, CLI는 매 단계 스냅샷으로 상태를 재구성 → 플로가 길어질수록 불일치 누적  
    - MCP는 세션 내에서 앞 단계의 성공 상호작용을 재사용하는 것으로 보임, CLI는 매 단계 처음부터 시작하는 느낌 (명시적으로 측정하지는 않음)  
- ## 속도 (Speed)  
  - **생성 테스트**가 일관되게 가장 빠름 (약 3분), MCP 약 5–8분, CLI 약 9–11분  
  - 생성 테스트 수치는 테스트 생성+실행을 포함, 각 테스트는 한 번 생성 후 5회 실행한 평균  
    - 실제 순수 실행은 훨씬 빠름 — thread reply 약 32초, search discovery 약 45초  
    - 반복 실행되는 CI 환경에서는 일회성 생성 비용이 무시할 수준이 되어 결정론적 테스트가 효율적으로 확장  
  - 에이전트 워크플로는 매 실행마다 비용 지불 — 각 단계가 UI 상태 관찰, 다음 동작 추론, 동작 실행 및 결과 검증을 수반  
- ## 적응성 (Adaptability)  
  - 동일한 동작 순서를 따른 실행은 **약 20%** 에 불과, 대부분 같은 목표에 도달하는 서로 다른 유효 UI 경로 발견  
    - 메뉴를 다른 순서로 열기  
    - 약간 다른 UI 요소 선택  
    - 대체 내비게이션 흐름 사용  
  - 측정을 위해 실행 간 **액션 시그니처(action signature)** 비교 — 에이전트가 수행한 도구 호출·UI 동작의 순서 목록  
    - 비교 전 정규화: 파라미터, 대기/스냅샷 동작, 동등한 도구 변형(fill vs type)을 통합해 의미 있는 차이만 계산  
  - 최종 결과가 옳아도 대부분 동작 순서가 다름 — 전통 E2E는 단일 결정론적 여정을 강제, 에이전트는 인터페이스를 탐색하며 목표 상태 도달 여부 검증  
- ## 비용과 발생 원인 (Cost and Where It Comes From)  
  - 에이전트 실행은 보통 **회당 $15–30**으로 전통 테스트보다 훨씬 비쌈  
  - 동일 search discovery 플로의 토큰 사용량 분석  
    - MCP (Opus 4.6) 약 3.8M, MCP (Sonnet 4.5) 약 3.5M, MCP (Haiku 4.5) 약 5.7M  
    - CLI (Opus 4.6) 약 6M, Code Gen (Opus 4.6) 약 7M  
  - **어떤 모델을 쓰는지보다 어떻게 실행하는지가 더 중요** — Haiku가 토큰을 더 썼지만, 모든 MCP 방식이 CLI·Code Gen보다 적은 토큰 사용  
  - Claude Code의 세션 실행 방식 분석: 기반 API가 **무상태(stateless)** 라 매 턴마다 전체 시스템 프롬프트와 전체 대화 이력 재전송  
    - 비용은 모델 출력이 아니라 **컨텍스트 누적 속도와 턴 수**가 결정  
  - 턴 수: MCP (Opus/Sonnet) 약 40, MCP (Haiku) 약 60, CLI (Opus) 약 85, Code Gen (Opus) 약 70  
    - CLI는 각 브라우저 상호작용이 동작·대기·스냅샷·읽기·요소 조회 등 여러 명령으로 분할되어 평균 85턴  
    - MCP는 상호작용과 상태 반환을 단일 왕복으로 결합  
    - 추가 턴마다 전체 시스템 프롬프트 비용과 이전 대화 컨텍스트 재전송 부담  
  - 컨텍스트를 채우는 요소  
    - MCP·CLI: 브라우저 스냅샷이 주 페이로드 — Playwright MCP가 반환하는 접근성 트리(accessibility tree) 스냅샷이 이후 모든 턴에 누적  
    - Code Gen: 재시도마다 전체 오류 트레이스·단언 실패·DOM 상태가 담긴 테스트 러너 출력 누적  
  - 비용의 대부분은 **이미 본 내용의 재전송**, 턴당 새 정보는 극히 일부  
  - 토큰 사용량은 최적화하지 않은 단계 — 절감 방법으로 **프롬프트 캐싱, 컨텍스트 압축(compaction), 스냅샷 빈도 축소** 제시  
  - 비용 때문에 현재로서는 고빈도 CI 실행보다 **표적 디버깅·탐색적 테스트**에 더 적합, 향후 모델·도구로 개선 가능  
- ## 인프라의 중요성 (MCP vs CLI)  
  - 모델 자체뿐 아니라 실행 환경이 신뢰성에 크게 영향 — MCP 0–12%, CLI 12–20% 실패율  
  - CLI 실패 대부분은 인증·내비게이션 문제(로그인 오류, 타임아웃, 세션 불안정)에서 발생, 에이전트 추론이 아닌 **실행 계층** 문제  
  - Playwright MCP는 구조화된 브라우저 프리미티브와 에이전트 도구 호출 워크플로와의 긴밀한 통합 제공, CLI는 에이전트와 브라우저 사이에 추가 계층 도입  
  - 병렬화 차이: MCP는 동시 실행이 쉬움, CLI는 병렬화가 어려워 대부분 순차 실행  
  - 신뢰성·속도·비용은 모델뿐 아니라 **실행 환경의 안정성과 설계**에 좌우됨  
- ## 실행 역량의 경계 (Execution Capability Boundaries)  
  - 본 실험은 **단일 세션 UI 워크플로**에 집중  
  - 크로스 워크스페이스 플로나 여러 브라우저 창을 여는 워크플로는 실행 모델 선택이 에이전트만큼 중요해지는 다른 난제 동반  
    - MCP는 긴 플로에서 관찰 루프가 늘며 비용 문제 가능  
    - CLI는 다중 브라우저 세션 관리 시 조정 복잡성과 높은 토큰 사용 가능  
  - 두 방식 모두 지원 가능하나 트레이드오프가 다름 — 본 실험에서는 미탐색, 평가 팀이 고려할 중요 사항  
  
### 테스트 피라미드 속 에이전틱 테스팅의 위치  
- 에이전틱 테스팅은 기존 방식을 대체하지 않고 그 위에 **새로운 역량 추가**  
- ## 결정론적 E2E 테스트  
  - CI에서 빠르고 반복 가능한 회귀 검사에 가장 적합  
    - 사람이 작성하거나 AI가 생성  
    - 빠르고 반복 가능, CI 친화적  
    - 낮은 운영 비용  
    - 특정 UI 여정 강제  
- ## 에이전틱 테스팅  
  - 정해진 스크립트 실행이 아니라 **목표에서 출발** — UI 관찰, 현재 상태 추론, 원하는 결과 도달 방법 결정  
    - 복잡한 UI 동작 탐색  
    - 불안정한(flaky) 워크플로 디버깅  
    - 프로덕션 버그 재현  
- ## 에이전틱 계층을 포함한 테스트 피라미드  
  - 시스템 관점에서 에이전틱 테스팅은 E2E와 같은 수준에서 실제 사용자 워크플로를 UI로 검증, 차이는 워크플로의 **실행 방식**  
  - 미래의 가장 효과적인 테스트 전략은 둘을 결합 — 결정론적 테스트가 CI의 안정적 토대 제공, 에이전틱 테스팅이 피라미드 최상단에서 탐색·디버깅·복잡 동작 검증 담당

## Comments



_No public comments on this page._