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

• 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의 안정적 토대 제공, 에이전틱 테스팅이 피라미드 최상단에서 탐색·디버깅·복잡 동작 검증 담당

댓글과 토론