E2E 테스트의 고질적 문제, "취약한 스크립트"
UI 자동화 테스트를 운영해본 팀이라면 누구나 공감하는 문제가 있다. 버튼 하나 위치가 바뀌거나, CSS 클래스명이 수정되거나, 렌더링 순서가 달라지는 순간 수십 개의 테스트가 일제히 실패한다. Slack 엔지니어링팀이 직면한 문제도 동일했다. 분산 시스템 환경에서 빈번하게 발생하는 UI 변경은 고정 스크립트 기반 E2E 테스트의 유지보수 비용을 기하급수적으로 높였고, 정작 중요한 기능 개발보다 "테스트 수리"에 엔지니어 리소스가 소모되는 상황이 반복됐다.
기존 E2E 테스트는 element.click(), element.sendKeys() 같은 구체적인 UI 조작 시퀀스를 코드에 직접 박아 넣는 방식으로 작성된다. 이 방식은 시스템 상태가 예측 가능할 때는 강력하지만, 실제 프로덕션 환경처럼 변화가 잦은 곳에서는 스크립트 자체가 또 다른 레거시가 되어버린다.
의도(Intent) 기반 에이전트 테스트란 무엇인가
Slack이 도입한 에이전트 기반 테스트는 접근 방식 자체를 바꾼다. "3번째 메뉴 항목을 클릭하라"는 식의 고정 명령 대신, "채널에 메시지를 전송하라"는 의도(intent) 수준의 목표를 에이전트에게 전달한다. 에이전트는 런타임에서 현재 UI 상태를 인식하고, 목표를 달성하기 위한 구체적인 조작을 스스로 결정한다.
// 기존 방식 (고정 스크립트)
driver.findElement(By.cssSelector(".p-channel_sidebar__channel--active")).click();
driver.findElement(By.id("msg-input")).sendKeys("Hello");
// 에이전트 방식 (의도 기반 지시)
agent.execute("채널 목록에서 'general' 채널로 이동 후 'Hello' 메시지 전송");
이 구조에서 핵심은 에이전트가 UI 변경에 동적으로 적응한다는 점이다. 입력 필드의 ID가 바뀌거나 버튼의 위치가 이동해도, 에이전트는 의미적으로 동일한 요소를 재탐색하여 워크플로우를 완성한다. 결과적으로 UI 리팩토링이 테스트 실패로 직결되는 연결고리가 끊어진다.
기존 테스트 전략을 대체하지 않고 보완한다
중요한 점은 Slack이 이 접근법을 기존 테스트 피라미드의 대체재로 보지 않는다는 것이다. 단위 테스트와 통합 테스트는 여전히 결정론적(deterministic) 검증의 핵심이다. 특정 메서드가 올바른 값을 반환하는지, 두 컴포넌트 간 인터페이스가 계약을 지키는지 확인하는 데 에이전트는 오히려 불필요하다.
에이전트 기반 테스트가 강점을 발휘하는 영역은 사용자 시나리오 수준의 플로우 검증이다. 로그인 → 채널 전환 → 메시지 전송 → 알림 확인 같은 다단계 워크플로우는 각 단계의 UI 세부 사항이 자주 바뀌더라도 비즈니스 의도 자체는 변하지 않는다. 이런 시나리오에서 에이전트 테스트는 유지보수 부담 없이 높은 커버리지를 유지할 수 있다.
백엔드 개발자 관점에서도 시사점이 있다. API 응답이 프론트엔드 렌더링에 어떻게 반영되는지를 E2E 레벨에서 지속적으로 검증하는 비용이 낮아진다면, 백엔드 변경이 사용자 경험에 미치는 영향을 더 빠르게 피드백받을 수 있다.
정리
- 고정 스크립트 E2E 테스트의 취약성 문제는 UI 변경이 잦은 분산 시스템에서 특히 심각하며, 에이전트 기반 접근법은 이를 런타임 적응으로 해소한다.
- 에이전트 테스트는 단위·통합 테스트를 대체하는 것이 아니라, 사용자 시나리오 수준의 플로우 검증을 담당하는 보완 레이어로 포지셔닝된다.
- 의도 기반 지시 구조는 UI 세부 사항 변경에 따른 테스트 유지보수 비용을 줄여, 엔지니어가 실제 기능 품질 검증에 집중할 수 있도록 한다.