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