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

Slack 엔지니어링 팀이 에이전트 기반 E2E(End-to-End) 테스트가 기존의 결정론적(deterministic) 테스트를 대체할 수 있을지 검증하기 위해 200건 이상의 에이전틱 워크플로를 실행한 흥미로운 실험 결과를 공유해 주었습니다.

기존 E2E 테스트가 정해진 UI 경로를 엄격하게 강제하는 반면, AI 에이전트는 목표(goal) 달성 여부를 검증하며 동일한 결과에 도달하기 위해 매번 서로 다른 경로를 유연하게 찾아냅니다. 실행 비용이 회당 $15~30 수준으로 비싸고 10분 이상 소요된다는 단점이 있지만, 신뢰성 측면에서 분명한 활용처를 보여주었습니다.

여정에서 목표로 (From Journeys to Goals)

전통적인 E2E 테스트는 UI를 따라가는 특정 여정(journey)을 검증합니다. 즉, 'A를 클릭하고, B를 입력한 뒤, C가 나타나는지 확인(assert)한다'는 정해진 시나리오를 따릅니다.

반면 에이전트 기반 테스트는 '스레드 메시지 보내기'와 같은 지시로 표현된 목표(goal)의 달성 가능 여부를 검증합니다. 목표를 던져주면 에이전트가 스스로 판단하고 UI에 적응하며 결과를 확인하는 방식입니다.

핵심 차이: "전통적인 테스트는 정해진 여정을 강제하고, 에이전트는 목표를 검증합니다."

실제로 전체 워크플로(로그인 → 검색 → 결과 확인 → 상태 초기화)는 일관되게 수행되었지만, 에이전트가 동작하는 구체적인 순서는 매번 달랐습니다.

• 서로 다른 입력 방식: 검색 추천 단어를 클릭하기도 하고, 직접 텍스트를 입력한 뒤 Enter를 누르기도 했습니다.
• 서로 다른 탐색 패턴: 검색을 완전히 새로 실행하는 에이전트가 있는 반면, 기존에 열려 있는 상태를 그대로 재사용하기도 했습니다.
• 추가되거나 생략된 단계: 중간 동작에서 추가 클릭을 하거나, 불필요한 스냅샷 단계를 건너뛰는 유연함을 보여주었습니다.

하지만 이러한 유연함 뒤에는 신뢰성, 비용, 실행 시간이라는 트레이드오프가 명확히 존재합니다.

실험 구성 (Our Experiment)

Slack 팀은 신뢰성, 실행 속도, 비용을 정밀하게 측정하기 위해 여러 조건에서 200건 이상의 자동 실행 실험을 수행했습니다.

1. 세 가지 실행 모델

• Agent + Playwright MCP (Model Context Protocol): 에이전트가 사전 정의된 브라우저 동작(요소 클릭, 입력, DOM 상태 읽기 등)을 사용하여 브라우저와 긴밀히 상호작용합니다. 세션 내에서 지속적인 컨텍스트(DOM 스냅샷 및 로그)를 안정적으로 유지합니다.
• Agent + Playwright CLI: 에이전트가 셸(Shell)에서 Playwright CLI 명령을 직접 실행하여 한 단계씩 처리합니다. 매 단계마다 갱신된 UI 상태를 보고 다음 동작을 결정합니다.
• Generated Playwright Tests: AI 에이전트가 자연어 설명서로부터 완전한 결정론적 Playwright 코드를 작성합니다. 표준 E2E 테스트로 실행한 후, 실패하면 코드를 수정해 가며 통과할 때까지 반복해서 개선합니다.

2. 실험 환경 및 시나리오

• 모델: MCP 및 CLI 에이전트 모델로는 Claude Sonnet 4.5를, 코드 생성 모델로는 Claude Opus 4.6을 사용했습니다.
• 실행 도구: 비대화형 Claude Code (claude -p)를 사용했으며, 테스트는 모두 비프로덕션 데이터로 채워진 테스트 워크스페이스에서 진행되었습니다.
• 테스트 플로 복잡도:
• Thread Reply (단순 플로): 채널 생성, 메시지 전송, 스레드 답글 작성, 스레드 상태 검증을 포함한 15~20단계 워크플로
• Search Discovery (중간 복잡도 플로): 검색어 입력, 결과 탐색, 뷰 간 이동(검색 탭 ↔ 채널 ↔ 스레드), 예상 결과 검증을 포함한 25~30단계 워크플로
• 입력 형식: 사람이 읽기 쉬운 자연어(NL) 형태의 지시문과, 이를 단계·동작·대상별로 명확하게 정의한 구조화된 YAML 형식을 비교하여 실행했습니다.

실험 결과 분석 (What We Observed)

실험 데이터 분석 결과, 실행 모델에 따라 신뢰성과 속도에서 뚜렷한 차이가 나타났습니다.

1. 신뢰성 (Reliability)

플로가 복잡해질수록 신뢰성 격차가 가장 커졌습니다.

• Playwright MCP 방식이 가장 안정적이었습니다. 단순 시나리오에서는 실패율 0%를 기록했고, 복잡한 플로에서도 12% 수준의 실패율만 보였습니다.
• Playwright CLI는 실패율이 12~20%로 다소 높았습니다. 실패 요인을 분석해보니 LLM의 추론 실패보다는 주로 인증 처리 지연, 페이지 내비게이션 타이밍 어긋남 등 실행 인프라 계층의 불안정성 때문이었습니다.
• 생성형 테스트(Code Gen) 방식은 단순 플로에서는 준수했지만, 복잡해질수록 실패율이 48%까지 치솟았습니다. 완전히 엉뚱한 코드를 짜기보다는 전체 플로의 70~80% 정도를 잘 진행하다가 마지막의 정밀한 요소 선택(Targeting)이나 단언(Assertion) 부분에서 삐끗하는 모습을 보였습니다.

2. 속도 (Speed) 및 적응성 (Adaptability)

• 속도: 미리 코드를 짜서 돌리는 생성형 테스트(Code Gen)가 평균 3분으로 가장 빨랐습니다. 일단 테스트 코드가 안정화되면 CI 환경에서의 실제 테스트 실행 시간은 수십 초 단위(Thread Reply 32초, Search Discovery 45초)에 불과합니다. 매번 실시간으로 추론해야 하는 에이전트 방식은 매 실행마다 5~11분이 꼬박 소요됩니다.
• 적응성: 에이전트 테스트를 돌렸을 때, 매번 완전히 동일한 동작 순서(Action Signature)를 따라서 성공한 비율은 20% 미만이었습니다. 에이전트는 메뉴를 여는 순서를 바꾸거나 대체 요소를 클릭하는 등 상황에 맞추어 유연하게 대처하며 목표에 도달했습니다.

비용과 발생 원인 (Cost Analysis)

에이전트 테스팅의 최대 장벽은 실행 비용입니다. 테스트 회당 평균 $15~30의 비용이 발생하여 기존 테스트에 비해 매우 비쌉니다.

토큰 사용량과 턴(Turn) 수의 관계

• MCP (Opus/Sonnet): 약 3.5M ~ 3.8M 토큰 사용 (약 40턴)
• MCP (Haiku): 약 5.7M 토큰 사용 (약 60턴)
• CLI (Opus): 약 6.0M 토큰 사용 (약 85턴)
• Code Gen (Opus): 약 7.0M 토큰 사용 (약 70턴)

비용을 결정하는 핵심 요인은 어떤 모델을 쓰느냐보다 어떻게 실행하느냐(인프라 설계)였습니다. API 기반 LLM은 기본적으로 무상태(stateless)이기 때문에 매 대화 턴마다 전체 시스템 프롬프트와 이전 누적 대화 이력을 다시 전송해야 합니다.

• CLI 방식은 하나의 브라우저 동작을 수행하기 위해 '동작 요청 -> 대기 -> 스냅샷 -> 읽기' 등의 명령을 매번 쪼개어 전달하므로 턴 수(평균 85턴)와 비용이 크게 늘어납니다.
• MCP 방식은 브라우저 상호작용과 상태 반환을 단일 왕복(single round-trip)으로 결합하여 턴 수(평균 40턴)와 토큰 사용량을 혁신적으로 절감했습니다.

이 비용 문제를 극복하기 위해 향후 프롬프트 캐싱, 컨텍스트 압축, 스냅샷 빈도 최적화 같은 엔지니어링적 접근이 필수적입니다.

인프라의 중요성: MCP vs CLI

실험 결과를 보면 모델의 지능 자체만큼이나 실행 환경의 인프라 설계가 성공 여부를 가른다는 것을 알 수 있습니다.

• Playwright MCP는 에이전트에게 최적화된 구조화된 브라우저 프리미티브(예: 접근성 트리 스냅샷 제공)를 직접 제공하므로 에이전트가 화면 상태를 훨씬 명확하게 인식합니다. 또한 병렬 동시 실행이 쉬워 효율적입니다.
• Playwright CLI는 에이전트와 브라우저 사이에 셸이라는 추가 레이어가 끼어 있어 직렬 실행에 의존해야 하고 타이밍 이슈에 취약합니다.

테스트 피라미드 속 에이전틱 테스팅의 위치

에이전틱 테스팅은 기존 테스트 도구들을 파괴하고 대체하는 게임 체인저가 아닙니다. 대신 테스트 피라미드의 최상단 레이어를 새롭게 채워주는 상호보완적인 기술입니다.

가장 효과적인 미래의 테스트 전략은 하이브리드 모델입니다. 신속하고 안정적인 코드 검증이 필요한 빌드 파이프라인(CI)에는 전통적인 '결정론적 E2E 테스트'를 촘촘히 배치하고, 그 위에 사람이 직접 손으로 하던 복잡한 시나리오 분석, 버그 디버깅, 탐색적 테스트 영역에 '에이전틱 테스팅'을 적용하는 구조가 가장 이상적일 것입니다.