화면이 자주 바뀌는 서비스에서 테스트 작성이 밀린다면, TesterArmy의 e2e로 작은 기능 하나를 먼저 평가해 볼 만합니다. 자연어로 화면 조작을 맡기고, 결과는 코드의 명시적 검사로 확인하는 오픈소스 테스트 프레임워크입니다. 기존 테스트 전체를 옮기기보다 합성 데이터만 있는 스테이징에서 한 흐름을 나란히 비교하는 방법을 권합니다.
2026년 10월 15일 10:34 UTC에 확인한 GitHub Trending 주간 목록에는 tester-army/e2e가 누적 별 10,674개, 3,505 stars this week로 표시됐습니다. GitHub가 표시한 기간 지표이며 정확한 최근 7일의 실사용자 증가량은 아닙니다. Show HN 토론에는 기존 Gherkin·Cucumber 방식과 무엇이 다른지 묻는 댓글도 있습니다. 관심을 확인할 수 있지만, 적은 댓글이나 별 수로 신뢰성과 도입 성과를 판단할 수는 없습니다.
이 글은 10월 15일 공식 문서를 검토한 도입 가이드입니다. 직접 설치하거나 테스트를 실행하지 않았으며 재생 성공률·비용 절감률을 측정하지 않았습니다. 공식 소개는 2026년 10월 1일에 나왔고, 확인한 GitHub 릴리스는 10월 14일의 e2e@0.21.0입니다. 아직 1.0 이전으로 API와 설정이 바뀔 수 있습니다.
자연어 조작과 정확한 결과 검사를 한 테스트에
공식 저장소의 프로젝트는 TesterArmy가 만드는 Apache-2.0 라이선스 도구입니다. SDK·실행기·CLI 패키지 이름은 e2e입니다. 웹 엔진은 Playwright를 통해 브라우저를 다루고, 모바일 엔진은 iOS 시뮬레이터와 Android 에뮬레이터를 다룹니다. Python이나 Django 라이브러리는 아니지만, 그런 백엔드가 제공하는 웹 화면을 검사하는 데 검토할 수 있습니다.
핵심은 테스트의 어느 부분을 AI에 맡길지 선택하는 것입니다. agent.act는 ‘새 할 일을 추가한다’처럼 목표를 받아 화면을 조작합니다. 반면 저장된 항목의 이름과 상태처럼 정확히 확인할 수 있는 결과는 locator로 요소를 찾아 assertion으로 검사할 수 있습니다. AI가 목적지까지 가는 방법을 찾더라도, 팀이 원하는 결과의 정의는 테스트에 남기는 구성입니다.
작은 팀에서는 세 가지 용도를 생각해 볼 수 있습니다. 화면 배치가 자주 바뀌는 신규 기능의 스모크 테스트, 웹과 모바일에 공통으로 있는 사용자 흐름의 점검, 코딩 에이전트가 만든 변경을 별도 시나리오로 확인하는 작업입니다. 모두 활용 제안이며, 실제 앱에서 얼마나 안정적으로 동작하는지는 따로 평가해야 합니다.
첫 파일럿은 결제 대신 가상의 할 일 추가
예를 들어 스테이징의 작업 관리 화면에 ‘데모 문서 정리’라는 할 일을 하나 추가하는 흐름을 선택합니다. 고객 계정이나 실제 결제는 쓰지 않습니다. 다음은 실행 결과가 아니라 팀에서 시험할 순서입니다.
- 성공 조건을 먼저 고정합니다. 새 항목의 이름이 정확히 보이고 상태가 ‘진행 전’인지 검사합니다. ‘화면이 정상처럼 보인다’만으로 끝내지 않습니다.
- 조작 목표를 작게 나눕니다. 항목 생성과 담당자 변경을 한 문장에 묶기보다, 한 가지 결과 뒤에 검사를 둡니다. 실패했을 때 어느 목표가 어긋났는지 분리하기 쉽습니다.
- 같은 화면에서 반복합니다. 이전 데이터는 정리하고 시작 상태를 맞춥니다. 최초 실행과 다음 실행의 모델 호출 수, 재생 여부, 소요 시간, 수동 수정 내용을 기록합니다.
- 의도적으로 결과를 틀리게 만듭니다. 테스트용 브랜치에서 저장된 이름이나 상태가 잘못 나오게 한 뒤 검사가 실패하는지 확인합니다. 버튼 위치만 바꾼 경우와 업무 결과가 틀린 경우를 나눠 봅니다.
이 비교에서 얻고 싶은 것은 ‘AI가 한 번 통과했다’는 화면이 아닙니다. UI가 바뀌었을 때 고칠 일이 줄었는지, 잘못된 결과를 계속 잡아내는지, 재실행 비용을 설명할 수 있는지가 도입 판단의 근거입니다. 측정 전에는 빈 기록표로 두고 예상 수치를 채우지 않는 편이 좋습니다.
재생 캐시는 어디까지 모델 호출을 줄이나
공식 캐시 문서에 따르면, 뒤따르는 적합한 검사가 성공한 agent.act의 동작을 기록해 다음 실행에서 재생합니다. 단순히 테스트가 종료됐다는 사실만으로 기록되는 것은 아닙니다. locator assertion 같은 결과 검사를 붙이는 이유가 여기에 있습니다.
재생 중 화면 요소나 예상 결과가 맞지 않으면 기본 동작은 에이전트에게 제어를 넘기는 것입니다. 또한 agent.assert, agent.waitFor, agent.extract는 계속 실시간으로 실행됩니다. 내장 에이전트의 이런 판단에는 모델 호출이 들어가므로, ‘첫 실행 뒤에는 AI 비용이 없다’고 계산하면 안 됩니다.
strict-cache는 오래된 기록의 재생 실패를 REPLAY_STALE로 드러내는 선택지입니다. 모든 모델 호출을 막는 스위치는 아닙니다. 아직 기록되지 않은 단계, 불완전한 기록, 저장소 읽기 실패 등은 여전히 실시간 실행으로 이어질 수 있습니다. 파일럿에서는 성공 여부와 함께 replayed·handed off·missed, 모델 호출 수를 읽어야 합니다.
로컬 실행에서도 화면 정보의 목적지를 확인
공식 보안 문서는 모델이 지시문, 접근성 트리로 표현한 화면 내용, 마스킹한 URL, 앞선 단계 기록을 본다고 설명합니다. 요청하거나 vision을 켠 단계에서는 허용된 경우 마스킹한 스크린샷도 전달됩니다. 등록된 Secret을 입력한 뒤에는 해당 시도의 스크린샷이 차단됩니다. 로컬 실행기를 사용해도 외부 모델을 선택하면 해당 공급자로 정보가 나갑니다.
등록한 Secret 보호가 모든 자료에 적용되는 것은 아닙니다. 비디오와 바이너리 다운로드는 마스킹하지 않으며, 앱의 command.log에는 표준 출력·오류가 그대로 남습니다. 일반 문자열로 입력한 값도 자동으로 비밀값이 되지 않습니다. 테스트 산출물은 공유 전에 따로 확인해야 합니다.
문서에는 origin allowlist가 없다고 명시돼 있습니다. 에이전트가 다른 사이트로 이동할 수 있으며, 테스트·설정·도구 등은 실행 계정의 OS 권한으로 동작합니다. 따라서 첫 평가 범위를 합성 데이터와 제한된 테스트 계정으로 좁히고, 신뢰하지 않는 PR은 비밀값·쓰기 토큰 없는 외부 격리 환경에서 다루는 것이 중요합니다.
시작 조건과 기존 Playwright를 남길 이유
시작 안내는 Node.js 24.8 이상 또는 Node.js 22 계열의 22.22.3 이상을 요구하며, Windows에서는 WSL을 안내합니다. 모바일은 별도 SDK와 시뮬레이터·에뮬레이터 준비가 필요합니다. 첫 평가는 웹 대상 하나로 좁히면 환경 문제와 테스트 설계 문제를 구분하기 쉽습니다.
공식 초기화 도구는 엔진과 모델 공급자를 선택하고 설정·예제·의존성을 준비합니다. AI 없는 기본 예제부터 확인한 뒤 필요한 목표에만 모델을 붙이는 순서가 가능합니다. 오픈소스 라이선스와 실행 비용은 별개입니다. 선택한 모델의 요금·구독 제한, 로컬 모델의 자원 요구, 선택한 호스팅 서비스 비용을 각각 확인하세요. CLI의 기본 텔레메트리와 선택 해제 방법도 전송 항목 안내에서 확인할 수 있습니다.
이미 안정적인 Playwright 테스트가 있다면 그대로 남길 이유가 충분합니다. 공식 이전 안내도 두 실행기를 나란히 두고 파일 단위로 옮기는 방식을 설명합니다. 설정과 파일 패턴을 구분해야 하고, API가 그대로 호환되는 교체품은 아닙니다.
권하는 출발점은 기존 릴리스 검사를 유지한 채, 새 흐름 하나를 별도 실험으로 추가하는 것입니다. 잘못된 결과를 놓치거나 호출 비용·산출물 노출을 통제하기 어렵다면 확장을 멈춥니다. 별은 살펴볼 계기를 주지만, 도입 결정은 우리 앱의 실패를 제대로 보여 주는지에 달려 있습니다.
댓글
댓글 쓰기