Slack이 200회 넘게 돌려본 에이전트 E2E 테스트: 결정론적 테스트를 대체할까?

읽는데 5분 소요

Slack Engineering · 2026년 6월 11일

Slack이 200회 넘게 돌려본 에이전트 E2E 테스트: 결정론적 테스트를 대체할까?

결론부터 말하면, 아직은 대체재라기보다 “목표를 탐색하고 실패를 설명하는 상위 레이어”에 가깝습니다. Slack은 Playwright MCP, Playwright CLI, 에이전트가 생성한 Playwright 테스트를 비교했고, 신뢰도·속도·비용의 균형이 꽤 다르게 나왔습니다.

▲ Slack Engineering 원문 상단. 목표까지 가는 경로가 하나가 아니라는 비유가 글 전체를 관통합니다. 출처

한 줄 요약: 빠르고 반복 가능한 회귀 검사는 여전히 결정론적 E2E가 맡고, 에이전트 테스트는 복잡한 UI 탐색·플레이키 재현·디버깅에 넣는 편이 현실적입니다.

목차

1. 실험의 질문 2. 실험 설계 3. 결과 3줄 요약 4. 비용이 커지는 이유 5. 테스트 스택에서의 위치 6. 느낀점

1. 실험의 질문

기존 E2E 테스트는 “이 버튼을 누르고, 이 값을 입력하고, 이 결과를 확인한다”는 하나의 여정을 강제합니다. 반면 에이전트 기반 테스트는 “스레드 메시지를 보내라” 같은 목표를 주고, UI 상태를 보며 경로를 바꿉니다. 원문 표현을 빌리면 테스트는 여정을 강제하고, 에이전트는 목표 달성을 검증합니다.

기존 E2Eclick 순서 고정

기존 E2Etype 값 고정

기존 E2Eassert 지점 고정

에이전트목표 달성 여부 검증

이 유연함은 매력적이지만 바로 비용 문제가 따라옵니다. Slack이 던진 실제 질문은 “한 번에 $15~30이 들고 10분 이상 걸릴 수 있는 실행을 현대적인 테스트 워크플로에 넣을 수 있나?”였습니다.

2. 실험 설계

Slack은 200회 이상의 자동 실행을 돌렸습니다. 비교한 모델은 3가지입니다. 에이전트가 Playwright MCP로 브라우저를 조작하는 방식, Playwright CLI 명령을 한 단계씩 실행하는 방식, 자연어 설명을 바탕으로 결정론적 Playwright 코드를 생성한 뒤 실행하는 방식입니다.

• 도구: Playwright MCP, Playwright CLI, 생성형 Playwright 테스트
• 흐름: Thread Reply는 약 15~20단계, Search Discovery는 약 25~30단계
• 입력: 자연어와 구조화된 YAML 비교
• 환경: 비운영 데이터가 들어간 테스트 워크스페이스
• 반복: 각 구성은 20회씩 실행

▲ 실행 모델과 입력 형식을 나눠 각 플로우를 20회씩 반복한 실험 매트릭스. 출처

3. 결과 3줄 요약

0~12%Playwright MCP의 실패율 범위. 단순 플로우는 0%, 복잡 플로우는 약 12%였습니다.

~48%생성형 Playwright 테스트가 Search Discovery에서 보인 실패율입니다.

~3분생성형 테스트의 평균 시간. 단, 에이전트 실행은 매번 추론 비용을 냅니다.

신뢰도만 보면 Slack 실험에서는 Playwright MCP가 가장 안정적이었습니다. CLI는 인증, 내비게이션 타이밍, 세션 안정성 같은 실행 계층 문제에 더 자주 걸렸고, 생성형 Playwright 테스트는 단순 흐름에서는 괜찮았지만 복잡한 흐름에서 마지막 상호작용이나 assertion에서 무너지는 경우가 많았습니다.

▲ 실패율과 평균 실행 시간을 한눈에 보여주는 원문 결과표. 출처

흥미로운 지점은 적응성입니다. 정확히 같은 액션 순서를 따른 실행은 약 20%뿐이었습니다. 대부분의 성공 실행은 메뉴를 여는 순서, 입력 방식, 탐색 경로가 달랐지만 최종 상태에는 도달했습니다. 이건 회귀 테스트에는 불안정성처럼 보이지만, 사용자가 실제로 다른 길을 택해도 목표를 달성하는지 보는 관점에서는 꽤 좋은 신호입니다.

4. 비용이 커지는 이유

Slack이 본 에이전트 실행 비용은 보통 1회 $15~30 수준이었습니다. 비싼 이유는 모델이 길게 답해서라기보다, 턴이 쌓일 때마다 이전 컨텍스트와 브라우저 상태가 다시 들어가기 때문입니다.

▲ 같은 Search Discovery 흐름에서 실행 모델별 토큰 사용량이 크게 달랐습니다. 출처

비용 요인	해석	낮추는 방향
턴 수	MCP는 약 40~60턴, CLI는 약 85턴까지 늘었습니다.	상태 관찰과 행동을 묶고 불필요한 왕복을 줄입니다.
컨텍스트 누적	접근성 트리, 로그, 실패 트레이스가 다음 턴에 계속 따라옵니다.	컨텍스트 압축과 스냅샷 빈도 조절이 필요합니다.
실행 계층	브라우저 자동화 인터페이스의 안정성이 실패율에도 영향을 줍니다.	MCP, CLI, 코드 생성 중 목적에 맞는 계층을 분리합니다.

5. 테스트 스택에서의 위치

Slack의 결론은 “결정론적 테스트를 버리자”가 아닙니다. 결정론적 E2E는 빠르고 반복 가능하며 CI에 잘 맞습니다. 에이전트 테스트는 같은 UI 레벨에서 동작하지만, 정해진 스크립트 대신 목표를 해석하고 현재 화면을 읽으며 다음 행동을 고릅니다.

▲ Slack은 에이전트 테스트를 기존 E2E 위의 탐색·디버깅 레이어로 배치했습니다. 출처

상황	더 어울리는 선택	이유
매 PR마다 돌리는 회귀 검증	결정론적 E2E	속도, 비용, 재현성이 중요합니다.
플레이키 흐름 재현	에이전트 테스트	여러 유효 경로를 시도하며 실패 조건을 좁힐 수 있습니다.
복잡한 UI 탐색	Playwright MCP 기반 에이전트	연속된 브라우저 상태와 구조화된 관찰이 도움이 됩니다.
테스트 코드 초안 생성	생성형 Playwright 테스트	빠른 초안에는 좋지만, 복잡 흐름은 사람이 고정해야 합니다.

▲ Playwright MCP는 접근성 스냅샷 기반 브라우저 자동화를 제공한다고 설명합니다. 출처

6. 느낀점

이 실험이 좋은 이유는 “AI 에이전트가 테스트를 다 바꾼다” 같은 주장으로 끝내지 않았다는 점입니다. Slack은 실패율, 실행 시간, 토큰 비용, 병렬화 난이도까지 같이 봤고, 그래서 결론이 더 실무적입니다.

내가 팀에 적용한다면 첫 단계는 CI 대체가 아니라 야간 탐색 작업입니다. 예를 들어 핵심 사용자 목표 5개를 에이전트에게 맡기고, 성공 여부보다 “어떤 경로로 갔는지, 어디서 망설였는지, 어떤 UI 상태가 테스트를 어렵게 했는지”를 수집합니다. 그중 반복되는 발견만 사람이 결정론적 Playwright 테스트로 굳히는 방식이 비용 대비 효율적입니다.

도입 체크리스트

• 목표는 “버튼 A 클릭”이 아니라 “사용자가 원하는 최종 상태에 도달”로 씁니다.
• 실패 로그에는 마지막 에러뿐 아니라 에이전트가 선택한 경로와 우회 행동을 남깁니다.
• 성공한 실행도 비교합니다. 같은 목표를 다른 경로로 달성했다면, 그 차이가 제품 UX의 힌트가 될 수 있습니다.
• 비용 예산을 먼저 정합니다. 매 PR 실행보다 릴리스 전, 야간, 장애 재현처럼 목적이 분명한 슬롯이 좋습니다.

특히 QA와 프론트엔드 팀이 함께 보면 효과가 큽니다. QA는 실패 조건을 구조화하고, 프론트엔드는 에이전트가 헤맨 지점에서 접근성 이름, 포커스 이동, 로딩 상태 표시를 개선할 수 있습니다. 테스트 자동화가 제품 품질 피드백으로 이어지는 셈입니다. 작게 시작해 지표를 보며 늘리는 편이 안전하고 좋습니다.

요약하면, 에이전트 E2E는 테스트 스위트의 새 엔진이라기보다 테스트 엔지니어의 탐사용 현미경에 가깝습니다. 매번 켜두기에는 비싸지만, 복잡한 흐름을 이해해야 할 때는 기존 스크립트가 못 보던 경로를 보여줄 수 있습니다.

FAQ

Q1. 에이전트 E2E가 기존 결정론적 테스트를 대체하나요?+

원문 결론은 대체보다 보완에 가깝습니다. 결정론적 테스트는 빠른 CI 회귀 검증에 남기고, 에이전트 테스트는 탐색·디버깅·복잡 흐름 검증에 쓰는 구성이 현실적입니다.

Q2. Slack 실험에서 가장 안정적인 방식은 무엇이었나요?+

Playwright MCP 기반 에이전트가 가장 안정적이었습니다. 단순 Thread Reply는 0% 실패율, Search Discovery는 약 12% 실패율로 요약됐습니다.

Q3. 생성형 Playwright 테스트는 왜 복잡한 플로우에서 실패했나요?+

원문은 UI 상태 변동과 추상화 불일치를 주요 원인으로 봤습니다. 흐름의 70~80%까지는 진행하지만 마지막 상호작용이나 assertion에서 깨지는 패턴이 많았습니다.

Q4. 비용은 어떤 방식으로 낮출 수 있나요?+

Slack은 비용 최적화를 이번 실험의 주목표로 두지 않았지만, 프롬프트 캐싱, 컨텍스트 압축, 브라우저 스냅샷 빈도 축소를 개선 여지로 언급했습니다.

Q5. 우리 팀은 어디서부터 시작하면 좋을까요?+

가장 먼저 야간 탐색, 릴리스 전 수동 점검 보조, 플레이키 버그 재현에 붙이는 것이 좋습니다. 매 PR마다 도는 필수 CI 게이트로 넣기에는 아직 비용과 시간 부담이 큽니다.

출처

• Slack Engineering - Agentic Testing: Where Agents Fit in the E2E Testing Stack
• Microsoft GitHub - Playwright MCP
• Microsoft GitHub - Playwright CLI
• Playwright 공식 문서 - Installation